On Tue, Oct 10, 2023 at 2:48 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On Пан, 09 кас 2023, Johnnie W Adams via FreeIPA-users wrote:
Hi, folks,
We've got a small shop with around a hundred RHEL boxes and a small
user base currently authenticating against LDAP using one user naming scheme. Our plan is to migrate these to freeipa (actually Red Hat IdM)
with
a one-way trust with AD using a different naming scheme. I'm trying to juggle in my head exactly how to sequence the needed activities to do
this.
Where users would be coming from for the new environment? IPA? AD? Are these users that have been in your LDAP server in past are in reality AD users?
They're in LDAP now. They would ultimately be AD users. My plan was to manually provision them into IPA/IdM. However...
If they would come from AD, then you don't copy users from LDAP to IPA at all but you'd create user ID overrides that have the same POSIX attributes as they had in the old setup in LDAP.
...I think you just told me that's the wrong way to do it.
If users came from AD and LDAP server was used as a stop-gap solution to represent them, then to use trust to AD one should make sure these users do not exist in IPA as normal users. AD users get handled by AD domain controllers, not IPA, so they must not overlap with IPA users. Instead, POSIX attributes for them would be stored in user ID overrides in IPA and authentication will be handled by AD DCs. ID overrides themselves aren't users or groups, they are placeholders to store POSIX info. However, SSSD which will synthesize AD user / group information will use details from AD LDAP and IPA ID overrides from 'Default Trust View' to create POSIX identities.
It is important to understand this part because that defines your next steps.
In both cases you need to know POSIX ID range for these users. Below 'base ID' of the range refers to the lowest POSIX ID used. Ideally it should be something above 1000 as the values below are used by system accounts and should not be used by normal users. There are certain assumptions in the code here and there about minimal ID limit.
Most of our accounts have nice high UIDs (>65536), but four of them have low numbers (2xxx) which I'm planning to fix while I have the systems in maintenance.
Users originally came from AD:
At this point, I'm slightly confused. Our current users are in LDAP and have naming schemes like ja9. Part of the plan is to harmonize those usernames with the AD naming scheme of names like jxadams, if possible.
- install IPA with default settings
configure trust to AD but use ipa-ad-trust-posix range type and specify the base ID of the range and size of the possible range
iterate over old users LDAP data and add user ID overrides to 'Default Trust View' for each of AD user to make sure they have POSIX attributes to be used by SSSD.
Users originally came from LDAP and have no overlap with AD users:
install IPA with that range to specify to ipa-server-install, e.g. --idstart='base ID' --idmax='base ID + size of the range'. This way you'd have the same range in use as for the original UID/GIDs and no need to do step (2) from your list.
add IPA users via 'ipa migrate-ds' from LDAP server. Just make sure
you read carefully through
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
What I'd like to do is this, which I believe will require a
moratorium
on user logons:
1) Provision IdM manually with new usernames and old UIDs. 2) Rename and chown home directories on the servers. 3) Join the servers to freeipa (IdM). 4) Establish a one-way trust with AD. This seems like the logical course of events, but the gap between 3
and 4 worries me.
Thanks,
John A
-- John Adams Senior Linux/Middleware Administrator | Information Technology Services +1-501-916-3010 | jxadams@ualr.edu | http://ualr.edu/itservices *UA Little Rock*
Reminder: IT Services will never ask for your password over the phone or in an email. Always be suspicious of requests for personal information
that
come via email, even from known contacts. For more information or to report suspicious email, visit IT Security http://ualr.edu/itservices/security/.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland