On Срд, 24 сту 2024, Harald Dunkel wrote:
Hi Alex,
On 2024-01-24 08:13:44, Alexander Bokovoy wrote:
On Аўт, 23 сту 2024, Harald Dunkel wrote:
I found one problem by now: Regular UIDs start with 501 in my environment, for historical reasons. The GIDs are >=1000. When we migrated from good ol' yellow pages to FreeIPA there was no problem with small UIDs. And in the BSD and SYSV years before Linux only the UIDs <100 were reserved for system.
Do I have to migrate the existing users between 501 and 999 to new UIDs
1000? I would like to see an error message showing that this is indeed the
problem, first. Surely I would prefer to just adjust the ID ranges instead of migrating about 90 user accounts.
What would you suggest?
You can add a new local ID range to cover existing UIDs/GIDs. Make sure to set base RID and secondary base RID when defining a new ID range.
See https://access.redhat.com/articles/7027037 for details.
ACK. One question, though: Shouldn't the
ipa config-mod --enable-sid --add-sids
I had run set the missing ipantsecurityidentifier entries at least for the users matching the existing address range from 1000 to 99999? It didn't, AFAICT. It didn't show an error message, either.
Looking at the changes between the previously installed freeipa packages and the version I have right now I got
# rpm -q --changelog ipa-server
- Fri Dec 01 2023 Julien Rische jrische@redhat.com - 4.9.12-11
- Generate Kerberos PAC as soon as server installation completed
Resolves: RHEL-16532
- Thu Nov 16 2023 Julien Rische jrische@redhat.com - 4.9.12-10
- ipa-kdb: Detect and block Bronze-Bit attacks
Resolves: RHEL-16532
- Fix for CVE-2023-5455
Resolves: RHEL-12577
- Wed Oct 04 2023 Julien Rische jrische@redhat.com - 4.9.12-9
: :
4.9.12-9 was the previous version. It worked fine. Fixing the CVEs was the reason for the upgrade. Kerberos authentication is fine in the new setup, too. How comes these changes triggered the problem about missing ipantsecurityidentifier entries? Is this as intended?
Yes, it was intended. Bronze-bit (CVE-2020-17049) is about Kerberos constrained delegation (S4U extensions). S4U Kerberos extensions require presence of MS-PAC structures in Kerberos tickets and to generate MS-PAC we have to have SIDs. This was already enforced in MIT Kerberos 1.20+ in RHEL 9 for quite some time.
New RHEL IdM deployments do have SIDs associated with user/group accounts since RHEL 8.5. If you have older installations, you might not have them. If you have earlier established trust to Active Directory, your IPA configuration might already permit generating SIDs for new users since ~2013. Still, some user and group accounts from 'legacy' configurations might not have them and those will be denied accessing any Kerberos resources protected with constrained delegation. IPA API is one such resource.
As discussions on this mailing list show, there are plenty of edge cases, mostly around 'legacy' UID/GIDs and missing ID ranges that would have covered those IDs. Or ID ranges missing SID-specific attributes (base RID and secondary base RID) that prevent use of those ranges to generate SIDs.
KCS https://access.redhat.com/articles/7027037 describes a lot of those details, so I would recommend reading through it and investigating your ID range configuration based on those details.
We also have upstream document that outlines ID mapping usage in FreeIPA: https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html