Distributed Password Files? 10
mrbill asks: "I'm looking for a distributed password/group file
system for a mixed network - we've got Linux,
HP-UX, IRIX, and Solaris (some using shadowed
password files, some not) systems here, but I need
to keep the passwords on the machines synchronized
to a "master" machine, *without* using NIS/NIS+.
Rdist is not acceptable either, since obviously a HP-UX machine cant use a password file straight from an IRIX box, etc. Suggestions? "
What's wrong with LDAP? (Score:1)
If you are finding that encrypted passwords from one UNIX variant cannot be used on all the other variants you are using, then the first issue would be that of course using the raw password file in any way is out of the question (as you've noted, by dismissing Rdist).
So, some way of keeping a platform-neutral password is required - either in clear-text, or in some standard encryption format.
In terms of distribution, you can use a readily available password distribution scheme (such as NIS/NIS+), or you will have to write your own; this would need to capture passwords at every possible point (for users changing passwords), maintain the remote database, and keep redistributing changes out to each of the platforms.
Why reinvent the wheel?
If it is mainly NIS/NIS+ that concerns you, why not use something similar - LDAP? As long as each of the platforms supports PAM/NSS and/or some equivalent, then LDAP modules can be installed to perform password update and distribution automatically.
Certainly the latest versions of Solaris, HP-UX and Linux distributions support PAM/NSS; not quite sure about IRIX, though the software (see below) does mention IRIX support so it's perhaps through an equivalent interface.
http://www.padl.com/ [padl.com]
Kerberos (Score:2)
An additional benefit to Kerberos is that many open packages include Kerberos support. Lprng and postgres SQL are two well-known examples. Work in a Kerberized environment for awhile and going back to a system where every application maintains its own authentication information is painful.
There are commercial packages available, or if you're in the US or Canada you can grab free source from MIT. If you're overseas, you can grab the Kth distribution. I know the latter is packaged in Debian 2.1.
Finally, many people complain that Kerberos is hard to set up and use. I've never had a problem with it and I think it might be the dreaded CLI factor - the pure MIT version focuses on security, not pretty wizards. For a large installation you'll probably want to set up a primary and secondary KDC in a secure area, but even if you use dedicated hardware you should find a 386 running Linux is more than adequate.
SSH could be of help (Score:1)
If you're distributing passwords over the network, they really should be encrypted. With SSH, you could set up the machines with keys for authentification, so that no passwords were required, and it could be "automatic".
Other good points about SSH: it's from Finland, and the source should compile on all of the systems you've mentioned. SSH is at ssh.fi [www.ssh.fi]. Or, you could skip their icky web site, and just search at Freshmeat [freshmeat.net].
passmass (Score:1)
My experience (Score:1)
MD5 ? (Score:1)
Is MD5 standard in other Unices beside Linux ? That would sound like the right choice...
Re:My experience (Score:1)
cjs
Our solution: postprocessing (Score:1)
We've been doing this for years locally. The approach we use is to have a master machine on which all password changes happen (ssh has made this much easier to construct, since it is now very easy to run 'passwd' remotely with a pty). The master machine's /etc/passwd (and /etc/group) is then propagated out to all the client machines, and after this propagation each client strips off the 'system' accounts and groups that are specific to the master machine's OS and adds in its own (which are themselves propagated from a master, just in case we want to change them sometime).
There are a number of ways to propagate the files from master to clients. I prefer to use a solution where the clients each 'pull' the files from the master, since it works better if some of the clients are down or unreachable. The program we've historically used for this is something called track; you can get the version we use from the anonymous ftp server at ftp.cs.utoronto.ca in /pub. You could also use rsync's daemon mode, rsync over ssh to a carefully chosen captive account on the master, scp, or various other methods.
Track scales well and can be cascaded; we have multiple labs, and in each lab a single machine has been elected as the lab master; it tracks from the true master, and the other lab machines track from it. Our experiences with rsync's daemon mode have been less happy, but we were synchronizing a lot more with it (a hierarchy of local software, about 100 megabytes worth).
Security: our solution currently propagates the files in cleartext. I don't consider this a large problem in our environment, since we have to count on a secure network anyways (given that we do NFS and other things over it). With more work, it would be possible to transfer the files in some encrypted form.