Read any Active Directory-related book, magazine article, or Web site and you'll probably find a warning that modifying the Active Directory schema is a delicate and non-reversible operation. While I wholeheartedly agree with the delicate part, under certain circumstances modifications to the Active Directory schema are reversible. A fellow technical author named Robbie Allen has developed a technique that will allow you to delete certain modifications to the Active Directory schema.
Words of caution
Before I get started, there are a few words of caution that I want to pass along. Adding, modifying, and deleting Active Directory attributes is a complex process. Additions are best classified as semi-permanent because, as I'll explain later, in some cases additions cannot be deleted. Because of this, I strongly recommend making a full backup of all of your domain controllers before beginning. I also recommend unplugging a domain controller from the network just in case you make a mistake. The unplugged domain controller will contain the Active Directory in its original form and can be used to rebuild the domain in an emergency. The other word of caution that I need to pass along is that any attributes or schema modifications that you make are case sensitive. With that said, let's get started.
Modifying the Active Directory
The first thing that I want to show you is how to extend the Active Directory's schema. It can cause serious problems if you attempt to delete any of Windows' built-in classes or attributes. Therefore, I want to show you how to create your own custom classes and attributes. Later I'll show you how to delete or disable the attributes that you have just created. Just remember that tampering with the Active Directory schema is a risky operation and should always be perfected in a test forest prior to deploying changes in a production forest.
Because modifying the Active Directory schema isn't something that Microsoft openly encourages you to do, the tools necessary for doing so aren't installed by default. Therefore, you must begin by installing the Windows 2000 Administration Tools. To do so, verify that Service Pack 2 or higher is installed. Then, open the Control Panel and double-click the Add/Remove Programs icon. When you do, you'll see the Add/Remove Programs dialog box. Now, go through the list of currently installed programs and select the Windows 2000 Administration Tools. Click the Change button to launch the Windows 2000 Administration Tools Setup Wizard. Follow the wizard's prompts for installing all of the Administrative Tools.
When you've finished installing the Administration Tools, you must also install the Windows 2000 Support Tools. To do so, insert your Windows 2000 Server installation CD and wait for the splash screen. On the splash screen, select the option to explore the CD's contents. Next, navigate to the \SUPPORT\TOOLS folder and double-click the Setup icon. When you do, you'll see a wizard that's used for installing the Windows 2000 Support Tools. The wizard is pretty much self-explanatory. Once you've completed the wizard and installed the Windows 2000 Support Tools, reboot your server.
Now that you've installed the necessary tools, enter the SCHMMGMT.MSC command at the Windows 2000 Server Run prompt. Doing so will open the Schema Manager console. When the console opens, right-click the Active Directory Schema from the column on the left and select the Operations Master command from the resulting context menu. Doing so will reveal the Change Schema Master dialog box as shown in Figure A.
|You'll extend the schema using the Active Directory Schema MMC.|
Select The Schema May Be Modified On This Domain Controller, then click OK. This is a crucial step because nothing else I'm going to show you will work until you have completed it. Furthermore, everything I'm about to show you must be done directly to the domain controller holding the Schema Master role. This domain controller is identified within this dialog box.
Now it's time to begin creating some new Active Directory attributes. The trickiest part of creating attributes is that you must assign each attribute a unique X.500 object ID number. What makes this so tricky is that you can't just make a number up, or you'll risk overlapping with an existing number or a number that has been reserved for use with future software. Fortunately, Microsoft makes a utility called OIDGEN, which can generate these numbers for you. OIDGEN is included in the Windows 2000 Server Resource Kit.
Running OIDGEN is a matter of simply opening a command prompt window and entering the OIDGEN command. Upon doing so, the utility will generate two numbers: an attribute base OID and a class base OID. Write these numbers down! All future OIDs that you create will be based on one of these two numbers. The numbers that are produced are actually a series of numbers separated by decimal points. The first several numbers are known as the OID prefix. All attributes that you create need to have a common prefix. If you happen to lose your OIDGEN information, you can run OIDGEN again to get a new set of numbers, but using a new set of numbers increases the size of the OID prefix table within the Active Directory and dramatically decreases the Active Directory's performance.
As I said, all of the OIDs that you create will be based on the numbers that you've generated. To create a unique X.500 OID, simply look at the Attribute Base OID, then take the set of numbers furthest to the right and increment it by one. The number that you produce (including the prefix) will be a unique OID. Record the number that you produced and the attribute that you're associating with it. The next time that you need to create an attribute, take the highest number on your list of unique OIDs and increment it by one. You must always only work with the last set of numbers.
The next step in this process is to begin creating attributes. To do so, return to the Active Directory Schema Attributes console, right-click the Attributes object, and select the Create Attribute command from the resulting context menu. When you do, you'll see a warning explaining that the process is irreversible. Click the Continue button to clear the warning.
The information that the Create New Attribute dialog box asks for is fairly simple to fill in. You can see a sample of it in Figure B. Essentially, you'll be entering a common name, an LDAP display name, and the X.500 object ID. The dialog box also contains a drop-down list that you can use to select the data type. You can enter minimum and maximum values if you like, although these are not necessary.
|You can add your own attributes.|
Disabling schema classes and attributers
According to Microsoft, you can't delete a schema class or attribute. If you create a class or an attribute and later decide that you want to delete it, your only option, according to Microsoft, is to disable it.
Unlike deleting an object, deactivating an object is a reversible operation and is relatively safe. Even so, you should only disable classes and attributes that you have created. Disabling a default Windows class or attribute can cause some major problems.
Before I explain this technique, I should mention that there is no direct way of disabling an attribute. Windows won't allow you to disable an attribute unless its corresponding class has also been disabled. Otherwise, it is possible that the attribute may be required for a class-related operation. On the other hand, if you disable an entire class, then you have effectively disabled the class's attributes as well.
To disable a class, open the SCHMMGMT.MSC console. Next, select the Classes container and then select the class you want to disable. Right-click the class and select the Properties command from the resulting shortcut menu. When you do, you'll see the class's properties sheet. The properties sheet's General tab contains a check box called Deactivate This Class. Select this check box and click OK. Doing so will mark the class as defunct within the Active Directory. Click OK to complete the operation. The class won't fully be deactivated until the next replication cycle completes. If you find that you have trouble deactivating a class, make sure that you have allowed the schema to be modified, as described in the section above.
Deleting schema classes and attributes
Earlier today when I spoke to Robbie Allen on the phone, he explained that he developed the technique I'm about to show you because not being able to delete classes or attributes from the schema made development difficult. He explained that frequently he would work on projects that involved making modifications to a test forest. If the test didn't go well, though, there was no easy way to backtrack and try the modifications again. The only options were to restore an authoritative backup or to rebuild the domain controllers from scratch.
Robbie went on to explain that he and a friend began to wonder if perhaps Microsoft had put a back door in Windows that would allow you to delete modifications you had made to the schema. In the end, Robbie found that being able to delete schema classes and attributes was simply a matter of tinkering with a few permissions.
Before I show you this trick, there are a few things that you need to know about it. First, use this trick at your own risk. While the technique does allow you to delete schema classes and attributes, you should still exercise caution when making schema modifications. Don't just assume that you will be able to reverse a modification. In production environments, schema deletions should be used only in an emergency situation because performing the procedure incorrectly can destroy the entire schema. Furthermore, excessive schema modifications and deletions can cause a fair amount of fragmentation within the database. As if that isn't enough, you won't be able to call Microsoft for help because they will likely tell you that you did something impossible or that you have done some irreparable damage.
Another thing you need to know is that you can only delete custom classes and attributes. Although technically you can delete classes and attributes from the base Active Directory schema, doing so is an extremely bad idea. Even if a default class or object is currently unused, it is there for a reason. Server applications such as Exchange and SQL tend to rely on some of the otherwise unused classes and attributes.
The last restriction is the big one. As I explained earlier, excessive schema additions and deletions can cause problems. Microsoft blocked schema deletions and additions for a reason. Unfortunately, Microsoft found out about the technique that I am about to show you and has blocked it. The technique will only work in Windows 2000 up to Service Pack 2. The block first appears in Service Pack 3. Therefore this technique will not work in Windows 2000 Service Pack 3 and higher or in Windows Server 2003.
As I said earlier, being able to delete from the schema is really only a matter of setting some permissions. The reason you can't normally delete from the schema is that normally neither the Enterprise Admins group nor the Domain Admins group have the necessary schema modification rights.
To solve this problem, log in as a member of the Schema Admins group and open the ADSI Edit console. You can get to ADSI Edit by selecting the ADSI Edit command from the Start | Programs | Windows 2000 Support Tools | Tools menu.
When ADSI Edit opens, there should already be several containers on display, including the Schema container. If not, simply right-click the ADSI Edit container within the console and use the Connect To command found on the resulting shortcut menu to make the necessary connection.
Now, expand the Schema folder to reveal the container named with the Schema folder's Distinguished Name (DN). For example, on my test server, the Schema container is named Schema [cartman.test.com]. The schema's DN container is named CN=Schema,CN=Configuration,DC=test,DC=com. Right-click this container and select the Properties command from the resulting shortcut menu. This will cause ADSI Edit to display the container's properties sheet. The next step is to select the properties sheet's Security tab.
The Security tab contains a standard access control list. The only thing that you have to do here is to select the group that you want to allow to delete items from the schema and grant it the Delete All Child Objects permission. Typically, you would grant this permission to the Schema Admins group. (In case you are wondering, by default the Schema Admins has all available permissions except for Full Control and Delete All Child Objects.) Click OK to make the change.
At this point, you must wait for the next replication cycle to complete. Once it has, you'll only be able to make schema deletions from the domain controller that holds the Schema Master role. Furthermore, the Schema Master must be configured to allow schema updates. I showed you how to enable schema updates earlier in this article by using the SCHMMGMT.MSC tool. If you are uncomfortable using this tool, you can also make the update through the system's registry.
Keep in mind that editing the registry is dangerous. Incorrect registry modifications can destroy Windows and / or your applications. Therefore, you should make a full system backup (as if you haven't already) before continuing. With that said, open the Registry Editor by entering the REGEDIT command. When the Registry Editor opens, navigate through the Registry tree to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Beneath the Parameters container, you should have a Registry key named Schema Update Allowed. If this key doesn't exist, you can create it as a REG_DWORD. Finally, assign this key a value of 1 to allow schema updates.
You must now close the Registry Editor and wait for the next replication cycle to complete. You're now free to delete objects from the schema. Typically, you would use ADSI or FDP to delete objects. You would delete schema objects the same way that you would delete any other type of object using these tools.
Not for the faint of heart
As you can see, you can greatly extend the usefulness of the Active Directory by customizing it to accept data pertinent to your organization. However, great care must be taken because these changes are not always reversible.