princ to DN mapping rules (was Re: concerns with ldap plugin and 1.5

[S Rahul]

You have captured most of the idea. But there are other ways a Kerberos 
principal can be mapped to a directory object.
1. Based on an attribute like 'cn' which may not be the naming attribute 
of the user object's DN.
2. Part of an attribute value matching part of a principal name. For 
example, if  the directory has an 'email' attribute defined, I will have 
to map a principal 'srahul at REALM' to a user object containing the email 
ID 'srahul at something.com'. Here, the rule will be "match the first part 
of the principal name with anything before '@something.com' in the email 
attribute'.
3. Rules like <user>@REALM matches the directory object with 
'cn=<user>*'. This type of rule will require a substring based search 
filter to be constructed and used in an 'ldapsearch'.

In addition to this, collisions must be resolved by the admin. For 
example consider the case where 'cn=user1,o=abc' and 
'cn=user1,ou=def,o=abc' both exist and the principal name is 
'user1 at REALM'. If the plugin implements this, we have to provide a 
mechanism by which the plugin gets admin input.

I think it is not good to put all this functionality inside the LDAP 
plugin. It is not a straightforward database write. Multiple LDAP 
searches (possibly substring matches) are performed and each search is 
followed by a series of comparisons. The LDAP plugin's 
'db_put_principal' implementation should just add the principal using an 
LDAP modify operation and not be concerned with all this logic.

-Rahul S.

Will Fiveash wrote:
> On Fri, Jun 09, 2006 at 06:03:45PM -0700, Henry B. Hotz wrote:
>> On Jun 9, 2006, at 5:25 PM, Nicolas Williams wrote:
>>
>>> On Fri, Jun 09, 2006 at 04:53:10PM -0700, Henry B. Hotz wrote:
>>>> You ought to be able to infer the dn from the principal name, based
>>>> on the (probably default) realm's configuration information.  In
>>>> other words "add hotz" should do the right thing.
>>> You can't always, not at principal creation time.
>>>
>>> The problem is that the kadmin create_principal command, and the
>>> protocol itself lack a way to convey principal type information.
>> The two main "types" (my definition, possibly not yours) are "users"  
>> which are a single component name+realm, and "services" which are a  
>> two-component name where the second is a FQDN.  Seems easy enough to  
>> infer which is which.  Maybe you've got some other things like */ 
>> admin and */batch that get mapped differently, but that should be  
>> generic config info, not something you have to put on a kadmin add  
>> command IMO.
>>
>>> Without principal name type information there are situations where the
>>> intended principal name type, and therefore, possibly, LDAP class  
>>> and DN
>>> of the intended LDAP object, cannot be unambiguously determined.
>> I think the special cases like kdamin/changepw and krbtgt/* could  
>> require extra options for correct handling.  They need special  
>> handling anyway.  Be better if they don't though.
>>
>> Is that what you mean?
>>
>>> foo at BAR.COM might be intended to be a user principal, if a user exists
>>> with the name 'foo' in that organization.  Then again, this might be
>>> something else.
>> Yeah, but do we have to make everything hard just to be able to  
>> handle the oddball stuff?
> 
> It would be nice if we could provide princ to DN mapping rules to the
> LDAP plugin where the rules could map specific principals to specific
> DNs and also provide more general rules.  Ordered rules like:
> 
> ####################################################################
> # specific krb princ    DN 
> kadmin/admin at ACME\.COM  "krbprincipalname=kadmin/admin at ACME.COM,cn=ACME.COM,cn=krbcontainer,dc=sun,dc=com"
> 
> # Note that the % in the DN will be replaced by the matched regex
> # enclosed by %% on the left side.
> # 2 component krb admin principal  matching DN
> %[^/]+%/admin at ACME\.COM            "uid=%,ou=people,dc=sun,dc=com"
> 
> # any single component princ not matched above.
> %[^/]+%@ACME\.COM  "uid=%,ou=people,dc=sun,dc=com"
> ####################################################################
> 
> The above is just an example so don't take the syntax too seriously.
> 
> Note, I'm not sure whether an heuristic of creating a krbprincipal
> object if the DN is not found is flexible enough (I am thinking that if
> the object did exist then the princ. auxiliary attribute would be
> updated).  If this heuristic isn't adequate then perhaps the object
> class can also be given as a rule parameter.
> 
> The rules could either be located in a local flat file or in a directory
> object and a krb5.conf dbmodules parameter could tell the ldap plugin
> where to find the rules.
> 
> Something along these lines would (I hope) allow "kdb5_util load" to
> migrate entries in a KDB dump to any DIT and also allow kadmin to work
> in a more plugin transparent fashion.
>