SUMMARY: centralizing account mgmt? is it worth doing?

• Previous message: JAMEEL MALIK: "password history feature sol9?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Thu, 13 Oct 2005 08:28:20 -0700 (PDT)
To: sunmanagers@sunmanagers.org

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/sunmanagers

• Previous message: JAMEEL MALIK: "password history feature sol9?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]