On Аўт, 10 кас 2023, Johnnie W Adams wrote:
On Tue, Oct 10, 2023 at 2:48 AM Alexander Bokovoy <aboko...@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.
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/html/migrating_to_identity_management_on_rhel_8/migrating-from-an-ldap-directory-to-idm_migrating-to-idm-from-external-sources#doc-wrapper
>
> 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 | jxad...@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 | jxad...@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
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
