OK, so I see the answer to my problem is to run ipa config-mod --add-sids --enable-sid
But we have old UIDs that with low numbers. It looks like I need to do ipa idrange-add CS.RUTGERS.EDU_low_id_range --base-id=1 --range-size=200000 --rid-base=200000000 --secondary-rid-base=300000000 ipa idrange-add CS.RUTGERS.EDU_mid_id_range --base-id=600000 --range-size=200000 --rid-base=400000000 --secondary-rid-base=500000000 In order for ipa user-add for those UIDs to work on any system, presumably I have to do that on all IPA servers. Is that OK? I'm assuming new id's where we don't specify a UID will be put in the same range before, which is different on each server. ________________________________ From: Sam Morris via FreeIPA-users <freeipa-users@lists.fedorahosted.org> Sent: Monday, May 15, 2023 8:08 AM To: FreeIPA users list <freeipa-users@lists.fedorahosted.org> Cc: Alexander Bokovoy <aboko...@redhat.com>; Sam Morris <s...@robots.org.uk> Subject: [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via FreeIPA-users wrote: > On su, 14 touko 2023, Sam Morris wrote: > > On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users > > wrote: > > > I wonder about the root cause; is this because MIT Kerberos 1.20 always > > > wants to include a PAC in its issued TGTs, and it gives up if it can't > > > retrieve a user's SID from the directory? (If so I wonder if setting > > > disable_pac = true in the realm section of krb5.conf would have worked > > > around the problem?) > > > > This seems to be the case. Specifically I: > > > > 1. Removed the ipantsecurityidentifier attribute from a user, and > > removed ipantuserattrs from the user's objectclass > > 2. Tried to log in as the user & got the same failures + 'No such file > > or directory' message in /var/log/krb5kdc.log > > 3. Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true' > > within the realm-specific configuration in the realms section > > 4. Restarted krb5kdc > > 5. Tried to log in as the user and it worked! > > > > The docs for disable_pac say: > > > > If true, the KDC will not issue PACs for this realm, and S4U2Self > > and S4U2Proxy operations will be disabled. The default is false, > > which will permit the KDC to issue PACs. New in release 1.20. > > > > ... which doesn't explain that if the KDC can't issue a PAC for some > > reason then the KDC will fail to issue the TGT. But at least I've gotten > > to the bottom of things now. :) > > RHEL IdM documentation has a separate chapter related to it. > > RHEL 9: > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts > > RHEL 8: > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts > > This documentation is in place since summer 2022. Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos in IdM requires that your IdM objects have SIDs, which are necessary for security based on Privilege Access Certificate (PAC) information.", but I had no problems with authentication on my RHEL 8.6/8.7 servers... > > > "After upgrading, krb5kdc may fail to issue TGTs to users who have not > > > had a SID assigned to their accounts ('ipa user-show user --all' will > > > not include an ipantsecurityidentifier attribute). In this case > > > krb5kdc.log will log a message "HANDLE_AUTHDATA: u...@example.com for > > > krbtgt/example....@example.com, No such file or directory". This can be > > > fixed by running 'ipa config-mod --enable-sid --add-sids' as an IPA > > > admin on another IPA server." > > > > ... "or on the same server after temporarily setting "disable_pac = > > true" in kdc.conf, and restarting krb5kdc." > > You should not be disabling PAC because you are really setting yourself > up to an attack with a known exploit out in a wild. Absolutely--I just wanted to document what I'd found out, because there isn't a clear connection documented between the behaviour in RHEL 9.2 with MIT Kerberos 1.20 and the behaviour seen when your IPA users don't have SIDs assigned. -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9 _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
