Hi gurus, Wow! What a great response from the list. I never believe there are 'too many people to thank' so THANKS to: Anjan Dave, Christophe Dupre, Aaron Lineberger, Andrew Konkol, John Willoughby, Dan Stromberg, Michael Schulte, Debbie Tropiano, Michael Di Domenico, Michael Chanslor, Dan Lowe, Adrian Ulrich, Matthew Joyce, David Foster, Matt Clausen, Eric Falen, Sandwitch Maker, John Stoffel, Scott Francis, Anthony D'Atri, Doug Hubbard, Bevan Broun, and Gary Tay. Almost everyone that responded said they either had, have, or expect to have, the problem I described. Everyone agreed that the problem IS worth addressing now and that it will only get harder to solve as we grow. A LOT of people just wrote to say: "Please summarize your findings! We're in the same boat!" The suggestions generally fell into one of three catagories: 1) NIS 2) Homegrown scripts 3) LDAP-accessible directory server For the impatient: NIS is simple, still widely used, and probably exactly what we need. Homegrown scripts may function, but tend to be fragile and may require customization to restrict developer access to specific hosts. LDAP directory servers do it all, but require a non-trivial installation and configuration effort up front. Let's take a closer look... ########################################################### NIS Yes, we have heard of NIS. :) We had not even considered NIS because we've grown so accustomed to hearing "NIS is dead...", "Sun is moving away from NIS...", and "Everyone is moving to directory services..." But when I think about it, I've been hearing the NIS-is-dead mantra since at least Solaris 2.6. I was very surprised by the number of people who said they use NIS currently AND suggested we use it. Most people mentioned the notion that NIS will eventually go away, but it's so easy to setup, and our requirements are so narrow, that it could easily address what we hope to accomplish. A few people mentioned that NIS does not enforce password aging. This is a minor issue that, if no work-arounds exist, we may simply address through written policy. "Sun is phasing NIS out after Solaris 10." -Dave Foster. Good point! We will probably not be moving to 10 for at least another year. And 10 should be supported for at least a couple years beyond that. That's waaaaaay in the futre AFAIC. The Sandwich Maker shared the following security note: "the classic way of enabling nis logins is to put a '+' at the end of the passwd file; a netgroup would be '+@netgroup_name'. but this leaves a security hole; under some circumstances it's possible to login in as user + or user +@netgroup_name and have root priviledges. it's a good idea to create an actual +@netgroup_name with locked passwd, uid/gid nobody, some useless home, and /dev/null for shell. all this is ignored when nis is running; info for the user in the netgroup is used." When mentioned, NIS+ was shunned. ########################################################### HOMEGROWN SCRIPTS Suggestions for homegrown scripts were usually focused on password synchronization. Well, not really synchronization, but update pushes. The typical model involved a 'master' server that maintained the authoritative passwd and shadow files. The files would be periodically updated and pushed out to all hosts in the environment. Tools to do this included rdist over ssh, rsync over ssh, and remote_update.pl available at http://freshmeat.net/projects/remote_update.pl/ Admitted shortcomings of this approach included lag between updates at the master server and the rest of the environment. BTW: If you're not familiar, remote_update.pl is a great tool for a lot of system administration tasks. ########################################################### LDAP ACCESSIBLE DIRECTORY SERVER Even the folks using NIS today recognized that LDAP-accessible directory servers are "the way of the future" (-Dan Stromberg). Gary Tay has an incredible site that provides step-by-step documentation at http://web.singnet.com.sg/~garyttt/ If you are at all considering the use of directory services within a Solaris environment, you need to check this site. "What we're going to is an OpenLDAP server that is going to handle User Information (UID, GID, Group definitions, home directories, mail aliases, etc.) and then a MIT KerberosV system to handle the authentication side of things. I could have done passwords in the LDAP but then I would have to make sure my PAM modules were working correctly and all that rot.... with this system, I can use the Kerberos/GSSAPI functionality built into programs such as OpenSSH to seemlessly authenticate users from a central source and no having to wait 30+ min for password propagation." -Matt Clausen ########################################################### OUR DIRECTION? We are leaning strongly towards NIS. Simple, easy, quick. I suspect we will eventually move to a centralized LDAP-accessible directory server, but that is far (by our standards) in the future. Enterprise-wide directory and naming services will be a project driven by our architectural development team. Organizationally, it doesn't make sense for the lowly sys-admins to create and lead any movement toward a global directory schema. ########################################################### Tools, links, and other resources mentioned: NIS http://www.brandonhutchinson.com/Solaris_NIS_configuration.html NIS FAQ: http://www.sunhelp.org/faq/nis.html Samba's winbindd: http://us2.samba.org/samba/docs/man/winbindd.8.html Kerberos: http://web.mit.edu/kerberos/www/ GSSAPI: http://www.faqs.org/rfcs/rfc2743.html rdist: http://www.magnicomp.com/rdist/ rsync: http://samba.anu.edu.au/rsync/ remote_update.pl http://freshmeat.net/projects/remote_update.pl/ OpenLDAP: http://www.openldap.org/ http://www.bolthole.com/solaris/LDAP.html Sun One Directory Server (iPlanet): http://www.sun.com/software/products/directory_srvr_ee/index.xml HTH! -John Christian ########################################################### ORIGINAL POST BELOW Hi gurus, We have ~30 developers and ~30 UNIX servers (Mostly Sol9, a few Sol8, couple RHEL). The developers use their desktop PCs to access the UNIX servers for much of their work. On average, one developer has 15 different UNIX accounts. Obviously, this has some hassles: - new-hire = sys-admin creates 15 UNIX accounts - new-fire = sys-admin deletes 15 UNIX accounts - developers suffer through 15 password changes every 60 days (in addition to Windows, corporate intranet, timesheet application, etc...) Since my primary goal in life is to make developers' lives easier ;) I figure we could at least reduce their ~15 UNIX accounts to 1 account. We are NOT interested in tackling single sign-on or Windows synchronization. We *think* we want: - new-hire = sys-admin creates 1 account and authorizes it for ~15 hosts - new-fire = sys-admin deletes 1 account - developer updates 1 UNIX password every 60 days - developer needs new access = sys-admin 'turns-on' access to additional host - developer changes duties = sys-admin 'turns-off' authority for certain hosts - ability to have certain accounts remain local-only (root, sys-admins) How have you addressed the challenges of developer account sprawl? In addition to Directory Servers (OpenLDAP, Sun One, Novell), are there any alternative approaches we should consider? I fear a full-blown Directory Server may be overkill. Maybe the problem isn't worth solving yet? Continuing with our current approach IS an option. Maybe we should have 50 developers and 100 machines before worrying about this issue? TIA if you take any time to respond this post. I will provide a SUMMARY unless I only receive out-of-office replies. No need to summarize those. -John __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Thu Oct 13 11:31:02 2005
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:52 EST