Subject: The correct behaviour of auxiliary object classes

From: Vincent Ryan <[email-masked]>
Date: Wed, 01 Mar 2000 14:01:43 +0000

I'm seeking clarification of how auxiliary object classes are
supposed to operate. My understanding of auxiliary object classes
is that they are designed to be mixed-in with structural object
classes when particular instances of a structural object class
need additional attributes. 

For example, 'strongAuthenticationUser' is an auxiliary class
defined in RFC 2256 and it mandates the 'userCertificate' attribute.
If I want to create an LDAP entry that is both an 'organizationalPerson'
and a 'strongAuthenticationUser' then I should specify both class
names in the object class attribute for the entry. In addition,
as 'sn' is mandatory for the 'organizationalPerson' class and
'userCertificate' is mandatory for the 'strongAuthenticationUser'
class then I must supply both of these attributes too.

Is my understanding correct? 

Should this behaviour be stated explicitly in the LDAP RFCs?

I notice that support for auxiliary classes in Windows 2000
Active Directory deviates from this behaviour. Auxiliary classes
are (permanently) associated with specific structural classes in
the Active Directory schema. The effect is that every instance of
a structural class must contain the mandatory attributes of all
of its associated auxiliary classes. That is, the auxiliary class
is associated with every instance of the structural class. In
addition, auxiliary class names must not appear as values of the
object class attribute of the instance of the structural class.

Can someone from Microsoft confirm that my description is correct?
(Or have I misunderstood how Active Directory operates.)

Do other LDAP server implementors support auxiliary classes differently?

---

From: Mark Wahl <[email-masked]>
Date: Wed, 01 Mar 2000 10:05:01 -0600

> Is my understanding correct? 

Yes.

The LDAPv3 information and operations model is defined by the following MUST 
statement of RFC 2251 section 3.3.

3.3. Relationship to X.500

   This document defines LDAP in terms of X.500 as an X.500 access
   mechanism.  An LDAP server MUST act in accordance with the
   X.500(1993) series of ITU recommendations when providing the service.
   However, it is not required that an LDAP server make use of any X.500
   protocols in providing this service, e.g. LDAP can be mapped onto any
   other directory system so long as the X.500 data and service model as
   used in LDAP is not violated in the LDAP interface.

> the Active Directory schema.

That sounds more like a content rule than an auxiliary class.  Content rules
also provide additional attributes to entries, and they are associated with
structural classes.  Content rules don't show up in the objectClass attribute,
however.

> Do other LDAP server implementors support auxiliary classes differently?

At least three LDAPv3 servers implement auxiliary classes as required by
RFC 2251. 

Mark Wahl, Directory Product Architect
Innosoft International, Inc.