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(a)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(a)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(a)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
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland