Hi, Tridge,
We reproduced the behavior by running your Python script with latest Samba
tree against Windows server. After further review, we confirmed that your
description of behaviors is correct. This is a documentation issue that we are
going to fix in MS-ADTS.
For the definitions of AUXCLASS(),POSSSUPERIORS(), and CLASSATTS(), your
assumption is also correct. The functions are mapped onto every element in the
list, and the resulting (concatenated) list is returned. We will update the
information into MS-ADTS too.
I will send you the document update when it is available. Please let us
know if you have any more questions.
Thanks!
Hongwei Sun - Sr. Support Escalation Engineer
DSC Protocol Team, Microsoft
hongw...@microsoft.com
Tel: 469-7757027 x 57027
-
-Original Message-
From: tri...@samba.org [mailto:tri...@samba.org]
Sent: Thursday, March 26, 2009 5:35 PM
To: Interoperability Documentation Help
Cc: cifs-proto...@samba.org; p...@tridgell.net
Subject: CAR - problem with MS-ADTS docs on possibleInferiors
Hi,
Andrew and I have been trying to implement possibleInferiors in the
ldap server in Samba4. To start with, we've written a python script to
test our understanding of how possibleInferiors is calculated.
We wrote the script based on the documentation in [MS-ADTS].pdf
(January 2009 version) sections 3.1.1.4.2 and 3.1.1.4.5.21.
The script connects to an AD ldap server and asks the server for the
list of object classes, then for every class it asks for the
possibleInferiors attribute. It then calculates the possibleInferiors
using the methods given in the documentation, and compares the
results.
We found that a windows server gave slightly different results than
what we get by following the documentation. After some experimentation
we found a different algorithm that does match windows behaviour.
Could you please check the description of possibleInferiors in the
[MS-ADTS].pdf and see if it is correct?
The script we've written is available here:
http://samba.org/ftp/unpacked/samba_4_0_test/source4/dsdb/samdb/ldb_modules/tests/possibleinferiors.py
If you look near line 142 of the script you can see this:
if opts.wspp:
# the WSPP docs suggest we should do this:
list2.extend(POSSSUPERIORS(classinfo, AUXCLASSES(classinfo,
[oc])))
else:
# but testing against w2k3 and w2k8 shows that we need to do
this instead
list2.extend(SUBCLASSES(classinfo, list2))
What this is saying is that the documentation suggests calculating the
POSSSUPERIORS() list to include the AUXCLASSES() list. When we
included the AUXCLASSES() list we found that we calculated an extra
class in our possibleInferiors that w2k8 does not return for 4
classes.
The class is 'remoteMailRecipient' and is calculated as being a
possibleInferior for 'rpcContainer', 'container',
'groupPolicyContainer' and 'msExchConfigurationContainer'. When we
don't use the AUXCLASSES() contribution to POSSSUPERIORS() then
'remoteMailRecipient' is not included in possibleInferiors.
Additionally, we found that we needed to include the SUBCLASSES() list
in the POSSSUPERIORS() calculation. The SUBCLASSES() list isn't
described in the documentation, but comes from an inversion of the
class tree using subClassOf.
If we don't include SUBCLASSES() in POSSSUPERIORS() then we get back
a mismatch for possibleInferiors for 22 classes. For example, for the
class 'linkTrackObjectMoveTable' a w2k8 server returns 4 entries in
the possibleInferiors list:
'fileLinkTrackingEntry', 'linkTrackOMTEntry',
'linkTrackObjectMoveTable', 'linkTrackVolumeTable'
whereas our code (with the SUBCLASSES() call removed) produced just
one entry, 'linkTrackOMTEntry'
We also found the documentation rather hard to follow. I think part of
that just comes from the notation. For example, the documentation
gives a definition of AUXCLASSES(O). That notation would seem to imply
that AUXCLASSES() takes the name of a class and returns a list of
classes, but in the recursive definition of AUXCLASSES() it refers to
AUXCLASSES(SUPCLASSES(O)), which now implies that AUXCLASSES() takes a
list of classes. We guessed that the documentation implied that when
the AUXCLASSES() function is called with a list as an argument it
takes the results of AUXCLASSES() for every object in the list, then
concatenates the resulting lists (possibly removing duplicates). Can
you confirm that this is what is meant?
It is also rather surprising that we found that AUXCLASSES() doesn't
contribute to possibleInferiors. Could you confirm whether this is a
bug in the documentation or the implementation in windows, or is it
just a bug in our little python script?
To run the script, build the Samba4 tree, then run it like this:
