Hi,
the sambaAccount object class is used by Samba to store its account
information in a directory. It is defined as (samba.schema from samba
2.2.4):
objectclass ( 1.3.6.1.4.1.7165.2.2.2
NAME 'sambaAccount'
SUP top
STRUCTURAL
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: [EMAIL PROTECTED]
Germany web: http://www.daasi.de
