>From: "Dean Wells" <[EMAIL PROTECTED]>
>Date: Tue, 27 Nov 2007 10:46:49 -0500
>>One can query the DIT content rules defined in AD by
>>querying the subschema subentry (e.g. by using web2ldap).
[Dean Wells] AD also supports the sub-schema entry ... though some deem =
it (and a number of other behaviors) 'broken' due to certain =
"extensions".
Heh. That's putting it mildly. LDAP is extensible of course, but the intention
is for bog-standard clients that are unaware of whatever extensions to still
be able to function with arbitrary servers. I.e., extensions must be purely
optional and servers must behave correctly even when extensions are not in
use. With AD, the bulk of the extensions are mandatory; if a client doesn't
know about them and doesn't understand how to request them or parse their
results, it will get incomplete or incorrect results back from the server.
Microsoft makes great claims about being compatible with LDAPv3 (note, they
don't even claim full compliance, which they obviously can't) but it's all a
crock.
> Structural classes are derived from the attributes
[Dean Wells] Hmmm .... snipping that sentence didn't represent it well. =
I believe it to be fairly accurate (though it is quite certainly and =
without any intention to be otherwise, incomplete) as it stood both per =
AD 2000/2003 and, for the most part, per LDAP v3 -
"Structural classes are derived from the attributes assigned directly to =
them, to their object-lineage (i.e. their parent, their parent's =
parents, etc.) and any direct relationship with aux. classes. Dynamic =
aux. classes simply permit the latter to occur per object instance =
rather than requiring the significant permissions necessary to modify =
the forest-wide schema."
Clearly designed by somebody who didn't actually understand the X.500 data
model.
>>Nitpicking (without offense):
>>Structural object classes are derived from other structural object =
classes
[Dean Wells] True, but that's not the whole picture. Structural classes =
can certainly be derived from other structural classes but, likewise, =
they are also derived (extensively in AD) from aux. classes and a few =
abstracts all the way back to [top].
And again. In X.500 (upon which LDAP is based) structural classes are only
allowed to inherit from structural classes. If they hadn't gotten this bit
wrong, and they actually implemented DIT Structure Rules, they wouldn't have
needed to invent "dynamic auxiliary classes." Instead, they have something
that behaves kinda-sorta-mostly like DIT Structure Rules but goes off into the
weeds with everything else they threw in.
>>and inherit the attributes in MUST and MAY of the superior
[Dean Wells] AD actually implements this notion twice -- systemMust and =
May contain (classically un-editable without significant effort) and an =
editable equivalent (obviously, hard and fast rules govern the use of =
Must and SystemMust).
Changing *anything* in the AD schema seems to require "significant effort" -
most AD administrators are mortally afraid of ever touching their schema. Yet
again - who in their right mind would willingly run software that they're
actually *afraid* of?
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
---
You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
