The company that I am working for is embarking on replacing the current locally developed NIS/YP structure with LDAP.
We already have AD in house for the Windows stuff and would like to consider using an AD system. The AD people are quite restrictive and would not support extensive modifications.
We have needs to have the replacement include the support the full capabilities of the NIS/YP suite include netgroups, login restrictions to specific servers for specific users or groups of users, consistent passwords between the *nix and Windows environment,etc. Our environment is a mixture of Linux (suse, RH, Debian), Sun, IBM, HP and MPRAS as well as a NETAPP. So whatever we use must be totally inclusive to all environment.
We have looked at Likewise, but our management wants other alternatives to compare with.
What other things should I be looking at and what is you assessment of the alternative?
Thanks
Microsoft used to have something called Services For Unix (It's still around but with a different name: It's now "Subsystem for UNIX-based Applications (SUA)") -- Among the features it included was an AD-to-NIS gateway that allows you to create a NIS domain that is effectively slaved to your AD domain.
This is probably the the path of least resistance for you since your unix environment is heterogeneous -- Anything that understood NIS will understand the MS NIS server, because as far as your unix systems are concerned it's still just a plain old NIS server.
Another option is pam_ldapd (or pam_ldap + nss_ldap) -- This would query against your AD servers directly & gets away from some of the limitations of NIS, but I don't know how good the netgroup support and such is on these (I know pam_ldap + nss_ldap doesn't have working netgroup support on FreeBSD).
you could try freeipa (http://freeipa.org) from the redhat folks. It is meant to replace nis/yp and it gives you a kerberized environment as a bonus. Of course you can just plug clients with just pam_ldap, but you lose then the single sign-on.
You can also synchronize users with AD, by the way.
Given you already have AD in house I recommend considering freeipa/Redhat IDM set up as a trusted domain of active directory. Besides being free, this allows you to use all existing user & group information in AD, while setting access controls and policies in ipa.
You also get kerberos & sso potential. Ipa in this setup presents ad groups as netgroups (like nis).
It comes with a nice web gui, and internal role based access control (eg who can join hosts to the kerberos realm, who can manage sudo etc).
Any client should be able to authenticate against either ipa or AD.
QAS (either version) is an ideal solution in my opinion except for the cost, which can be insane. It also requires a schema change to AD, which itself is fine but your AD guys might not like that.
The newer versions of winbind are much more stable than 3.x, but require you to have access policies (sudo, ssh) configured on each host.
I can't speak for centrify.
I've been in environments that used VAS (now named something else, from Quest) and Centrify. I did not maintain either system, I was only a user. So, I can't help you decide, but those are some other names.
From what I saw, both worked, and both met your listed requirements, although there were always some hiccups.
Winbind works fine especially with the RID option. Use the AD servers as the NTP maters for the unix boxes, it makes thing a little easier and it works fine. Get kerberos working with AD next, it's very simple, just make sure ntp is working and the clients are using ad for dns. The RID option in winbind will produce a predictable uid for users and gid for your groups. The samba/winbind config will let you pick a shell that all the users will get, I'm not sure if you can config to have individual users have different shells, the user can always start up whatever shell they want when they login. The login restrictions can be maintained through the sshd_config, restricting based on groups. You'll have to start with the older machines and the Netapp to see if the version of samba/winbind you install supports the backend RID option.