user account management (LONG)
Ed McGuire
emcguire at ccad.uiowa.edu
Tue Oct 9 03:35:35 AEST 1990
Recently I posted a list of my concerns in the area of user account
management in a heterogeneous network environment:
o Automation of account management
o Consistent login names in all password files
o Unique uid and gid assignment
o Resource accounting on a per user or per group basis
o Removal of obsolete login names
o Enforcing password security
o Consistent user environment
o Electronic mail routing
I solicited your methods for approaching user account management, and
promised to post what I got.
What I got is a description of each site's homegrown software to deal with
these concerns. Titles include "ACmaint," "expect," "udb," "adduser." I
believe we would all benefit from the eventual inclusion of these features
in the operating system software, or adoption of one system as a community
utility. I was particularly impressed by the "ACmaint" approach to the
account maintenance bullets and look forward to hearing more about it.
Here is a summary of the articles I received, in the order that I received
them, followed by the actual (edited) articles.
------------------------------
From: kimery at dynamo.ecn.purdue.edu (Sam Kimery)
Their "ACmaint" claims to handle 99% of the items in my list
with a central database, using slave "account maintenance daemons"
to do the actual work on each node.
From: libes at cme.nist.gov (Don Libes)
Their "expect" automates interactive programs like "passwd",
facilitating (for example) changing password on several machines
at once.
From: Kandler <Matthias.Kandler at lan.informatik.tu-muenchen.dbp.de>
They are developing a central database server permitting a
decentralized approach to account management.
From: Ed Anselmo <anselmo-ed at cs.yale.edu>
Their "udb" tracks users, uids, mailboxes, mailing lists, machines,
serial numbers (among other things).
From: poepping at SEI.CMU.EDU
They have scripts which propagate passwords and keep accounts
consistent within a single domain. Mail service is described.
From: System Admin (Mike Peterson) <system at alchemy.chem.utoronto.ca>
Organization: University of Toronto Chemistry Department
They provide standard login files and pathnames which make all
user environments as similar as possible. Mail and print server
configurations are described.
From: Dave Sill <de5 at de5.ctd.ornl.gov>
They have an IBM based master account database, a modified `whois' with
"white pages" capability, and central mail server.
From: whaley at elbo.ucs.ubc.ca (Paul Whaley)
They are using a modified Boulder "adduser" and their own accounting
system using periodic snapshots of current activity.
------------------------------
From: kimery at dynamo.ecn.purdue.edu (Sam Kimery)
Package to be release after the USENIX LISA conference: ACmaint.
Handles 99% of the items in your list. More details upon request.
[In a telco Sam explained that ACmaint implements a global account database
and generic operator interface, which responds to requests such as "add,"
"copy," "delete," and "terminate" (global delete). The sysadmins using
ACmaint claim this cuts their time to do account administration by more
than half. A system-specific daemon on each machine is contacted via
UDP socket to do the actual work. Currently ACmaint daemons are
implemented only on BSD4.3 machines, but could of course be ported to
SYSV or non-UNIX systems which support UDP sockets. --Ed]
--Sam
Sam Kimery - Unix Systems Programmer
Engineering Computer Network - Purdue University
UUCP: pur-ee!kimery ARPA: kimery at ecn.purdue.edu BELL: 317-494-3473
------------------------------
From: libes at cme.nist.gov (Don Libes)
Organization: National Institute of Standards and Technology
I have a paper in the upcoming USENIX Large Installation System
Administration Conference on "expect". It's a tool for automating
interactive programs like passwd. In fact, that is one of the examples
in the paper. One of the benefits I point out is that this provides a
simple way of preventing users from choosing passwords that are, say,
usernames or in the on-line dictionary (or any criteria you like).
expect also lets you automate procedures on non-UNIX systems. So, for
example, when a user changes their password on their UNIX system, it
can also be changed on their VMS system at the same time.
Don Libes libes at cme.nist.gov ...!uunet!cme-durer!libes
------------------------------
From: Kandler <Matthias.Kandler at lan.informatik.tu-muenchen.dbp.de>
Organization: Inst. fuer Informatik, TU Muenchen, Germany
Currently we have nearly 800 users and 120 workstations(DEC,HP,Sun)
here. We expect these numbers to double in the next two years. We are
now only 3 sysadmins and can't keep up with the workload. Therefore we
are working on a decentralised solution for user acccount management,
e.g. we want to partition our 120++ workstations in 10 to 12 groups
following the organizational structure of our institute. For every
group there will be one user account manager. We will have one
centralised database containing all user account data. This database is
managed by a server daemon. Every adduser program in our LAN can send
requests to this database server.
If a user is added for the first time the user account data is entered
only once. The user then is added on every machine that the user
account manager specifies.
If a user moves from one machine to another the user account data is
provided by the central databse server.
Login names are stored in the central database. So every login name is
bound to _one_ person. The adduser programs do not allow to give an
existing login name to a different person.
Uid and gid per login/person are also stored in the central database.
As far as accounting is concerned we have 3 groups of users: students,
collaboraters and projects. Each group has certain access rights to
resources like printers, disks... . The group membership of a login is
also stored in the central database.
A login entry in the central database contains also an expiration date
and the name of a responsible person (for a collaborater the
responsible person is usually his boss). If a login expires, the
responsible person is asked if the login can be removed. If he says yes
we delete the login. (We play it save: The data belonging to this user
is automatically archived on tape before removing it.) Also the
database entry is deleted by the removeuser program.
For every user our database stores a mailhost(where does he have his
mailbox) and a mailbox name (usually the login, but some professors
want their mail sent to their secretarys). This data is regularly
sent to our mailrelay host.
~~
Matthias Kandler Institut f. Informatik
TU Muenchen
kandler at informatik.tu-muenchen.dbp.de Postfach 20 24 20
Telefon: +49 89 2105 2025 D-8000 Muenchen 2
------------------------------
In article <26107 at cs.yale.edu> anselmo-ed at cs.yale.edu writes:
Yale CS uses the all-singing, all-dancing "User Database Program"
(udb) which tracks users, uids, mailboxs, mailing lists, machines,
serial numbers (among other things). Through a series of programs and
Shell Scripts from Hell, it's used to build and delete accounts
(assigning unique uids, and keeping them consistent across machines),
and rebuild the sendmail aliases files.
It has also managed to keep several generations of Yale undergraduate
summer programmers entertained for months on end.
--
Ed Anselmo anselmo-ed at cs.yale.edu {harvard,cmcl2}!yale!anselmo-ed
------------------------------
From: poepping at SEI.CMU.EDU
o Automation of account management
passwd propogation scripts
o Consistent login names in all password files
single domain capability, would like flexible password configuration
uniqueness of uid/gid, but per-system capability for password access.
there are some paradigms which may help here, but I've never spent much
time looking into them.
o Unique uid and gid assignment
single domain.. trivial
o Resource accounting on a per user or per group basis
no.
o Removal of obsolete login names
ouch.
o Enforcing password security
password scanning programs (cops, etal).
o Consistent user environment
only at user setup, again consistency from single domain
o Electronic mail routing
we use .forwards from a central mail hub and force ALL mail (even local)
through it (local mail is two-hop) rather than a huge aliases file (it's
already quite big) only ~500 accounts (200 systems). I'd like a UNIX
POP.
--
Mark Poepping poepping at sei.cmu.edu
Software Engineering Institute (412) 268-6392
Pittsburgh, PA
------------------------------
From: System Admin (Mike Peterson) <system at alchemy.chem.utoronto.ca>
Organization: University of Toronto Chemistry Department
Users can not choose their loginid.
We use first initial plus last name to a total of 8 letters maximum.
All systems seem to be able to handle 8 character names.
This makes rlogin simple, since the loginids match properly.
One really nice thing about Apollo is the network wide password "file",
but we'll try to use NFS/Yellowpages for this I guess.
The users .cshrc/.login/.profile files source master copies in
/usr/local (if the system doesn't provide some master copy somewhere).
These files make all systems appear as similar as possible.
All locally supplied software hangs from /usr/local, with user-oriented
executables in /usr/local/bin, which is put on the standard path.
We set up mail so that all systems send out mail as if it came from the
real mail handling node (the one with /usr/spool/mail on it), so that
it always gets sent back to the proper node. Also, our nameserver uses
the MX records for all hosts to point to the proper mail node
so that even if someone does try to send to another node, it should be
delivered to the mail node.
Each node has its own outgoing mail queue area, so mail can still be
"sent" even if the mail node has gone bye-bye.
(Printing is set up the same way, with local queueing directories on
each node so files can be "printed" any time, even if the node that
has the printer attached is out of action.)
--
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system at alchemy.chem.utoronto.ca
Tel: (416) 978-7094 Fax: (416) 978-8775
------------------------------
From: Dave Sill <de5 at de5.ctd.ornl.gov>
We have a fleet of UNIX, VMS, and IBM (mainframes) systems. My
personal responsibility is (UNIX) workstations.
A master account database resides on one of the IBM's. Passwords and
IDs are distributed via various mechanisms to other "central" systems.
All of our ID's are three characters, of the form:
[A-Z][A-Z1-9][A-Z1-9]
(Notice no zero's). That allows 26*35*35=31,850 total possible ID's.
ID's are never reused. Usually they're are based on initials. On
UNIX systems, the numeric uid is determined by assigning
A=0,..,Z=25,1=26,..,9=34, and applying the formula:
uid=((first_char*35)+second_char*35)+third_char+150
So ID aaa would have UID 150, and ID z99 would be 31999. This leaves
0-149 free for various system IDs such as root, news, system, etc.,
and fits nicely under POSIX' maxuid of 32000. It's very convenient
being able to generate the ID from the UID and vice versa.
Aliases are set up that allow mail to be sent to longer "mail names"
of the form LASTFM (lastname first-initial middle-initial). E.g., my
name is David E. Sill, so my mail name is sillde. Of course there are
conflicts...
A modified version of the `whois' command allows employees to look up
other employee's usernames, mail names, phone numbers, etc.
We have no GID mechanism in place at all, it's totally system dependent
at this time.
[Resource accounting] also system dependent.
[Removal of obsolete login names] handled on centralized systems by the
IBM account database.
Passwords are pseudo-randomly generated on the IBM system. Users
can't change their passwords.
We don't have [consistent user environment.] Yet.
All mail to users on a different system goes though ornl.gov, which
knows where everyone receives mail. UNIX systems have alias files
that accomplish this.
--
Dave Sill (de5 at ornl.gov)
Martin Marietta Energy Systems
Workstation Support
------------------------------
From: whaley at elbo.ucs.ubc.ca (Paul Whaley)
In reply to your request about account management, University Computing
Services of the University of British Columbia is embarking on the
offering of a generally available unix service, in addition to a
specifically numerical- intensive unix service. The general service is
offered on a small group of Sun and SGI servers, while the numeric
service is on an IBM 3090 using AIX/370.
We are using an adduser program which is a modified form of the one
from Boulder.
[Consistent login names] is managed by the adduser junk, after some
hassles and continuing inconsistencies in the system-related
(vendor-supplied) ids.
The adduser junk comes with a uniquid daemon and network service to
try to manage the uid and gid space.
We have put together our own system for collecting the resource usage
data. It is based on the usual runacct-style collection, but it doesn't
use the pacct data (we keep this too, though, for an audit trail).
Instead the data is derived from sampling the system periodically -
currently at every 5 seconds. We do this because the pacct data doesn't
contain the data we want. We have a policy of encouraging people to
"nice" their jobs by giving them a cut rate depending on the nice value
that they are running at. In our environment of cost-consiousness this
(and perhaps more) is necessary to encourage use of the services.
Since ours is a fairly new service, we haven't had to face up to
[removal of obsolete login names] yet...
We have some virtuous plans, as yet unimplemented, to run such things
as the COPS package to check for security-related problems...
Not sure what you meant by [consistent user environment,] but we do
supply default .cshrc files and such that attempt to make the systems
feel somewhat similar.
There is a project currently ongoing to plan a campus-wide email
strategy. The unix services we offer will probably be used as
POP servers for the many personal machines on campus. On the unix
services themselves we will probably be offering both ean (a locally
developed X400 email system) and the usual mail.
Paul Whaley Internet: whaley at staff.ucs.ubc.ca
Academic Operating Systems UUCP: ...!ubc-cs!mtsg.ubc.ca!Paul_Whaley
University Computing Services BITNET: USERWHAL at UBCMTSG
U. of British Columbia Phone: (604) 228-3976
------------------------------
--
peace. -- Ed
"Vote. Because it's the Right Thing."
More information about the Comp.unix.large
mailing list