david@pyr.gatech.EDU (David Brown) (01/04/89)
Hi. Over the past several months, I've read several articles from
SysAdmins who said that they didn't use Yellow Pages on their networks.
I can understand this: we use yp and it's a real pain sometimes. What
are some alternate ways to get similar effects? (I want user x to be able
to use his same username and password on all our machines, and when he
changes it on any machine, I want that change propagated to all the others).
I don't even know if this is possible without a working yp, but any and
all ideas are welcome! I've got a small network of Suns (SunOS3.5) and
a VAX (4.3+NFS).
Thanks in advance,
David Brown
----------------------------------------------------------------------------
David Brown
Armstrong State College, Savannah, Georgia
uucp: ...!{akgua,allegra,amd,hplabs,uunet,seismo,ut-ngp}!gatech!gitpyr!david
ARPA: david@pyr.gatech.eduarosen@hawk.ulowell.edu (MFHorn) (01/05/89)
> What > are some alternate ways to get similar effects? (I want user x to be able > to use his same username and password on all our machines, and when he > changes it on any machine, I want that change propagated to all the > others). We have our central server periodically (every two hours, via cron) copy /etc/passwd, /etc/group and /etc/hosts to a list of hosts. It's pretty slow, and it's very inefficient, but it works. The shell script that does it mounts the remote host's /, copies the files over and then runs a script located on the remote machine (if the script exists). This second script is used to add host specific stuff to any of the files copied over. Eg., one of the hosts supports several diskless workstations, so it has a script to copy the files into the diskless partition. All the scripts do as thorough error checking as possible. One thing they don't do is check if the file has changed before copying it. Rdist may be better, but I couldn't get it to work they way I wanted it. The big things that you lose out on are a hashed host table (for those without a named), netgroups (/etc/exports can get pretty big) and yppasswd (chaning your password on any machine but the central server is meaningless). This is probably an unacceptable solution for very large networks; we have about 15 hosts to update, but I can send our shell scripts to whoever wants them. -- Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should've been
flint@gistdev.UUCP (01/06/89)
We set up a system like you described to update password files for one of our clients: as a solution it stinks, but I think it is about all you can do. Our client later messed up when they set up a cron job which scrogged their /etc/passwd file on the main machine at midnight. Our cron job dutifully came along an hour later and copied the garbaged passwd file to all the other hosts in the network. My advice: if you gotta do that, at least make sure that the root login entry cannot be corrupted no matter what else happens. (This isn't a hard problem to repair, IF you know what happened, and what to do. When you don't, finding that you are unable to log into any of the machines in the network is likely to send your management into a serious panic, especially if they are at all security conscious.)
scooter@genie.UUCP (Scooter Morris) (01/08/89)
From article <6999@pyr.gatech.EDU>, by david@pyr.gatech.EDU (David Brown): > Hi. Over the past several months, I've read several articles from > SysAdmins who said that they didn't use Yellow Pages on their networks. > I can understand this: we use yp and it's a real pain sometimes. What > are some alternate ways to get similar effects? (I want user x to be able > to use his same username and password on all our machines, and when he > changes it on any machine, I want that change propagated to all the others). We had the same problem, but because we weren't using NFS, Yellow Pages wasn't an option. We have two VAXes running 4.3bsd and have hacked in the remote file system (RFS) distributed over USENET a couple of years ago. So, we wanted to have duplicate password files on both systems, and wanted to have any changes on one system to take effect immediately on the other system. We also wanted to have no user visible changes, and wanted to only have to add users on one system (easy, huh?). So, we modified /bin/passwd so that insted of updating the password database directly, it sends a packet to a password daemon. The password daemon (passwordd) updates the local database, and queues up the change to any other machines which are sharing the same uid scheme. The changes are then sent over TCP to the password daemon on each of the other machines which, in turn, update their local databases. Sounds complicated, but its actually quite easy and (so far) reliable. We've been using this scheme for about 2 years. One added benefit of this is that because all updates are to the password database insted of /etc/passwd, the system is much more efficient. /etc/passwd gets regenerated once every 20 minutes if there's been any changes. This seems more than ample for programs like finger which requires /etc/passwd. Another benefit, which I haven't implemented so far is the ability to exclude fields from /etc/passwd, like the password, for example. At any rate, alternatives to YP are available! We will be porting this code this year to our new Silicon Graphics Irises, so I'll be able to report on the portability of this stuff in the (hopefully) near future. Scooter Morris Genentech, Inc. scooter@genie.gene.com P.S. This stuff is available to anyone who wants it, but you'll need source to take advantage of it because of the changes to /bin/passwd.
bnick@aucis.UUCP (Bill Nickless) (01/10/89)
In article <747@genie.UUCP>, scooter@genie.UUCP (Scooter Morris) writes: > From article <6999@pyr.gatech.EDU>, by david@pyr.gatech.EDU (David Brown): > > Hi. Over the past several months, I've read several articles from > > SysAdmins who said that they didn't use Yellow Pages on their networks. > > I can understand this: we use yp and it's a real pain sometimes. What > > are some alternate ways to get similar effects? (I want user x to be able > > to use his same username and password on all our machines, and when he > > changes it on any machine, I want that change propagated to all the others). > > So, we modified /bin/passwd so that insted of updating the > password database directly, it sends a packet to a password > daemon. [ Description of solution deleted ] > P.S. This stuff is available to anyone who wants it, but > you'll need source to take advantage of it because of the > changes to /bin/passwd. At our installation, we run 2 AT&T 3B2/400's with an RFS link set up between them. Unfortunately (?) we don't have a source license here, so we have to make do with the binaries. The first step was to restrict /bin/passwd (chmod o-rx /bin/passwd). Then we created a simple program to act as a front-end to /bin/passwd, with a set-gid to sys (or whatever the group of /bin/passwd is). We installed this as /usr/local/bin/passwd. This front end traps SIGQUIT and SIGINT, creates a lockfile in a common place in the RFS domain, and executes /bin/passwd as a child process with the same argument that the front end was called with. When /bin/passwd returns, it copies /etc/passwd to the remote sites using chmod and /bin/cp. Problems include: 1. Only one person, domain-wide, can change their password at a time. This can cause significant delays because many people wait for the "Enter new password:" prompt before thinking one up! 2. Password aging probably can't be used, because I suspect login expects to execute /bin/passwd to change passwords. 3. /etc/passwd has to be copied to all the other machines. Good luck! -- William (Bill) Kirk Nickless Andrews University 305 Meier Computer and Information Science Department Berrien Springs, MI 49104 UNIX Support Group (616) 471-6515 or (616) 471-3422 ...!uunet!cucstud!aucis!bnick
treese@athena.mit.edu (Win Treese) (01/15/89)
In article <747@genie.UUCP> scooter@genie.UUCP (Scooter Morris) writes: (in answer to a question about replacing YP) > > [...] > > So, we modified /bin/passwd so that insted of updating the > password database directly, it sends a packet to a password > daemon. The password daemon (passwordd) updates the local > database, and queues up the change to any other machines which > are sharing the same uid scheme. The changes are then sent > over TCP to the password daemon on each of the other machines > which, in turn, update their local databases.... How do you guarantee that the request to change a password is legitimate? That is, can I spoof the password daemon as another user or from another machine on the network that I control? It seems that this system is vulnerable to a number of attacks, including some that YP is also vulnerable to. The design of a good network authentication system isn't entirely obvious, but it's fairly well understood now. A good start in the literature is Needham & Schroeder's 1978 CACM paper on the subject (the system described there is the basis of MIT Project Athena's Kerberos authentication system). Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corporation