Why sambaAccount should be an auxiliary object class

Norbert Klasen norbert.klasen at daasi.de
Mon May 27 09:07:01 GMT 2002

the sambaAccount object class is used by Samba to store its account 
information in a directory. It is defined as (samba.schema from samba 

objectclass (
        NAME 'sambaAccount'
        SUP top
        DESC 'Samba Account'
        MUST ( uid $ rid )
        MAY  ( cn $ lmPassword $ [...] ))

While it may be convenient to use a structural object class in a directory 
service that will only hold information about Samba accounts this 
effectively precludes the integration of such data into existing services. 
Such services generally use "account" or "person" (or one of its 
descendants like "inetOrgPerson") as structural object class. However, the 
X.500 and thus the LDAP data model only allows one "structural object class 
of an entry". An entry must have "precisely one structural object class 
superclass chain which has a single structural object class as the most 
subordinate object class". That is, an entry may not be member of both 
"sambaAccount" and, for example, "inetOrgPerson" as neither is derived from 
the other.

Current version of OpenLDAP (and maybe other directory servers) do not 
validate superclass chains in their schema check, but the upcoming 2.1 
release will enforce this restriction.

We at DAASI suggest that "sambaAccount" is redefined (new OID, new name?) 
as an AUXILIARY object class. For Samba-only repositories, the "account" 
object class should be used as structural object class just as RFC2307 
suggests for "posixAccount".

Dipl.-Inform. Norbert Klasen
DAASI International GmbH                 phone: +49 7071 29 70336
Wilhelmstr. 106                          fax:   +49 7071 29 5114
72074 Tübingen                           email: norbert.klasen at daasi.de
Germany                                  web:   http://www.daasi.de

More information about the samba-technical mailing list