Re: Authentication failures on a RHEL 9.2 IPA server

[Rob Crittenden]

Charles Hedrick via FreeIPA-users wrote:
> 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.

Ranges are global, not per-server. So assuming your ranges are ok and
there are no overlaps for the IDs or RID ranges this is probably ok, but
I'm not a PAC expert.

I think what you're seeing is the DNA  (Distributed Numeric Assignment)
plugin at work.

On the first installed server, DNA has the full range of id_range values
to generate UIDs and GIDs. The first time a replica needs to generate a
UID/GID it requests a range and gets half of the allocation. A replica
does not automatically get a range on install. The more servers you have
AND the more replicas you've added entries on, the smaller the available
ranges may be. You can use ipa-replica-manage to display and manipulate
the ranges.

rob
> *From:* Sam Morris via FreeIPA-users 
> *Sent:* Monday, May 15, 2023 8:08 AM
> *To:* FreeIPA users list 
> *Cc:* Alexander Bokovoy ; Sam Morris
>
> *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
> > > 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/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: [e-mail] for
> > > > krbtgt/[e-mail], 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Authentication failures on a RHEL 9.2 IPA server

[Charles Hedrick]

ipa id-range-find didn't find the ranges on the other servers after I added them on one. It found the primary ranges (managed by ipa-replica-manage) on all 3 systems, but of course they are different.

________________________________
From: Rob Crittenden 
Sent: Monday, May 15, 2023 4:15 PM
To: FreeIPA users list 
Cc: Sam Morris ; Alexander Bokovoy ; Charles Hedrick 
Subject: Re: [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server

Charles Hedrick via FreeIPA-users wrote:
> 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.

Ranges are global, not per-server. So assuming your ranges are ok and
there are no overlaps for the IDs or RID ranges this is probably ok, but
I'm not a PAC expert.

I think what you're seeing is the DNA  (Distributed Numeric Assignment)
plugin at work.

On the first installed server, DNA has the full range of id_range values
to generate UIDs and GIDs. The first time a replica needs to generate a
UID/GID it requests a range and gets half of the allocation. A replica
does not automatically get a range on install. The more servers you have
AND the more replicas you've added entries on, the smaller the available
ranges may be. You can use ipa-replica-manage to display and manipulate
the ranges.

rob
> *From:* Sam Morris via FreeIPA-users 
> *Sent:* Monday, May 15, 2023 8:08 AM
> *To:* FreeIPA users list 
> *Cc:* Alexander Bokovoy ; Sam Morris
>
> *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: [e-mail] for
> > > > krbtgt/[e-mail], 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue