On Mon, Feb 04, 2019 at 03:19:27PM -0600, Spike White wrote: > Sssd practitioners, > > (I hope this topic is not inappropriate to this target audience.) > > My company is looking at retiring NIS, in favor of AD. Altogether, there > are several thousand Linux servers (& a few UNIX servers) getting their > authentication via NIS. > > There’s three components being looked up from NIS: > > · Users and groups > > · Automount maps > > · netgroups > > Additionally, there’s thousands of Linux servers getting their > authentication via our corporate AD domain. (Using commercial products). > The corporate AD domain has the rfc2307bis schema extension. Also, it has > child domains – so cross-domain authentication (between > transitively-trusted subdomains) is important to us. > > We have kicked the tires on sssd on RHEL7. As long as you avoid using the > ‘tokengroups’ optimization, it works great. Even does all cross-domain > authentication. We’re able to pick up users, groups and even automount > maps. > > We believe that we can mostly replace the NIS netgroups with AD groups > (because these NIS netgroups are not using the “server” component). > > We have a wealth of AD and some NIS expertise in-house. We have > considerable expertise in two commercial AD integration products for > Linux/UNIX. > > What we do *NOT* have is any experience with a NIS => AD migration.
Me neither, but I'll add some minor comments about SSSD. > > What problems will we encounter? > > 1. We know that some NIS UIDs and GIDs will conflict with > already-existing AD entries. In general SSSD does not support conflicting IDs, but.. > > 2. If we change these users’ UIDs to non-conflicting UIDs, then our > NFS NAS shares will break (as the directory trees are owned by the old UID, > not the new UID). ..there is a utility called sss_override that might help you set up a per-client UID and GID override if that would help. > > What other problems do we need to look out for? > > Here’s our initial idea of how to proceed: > > 1. We’re thinking of standing up RHEL8 with sssd first. As far as the AD integration goes, RHEL-8 is pretty much equivalent to RHEL-7. There are differences wrt smart cards and Kerberos ticket handling as well as many changes under the hood which would allow us to do more enhancements down the road in RHEL-8, but I would say that for AD integration purposes, you can just go ahead with RHEL-7.. > > 2. After period of stability: > > a. Forklift NIS accounts into AD, deconflicting UIDs and GIDs. > > b. Stand up new NAS shares with new UIDs, GIDs? > > c. retrofit RHEL7 (remove NIS, put in AD on RHEL7 clients). > > > > 3. After period of stability, do same with RHEL6 and RHEL5 – except > with commercial products. (version of sssd on RHEL5 and RHEL6 too old and > flaky – particularly for cross-domain auth). The 6.10 version /should/ be relatively stable and I'm not aware of many issues. RHEL-5 on the other hand is EOL for most intents and purposes.. > > Are we totally off on the above roll-out plan? > > What are best practices? > > Does anyone have experience with such a NIS => AD large corporate migration? > > Spike > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
