On Thu, Apr 19, 2018 at 8:14 AM, John Hearns <hear...@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 _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
