home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.protocols.kerberos
- Path: sparky!uunet!sun-barr!cs.utexas.edu!sdd.hp.com!ux1.cso.uiuc.edu!usenet.ucs.indiana.edu!logos.ucs.indiana.edu!hughes
- From: hughes@logos.ucs.indiana.edu (larry hughes)
- Subject: Re: New User Accounts
- Message-ID: <Btyv94.Ky6@usenet.ucs.indiana.edu>
- Sender: news@usenet.ucs.indiana.edu (USENET News System)
- Nntp-Posting-Host: logos.ucs.indiana.edu
- Organization: University Computing Services News
- References: <9209020104.AA25528@windsail.nersc.gov> <1992Sep2.162020.14082@news.columbia.edu>
- Date: Wed, 2 Sep 1992 19:53:28 GMT
- Lines: 29
-
- In article <9209020104.AA25528@windsail.nersc.gov> ramus@nersc.gov (Joe
- Ramus) writes:
- > How do other sites manage new accounts and assigned passwords?
-
- At IU, we used a "volunteer" approach. If you don't volunteer,
- you don't get the benefits of using the distributed workstation
- services.
-
- We wrote an application that users run from a single timeshared
- system (hence we know who they are already). The program queues
- the username (which becomes the principal name) and password
- in a secure way, where it is later processed in batch. I might
- add that we obviously maintain a strict dictionary of usernames
- across our timeshared systems. :-)
-
- The batch job performs a kinit to a privileged principal, and
- sends the principal name and password (all encrypted of course)
- to a server process running on the master Kerberos server. If
- you look in the source for kdb_edit, you'll see that there's
- actually very little code required to add a principal into the
- Kerberos database.
-
- Cheers,
-
- //==================================================================\\
- || Larry J. Hughes, Jr. | hughes@indiana.edu ||
- || Indiana University | "The person who knows everything ||
- || University Computing Services | has a lot to learn." ||
- \\===================================================================//
-