1:31 p.m.
On Thu, Apr 19, 2018 at 8:14 AM, John Hearns <hearnsj(a)googlemail.com> wrote:
I think this question must be asked many times. So forgive me. We
have an existing set of Unix usernames/uids which are pushed out
onto the client workstations vi a configuration management
system. Ie there are local /etc/passwd files which are updated when
new users joint he company. the uid range is 1000 to 3000
If we start to use sssd with AD authentication and the AD RID
mapping, then different UIDs will be reported.
We do not wish to use the Posix attributes - the whole point is to
reduce the manual steps needed when new accounts are created.
So my questions are:
a) is there any way to map AD RID style UIDs to existing UIDs (I
have tried to search for this)
b) other orgnisations have faced this. Is the only answer a script
to chown each users files if they are transitioned over to AD?
We faced this same situation: we had a configuration management system
that was maintaining information for user accounts in /etc/passwd and
/etc/group, but we wanted to transition to mapping passwd/group data
via sssd via AD, using sssd's RID-based id mapping.
Our solution was to perform a gradual transition:
1. On all hosts, we configured /etc/nsswitch.conf with "files sss" for
the passwd/group databases. This means that if a user has a local
account in the passwd/group files, that account will be used
instead of the sssd mapping.
2. For all new hosts we build, we don't push any user accounts to the
passwd/group files; i.e., the /etc/passwd and /etc/group files
contain only system accounts. So on new hosts, the sssd mappings
will always be used, for all users.
3. For new users who join our organization, we no longer push out
manual passwd/group entries to legacy hosts. So new users who log
into legacy hosts will receive sssd passwd/group mappings, but old
users who already had entries in the passwd/group files will
continue to use those mappings.
4. Over time, as legacy hosts rot off, gradually all hosts will be
providing user passwd/group information solely via sssd mapping.
For us, this was the only feasible way to transition, as we have
terabytes of local data spread across millions of files. So, manually
chowning all files on all filesystems on all hosts was an intractable
problem.
Also a question about pam_mkhomedir I have used this successfully in
the past, on a BeeGFS filesystem where all the clients have
read/write access. If the workstation is an NFS client, then
creating a new home directory for a user should not be possible,
given that root squash is configured on the NFS share.
Is there a smart way to get pam_mkhomedir to work on an NFS client
system? Or perhaps the user needs to log into the NFS server system
one time only (assuming logins are encouraged directly to servers
like that anyway)
Since our NFS server is a Linux host, our solution was to write a
create-home-dirs(8) script to pre-create home directories. The script
enumerates a configurable list of OUs in Active Directory to find
users, using the host's machine account to bind to AD. It runs
hourly, so users have home directories on our Linux NFS clients fairly
quickly after their account is created in AD.
Regards,
James