LDAP schema questions

[K.G. Gokulavasan]

>>> On 6/7/06 at 9:55 PM, in message
<1149697541.650.11.camel at amy.samba4.abartlet.net>, Andrew Bartlett
<abartlet at samba.org> wrote:
> On Wed, 2006-06-07 at 06:01 -0600, K.G. Gokulavasan wrote:
>> >>> On 6/7/06 at 4:29 AM, in message
>> <1149634758.20633.13.camel at amy.samba4.abartlet.net>, Andrew
Bartlett
>> <abartlet at samba.org> wrote:
>> > Sorry to be coming late to this discussion, but as I've just been
>> tasked
>> > with working with the MIT Kerberos LDAP backend, and I have some
>> > questions and concerns as to the schema:   (I have the schmea
from
>> > current SVN, noted as Version 1.3, 2005)
>> > 
>> > In particular, I'm surprised by the format of the krbSecretKey
>> > attribute:
>> > 
>> > It seems to me that about a dozen different attributes have been
>> placed
>> > into this attribute.  Why is a such a complex structure used? 
The
>> > Heimdal schema (which I am more familure with) encodes many of
these
>> as
>> > separate attributes.  I'm thinking in particular of the times:
why
>> not
>> > use pwdLastSet, or at worst a 'krb5KeyLastSet'?  Likewise, why is
>> there
>> > duplication between the krbPrincipalName and part of the
>> krbSecretKey?
>> > 
>> > Likewise, why are the keys not in a multivalued attribute? 
(Heimdal
>> > uses an asn1 structure to combine the key and salt, then places
them
>> > into each value of the multivalued attribute)
>> >
>> Keys are multivalued attributes. But each value will be pertaining
to a
>> kerberos principal identity. Each user in the directory can have
more
>> than one principal identity(same realm or different realms). All
the
>> different keys(e.g.des,des3,aes) of same version of a principal will
be
>> stored in each value of the krbSecretKey attribute. All the
principal
>> identities information are stored as part of User instead of cross
>> referencing for ease of administration. All the key related
>> information(key,key type, salt,salt type, key version, master key
>> version, last password change) of a principal are part of the
>> krbSecretKey attribute.
>> 
>> krbPrincipalName is part of the krbSecretKey to map the principal
with
>> the key.
> 
> Why not reverse the problem, and have multiple entries in LDAP, one
per
> principal?  If need be, an attribute could be created to point to
the
> 'user' that the principal authorizes as (if different), but this
> shouldn't concern the KDC. 
> 
> This would create a far more 'natural' LDAP look.
> 
Having a separate ldap object for each principal will lead to user's
information distributed in more than one object in directory. It may
lead to dangling principal objects when the "user" object is deleted.
Having all the user's information in a single object will help in
administration.

>> > Also, the document specifies many time attributes, but I'm
unclear
>> what
>> > all the time formats are.  In particular, is krbMaxPwdLife in
>> seconds?  
>> > 
>> krbMaxPwdLife is the number of seconds (of the duration) that is
added
>> to the Last Password Change value to compute the password
expiration
>> time
> 
> Yeah, that was just a nit-pick.  The schema file should be updated
to
> reflect that, just for clarity.

I will update the document for clarity.

Regards,
 Gokul.