[3403] in Kerberos

home help back first fref pref prev next nref lref last post

Re: removing users from the kerberos database

daemon@ATHENA.MIT.EDU (Jon A. Rochlis)
Tue Jun 14 13:14:36 1994

To: spgmnf@cmsa.Berkeley.EDU (Mike Friedman (510) 642-1410)
Cc: kerberos@MIT.EDU
In-Reply-To: Your message of "Mon, 13 Jun 1994 15:26:10 PDT."
             <16FD4D91D.SPGMNF@CMSA.BERKELEY.EDU> 
Date: Tue, 14 Jun 1994 11:03:02 -0400
From: "Jon A. Rochlis" <jon@cam.ov.com>


  The MIT distribution of Kerberos V4, by intention, does not provide a utility
  to delete principals from the database.  The reasoning is that you may later
  assign the same principal name to another person, who might be able
  to acquire archived files belonging to the original owner of the principal
  name. 

Actually a lot of MIT's reasoning deleting a user is dangerous. If you
automate it, then you may well walk in one morning and find all of
your users deleted.  Not re-using ID's is another reason, but MIT
recylces ID fairly frequently.

 It can be done, however.  As a user (eg root) with R/W access to the database,
 first do a 'kdb_util dump' of the database to an ASCII file, edit the file and
 then do a 'kdb_util load' back to a new copy of the database.  Kerberos had
 better not be in use when you do the latter!
    
There is no problem with doing a "kdb_util load" while the KDC is
running.  This is how the slaves are updated.  "kdb_util load" builds
another dbm database and plays the rename game.  The Kerberos server
is on the lookout for the database changing out from underneath it.

 This is not a very nice method, of course.  What's really needed is a database
 management system.  Commercial implementations of Kerberos usually come with
 such a thing.
   
MIT was also more interested in doing mass deletions than doing one
at a time.  I.e. the senior class has just graduated.  Those
operations are best done very carefully and doing a dump, join with a
user management db/load cycle makes you think carefully about what
you are doing.  To deal with the one shot deletions MIT just
"deactivates" a user in its user/service management system (Moira).
This allows "reactivation" if it turns out the person shouldn't have
been deleted in the first place.  Otherwise the next (manual) purge
will remove all traces of the users from the Moira, Kerberos, file
servers, etc.

		-- Jon

home help back first fref pref prev next nref lref last post