For Active Directory to hold any object, such as a user, it needs to know what the attributes and characteristics of that object are. In other words, it needs a blueprint for that object. The Active Directory schema is the blueprint for all classes, attributes, and syntaxes that can potentially be stored in Active Directory.
The following considerations should be kept in mind when you contemplate extending your schema:
Microsoft designed Active Directory to hold the most common objects and attributes you will require. Because it could never anticipate every class of object or every specific attribute that a company would need, Active Directory was designed to be extensible. After all, if these objects and properties are going to be in everyday use, the design shouldn’t be taken lightly. Administrators need to be aware of the importance of the schema and how to extend it. Extending the schema is a useful and simple solution to a variety of problems, and not being aware of this potential means that you will have a hard time identifying it as a solution to problems you might encounter.
Designing schema extensions is very important, in part because any new class or attribute that you create in the schema is a permanent addition. Under Windows Server 2003 and newer forests, you can disable or redefine schema extensions, but you can never remove them completely.
Although it is easy to extend Active Directory, it’s surprising how many companies are reluctant to implement schema extensions due to concerns over the impact to Active Directory. One of the biggest impediments in Windows 2000 was that anytime the partial attribute set was extended (i.e., an attribute was added to the Global Catalog), a full resync had to be done for all Global Catalog servers. Fortunately, Microsoft resolved this in Windows Server 2003, and a full resync is no longer performed.
This chapter takes you through the process of extending the schema, from the initial design of the changes through the implementation, and discusses how to avoid the pitfalls that can crop up. We then talk about analyzing the choices available and seeing whether you can obtain the required design result some other way. We obviously cover how to implement schema changes from first principles, but before that we identify the steps in designing or modifying a class or attribute. Finally, we cover some pitfalls to be aware of when administering the schema.
We won’t spend much time introducing a large number of specific examples. This is mainly because there’s no way we can conceive of every sort of schema extension that you might require. Consequently, for examples we use only one new generic class as well as a few attribute extensions to the default user object. When giving examples of modifying a class, we extend the user object class.
Let’s first look at how you would design the changes you may wish to make in an enterprise environment.
If you have not done so already, we highly recommend that you review Chapter 5 for an in-depth discussion of the Active Directory schema. This chapter is dependent on the concepts discussed there.
If you don’t already have a central person responsible for the object identifier (OID) namespace for your organization, you should identify such a person. This OID manager is responsible for obtaining an OID namespace, designing a structure for the namespace that makes sense for your organization, managing that namespace by maintaining a diagram of the structure and a list of the allocated OIDs, and issuing appropriate OIDs for new classes and attributes from that structure as required. Whenever a new class or attribute is to be added to your organization’s schema, the OID manager will provide a unique OID for that new addition. This is then logged by the OID manager with a set of details about the reason for the request and the type of schema extension that it is to be used for. Keep in mind that aside from Active Directory, other members of your IT organization may have a requirement for OIDs. Other LDAP directories and Simple Network Management Protocol (SNMP) applications are two examples of applications that also make use of OIDs.
The Active Directory administrators, by comparison, are responsible for designing and creating proper classes in the schema for a forest as well as for implementing schema extensions required by third-party applications. They are responsible for actually making changes to the schema via requests from within the organization, and for ensuring that redundant objects doing the same thing are not created, that inheritance is used to best effect, that the appropriate objects are indexed, and that the partial attribute set contains the right attributes.
If you are designing code that will modify some other organization’s schema, such as for a software product, the documentation accompanying that code should make it explicitly clear exactly which classes and attributes are being created and why. The documentation also should explain that the code needs to be run with the privileges of a member of the Schema Admins group, since in many organizations the Schema Admins AD group is empty.
A better solution to programmatically processing schema changes is to supply organizations with the LDIF files for the schema modifications. This allows the organizations to review the actual changes and incorporate them into a batch update process with other schema modifications, which allows for easier testing and production implementation. Some large organizations have extensive schema change control procedures that require LDIF-format files describing all changes. Failure to supply the required LDIF file in these organizations results in the update being rejected.
Note that while the responsibilities of the OID manager do not necessarily coincide with those of Active Directory administrators, it is entirely possible that they are the same person or persons.
Before you start thinking of changing the schema, you need to consider not just the namespace, but also the data your Active Directory deployment will hold. After all, if you know your data, you can decide what changes you want to make and whom those changes might impact.
No matter how you migrate to Active Directory, at some point
you’ll need to determine exactly what data you will store for the
objects in Active Directory. Will you use the physicalDeliveryOfficeName
attribute of the
user object? What about the telephonePager
attribute? Do you want to merge
the internal staff office location list and telephone database during
the migration? What if you really need to know what languages each
member of your staff speaks or what qualifications they hold? What about
their shoe size, their shirt size, number of children, and whether they
like animals?
The point is that some of these attributes already exist in the Active Directory schema, and some don’t. At some point, you need to determine the actual data that you want to include. This is an important decision, since not all data should necessarily be added to Active Directory. While it may be nice to have shoe size data in the directory, it may not make much business sense. You need to ask, “Is this data needed on all domain controllers for a given domain or all global catalogs in the forest?” It is possible that an application partition, Active Directory Lightweight Directory Services (AD LDS), or even a SQL Server database may be a better store for this information. Solutions outside of the AD forest are often particularly appropriate when the data in question is sensitive or confidential in nature.
Keep in mind that every piece of data that gets added to the directory needs to be replicated. This can have a significant impact on network traffic, storage needs, and the time required to build new domain controllers. If the data will change frequently, factor in the increased replication load. If replication is a burden on your network, you may experience additional latency in overall replication due to the added overhead.
When you identify a deficiency in your Active Directory schema,
you have to look into whether modifying the schema is the correct way to
proceed. Finding that the schema lacks a complete series of objects
along with multiple attributes is a far cry from identifying that the
person-who-needs-to-refill-the-printer-with-toner
attribute of the printer object is missing from the schema. There’s no
rule, either, that says that once you wish to create three extra
attributes on an existing object, you should modify the schema. It all
comes down to choice.
To help you make that choice, you should ask yourself whether there are any other objects or attributes that you could use to solve your problem.
Let’s say you were looking for an attribute of a user object that
would hold a staff identification number for your users. You need to ask
whether there is an existing attribute of the user object that could
hold the staff ID number, which you are not planning to use. This saves
you from modifying the schema if you don’t have to. Take Leicester
University as an example: we had a large user base that we were going to
register, and we needed to hold a special ID number for each of our
students. In Great Britain, every university student has a University
and Colleges Administration System number, more commonly known as the
UCAS number; this is a unique alphanumeric string that UCAS assigns
independent of a student’s particular university affiliation. Students
receive their UCAS numbers when they first begin looking into
universities. The numbers identify students to their prospective
universities, stay with students throughout their undergraduate careers,
and are good identifiers for checking the validity of students’ details.
By default, there is no schema attribute called UCAS-Number
, so we had two choices: we could
find an appropriately named attribute that we were not going to use and
make use of that, or we could modify the schema.
Since we were initially only looking to store this piece of
information in addition to the default user information, we were not
talking about a huge change in any case. We simply looked to see whether
we could use any other schema attribute to contain the data. We soon
found the employeeID
user attribute
that we were not ever intending to use, and that seemed to fit the bill,
so we decided to use that. While it isn’t as appropriately named as an
attribute called UCAS-Number
would
be, it did mean that we didn’t have to modify the base schema in this
instance.
The important point here is that we chose not to modify the schema, having found a spare attribute that we were satisfied with. We could just as easily have found no appropriate attribute and decided to go through making the schema change using our own customized attribute.
This example of repurposing the employeeID
attribute is one where the data
the attribute was repurposed to hold is closely aligned with the
original intent implied by the name employeeID
. It is not at
all advisable to repurpose attributes that are included in
the base schema for purposes that are not remotely related to their
original intent. It is entirely possible that a later version of
Active Directory may begin using an attribute in the base schema for
its original intent, or a third-party application may make this assumption. If
you have elected to repurpose the attribute, you will then need to
migrate the data out of this attribute and update all of the
applications that depend upon it.
If you’ve installed Microsoft Exchange into the forest, there is
also a set of attributes available for you to use for whatever you need.
These are known as the extension
or
custom attributes
and have names like
extensionAttribute1
, extensionAttribute2
, and so on. These are not
generally used by the operating system and have been left in for you to
use as you wish. There are 50 created by default with Exchange Server
2013, thus giving you spare attribute capacity built right into Active
Directory. So, if we wanted to store the number of languages spoken by a
user, we could just store that value inside extensionAttribute1
if we chose.
Making use of extension attributes and making use of unused attributes works well for a small number of cases. However, if there were 20, 30, or more complex attributes, each with a specific syntax, or if we needed to store 20 objects with 30 attributes each, we would have more difficulty. When you have data like that, you need to consider the bigger picture.
So, you have a list of all your data, and you suspect either that the schema will not hold your data or that it will not do so to your satisfaction. You now need to consider the future of your organization’s schema and design it accordingly. The following questions should help you decide how to design for each new class or attribute:
Is this class or attribute already in the schema in some form? In other words, does the attribute already exist by default, or has someone already created it? If it doesn’t exist, you can create it. If it does already exist in some form, can you make use of that existing attribute? If you can, you should consider doing so.
If you can’t, you need to consider modifying the existing attribute to cope with your needs or creating a second attribute that essentially holds similar or identical data, which is wasteful. If the existing attribute is of no use, can you create a new one, migrate the values for the existing attribute to the new one, and disable the old one? These are the sorts of questions you need to be thinking of.
Is this a class or attribute that is to be used only for a very specific purpose, or could this object potentially be made of use (i.e., created, changed, modified) by others in the organization? If the class or attribute is for only a specific purpose, the person suggesting the change should know what is required. If the class or attribute may impact others, care should be taken to ensure it is designed to cope with the requirements of all potential users—for example, that it can later be extended if necessary without affecting the existing object instances at the moment the schema object is updated.
For an attribute, for example, you should ask whether the
attribute’s syntax and maximum/minimum values (for strings or
integers) are valid or whether they should be made more applicable
to the needs of many. Specifically, if you created a CASE_INSENSITIVE_STRING
of between 5 and
20 characters now and later you require that attribute to be a
CASE_SENSITIVE_STRING
of between
5 and 20 characters, you would need to create a new attribute and
migrate the data as the syntax of an attribute cannot be changed
once the attribute is created.
Are you modifying an existing class by adding an attribute? If so, would this attribute be better if it were not applied directly to the object, but instead added to a set of attributes within an auxiliary class?
Are you adding an attribute to an existing class that you normally manage through the standard GUI tools, such as Active Directory Users and Computers? The new attribute will not automatically show up in the GUI and will require changing the tool being used or extending the tool (if that is possible). You must be aware of the impact that your changes may have on existing tools and ones that you design yourself.
Basically, these questions boil down to four much simpler ones:
Is the change that needs to be made valid and sensible for all potential uses and users of this object?
Will the change impact any other changes that may need to be made to this and other objects in the future?
Will the change impact anyone else now or in the future?
Will the change impact any applications that people inside or outside the company are developing?
As when creating a valid OID namespace, make sure that your classes and attributes are created with sensible names. These names should have a unique company prefix for easy identification and consist of capitalized words separated by hyphens. For more information about choosing a prefix for your names, see the sidebar “Choosing a Sensible Naming Prefix.”
An important rule of thumb is to never modify default system attributes. This ensures that you never conflict with anything considered a default by the operating system, which might eventually cause problems during upgrades or with other applications, such as Exchange. Adding extra attributes to classes is fine, but avoid modifying existing attributes.
There are three ways to modify the schema: through the Active Directory Schema MMC snap-in, using LDIF files, or programmatically using ADSI or LDAP. We will not cover the Active Directory Schema snap-in very heavily here since it is fairly straightforward to use, although we will cover its use in managing the schema master FSMO role. Typically, you should not use the Active Directory Schema snap-in to extend the schema. Instead, you should use LDIF files. LDIF files are much easier to review and document, since they are simply specially formatted text files. Most vendors provide LDIF files, which contain the schema extensions that you can review and then import at your leisure.
It can be extremely tedious to create custom schema extensions by hand with an LDIF file. Instead, you may want to take advantage of the Active Directory Schema MMC snap-in in a development forest (or an AD LDS instance) to create your schema extension. Once you have created the extension with the MMC, you can export it to an LDIF file with ldifde or the AD Schema Analyzer and publish the LDIF file. For more information on AD LDS and the AD Schema Analyzer, refer to Chapter 20.
The Schema Management MMC snap-in is not available from the Administrative Tools menu, like the other Active Directory snap-ins. To use it, you need to first register the Dynamic Link Library (DLL) file for the snap-in by typing the following command at the command prompt:
regsvr32.exe schmmgmt.dll
You can then start the Active Directory Schema console by creating
a custom MMC and adding the Active Directory Schema snap-in to it. To
create a console, go to Start → Run, type mmc.exe
, and click OK. Then, in the empty
MMC, go to File → Add/Remove Snap-in. From here, you can click the Add
button and select Active Directory Schema as the item. If you then click
the Add button, followed by Close, and then the OK button, that will
give you an MMC hosting the Active Directory Schema snap-in for you to
use and later save as required.
Each domain controller maintains a copy of the entire schema in memory. This is known as the schema cache. It is used to provide a very rapid response when requesting a schema object OID from a name.
The schema cache is actually a set of hash tables of all the
classSchema
and attributeSchema
objects known to the system,
along with specific indices (attributeID
, mAPIId
, and lDAPDisplayName
for attributeSchema
objects and governsID
and lDAPDisplayName
for classSchema
objects) for fast
searching.
The objects are loaded into the schema cache when the domain controller is booted, and again five minutes after an update. However, if you need the schema cache to be updated immediately for some reason, say after the creation of a new object or attribute class, you can force an immediate reload of the cache.
As we said, the system holds a copy in memory solely to aid in searches that require quick and regular access to the schema. If the system were to keep the cache and the actual Active Directory schema in sync, it could be costly in terms of performance; making changes to the schema is an intensive process due to the significant checking and setting of object defaults by the system upon creation of new objects. Consequently, there is a time delay between changes made to the underlying schema and the cached copy. Typically, the schema tends to be updated in bunches. This is likely to be due to applications creating multiple classes for their own purposes during an installation or even normal operation. If classes are still being created after five minutes, the system updates the cache in five-minute increments after the first five-minute update has completed. This continues for as long as the schema class updates continue.
During the intervening five-minute period, when the underlying schema has been modified but the cache has yet to be updated, instances of objects or attributes of the new classes cannot be created. If you try to create an object, the system will return an error. This is due to the fact that object creations refer to the cache and not the underlying schema. To get around this problem, you can force an immediate reload of the cache by updating a special operational attribute on the RootDSE. We’ll cover this later when we consider how to use the Schema Management MMC snap-in to create and delete classes. In a similar vein, if you mark an object as defunct, this will not take effect until the cache is reloaded.
Although you cannot create new instances of new object types that you have created until the schema cache refreshes, you can add new attributes or classes that you have created to other classes that you are creating. For example, if you create a new attribute, you can immediately add it to a new class. Why? Because the attribute or class is added using an OID, and the system thus doesn’t need to do any lookups in the schema cache. While all system checks by Active Directory confirming that the data is valid—covered in the section “Checks the System Makes When You Modify the Schema” (page 508)—will still be performed, the checks are performed on the schema in Active Directory, not the cache. If this weren’t the case, you would have to wait for at least five minutes before any new attributes that you created could be added to new classes, and that would be unacceptable.
The schema master FSMO is the domain controller where changes to the schema take place so that multiple users or applications cannot modify the schema on two or more different domain controllers at the same time. When Active Directory is installed in an enterprise, the first server in the first domain in the forest (the forest root domain) becomes the nominated schema master FSMO. Later, if changes need to be made to the schema, they can be made at the current master.
You can transfer the role from an existing schema master in three ways: via the Active Directory Schema MMC snap-in, via the NTDSUTIL tool, or via code that makes use of ADSI or LDAP.
Using the Active Directory Schema MMC snap-in to transfer the role is easy. First you need to connect to the server that is to be the new master, and then you need to force the role to change to the server to which you are now connected. To start the process, simply run the MMC and right-click Active Directory Schema in the lefthand scope pane. From the context menu that drops down, select Change Active Directory Domain Controller.
You can now select a new server to connect to. You should transfer any FSMO roles (not just the schema master) to a new server before shutting down a server for an extended period, such as for maintenance. Once you have connected to the intended target for the schema master FSMO role, right-click on Active Directory Domains Schema in the scope pane and select Operations Master from the context menu. A dialog box will appear, showing the current DC holding the schema master FSMO role, as well as an option to change the role to the currently connected server. Figure 17-1 shows this dialog box. Click the Change button to transfer the schema master role.
In the event that the schema master role owner becomes permanently unavailable (due to hardware failure, operating system corruption, etc.), you will need to seize the schema master role on another domain controller. In order to seize a FSMO, you must use the ntdsutil command-line utility. For more information about seizing FSMO roles, see Chapter 18.
One of the most commonly used ways to extend the schema is with the LDAP Data Interchange Format, or LDIF. LDIF was defined in RFC 2849 and provides a way to represent directory data via a human-readable text file. You can export data from Active Directory in LDIF format, and you can also add, modify, and delete data with LDIF. The ldifde program comes installed as part of any Windows Server and can be used to import and export LDIF data. To import the contents of an LDIF file, run the following command:
c:> ldifde -v -i -f import.ldf
Replace import.ldf with the name of the LDIF file you want to import.
LDIF files contain one or more entries, with each entry containing one or more attributes that should be added, replaced, or removed. The format is straightforward, but very strict. The following is an example of an LDIF file that would add a group object to the Users container:
dn: cn=mygroup,cn=users,dc=mycorp,dc=com changetype: add objectclass: group description: My Group member: cn=administrator,cn=users,dc=mycorp,dc=com member: cn=guest,cn=users,dc=mycorp,dc=com
The first line must be the DN of the object. The second line is
the changetype
, which is one of
add
, modify
, modrdn
, or delete
. When using add
, as in this case, we must specify all the
mandatory attributes for the object. For group objects, we need to
specify only objectClass
. The
cn
attribute is not required because
it is already specified as part of the DN.
Windows 2000 Active Directory also requires the sAMAccountName
attribute to be specified for
new users and groups.
It is easy to create portable schema extensions using LDIF files.
Simply create an LDIF file with all the necessary classSchema
or attributeSchema
object additions or
modifications, and administrators using any LDIF-based client (such as
ldifde, which ships with Windows) can easily import
it into Active Directory. The following LDIF file shows how to create an
attribute and an auxiliary class that contains the new
attribute:
dn: cn=myCorp-ITUserBuilding,cn=schema,cn=configuration,dc=X changetype: add attributeID: 1.2.3.4.111.1 attributeSyntax: 2.5.5.1 oMSyntax: 127 isSingleValued: TRUE lDAPDisplayName: myCorp-ITUserBuilding objectClass: attributeSchema dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - dn: cn=myCorp-ITUser,cn=schema,cn=configuration,dc=X changetype: add objectclass: classSchema description: Class for MyCorp Employees lDAPDisplayName: myCorp-ITUser governsID: 1.2.3.4.111.2 objectClassCategory: 3 subClassOf: top mayContain: myCorp-ITUserBuilding dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 -
To import this sample, you need to replace the placeholder DNs with the DN of the Schema NC. You can use the -c switch and ldifde’s macro expansion capability to easily do this:
>ldifde -i -f schema-extension.ldf -c "cn=schema,cn=configuration,dc=x" "#schemaNamingContext"
As we mentioned, all mandatory attributes for attributeSchema
and classSchema
objects must be specified. The
order of the additions is also important. Because we wanted to add the
new attribute to the class, we needed to create it first. We also needed
to reload the schema cache before attempting to reference the new
attribute by lDAPDisplayName
, or a
failure would have occurred. To accomplish that, we perform a modify
operation against the RootDSE
(i.e.,
blank DN) and write to the schemaUpdateNow
attribute.
We could have skipped the schema cache refresh after the
attribute creation if we had used the attributeID
OID 1.2.3.4.111.1 in place of
the lDAPDisplayName
myCorp-ITUserBuilding
in the mayContain
attribute of the myCorp-ITUser
class. Since we used the
lDAPDisplayName
in this example, it
required the schema cache to be reloaded because a lookup to retrieve the proper
OID had to be performed.
The benefits of using LDIF to implement schema extensions are twofold. First, since LDIF is human-readable with a well-defined syntax, it is easy for those who need to implement the extensions to see what is going to be done. If you use a program whose source the administrator cannot view, he will not have as much visibility into what changes are made. Along the same lines, LDIF files provide a crude documentation mechanism for schema extensions. Because LDIF files are just text-based files, schema administrators can archive the files on a server and have instant access to exactly what changes were made for certain applications.
When you create a new class or attribute, the system performs some basic checks within Active Directory to see if the data is valid, in addition to any checks you provide. The checks for attributes are shown in Table 17-1, and those for new classes are shown in Table 17-2.
Attribute | System check performed |
| Must be unique in Active Directory. |
| Must be unique in Active Directory. |
| If present, must be unique in Active Directory. |
| Must be unique in Active Directory. |
| Must correlate with
|
| Must correlate with
|
| If |
| If |
| Must be unique in Active Directory. Back links must have corresponding forward links. |
| Ambiguous name resolution (ANR) attributes must be Unicode or Teletex. |
Attribute | System check performed |
| Must be unique in Active Directory. |
| Must be unique in Active Directory. |
| Must be unique in Active Directory. |
| Checks to make sure that the X.500 specifications are not contravened (i.e., that an auxiliary class cannot inherit from a structural class, and an abstract class can only inherit from another abstract class). All classes defined in this attribute must already exist. |
| Must have a Unicode string as its syntax. |
| Before you can specify a
class in the |
| All classes defined in this attribute must already exist. |
| All classes defined in this attribute must already exist. |
| All classes defined in this attribute must already exist. |
| All classes defined in
this attribute must already exist and must have an |
| All classes defined in
this attribute must already exist and must have an |
| All classes defined in
this attribute must already exist and must have an |
| All classes defined in
this attribute must already exist and must have an |
Active Directory does not allow you to delete objects from the schema. However, if your forest is running at the Windows Server 2003 or better functional level, you can redefine or disable classes and attributes. This allows you to correct potential mistakes you may have made or to repurpose classes or attributes you are no longer using.
If you create a class or attribute of some sort and decide that
you don’t want it any more, you can simply disable it, which is
otherwise known as making it defunct. This is
achieved by setting the isDefunct
attribute on the schema object to TRUE or by unchecking the “Attribute
is active” or “Class is active” checkbox in the Active Directory Schema
MMC snap-in.
For this to succeed for an attribute, the system makes sure that
the attribute is not a mandatory or optional attribute of any
non-defunct class and is not the RDN attribute (rDNAttID
) for any class. For this to succeed
for a class, the system makes sure that the class is not a parent of any
other non-defunct class, is not an auxiliary class to any other
non-defunct class, and is not a possible superior of any other
non-defunct class. If you later decide that you want to use the schema
object again, set the value of isDefunct
to FALSE. The checks that occur when
doing this are the same as for creating a new schema object of the
appropriate type in the first place.
In order to view defunct attributes and classes in the Active Directory Schema MMC snap-in, you must enable the display of these attributes and classes. To display defunct schema objects, click View→Defunct Objects.
When an attribute or class is marked as defunct, the corresponding data stored in Active Directory is not removed. With this in mind, prior to marking a class as defunct, you should remove all instances of that class from the directory. Likewise, prior to marking an attribute as defunct, you should clear the attribute on all objects.
When a schema object is defunct, attempts to create instances of it fail as if it doesn’t exist. The same applies to modifying existing instances, whether of an attribute on an object or an object itself, as they will appear not to exist. You can, however, delete objects that are instances of defunct classes. Searches for objects that are instances of defunct classes will happily succeed, as will searches on non-defunct classes that contain defunct attributes. All attributes, defunct or not, can be read. This is all required to enable the administrator or application author to clean up and remove the now-defunct object instances and all values from now-defunct attributes.
Even though a schema object is defunct, it still exists in terms
of its distinguishedName
, OID, and
lDAPDisplayName
. You cannot create
a second schema object that has these values, but in most cases, you
can change them. The exception to this is that for an attribute used
as the RDN attribute for an objectClass
, you cannot reuse the
OID.
Some applications that extend the Active Directory schema have done so in a way that doesn’t conform with the best practices discussed in this chapter. In the most egregious cases, third parties used arbitrary OIDs from Microsoft’s OID space. When administrators imported the schema extensions, they succeeded and everything appeared to be just fine. Unfortunately, Microsoft later used the same OIDs (as they were Microsoft’s to begin with), and steps such as Active Directory schema upgrades during adprep when upgrading the forest failed.
Prior to Windows Server 2008, the LDIF files used by adprep could be edited to mitigate a failure due to a conflict. While this alleviated the immediate problem, it led to a forest with a base schema that was divergent from the schema Microsoft ships with each version of Active Directory. To combat this problem, Microsoft changed the adprep process in Windows Server 2008 to require that the LDIF files be digitally signed. Digital signatures ensure that files have not been altered or tampered with.
The signatures for the Active Directory schema LDIF files are verified with an accompanying catalog file. ldifde includes a -$ parameter that specifies the catalog file to verify the LDIF file signatures against.
Since the LDIF files for the base Active Directory schema are now signed, it’s not possible to simply modify them in advance of running adprep to ensure the process will succeed. Instead, you will need to first mark the conflicting classes or attributes as defunct, recreate them with valid OIDs, and then repopulate the attributes or recreate the objects. Once this process is complete, you will be able to successfully complete the adprep process.
The importance of carefully designing the changes that you make to the Active Directory schema cannot be stressed highly enough for large corporations or application developers. Extending the Active Directory schema is not something that you should fear as an administrator or as an organization, but it is something that you should think through and plan properly. Following the guidance outlined in Chapter 5 as well as this chapter will ensure that your schema extensions are well planned. In the event that something does turn out to not be well planned, you can use the schema’s defunct functionality to disable and hide classes or attributes so that you can reuse their names and unique identifiers.
Hopefully we have shown you not only the perils and pitfalls of modifying the schema, but also why the schema is necessary and how it underpins Active Directory as a whole. While you should be cautious when modifying Active Directory, sensible administrators should have as little to fear from the Active Directory schema as they do from the Windows Registry.