An alternative plan for principal mapping

[Sam Hartman]

Hi.  I'd like to propose  a simpler plan  for principal mapping.

My goal is to provide the administrator with sufficient tools to
manage their directory but not to enforce any particular information
model.

First, I'd like to decide on abstraction barriers.  It seems
reasonable for the DAL plugin to manage creating new kerberos
structural objects,adding kerberos auxiliary classes to objects,
reading kerberos objects where ever they exist in the directory, and
writing Kerberos objects where ever they exist in the directory.
The DAL plugin should also handle deleting principals.

I don't see why the DAL plugin needs to handle links from kerberos
principals to other objects.  It seems better to move that handling
into the code that understands the other objects and better
understands the information model of the directory.  Kerberos could at
best maintain such links, but Kerberos is going to be no better at
maintaining the links that something else.  And if such links are
useful, it is clear you have a something else.


I also don't think it makes sense to have rules logic for where to
create structural principals.  My assumption is that these rules are
only useful in situations where you have some sort of other account
management system that knows about kerberos principals.  It seems that
system is going to be in a better position to know where principals
belong than any rules.

                         Schema Implications

I think we need two things out of the schema.  The first is a way to
express a link from a directory object to a principal.  I am proposing
that the DAL plugin never create or modify these links, but  I think
they need to exist.

Second, we need a way for management systems to put in a placeholder
for a kerberos principal that does not yet have data associated with
it.  This is especially true for the kdb5_util load case.  In that
case, you want the management system to go populate the directory with
dummy auxiliary classes or kerberos structural objects as appropriate
so that kdb5_util load can just put things in the right place.  One
way to accomplish this would be to make it so that the only required
field in the kerberos principal is the principal name.  Another way
would be to create object classes from which the structural and
auxiliary classes inherit that only include the principal name.

                            DAL Operations

1) Read: search for an object with a principal name attribute as
   specified; use that.

2) Write (but not create): Write to the same place read would read
   from.


3) Delete: If the object is a kerberos structural object, delete the
   whole object.  If the object has a kerberos auxiliary class, delete
   that object class and its attributes.

4.1 Create with DN specified:  If no such dn exists, create it  as  a
  kerberos structural object.  If the DN exists and has no kerberos
  auxiliary class, create one and populate it.  If the DN exists and
  has a kerberos auxiliary class corresponding  to the principal we're
  creating but has no real data, populate it.  (This corresponds to
  the second proposed schema change)  Otherwise  return an appropriate
  error.

4.2: Create with existing object:  If no DN is specified, but an
  unpopulated object (either structural or not) exists with the
  principal name we're trying to create.  Use that object.

4.3: Create with nothing:  Create a structural object in a default
  place for the realm.