> I'd very much like to hear how other mixed AFS/NFS sites
> handle uniform login....
> We have a few hundred workstations and several servers -
> most vendors are represented. Each machine has its own
> password file containing a (usually) small number of
> accounts. No two password files are the same; it is an
> administrative nightmare and machine utilisation is
> very poor. ... I expect we'll always have
> a few NFS-only clients.
>
> Other relevant pieces of information:
>
> - I am not allowed to use NIS.
> - I use AFS login on AFS clients.
> - I keep AFS id's the same as UNIX uid's.
In dealing with this problem, I wrote a simple password data base
manager (using only public domain software). The program keeps
a data base containing all of the information which normally goes
in password files, as well as information about access to groups
of machines and changes.
Normally, a user's password entry is the same on all machines, except
that on machines to which he has no access, the encrypted password is
'*' and the login shell is '/bin/false'. It is possible for most
entries to have contextual variants; thus the encrypted password,
login shell, and home directory can be different in different files.
Communication with the data base takes place in 3 ways:
(1) The underlying communication is via Unix line-mode commands.
Return codes can be used to test, for example, for the
existence or non existence of a username or id number, the
legitimacy of a string, etc.
(2) I and other site administrators can edit the data base using
a shell script, which displays an entry, permits alterations,
and is menu driven.
(3) Users and administrators can change the data base using adm.
The adm server tests the legitimacy of requests, issues an
appropriate Unix command, and reports its success or failure.
A special shell script for adding new users prompts for the standard
input, modifies the data base, and appends to a file the AFS commands
which are required for adding the new user. A cron job runs once an
hour to write out the current password files on one machine. If a
password file has changed, the cron job replaces the old file in
an AFS directory (/afs/cell/common/passwd). A few minutes later
package runs on each client machine to update the local passwd file
if necessary. The whole system was written in a couple of days.
Since putting it in last December, I have found only one bug in the
data base management scripts (involving deleting a user), and I have
modified the cron job so that it ensures there is a root entry in
each passwd file before copying it to AFS. (Once when the /tmp disk
was full, the new passwd files were all blank. The package jobs replaced
/etc/passwd on all machines with null files, and cron stopped running,
since cron for root requires a root entry in /etc/passwd.
It took half a day to fix the 80-odd clients.)
> In summary:
>
> - I'd like to maintain a central password file.
> - It must be served securely (i.e. no uid/gid spoofing).
> - Individual users must be able to do the normal 'passwd'
> command (but no cleartext passwords on the wire).
> - Ideally the service would be replicated.
Individual users change their passwords either with 'kpasswd' or
with adm.
-- Owen
[EMAIL PROTECTED]
