12.4 Wreaking Havoc with Your Schema

There are a number of ways to cause problems in your Active Directory schema. We include a few examples here so that you can be fully aware of the problems.

Let's start by considering the main base classes of attributeSchema, classSchema, and top. Imagine we decide to add a new mandatory attribute to top. As all classes derive from top, the mandatory attribute requirement is suddenly added to every class and attribute throughout the schema in one go. Since none of the existing classes and attributes have this value, they all suddenly become marked as invalid. They still exist and can be used, but they cannot be modified at all. New timestamps cannot be added, USNs cannot be changed, replication stops, and effectively your Active Directory grinds to a halt. The reason that the objects cannot be modified is that Active Directory does a special check when existing instances of objects are modified to make sure that all mandatory attributes have been set. If they have not all been set, which they won't have been in this case, Active Directory will not allow any attribute changes from now on. The only solution is to remove the new mandatory attribute or set a value for the attribute on every single object in every NC in the entire forest.

There are also concurrency problems. Having a Schema FSMO is perfectly fine, but that doesn't necessarily stop members of Schema Admins from attempting to run two schema-modifying applications at the same time. Every time an application or piece of code attempts to write to the schema, it automatically writes a special system attribute at the same time. Two system-attribute writes anywhere in Active Directory cannot occur simultaneously, so one will fail if this is the case. In the scenario of simultaneous applications executing, the changes to the schema may all be handled sequentially and the requests from both applications may be interleaved, but the two applications at some point may attempt to write together. At that point, one of them will fail. If the failed application is rerun, it must be coded to detect the existence of each object (i.e., the previous creation succeeded) prior to creating the object, or else the object-creation process will continually fail.

You can also make instances of objects invalid quite easily. For example, let's say that we define that new class we mentioned earlier called Finance-User, and create an instance of it called cn=SimonWilliams. If we then remove Languages-Spoken from Finance-User's mandatory attributes, the SimonWilliams user becomes invalid because the SimonWilliams instance has an attribute that is not now allowed in the schema definition for Finance-User. Again, it is up to the person or code that makes the Languages-Spoken attribute defunct to go through Active Directory and find all instances of Finance-User and modify them to remove the value in this now-defunct attribute. If this isn't done, any instances of Finance-User with the Languages-Spoken attribute defined (all, in this case, as it was mandatory) remain invalid.

You cannot cause invalid instances by modifying existing attributeSchema objects, as all the key attributes are defined in system attributes. However, you can cause havoc with existing classSchema objects. Ways of doing this are:

• Removing classes as possible superiors; this can leave instances under invalid parent containers.

• Adding classes to the list of auxiliary classes; this can change what attributes are now considered mandatory.

• Removing classes from the list of auxiliary classes; this can change what attributes are now considered mandatory and optional and can thus leave instances with now nonexistent attributes.

• Directly removing mandatory or optional attributes; this can leave instances with now nonexistent attributes.

If the DC holding the Schema FSMO role unexpectedly disappears, you can force another server to assume the role. But if the original DC ever comes back, you have two Schema FSMOs, and you will need to rectify that by making sure only one server has the role. However, if the original server had some updates applied prior to its crash, and you allow updates to be made on the new Schema Master, the updates from the old DC will eventually propagate around the network. Your problems to be aware of in this scenario are twofold:

• If the new Schema FSMO created objects that conflict with some created on the original master prior to its departure, some objects will be removed from Active Directory during the conflict-resolution process.

• If the two DCs are online and both believe they are the Schema FSMO, both will accept schema updates equally.

A simple solution, if you can live with it, is either not to force a FSMO until the old DC returns and assumes its role or to force a FSMO temporarily and remove everyone from the Schema Admins group to prevent changes in the meantime. In the latter case, when the original DC comes back, force the FSMO role onto it.

Finally, the system itself will protect you from some forms of stupidity using the system-only attribute and Access Control Lists (ACLs). These work together to prevent you from deleting the user or group object from Active Directory or removing the securityPrincipal as an auxiliary class of both. While you may be aware of this already from our many examples of the use of the four system attributes, it bears mentioning one final time. For attributeSchema object classes, the attributeId, attributeSyntax, and oMSyntax are marked as system-only attributes and so cannot be changed or deleted. For classSchema objects, the subClassOf, governsId, systemMayContain, systemMustContain, systemAuxiliaryClass, and systemPossSuperiors are marked as system-only attributes and so cannot be changed or deleted. Other very important classes and attributes cannot be deleted as their ACLs are locked to prevent this.