[Samba] Samba4: Full schema problems

[Andrew Bartlett]

On Tue, 2009-05-12 at 17:42 +0200, Michael Ströder wrote: 
> 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 use that term to mean clients of Samba4, to avoid confusion with
Samba4 being the client of OpenLDAP.  Also, to mean clients that are
expecting AD behaviour (because they are talking to Samba4, mimicing
AD).

> I'd assume every
> LDAPv3 client is an AD client too.

It is very clear to me that this is not the case, or we would not be
having many of the discussions you bring here.  There are many tools
that expect AD behaviour (only) and many that expect 'standard'
behaviour (only).  As I have said many times, I only propose to serve
the former. 

> 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.

Interesting that this is on every single entry...

> 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:
> attributeTypes
> objectClasses
> dITContentRules
> 
> 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.

Given that this is on every entry, this should not be hard to do.  We
already have modules to return operational attributes, so this will not
be hard to add at all.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20090513/174405f6/attachment.bin