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

[S Rahul]

Specifying rules with such wildcards will definitely be useful in the 
following case. The administrator has an existing LDAP directory with 
users. He is maintaining an attribute (or an attribute set) whose values 
are unique in the LDAP database (not supported by LDAP server itself). 
He is maintaining a separate Kerberos database. He has derived the 
Kerberos principal names from the unique attribute values in the tree. 
In such a case he can put down his rule in a file and 'load' principals 
from the Kerberos database into the directory.

But, if the administrator is newly Kerberizing existing  users in a 
directory through 'kadmin', he would be aware of which user he is 
associating the principal with and can provide the user's DN with the 
'add_principal' command itself.

Since this 'intelligent' mapping functionality is mainly going to be 
used for 'load' (a one time operation), it is not correct to implement 
it in 'db_put_principal'. However, a file containing a mapping of 
Kerberos principal names to directory DNs (the first type of rule 
suggested by you under the heading "specific krb princ DN") might help 
retain the original 'kadmin' interface (without the -x userdn=<DN> kind 
of arguments to 'put_principal').

Moreover, rules for mapping principal names to DNs can not be written if 
there is no unique attribute (or attribute set) in the tree.

-Rahul S.

Will Fiveash wrote:
> On Tue, Jun 13, 2006 at 12:10:39PM +0530, S Rahul wrote:
>> 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'.
> 
> A rule syntax that allows for a princ to directory entry mapping using
> search criteria other than the DN would be useful.
> 
>> 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.
> 
> I'm not convinced.  My feeling is that if the rule semantics/syntax is
> well designed then admin interaction should be rare unless the directory
> DIT is poorly designed.  The DAL interfaces should be such that
> ambiguity errors as you describe should be passed back to the utility
> (kadmin, kdb5_util) and at that point the admin will have to sort it
> out.  This would allow existing KDB user interfaces to work in a more
> plugin transparent way.
> 
> Besides, db_put_principal() isn't done that often compared to
> db_get_principal().
>