LDAP schema questions

[Andrew Bartlett]

On Thu, 2006-06-08 at 05:43 -0600, K.G. Gokulavasan wrote:
> >>> 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:

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

Is this a problem any more than the dangling groups, which reference a
user?  Cleaning up references is a broader problem, that an
administrator or LDAP vendor has to deal with anyway.

> Having all the user's information in a single object will help in
> administration.

I just don't buy this.  And in any case, if there is the need to keep
these entries close to each other, why not put them 'under' the user in
the tree, ensuring they must be deleted with the user? 

I don't see why these *must* be stored on the user record in this way,
in terms of LDAP design.  That said, I do understand that is may have
been far easier to write the *code* this way, due to the historical
design of MIT kerberos, and a desire to avoid massive changes in
introducing this patch.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20060608/3ca2ac84/attachment.bin