[OLUG] Single system login administration?
hagler at th.in.gs
Sat May 27 02:20:51 UTC 2000
Depending on your needs, each auth system has its advantages.
Traditional NIS is easy to configure and administer, and it generally works
pretty well. Its huge downfall is the inability to shadow passwords, and
other security problems. NIS (and NIS+) are RPC-based services, so there
may be some other security problems related to RPC that aren't necessarily
NIS-related that you'll have to deal with.
NIS+ works OK on linux, but it's a huge pain in the ass to administer. I've
never set up a NIS+ server on linux, but I've got Linux to behave as a NIS+
client to a Solaris master. NIS+ secuity is much better, but the security
model is what makes the administrative pain. Everything is encrypted with
a key-based encryption model, and things are fun to fix when somebody's
NIS key and their login password fall out of sync.
LDAP is a good alternative, and things are moving towards LDAP all over the
place. I don't personally like the Netscape directory server. It's too
expensive for the quality of the product (much like their web and mail
servers) and its fairly resource intensive. I would recommend using
OpenLDAP as the server (http://www.openldap.org). It's possible to use
OpenLDAP for slave servres, and buy a single Netscape server if you're
really interested in the horrible Java gui thing. I've accomplished this
by having the Netscape server export via LDIF and import that on the
OpenLDAP server. The biggest problem here is the Netscape server seems
to have a bunch of their own object classes defined in the directory and
they do some kind of black magic to keep track of things about objects
with their own stuff. I've never found a way to export the object class
hierarchy from the Netscape server.
NDS is very similar in concept and operation to x.500, and LDAP is a sub-set
of the x.500 spec (hence, "lightweight"). Unless you've already got a
Novell NDS tree in place, I wouldn't consider this since everything seems to
be moving towards LDAP anyway.
There's a PAM module to get Linux to auth users against a NT domain, if that
helps you at all.
For a small enterprise (under 200 servers or so...) it may be easier to just
use some home-grown scripts to sync /etc/passwd and /etc/shadow across a few
nodes, and just NFS mount home dirs (or use automounter.)
On Thu, May 25, 2000 at 09:14:36AM -0500, Adam Haeder wrote:
> I'm getting to the point where the number of linux servers I have is quickly accelerating. Since we only had 2 for the longest time, I never worried about user account sychronization between them. The few people that needed accounts got them, and when they changed their passwords, they had to change them on both systems.
> This will not work anymore. What I would like to get some advice on is what is currently the best way to do this? I'm looking at 3 different choices:
> - NIS
> - LDAP
> - Novell's NDS for Linux
> Since I'm not that familiar with NDS, that's probably the last resort. My big question is: does anybody use NIS anymore? Everywhere I go to read about it, major security considerations are brought up. Then there's talk of NIS+, but I was under the impression that it was still very immature on Linux. Please feel free to correct my assumptions.
> I'm sort of leaning towards LDAP right now. I know that you can LDAP-enable PAM, and I could also have Apache authenticate against it, and it could become more than a username:password store, it could our whole company contact database. I like that idea.
> What have other people done? Is NIS really not worth considering anymore for the security considerations? Has anyone used OpenLDAP enough to know if it is robust enough to handle this? Is Netscape's Directory Server (the only major commerical linux ldap server I know of) worth the money? Thanks for any input.
> Adam Haeder
> Technical Coordinator, AIM Institute
> adamh at omaha.org
> To unsubscribe, e-mail: olug-unsubscribe at bstc.net
> For additional commands, e-mail: olug-help at bstc.net
Email is packaged by intellectual weight, not volume. Some
settling of contents may have occurred during transmission.
To unsubscribe, e-mail: olug-unsubscribe at bstc.net
For additional commands, e-mail: olug-help at bstc.net
More information about the OLUG