Confusion on Schema changes#
There is a lot of confusion about changes to Microsoft Active Directory LDAP Schema and making changes. There are a lot of mistakes made when doing LDAP Schema changes on any LDAP server, if not in the execution of extending the schema, but also in the design of LDAP Schema changes.Proper LDAP Schema changes for any LDAP directory takes experience and knowledge about how the LDAP Schema works.
Additionally, in Windows 2000, there were some more strict consequences of extending the schema in Microsoft Active Directory which has largely been eliminated in later releases.
Microsoft's Schema Reference
#
Microsoft's Schema Reference from Microsoft.
Impact of Schema Changes#
Impact of Schema Changes from Microsoft.
Before Making Schema Changes#
As with any LDAP vendor, you should make sure that your LDAP server is working properly before extending the schema. Microsoft shows on How to Extend the Schema that you should "Verify Active Directory functionality before you apply any schema extensions". Heed their advise.
What Type of ObjectClass#
In most LDAP vendor implementation we try to never extend a "base" ObjectClass and prefer to use Auxiliary ObjectClass. The same is true for most changes in Microsoft Active Directory.Microsoft Active Directory also has a concept of Dynamically Linked Auxiliary Classes which is a class that is attached to an individual object, rather than to an object class. Dynamic linking enables you to store additional attributes with an individual object without the forest-wide impact of extending the schema definition for an entire class. For most LDAP people this is the "normal" Auxiliary ObjectClass as implemented in other LDAP products.
In addition, Microsoft Active Directory supports Statically Linked Auxiliary Classes where when they are included in the auxiliaryClass or systemAuxiliaryClass attribute of an object class's classSchema definition in the schema. This means that the auxiliary class is part of every instance of the class with which it is associated.