The correct behaviour of auxiliary object classes

[Vincent Ryan <Vincent.Ryan@Ireland.Sun.COM>]

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?