[Samba] Samba4: Full schema problems

Michael Ströder michael at stroeder.com
Tue May 12 15:42:34 GMT 2009

Andrew Bartlett wrote:
> On Sat, 2009-05-09 at 15:58 +0200, Michael Ströder wrote: 
>> Attribute 'subSchemaSubEntry' in the rootDSE correctly points to
>> CN=Aggregate,CN=Schema,CN=Configuration,$BASEDN (like on AD) but there
>> are no schema descriptions in there.
>> Attribute 'subSchemaSubEntry' in all other entries *falsely* points to
>> CN=Subschema. I guess that DN generated by OpenLDAP. 
> Hmm.  This is unfortunate.  We are going to need a way to block AD
> clients from seeing this attribute.  Is there any sane way (an ACI
> perhaps?) to prohibit reading this attribute from the OpenLDAP side?  
> Otherwise, I'll put in a rule in our 'mapping' table to map all queries
> for subSchemaSubEntry to
> samba4NeverWantsToHaveSubSchemaSubEntryReturned :-)

Did you actually read my e-mail? What are AD clients? I'd assume every
LDAPv3 client is an AD client too.

MS AD correctly returns attribute 'subSchemaSubEntry' for each entry
correctly if explicitly requested pointing to the subschema subentry
CN=Aggregate,CN=Schema,CN=Configuration,$BASEDN which a schema-aware
LDAPv3-compliant client SHOULD read and parse.

In general the subschema subentry contains the LDAPv3-compliant schema
information in the attributes ldapSyntaxes, matchingRuleUse, nameForms,
attributeTypes, dITStructureRules, objectClasses, dITContentRules and
matchingRules. Not all LDAP servers maintain all schema attributes. The
LDAP client SHALL explicitly request the schema attributes when reading
the subschema subentry.

AD (at least W2K3) provides these attributes in the subschema subentry
which MUST be explicitly requested by the client:

So your mapping has to map the attribute value "CN=Subschema" to
"CN=Aggregate,CN=Schema,CN=Configuration,$BASEDN" for attribute
'subSchemaSubEntry'. The content of the subschema subentry with the
above mentioned attributes has to be exactly the same like that of AD
including possible schema bugs in AD.

Ciao, Michael.

More information about the samba-technical mailing list