Turns out this was not the end :) Fully acknowledging that my config is not supported, I'd like to try out if anyone knows how I can fix the current issue.
Linux clients are just fine now. The problem is with Windows clients - user mapping doesn't work anymore. Password check passes but after that users get a new profile. My IPA domain name is DOMAIN.LOC. After I set up SIDs for IPA accounts, PAC record generated by IPA adds "logon_domain: DOMAIN" value, but the default realm is set to DOMAIN.LOC with ksetup. I think this confuses Windows - whoami returns "DOMAIN\me" (instead of LOCALPC\me). I can probably live with this (just need to move user profiles into new directories), but it would be nice to make mapping work correctly again. I tried playing with ksetup: * added another non-default kerberos realm DOMAIN * added explicit mapping of me@DOMAIN and m...@domain.loc to me instead of "* *", tried changing computer's work group from DOMAIN.LOC to DOMAIN (which changes little if anything), and tried changing ipantflatname (which can't be changed, at least not with ipa trustconfig-mod). What else can I try? Thanks! пт, 31 дек. 2021 г. в 12:06, Alexander Bokovoy <aboko...@redhat.com>: > On pe, 31 joulu 2021, Konstantin M. Khankin wrote: > >Thanks for your help Alexander! > > > >Turns out my exact problem was this <https://narkive.com/rCnXSfSy.6>. > > Glad that you found a way to fix your ranges to generate SIDs. > > > > >> Anyway, the scenario you are running is not supported by FreeIPA team. > > > >Could you please educate me which scenario is supported? Or is it not > >supported only because of RHEL 7 / CentOS 7? > > FreeIPA is not providing domain controller services for Windows clients, > regardless of their version. Regardless of RHEL version, this is not > planned and not supported. > > Whatever appears to work for you with a standalone Windows client logon > with IPA accounts, it is *not* something that is supported and not > guaranteed to continue working. > > If you need to enroll Windows systems to some non-Microsoft-provided > Active Directory, you can use Samba AD DC for that and then establish > trust with FreeIPA forest. However, enrolling Windows machines to > FreeIPA is not planned and is not supported. Also, current FreeIPA > versions do not support login to Windows systems in a trusted Active > Directory forest. The latter is being worked on. > > > > >Happy New Year! :) > > > > > >чт, 30 дек. 2021 г. в 20:03, Alexander Bokovoy <aboko...@redhat.com>: > > > >> On to, 30 joulu 2021, Konstantin M. Khankin via FreeIPA-users wrote: > >> >Hello! > >> > > >> >I have several SMB shares served by Samba using Kerberos accounts > managed > >> >by FreeIPA. I have no AD integrations and no AD itself. Windows clients > >> are > >> >configured using this > >> ><https://www.freeipa.org/page/Windows_authentication_against_FreeIPA> > >> >guide, linux clients use ipa-client and "smbclient -k". Servers and > linux > >> >clients use CentOS 7. > >> > >> This method is not supported, as stated multiple times on this very > >> least for the past several years. > >> > >> > > >> >Today I received updates for ipa-* (to 4.6.8-5.el7.centos.*10* from > >> >4.6.8-5.el7.centos.*9*) and samba-* (to 4.10.16-*17*.el7_9 from > >> >4.10.16-*15*.el7_9) > >> >packages and authentication broke, no clients can connect to shares > >> >anymore. Here are logs from linux client: > >> > > >> >$ klist > >> >Ticket cache: KEYRING:persistent:1696200001:1696200001 > >> >Default principal: m...@mydomain.loc > >> > > >> >Valid starting Expires Service principal > >> >12/30/2021 18:04:03 12/31/2021 18:03:46 > >> > cifs/samba.server.mydomain....@mydomain.loc > >> >12/30/2021 18:04:02 12/31/2021 18:03:46 > >> > nfs/samba.server.mydomain....@mydomain.loc > >> >12/30/2021 18:03:49 12/31/2021 18:03:46 > krbtgt/mydomain....@mydomain.loc > >> > > >> >$ smbclient -k -L //samba.server.mydomain.loc > >> >session setup failed: NT_STATUS_NO_IMPERSONATION_TOKEN > >> > > >> >Server logs: > >> > > >> >*log.smbd:* > >> >[2021/12/30 19:03:23.597495, 2] > >> >../../source3/lib/smbldap.c:847(smbldap_open_connection) > >> > smbldap_open_connection: connection opened > >> >[2021/12/30 19:03:23.695598, 3] > >> >../../source3/lib/smbldap.c:1069(smbldap_connect_system) > >> > ldap_connect_system: successful connection to the LDAP server > >> >[2021/12/30 19:03:23.737401, 1] ipa_sam.c:4896(pdb_init_ipasam) > >> > pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain > >> >mydomain.loc > >> >[2021/12/30 19:03:23.737597, 3] > ../../lib/util/access.c:365(allow_access) > >> > Allowed connection from 192.168.10.1 (192.168.10.1) > >> > > >> >*log.192.168.10.1:* > >> >... > >> >[2021/12/30 19:05:22.458992, 3] > >> >../../source3/smbd/negprot.c:776(reply_negprot) > >> > Selected protocol SMB 2.??? > >> >[2021/12/30 19:05:22.459495, 3] > >> > >../../source3/smbd/smb2_negprot.c:293(smbd_smb2_request_process_negprot) > >> > Selected protocol SMB3_11 > >> >[2021/12/30 19:05:22.524677, 3] > >> >../../auth/kerberos/gssapi_pac.c:123(gssapi_obtain_pac_blob) > >> > gssapi_obtain_pac_blob: obtaining PAC via GSSAPI > gss_get_name_attribute > >> >failed: The operation or option is not available or unsupported: No > such > >> >file or directory > >> >[2021/12/30 19:05:22.524750, 1] > >> >../../auth/gensec/gensec_util.c:70(gensec_generate_session_info_pac) > >> > gensec_generate_session_info_pac: Unable to find PAC in ticket from > >> >m...@mydomain.loc, failing to allow access > >> >[2021/12/30 19:05:22.524784, 3] > >> >../../source3/smbd/smb2_server.c:3213(smbd_smb2_request_error_ex) > >> > smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] > >> >status[NT_STATUS_NO_IMPERSONATION_TOKEN] || at > >> >../../source3/smbd/smb2_sesssetup.c:146 > >> >[2021/12/30 19:05:22.525565, 3] > >> >../../source3/smbd/server_exit.c:236(exit_server_common) > >> > Server exit (NT_STATUS_END_OF_FILE) > >> > > >> >Googling, source-digging and "log level = 5" were not helpful. > However, I > >> >find changelogs somewhat interesting: > >> > > >> >$ rpm -q --changelog ipa-server | head > >> >* Thu Dec 16 2021 CentOS Sources <b...@centos.org> - > >> 4.6.8-5.el7.centos.10 > >> >- Roll in CentOS Branding > >> > > >> >* Thu Dec 02 2021 Florence Blanc-Renaud <fren...@redhat.com> - > >> >4.6.8-5.el7_9.10 > >> >- Resolves: 2025848 - RHEL 8.6 IPA Replica Failed to configure PKINIT > >> setup > >> >against a RHEL 7.9 IPA server > >> > - Fix cert_request for KDC cert > >> >- Resolves: 2021444 - CVE-2020-25719 ipa: samba: *Samba AD DC did not > >> >always rely on the SID and PAC in Kerberos tickets* > >> > - SMB: switch IPA domain controller role > >> > > >> >$ rpm -q --changelog samba | head > >> >* Mon Nov 15 2021 Andreas Schneider <a...@redhat.com> - 4.10.16-17 > >> >- related: #2019673 - *Add missing checks for IPA DC server role* > >> > > >> >* Mon Nov 08 2021 Andreas Schneider <a...@redhat.com> - 4.10.16-16 > >> >- resolves: #2019661 - Fix CVE-2016-2124 > >> >- resolves: #2019673 - Fix CVE-2020-25717 > >> >- resolves: #2021428 - *Add missing PAC buffer types to krb5pac.idl* > >> > > >> >I don't have access to the mentioned bugs in Bugzilla unfortunately. > Maybe > >> >someone knows if I need to do something after upgrading these packages? > >> > >> You need to make sure IPA has issued proper SIDs to all your users. > >> This can be achieved with 'ipa-adtrust-install --add-sids' ran on IPA > >> server owning Trust Controller role. Once SID is present in the user's > >> entry, its presence will force IPA KDC to issue PAC as a part of a TGT > >> and it will be copied to a service ticket requested by a client which > >> presented this TGT, unless the target service object in IPA forbids that > >> (only NFS so far). > >> > >> IPA update on RHEL 7.9 does not have additional logic which went into > >> security updates IPA on RHEL 8.4+ and Fedora to issue SIDs at install > >> time (and additional tools to make up for missing SIDs). It also does > >> not have the code to enforce some of new buffers in PACs as backporting > >> them was not feasible. > >> > >> Regarding what this is all about, I have a blog in works about it but > >> now is holidays' time. Below I'd give you few references to read to get > a > >> glimpse of what we dealt with: > >> > >> --------------------------------------------------------- > >> On November 9th 2021 Microsoft did their traditional monthly security > >> update. Four issues among the published security fixes were in the area > >> of Active Directory and were attributed to Samba Team and its members: > >> > >> - CVE-2021-42291: Active Directory Domain Services Elevation of > >> Privilege Vulnerability, Active Directory permissions updates, > >> > >> > https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42291 > >> > >> - CVE-2021-42287: Active Directory Domain Services Elevation of > >> Privilege Vulnerability, Authentication updates, > >> > >> > https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42287 > >> > >> - CVE-2021-42282: Active Directory Domain Services Elevation of > >> Privilege Vulnerability, Verification of uniqueness for user > >> principal name, service principal name, and the service principal > >> name alias, > >> > >> > https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42282 > >> > >> - CVE-2021-42278: Active Directory Domain Services Elevation of > >> Privilege Vulnerability, Active Directory Security Accounts Manager > >> hardening changes, > >> > >> > https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42278 > >> > >> A coordinated security release of Samba 4.15.2 by the Samba Team fixes > >> eight security issues, some of them around the same theme as Microsoft's > >> ones: > >> > >> - CVE-2016-2124: SMB1 client connections can be downgraded to > >> plaintext authentication, > >> https://www.samba.org/samba/security/CVE-2016-2124.html (Something > >> left from the Badlock bugs) > >> > >> - CVE-2020-25717: A user on the domain can become root on domain > >> members, https://www.samba.org/samba/security/CVE-2020-25717.html, > >> (PLEASE READ! There are important behaviour changes described) > >> > >> - CVE-2020-25718: Samba AD DC did not correctly sandbox Kerberos > >> tickets issued by an RODC, > >> https://www.samba.org/samba/security/CVE-2020-25718.html > >> > >> - CVE-2020-25719: Samba AD DC did not always rely on the SID and PAC > in > >> Kerberos > >> tickets,https://www.samba.org/samba/security/CVE-2020-25719.html > >> > >> - CVE-2020-25721: Kerberos acceptors need easy access to stable AD > >> identifiers (eg objectSid), > >> https://www.samba.org/samba/security/CVE-2020-25721.html > >> > >> - CVE-2020-25722: Samba AD DC did not do sufficient access and > >> conformance checking of data stored, > >> https://www.samba.org/samba/security/CVE-2020-25722.html > >> > >> - CVE-2021-3738: Use after free in Samba AD DC RPC server, > >> https://www.samba.org/samba/security/CVE-2021-3738.html > >> > >> - CVE-2021-23192: Subsequent DCE/RPC fragment injection vulnerability, > >> https://www.samba.org/samba/security/CVE-2021-23192.html > >> > >> The scope of changes is enormous. Just on the Samba side there are 220 > >> patches between 4.15.2 and the previous minor release, 4.15.1. However, > >> Samba 4.15.1 release was a preparation -- it also merged some 3000 > >> patches, establishing a ground for testing Kerberos protocol behavior. > >> These tests helped to reduce behavior differences between Samba AD and > >> Windows-based Active Directory deployments and made the security release > >> possible at all. > >> > >> --------------------------------------------------------- > >> > >> > >> Anyway, the scenario you are running is not supported by FreeIPA team. > >> > >> > > >> >Rolling back samba packages is unwanted given that Samba sources > mention > >> >this is unsafe. > >> > > >> >Thanks! > >> > > >> >-- > >> >Konstantin Khankin > >> > >> > >> > >> > >> -- > >> / Alexander Bokovoy > >> Sr. Principal Software Engineer > >> Security / Identity Management Engineering > >> Red Hat Limited, Finland > >> > >> > > > >-- > >Konstantin Khankin > > > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > > -- Konstantin Khankin
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
