LDAP schema questions

[Luke Howard]

>###### 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')

Is this supposed to be STRUCTURAL? This should be specified in the schema
defintion.

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

That seems to make sense to me, although it puzzles me why krbPrincipalType
is here and not in krbPrincipalAux. Where does the principal type come from
if krbPrincipalAux is associated with another object class, such as person?
Is it assumed to be a fixed value? What if I want to use another structural
object class with a different name type?

(Also, let's be careful not to let any eDirectory assumptions creep in, eg.
Universal Passwords cf. krbUPEnabled, the "user" object class, etc.)

Generally you would use some attribute like "seeAlso" to associate a
principal with a user but generally this would a deployment decision
and out of scope for discussion here.

-- Luke

--