An alternative plan for principal mapping
hartmans at MIT.EDU
Thu Jul 27 08:23:28 EDT 2006
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
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.
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.
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
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
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.
More information about the krbdev