An alternative plan for principal mapping

[S Rahul]

Hi,

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

Yes. The admin can choose not to apply user's login policy to the
principal. About having a krb specific login policy for the principal
... when a principal belongs to a user, shouldn't the principal inherit
the login policy of the user (set in the directory) ?

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

I agree that invoking some LPP API from the KDC to enforce login
policies is a straight forward way of performing login policy checks in
the KDC. But (user) principals have to get directory login policy
through their association with (through link or aux class) user objects
in the directory. I don't think such a principal should be independently
associated with a login policy.

Moreover, I don't think the LPP should read all the login policy
attributes from the directory and use it to enforce the policy. That is
the job of the directory. Duplication of the authorization code in the
KDC should not be done. One way to make use of the directory for
performing login policy checks is to have the directory provide LDAP
extensions / controls for performing the checks (and for updating the
directory with the result of the authentication).

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

Yes. The service need not follow the link if the KDC can generate the
PAC (by PAC I am referring to general authorization data and not to MS
PAC). But the KDC will have to follow the link to generate the PAC.

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

It is not currently needed by KDC for generating PAC. But if the links
are added now, then deployments will be able to make use of it when a
future version of KDC supports generation of a PAC containing directory DN.

As for the login policy part, we have Novell eDirectory specific patches
to the LDAP plugin for enforcing user login policies on Kerberos
principals belonging to the user. It makes use of two LDAP extensions -
one extension for each of the two proposed LPP calls above.

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

No. The realm object (under the DN specified using
'ldap_kerberos_container_dn') points to a realm subtree under which all
principals are created by default. This can be overridden by using the
'containerdn' argument to 'addprinc'. Any container in the realm subtree
can be specified during principal creation. The new principal object
will be created under that container. Though the command accepts the DN
of the container instead of the principal itself, it is effectively same
since the principal objects DN can be derived from the container DN and
the principal name.

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

Hmm ... that is reasonable. But it will introduce an additional argument
to kadmin addprinc. Is that ok ? One problem I can see with this
approach is while adding a second Kerberos principal to a directory
user. The admin will receive an error (since there is already a
principal on the user) and he will have to retry ... this time creating
a separate principal object.

-Rahul S.