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

[Will Fiveash]

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.

-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)