An alternative plan for principal mapping
srahul at novell.com
Fri Jul 28 13:03:10 EDT 2006
> 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.
A link between a Kerberos principal object and a directory user object
needed for two reasons.
1. The KDC should apply the user's login policies and password policies
2. When the principal authenticates to a service, the service will use
to find which user the principal belongs to and grant appropriate
Since it is the KDC which needs the link (reason 1 above), it should
able to create it. Moreover, principals linked to a directory object
same 'status' as principals added to the object (through auxiliary
link is to be used only when the principal can't be directly added to
directory object. So, if the LDAP plugin can add a principal to a user
auxiliary class), it should also be ablr to create links.
> 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.
The schema we have come up with does fit this model. The only mandatory
attribute in the auxiliary class is 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
> 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.
I agree that this technique will give the administrator a lot of
while creating principals. In fact, except for the 'link' part, the
LDAP plugin does this. You can use some LDAP based tool for creating
with only the principal name attribute value set. 'modprinc' can be used
the rest of the Kerberos attributes later.
The problem is that the two step process - creating an empty principal
populating it, can only be used for adding individual principals. If the
functionality is supported, then this will become very difficult for the
administrator. He will have to manually create a placeholder for each
in the dump before 'load'ing.
PS: My mail server appears to be dropping mails randomly. I haven't
original mail. So I am sending a new mail instead of replying to the
More information about the krbdev