An alternative plan for principal mapping

[Will Fiveash]

On Fri, Jul 28, 2006 at 11:03:10AM -0600, Rahul Srinivas wrote:
> Hi,
> 
> > 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
> is needed for two reasons.

> 1. The KDC should apply the user's login policies and password
> policies to the principal. 

I don't think "should" is appropriate here.  The KDC could apply some
non-krb specific login policy if the admin has configured it to do so.
Or it could apply a krb specific login policy (which isn't supported by
the current schema but should be).

This relates to something I brought up before on this list and that is
support for login policy plugins (LPP).  Note, this is distinct from
password policy.  The KDC would interact with a LPP in two ways:

1. To determine that the login policy allows issuance of a ticket to a
   requesting principal.  The LPP would deal with the specifics of
   acquiring the login policy and determining whether the principal's
   login activity conforms to the policy.
   
2. To record a success or failure when verifying the AS_REQ padata.
   Again, the LPP would deal with the specifics of updating 

Regarding item 1, given that the KDC would pass the principal name to
the LPP, the LPP would need some way to map the principal name to a
login policy.  I can see that a link from a krbprinc object to an
associated user object could be useful assuming there was a way to find
the login policy given the user object.  Or perhaps the link attribute
should be a login policy reference and support mix-in with any
structural object that required association with a login policy.  Login
policy lookup would be more straightforward in that case.

In either case I wonder if a login policy link attribute belongs in the
krb schema or some other schema associated with login policy mapping
since this is a broader issue.

> 2. When the principal authenticates to a service, the service will use
> the link to find which user the principal belongs to and grant
> appropriate access.

Well "will use" is presumptuous.  What if the KDC provides PAC like
PADATA in the service ticket that contains the user name/ID?
In either case, I could see the advantage to providing an efficient way
to map a krb princ to a user object.

Again, this is a future enhancement.  A link from a krbprinc object to a
non-krb object entry is not needed currently by the KDC.  So, do we need
to worry about this now?  Note that this creates another opportunity for
referential integrity problems.

> Since it is the KDC which needs the link (reason 1 above), it should
> also be able to create it. Moreover, principals linked to a directory
> object have the same 'status' as principals added to the object
> (through auxiliary class). The link is to be used only when the
> principal can't be directly added to the directory object. So, if the
> LDAP plugin can add a principal to a user (through 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
> >    from.
> >
> > 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
> >   error.

Are you saying that one could create a krbprinc structural object using
an arbitrary DN?  Doesn't the LDAP plugin have an assumption that these
object be contained by a realm container object which in turn is
expected to be found under whatever DN the ldap_kerberos_container_dn is
assigned?

Also, I have a concern about control over whether krb princ attributes
are mixed-in to an existing object or used in creating a new krb princ
structural object entry.  More below.

> > 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
> flexibility while creating principals. In fact, except for the 'link'
> part, the current LDAP plugin does this. You can use some LDAP based
> tool for creating principals with only the principal name attribute
> value set. 'modprinc' can be used to add the rest of the Kerberos
> attributes later.
>
> The problem is that the two step process - creating an empty principal
> and then populating it, can only be used for adding individual
> principals. If the 'load' functionality is supported, then this will
> become very difficult for the administrator. He will have to manually
> create a placeholder for each principal in the dump before 'load'ing.

We should decide how kadmin/kadmin.local is to work with the LDAP
plugin.  I also worry about assuming that control over whether krb princ
creation causes krb princ attributes to be mixed in to an existing
non-krb object entry or causes a new krb princ object entry to be
created will be left to a LDAP directory tool.  In other words the LDAP
directory tool will need to populate the krb princ name attribute in a
non-krb object entry in order for the kadmin addprinc command to mix-in
the krb princ attributes.

While I agree with Sam's proposal on most points, I feel that
kadmin/kadmin.local be able to to specify mix-in or not on the addprinc
operation and return an error if this is not possible.  If the admin
does not specify a preference for mix-in/new krb object, then the LDAP
plugin should fall back to the behavior that Sam described above.

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