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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o...