concerns with ldap plugin and 1.5

[Nicolas Williams]

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:
> 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.

Not that simple.  We're talking about a KDC for the Kerberos V protocol.

The KDC that MIT has had so far didn't need to know about name types
because that made no difference to it as far as how to represent those
principals in the KDB, nor did it make a difference on the wire as krb5
name types are hints.

You can understand, I'm sure, how the representation of different types
of principals might differ in a different KDB design, one where the
distinction between "user," "user-like," "hostbased service,"
"realm/domain-based service," and ad-hoc types is semantically
significant.

Then here's the question MIT has to grapple with: given multiple,
significant choices for representing principals, and given a need to
pick one of these choices at certain times, how should their product
deal with making that choice, particularly given a protocol
specification that doesn't provide reliable heuristics for making that
choice.

> >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?

Sort of.

A simple heuristic is:

 - one-component principal names are user principals

 - two-component principal names where the first component is "krbtgt"
   are TGS names

 - two-component principal names known to be special a priori
   (e.g., kadmin/changepw) are what they are and a list can be hardcoded

 - two-component principal names where there are at least N (one, say)
   periods in the second component are hostbased principals

 - for all other principal names fail; the admin must provide some name
   typing information

That's fine for a default heuristic.  But it does make the KDC a lot
less flexible to just hard code it in.

So, I think a heuristic and an option that can override it should do.

> I don't know much about MIT's "policy" data.  Does it help if you  
> associate the necessary LDAP mappings with that data instead of the  
> realm?

I'm not sure what we;re talking about here.