I got my test servers working properly. But when I did my first production server, I ran
into problems that might affect others:
Unlike the test, for the primary migration I wanted to generate SIDs before doing the
upgrade, to minimize downtime after the upgrade. In testing, I used "ipa config-mod
--add-sids --enable-sid" on an upgraded (RHEL 9.2) server. It worked fine once I got
the necessary idranges set up. However on the production service "ipa config-mod
--add-sids --enable-sid" was done under RHEL 9.0 with IPA 4.9.8. It gave an error
when there was a UID and GID with the same numeric value. In the new version, it used the
secondary SID, but not always with the old version. I had to set the SIDs manually in some
cases.
This is simply a warning for people trying the same thing. Error messages occur in
/var/log/dirserv/.../errors. There's no sign from the command line of any problems.
________________________________
From: Charles Hedrick via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
Sent: Monday, May 15, 2023 4:33 PM
To: Rob Crittenden <rcritten(a)redhat.com>; FreeIPA users list
<freeipa-users(a)lists.fedorahosted.org>
Cc: Sam Morris <sam(a)robots.org.uk>; Alexander Bokovoy <abokovoy(a)redhat.com>;
Charles Hedrick <hedrick(a)rutgers.edu>
Subject: [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server
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 <rcritten(a)redhat.com>
Sent: Monday, May 15, 2023 4:15 PM
To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
Cc: Sam Morris <sam(a)robots.org.uk>; Alexander Bokovoy <abokovoy(a)redhat.com>;
Charles Hedrick <hedrick(a)rutgers.edu>
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 <freeipa-users(a)lists.fedorahosted.org>
*Sent:* Monday, May 15, 2023 8:08 AM
*To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
*Cc:* Alexander Bokovoy <abokovoy(a)redhat.com>; Sam Morris
<sam(a)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/...
>
> RHEL 8:
>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
>
> 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(a)EXAMPLE.COM for
> > > krbtgt/EXAMPLE.COM(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue