[comp.protocols.kerberos] What are a principal's attributes used for?

jmsellens@WATDRAGON.WATERLOO.EDU ("John M. Sellens") (12/15/90)

A principal in the Kerberos database has an attributes field.  I found
this in kadm.h
    /* Attributes fields constants and macros */
    #define ALLOC        2
    #define RESERVED     3
    #define DEALLOC      4
    #define DEACTIVATED  5
    #define ACTIVE       6
but I haven't seen anything that actually seems to use these attributes.
Does anything?

I'm wondering how to set up classes of users.  For example, imagine a
campus wide Kerberos database.  What happens when someone forgets his/her
password?  Should a student consultant be able to change the password
of a faculty member in another faculty? (and so on).  It might be nice
if there was a way to give (more) different levels of database control to
various people, without having to resort to multiple realms.  Hmmm ...

And on another topic - does anyone have any (available) tools for doing
bulk adds or updates to the Kerberos database?  I'm wondering how to
get a lot of people in without doing a dump and load or something.


John Sellens
University of Waterloo
jmsellens@watdragon.waterloo.edu

jon@MIT.EDU (Jon A. Rochlis) (12/15/90)

   A principal in the Kerberos database has an attributes field.  I found
   this in kadm.h
       /* Attributes fields constants and macros */
       #define ALLOC        2
       #define RESERVED     3
       #define DEALLOC      4
       #define DEACTIVATED  5
       #define ACTIVE       6
   but I haven't seen anything that actually seems to use these attributes.
   Does anything?
   
I don't think so.

Athena's Moira registers users in a 2 step process.  It creates the
principal with a null key and stores it's unix uid in the attributes
field.  Then it asks the user for a password and set's the principal's
key (the existing key should be null and have the expected attribute
field).  That's the only use of the attributes field that I'm aware of.

   I'm wondering how to set up classes of users.  For example, imagine a
   campus wide Kerberos database.  What happens when someone forgets his/her
   password?  Should a student consultant be able to change the password
   of a faculty member in another faculty? (and so on).  It might be nice
   if there was a way to give (more) different levels of database control to
   various people, without having to resort to multiple realms.  Hmmm ...
   
We've been doing some thinking about that.  Ted T'so came up with a
good scheme of putting user's in groups (bits in an attributes-like
field).  Administrator's could be given access to modify certain groups
... a simple "and" is all you need to determine whether an
administrator can make a change.

   And on another topic - does anyone have any (available) tools for doing
   bulk adds or updates to the Kerberos database?  I'm wondering how to
   get a lot of people in without doing a dump and load or something.
   
We don't.  Unless the Moira registration program counts.  You give it
your name and MIT id and it will create a principal (and lots of other
non-kerberos stuff) if that name/id appear in a database supplied by
the Registrar and Personnel offices.

Other than that we generate the dump files, awk/sed/join them to our
hearts content and then reload.  If you've got a slave then you don't
need to have any downtime.

		-- Jon