ddk@lanl.gov (David D Kaas) (03/09/90)
Our site has a CRAY xmp, a large UNIX mini and several dozen workstations. My department currently only has administration control over the CRAY, mini and a SUN used as an ftp gateway, but we expect this to change in the future. We now administer the user-names/uids across the machines manually but would like to centralize this. We would also like to add to this control of hostnames, ip addreses, NQS host names etc.. We know of yellow pages but have heard that it has some security holes. What is available? What do other sites use? Thanks in advance Dave Kaas Boeing Computer Services Richland D. O. E. Richland, WA 99352 (509) 376-6386 e41126%rlvax3.lanl.gov -- Dave Kaas - D.O.E. Richland, Wa. e41126%rlvax3.xnet@lanl.gov
davecb@yunexus.UUCP (David Collier-Brown) (03/09/90)
ddk@lanl.gov (David D Kaas) writes: > We now administer the user-names/uids across the machines >manually but would like to centralize this. We would also like >to add to this control of hostnames, ip addreses, NQS host names etc.. >We know of yellow pages but have heard that it has some security holes. >What is available? What do other sites use? NFS-mount critical/shared files. This has the following tradeoffs... advantages: it's substantially faster very visible (ie, you do a mount and see where something comes from) reliable secure as nfs (which isn't anything to write home about...) widely supported (much more than yellow pages) disadvantages: it's a single point of failure (fallback is easy, though) dependant on NFS semantices (not unix semantics), and necessary to write your own passwd/chsh/chfn/mkuser --dave -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
mascio@math-cs.kent.edu (John R. S. Mascio) (03/09/90)
Here at Kent State University, we have a simiular problem with uid administration (locally known as "the !@#$% networked password file!") We have the password file distributed about once an hour via rcp in crontab by the local machines. This way the local macine is responsible for updating itself. If it crashes, the rest of the net is (relativly) unaffected. The crashed machine will update itself when it comes back up. The master host runs a daemon to handle passwd/chsh/chfn requests. When a user on a machine runs passwd/chsh/chfn, they are running a client frontend which goes through all the motions of the originals, but then passes the info to the daemon on the master host and lets the daemon worry about the actuall change to the file. At the moment, I am about half done with it. I need to secure the data transmissions better and insure against daemon crashes. If you may be interested contact me at "mascio@cs.kent.edu". I hope this helps. JRSM --- John Raymond Stone Mascio (mascio@cs.kent.edu) KSU Department of Math/CS, KSU Merrill Hall Kent, Ohio 44242 USA Bus # (216) 672-2077 / 672-2430
kimery@orchestra.ecn.purdue.edu (Sam Kimery) (03/10/90)
Here at the Purdue Engineering Computer Network (ECN), we are using
software known as ACmaint, which was written in house. In an attempt to
keep this brief, I'll give the "glossy" description of ACmaint. Those
wanting more detail may contact me (kimery@ecn.purdue.edu).
Currently ACmaint controls about 400 machines (all at ECN). There are
about 12,000 users with 90,000 accounts. Each Fall about 2,000 new
accounts are added, with 1,000 (or so) accounts deleted each summer.
ACmaint uses a daemon on each machine under its control (TRANSD) and a
single daemon that controls a central database (DBD). ACmaint controls
all user accounts. Some items are maintained as "common" to an login
(eg: uid, login, fullname, etc) and changes to these
cause changes on all machines the user has an account on. Other items
are consider to be "per machine" and are stored seperately (eg: gid,
passwd, shell, homedir, etc). Changes to the per-account information
are only transmitted to the machines effected. All changes occur
immediately (or reasonably close :-)). Fun things like changing the
root password, which used to take 3+ hours to do, now consumes less than
1 minute of a "human" time, and is completed in less than 20 minutes
(network wide).
ACmaint also understands the things that it must do in order to
create/delete an account and several local "features."
There are several front-ends to ACmaint:
The most commonly used by standard users is through modified versions of
the standard commands (eg: passwd, chsh, chfn, etc) that contact the DBD
rather than update the local copy of /etc/passwd. These commands have
also been modified to allow the use of a new flag ('-n')
which causes the change to take place 'netwide'. A good example would
be 'passwd -n barfoo'
which would cause the password for the user 'barfoo' to be changed on
every machine (under ACmaint's control, of course) - with the exception
of the '-n' flag, the command interacts
the same as the standard Unix /bin/passwd.
The administrative front end is known as AH (account handler) and allows
a system administrator to manipulate (create/destroy/change) accounts
from any machine on our network.
The current version of AH support the following commands:
! - execute shell command
# - a comment, the entire line is ignored
= - set a default value or assign a value to a variable
? - see help
add - add a user to new host(s)
add_group - add user(s) to a group
change - change user information by field
change_group - change group information by field
copy - copy a user from one host to other host(s)
create - create a new account
create_group - create a new group
disable - disable an account
edit - edit last command and re-execute
enable - enable a disabled account
help - print help
log - manipulate log files
message - set a message on an account
quit - quit, exit ah
read - execute commands from a file
remove - remove a user from host(s)
remove_group - remove user(s) from a group
show - show user information
show_group - show group information
terminate - remove a user from all hosts
terminate_group - eliminate a group
unmessage - remove a message from an account
ACmaint has the ability to survive system crashes, and goes to great
length to assure that
no data loss occurs.
ACmaint has run or is running on the following architectures; sun3, sun4
(all), vax 780,
Gould NP-1, Gould 9080, CCI Tahoe, and Sequent Symmetry.
I'm working on the next version of ACmaint, which is expected to be
complete sometime
this summerish. That will be the first publicly available version.
Again, for further details, please contact me (kimery@ecn.purdue.edu)
--Sam
------------------------------------------------------------------------
---------
Sam Kimery - Unix Systems Programmer
Engineering Computer Network - Purdue University
UUCP: pur-ee!kimery ARPA: kimery@ecn.purdue.edu BELL: 317-494-3473fuat@cunixf.cc.columbia.edu (Fuat C. Baran) (03/14/90)
Here at Columbia University we currently have a locally written id
system. All the information associated with a user is kept in an
Ingres (RTI) database. Programs such as passwd, chfn, chsh, etc. are
local versions that start up an Ingres backend (directly on the server
host, and via pseudo-ttys on clients). Ingres runs on a "server" host
and the changes are propagated to all "client" machines.
The current implementation has several shortcomings so it is in the
process of being rewritten from scratch. The new system will have an
Ingres database, and several ISODE applications (e.g. the database
manager which talks to the Ingres backend will be an isode responder).
We are also implementing "reliable queueing" so that clients don't all
have to be up at the same time (problem with the current
implementation).
The new system organizes hosts into clusters. Also there is the
concept of a "person" which can have several users on one or more
clusters. The id system will be tied in to the student registration
system as well as the personnel database. White-pages services as
well as university-wide mail aliases (e.g.
FirstName_LastName@columbia.edu or anything else unique and
reasonable) are going to be implemented.
/etc/group is also maintained in Ingres, and /usr/lib/aliases will be
too (the current system just adds entries for users, but doesn't
maintain the whole database).
Not part of the ID system, but hostname/address administration for
named is also done with Ingres.
--Fuat
Internet: fuat@columbia.edu U.S. MAIL: Columbia University
BITNET: fuat@cunixc Center for Computing Activities
UUCP: ...!rutgers!columbia!cunixc!fuat 712 Watson Labs, 612 W115th St.
Phone: (212) 854-5128 Fax: (212) 662-6442 New York, NY 10025