unix_fan wrote: > @$WORK, We've finally decided to get serious about a NIS migration, i.e, a > migration away fro NIS. I'm seeking words of wisdom advice, and Experience > gotchas. > > We are geographically dispersed into regional administrative groups. We have > two existing Enterprise authentication services, one AD based, one is LDAP > based, that serve all regions. For authentication maps (passwd, group) we > have consensus that we'd like that migrated service to be from one of the > Enterprise services. We have less than consensus about whether to utilize > Enterprise services for the non-authentication pieces, i.e., for historical > reasons, we are pessimistic about how much we can migrate to the Enterprise > AD or LDAP services. > > We'd also have to deal with name space collisions in an Enterprise > implementation that we wouldn't have with regional control (e.g., whose > /home/pkg_version gets mounted). > > Part of the hesitation to centralize more than necessary beyond the regional > boundaries is that the Enterprise services have *always* > balked at change: no schema changes have ever been allowed; there is > serious reluctance to introduce any change. Another complication is > that the regional operations are handing over the majority of the OS > management to another service supplier this year. That last bit is > water under the bridge, a decision cast in stone. > > Different regional groups have looked at and/or implemented various solutions: > 1. Migrating NIS maps to regional non-Enterprise managed LDAP servers, with > pass through authentication to the Enterprise services(AD or LDAP) > 2. Centrify - (works; large $$$$$; pinning down a price based on a subjective > "server" definition is unpleasant) > 3. Likewise (new kids on the block, not sure what is different than Centrify) > 4. A mix of AD/kerberos authentication with OpenLDAP nonauthentication data. > > Another thing to consider is user name mapping. Some of us have tried > changing our existing production usernames (e.g., "joeengineer") to the > corresponding Enterprise name (e.g., "12345678") with varying levels of > success. Some groups utilize a custom PAM module to do the username mapping > (i.e., "joeengineer" gets authenticated with username "12345678" > credentials), similar to a classic samba smbusers map. Our main *nix flavors > are RHEL, SuSE, and Solaris, with islands of HP-UX thrown in. We are > primarily concentrating on the Solaris and Linux bits. In case anyone asks, > we have not had issues with all numeric usernames in Solaris 9+ or RHEL3+. > > Both Enterprise Authentication mechanisms (AD and LDAP based) are entrenched > and not going away. There is a slight bias toward the AD service though. > > Our Enterprise folks would like us to pin down our NIS migration requirements > for eventual submission to an RFP process.That's part of the impetus for me > posting here for lessons learned and gotchas. > > What are the things that you folks have encountered, or decisions you made in > your NIS migration? > I also welcome questions or comments on anything about the installed base I > wrote above. > Thanks for your feedback and patience. >
If your AD servers are 2003R2 or later, adding groups using the MS-supplied tools will add RFC 2307bis objects. This works for Linux clients, but the Solaris NSS client layer only talks RFC 2307 (not bis). The biggest difference from an authorization standpoint is that 2307bis uses the memberUid field of a group object to specify a list of LDAP CNs. 2307 uses the member field to specify a list of usernames, which means that Solaris clients won't be able to see any secondary group memberships for a user. The workaround is to write your own tools to add groups and populate both member and memberUid, or to have a script come by afterwards and do the same thing. If the Enteprise group isn't keen on updating the schema they probably wouldn't go for this either. -- -- Skylar Thompson ([email protected]) -- http://www.cs.earlham.edu/~skylar/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
