LDAP schema questions

[Will Fiveash]

On Tue, Jun 13, 2006 at 05:44:30AM -0600, K.G. Gokulavasan wrote:
> 
> >>> On 6/10/06 at 10:05 PM, in message <tslbqt1x93b.fsf at cz.mit.edu>,
> Sam Hartman
> <hartmans at MIT.EDU> wrote:
> >>>>>> "Jeffrey" == Jeffrey Altman <jaltman at columbia.edu> writes:
> > 
> >     Jeffrey> All of these principals must be associated with my user
> >     Jeffrey> account since their usage specifies actions performed
> by
> >     Jeffrey> me.
> > 
> > 
> > Sure, but it seems that perhaps one principal could live in the user
> > object and the rest could be linked to the user object.
> > 
> If we like to use some common attribute across all identities, then it
> may involve more than one ldap search. For e.g., if we want to use "Last
> Password Change" attribute on the User object for kerberos principals
> also, then it will involve first ldap search to find the user object
> from the principal object(using the link) and then another search to
> find the value from the user object. So to get additional principal
> information from User object or to get any User information from the
> additional principal object will involve more than one ldap search.
> Moreover if we want to have a common password and synchronize it across
> other identities(kerberos keys), then whenever the user password is
> changed, all the principal object's kerberos keys have to be changed.
> This will end up in updating more than one object and we have to
> maintain atomicity here. Otherwise there will be inconsistency with
> respect to password.

Just as a refresher, the current Novell/MIT schema has this:

###### The principal data auxiliary class. Holds principal information
###### and is used to store principal information for Users and any services.
dn: cn=schema
changetype: modify
add: objectclasses
objectClasses: ( 2.16.840.1.113719.1.301.6.8
                NAME 'krbPrincipalAux'
                AUXILIARY
                MAY ( krbPrincipalName $ krbUPEnabled $ krbSecretKey $
                      krbPolicyReference $ krbPrincipalExpiration $
                      krbPasswordExpiration ) )

###### This object is created to hold principals of type other than USER.

dn: cn=schema
changetype: modify
add: objectclasses
objectClasses: ( 2.16.840.1.113719.1.301.6.9
                NAME 'krbPrincipal'
                SUP ( top )
                MUST ( krbPrincipalName )
                MAY ( krbPrincipalType )
                X-NDS_NAMING 'krbPrincipalName'
                X-NDS_CONTAINMENT ( 'organization' 'organizationalUnit'
                                    'domain' 'krbRealmContainer'
                                    'country' 'locality' )
                X-NDS_NOT_CONTAINER '1')

#######################################################################

All the principal attributes are in the aux. class krbPrincipalAux and
can be mixed with arbitrary structural object classes.

While krbSecretKey contains the principal name to associate it with a
principal, the other attributes do not.  I'm assuming then that the only
way to associate more than 1 principal with a user requires use of a
krbPrincipal object if the krbPrincipalAux attributes differ between the
principals.  Is this correct?

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