Inline below ... In summary - I fear we're communicating poorly here. My original response was meant to only to address your specific question and provide a little related information to reinforce the answer. Did the collective responses successfully explain what a dynamic aux. class is?
-- Dean Wells MSEtechnology t Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: Michael Ströder [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 27, 2007 9:06 AM To: Dean Wells Cc: [email protected] Subject: [ldap] RE: AD extending schema and objectClass Dean Wells wrote: > > > 1. It means to associate. My terminology is influenced by the > common-place AD interfaces used to manipulate the AD schema – > [..screenshot snipped..] >>So that means adding a DIT content rule in LDAPv3 terminology. But in >>LDAPv3 you can solely define DIT content rules for structural object classes. [Dean Wells] I fear we're on entirely different pages. Since structural classes are the only class for which an instance can be created -- AD behaves similarly. >>It might be that AD allows DIT content rules also for auxiliary >> classes but there's nothing like this defined in LDAPv3 (see RFC 4512, >> section 4.1.6.). [Dean Wells] AD does not support the concept of instantiating an aux. class, so I'd say that's a 'no'. >>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". > 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." >>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 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). --- 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.
