Path: utzoo!attcan!uunet!ns-mx!ccad.uiowa.edu!emcguire From: emcguire@ccad.uiowa.edu (Ed McGuire) Newsgroups: comp.unix.large Subject: Re: user account management (LONG) Summary: results of survey Keywords: user account management Message-ID: <1990Oct8.173535.16792@ccad.uiowa.edu> Date: 8 Oct 90 17:35:35 GMT References: <1990Sep12.205016.16803@ccad.uiowa.edu> Organization: CAD-Research, U. of Iowa, Iowa City, Iowa Lines: 334 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@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@cme.nist.gov (Don Libes) Their "expect" automates interactive programs like "passwd", facilitating (for example) changing password on several machines at once. From: Kandler They are developing a central database server permitting a decentralized approach to account management. From: Ed Anselmo Their "udb" tracks users, uids, mailboxes, mailing lists, machines, serial numbers (among other things). From: poepping@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) 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 They have an IBM based master account database, a modified `whois' with "white pages" capability, and central mail server. From: whaley@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@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@ecn.purdue.edu BELL: 317-494-3473 ------------------------------ From: libes@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@cme.nist.gov ...!uunet!cme-durer!libes ------------------------------ From: Kandler 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@informatik.tu-muenchen.dbp.de Postfach 20 24 20 Telefon: +49 89 2105 2025 D-8000 Muenchen 2 ------------------------------ In article <26107@cs.yale.edu> anselmo-ed@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@cs.yale.edu {harvard,cmcl2}!yale!anselmo-ed ------------------------------ From: poepping@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@sei.cmu.edu Software Engineering Institute (412) 268-6392 Pittsburgh, PA ------------------------------ From: System Admin (Mike Peterson) 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@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775 ------------------------------ From: Dave Sill 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@ornl.gov) Martin Marietta Energy Systems Workstation Support ------------------------------ From: whaley@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@staff.ucs.ubc.ca Academic Operating Systems UUCP: ...!ubc-cs!mtsg.ubc.ca!Paul_Whaley University Computing Services BITNET: USERWHAL@UBCMTSG U. of British Columbia Phone: (604) 228-3976 ------------------------------ -- peace. -- Ed "Vote. Because it's the Right Thing."