Distributed Password Files?

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?

[Anonymous Coward]

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?

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

[coyote-san]

This is exactly the type of situation Kerberos was designed to handle.. and it's no coincidence that Micros~1 has based W2K security on a (suitably 'enhanced' version of) Kerberos.

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

[rflb]

This would require some scripting and whatnot (to make HPUX and Irix happy, etc), but I think that it's a good idea. SSH provides secure shell, secure replacements rdist and rcp, among other stuff. Here's a blurb:

SSH (Secure Shell) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over insecure channels. It is intended as a replacement for rlogin, rsh, rcp, and rdist.

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

[Just Your Average Li]

There's a shell script common to many variants called passmass which connects to the many systems and then uses whatever passwd command is there to change the password. It's definitely not the most secure thing out there, but it works.

My experience

[Anonymous Coward]

The easy way: use a master server where users change passwords and propogate the changes on a regular basis to all client machines. The difference between SGIs & HP's is generally just a small change in the password file which can be handled by awk quite easily. The problem with this is that you may have problems if the clients use different encryption formats. Fortunately almost all unices have DES as an option. The best way: (?) Use LDAP & something like pam_ldap. Keep all your information in one place. The problem with this is that not all platforms can authenticate off an LDAP server, though this should change soon. This might take a while to set up. An alternative: There is something called ganymede (check freshmeat) that maintains a centralized authentication directory and propagates the changes to client machines. Because it uses shell scripts to propogate the changes, you can customize it for different unices quite easily.

MD5 ?

[Etyenne]

So, some way of keeping a platform-neutral password is required - either in clear-text, or in some standard encryption format.

Is MD5 standard in other Unices beside Linux ? That would sound like the right choice...

Re:My experience

[cjs]

...not sure if you can run either over an encrypted ssh type connection...

RADIUS packets are already encrypted.

cjs

Our solution: postprocessing

[Chris Siebenmann]

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.