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 abokovoy@redhat.com; Sam Morris sam@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:
- Removed the ipantsecurityidentifier attribute from a user, and removed ipantuserattrs from the user's objectclass
- Tried to log in as the user & got the same failures + 'No such file or directory' message in /var/log/krb5kdc.log
- Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true' within the realm-specific configuration in the realms section
- Restarted krb5kdc
- 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/htm...
RHEL 8: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
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: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@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-leave@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.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue