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 me@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 <abokovoy@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 <abokovoy@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: me@MYDOMAIN.LOC
>> >
>> >Valid starting       Expires              Service principal
>> >12/30/2021 18:04:03  12/31/2021 18:03:46
>> > cifs/samba.server.mydomain.loc@MYDOMAIN.LOC
>> >12/30/2021 18:04:02  12/31/2021 18:03:46
>> > nfs/samba.server.mydomain.loc@MYDOMAIN.LOC
>> >12/30/2021 18:03:49  12/31/2021 18:03:46  krbtgt/MYDOMAIN.LOC@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
>> >me@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 <bugs@centos.org> -
>> 4.6.8-5.el7.centos.10
>> >- Roll in CentOS Branding
>> >
>> >* Thu Dec 02 2021 Florence Blanc-Renaud <frenaud@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 <asn@redhat.com> - 4.10.16-17
>> >- related: #2019673 - *Add missing checks for IPA DC server role*
>> >
>> >* Mon Nov 08 2021 Andreas Schneider <asn@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