On Аўт, 10 кас 2023, Johnnie W Adams wrote:
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 smalluser 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.
Ok, so there is no big problem then. You can follow my 'recipe' below:
- 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.
User names' change (ja9 -> jxadams@ad.domain) would be something that would need to be taken care of with the ID override creation. You can, technically, do an ID override for the name as well but I'd rather do it with UID/GID and the rest of properties but the name.
$ ipa help idoverrideuser-add Usage: ipa [global-options] idoverrideuser-add IDVIEW ANCHOR [options]
Add a new User ID override. Options: -h, --help show this help message and exit --desc=STR Description --login=STR User login --uid=INT User ID Number --gecos=STR GECOS --gidnumber=INT Group ID Number --homedir=STR Home directory --shell=STR Login shell --sshpubkey=STR SSH public key --certificate=CERTIFICATE Base-64 encoded user certificate --setattr=STR Set an attribute to a name/value pair. Format is attr=value. For multi-valued attributes, the command replaces the values already present. --addattr=STR Add an attribute/value pair. Format is attr=value. The attribute must be part of the schema. --fallback-to-ldap Allow falling back to AD DC LDAP when resolving AD trusted objects. For two-way trusts only. --all Retrieve and print all attributes from the server. Affects command output. --raw Print entries as stored on the server. Only affects output format. --no-members Suppress processing of membership attributes.
For user jxadams@ad.domain that was ja9 before and had UID 12345 and GID 54321, with home directory /home/ja9 and shell /bin/bash, then we would have something like the call below:
$ ipa idoverrideuser-add 'Default Trust View' jxadams@ad.domain \ --uid 12345 --gidnumber 54321 \ --homedir /home/ja9 --shell /bin/bash
This way you wouldn't need to change file permissions for all files used by existing users even though they'd be resolved through IPA and trust to AD. File permissions stored with UID/GID values, not names. Same for POSIX ACLs -- Linux file systems use extended attributes to store POSIX ACLs and those use UID/GID values too.
You'd be left with textual representation of the user and group names in various configuration files. Since you are already planning to replace user names (ja9 -> jxadams@ad.domain), I hope you have taken those into account already.
The ID range for a trusted AD domain is important to have set up properly when creating the trust because it would help you avoiding management issues later. Within that range things can be overridden using ID overrides, however, SSSD needs to know the range boundaries for a specific domain.
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 amoratorium
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 3and 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
-- 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/.