How do I extend the Active Directory Schema (ADS)?

Issue

How do I extend the Active Directory Schema (ADS)?

Solution

To prepare to extend the schema for Microsoft active directory server, follow these steps:

1. Install the Schema administration snap-in from the Windows2000 installation media.

2. In Windows 2000, only the Administrator or a member of the "schema admins" group can update the schema. If the domain controller is part of a forest that shares a single global catalog, you must log in to the domain controller designated as the schema master.

Windows 2000 is a multi-master environment with regard to data stored in the directory. Windows 2000 is a single-master environment with regard to the directory metadata and replicating changes in the schema. In ADS, single-master activities are called Floating Single Master Operations (FSMO) and the domain controller that acts as the schema master is called the Schema FSMO.

3. If you have not done so already, make the schema read/write. This requires a change to the Windows 2000 registry. On the Schema FSMO, run regedit and add the parameter Schema Update Allowed, with data type of REG_DWORD, under HKEY_Local_Machine\System\Current Control Set\Services\NTDS\Parameters. Set the value of this parameter to a non-zero number.

This automatically promotes the current domain controller to Schema FSMO if it had not been previously designated as such, and demotes any domain controller that previously held this designation.

4. If you have successfully installed the Active Directory Schema Manager, start an instance of the Microsoft Management Console by running MMC. Otherwise, from the Console Menu select Add/Remove Snap-in and add the Active Directory Schema Manager tool to the console. You are now ready to begin extending the schema.

5. Great care should be taken when adding new classes and attributes, because once added they cannot be removed from the global catalog. All extensions require X.500 OIDs, common names known to ADS and LDAP display names (name mappings that are returned to LDAP clients). Be sure to double check spelling and OIDs before committing changes to the catalog.

Attributes

All Mirapoint attribute objects carry a caseIgnoreString syntax. Some attributes may be multi-valued, while others may not. Be sure to read the Mirapoint or RazorGate documentation about attributes before committing changes to the catalog.

Object Classes

As is true with other LDAP implementations, object classes carry the following constraints:

• Inheritance (from what class the object is derived in the class hierarchy) - This determines what attributes are (implicitly) mandatory or allowed for newly created objects belonging to the class.
• Containment - Defines the container classes for a newly created object, that is, under which classes this object may exist. Containment is defined for a class after the class has been added to the global catalog.
• Type (Structural, Abstract, or Auxiliary) - Determines whether the class can be used to create objects (Structural), add new attributes to a pre-existing object (Auxiliary), or create a template for a structural class (Abstract, for instance TOP).

The class definitions for Mirapoint extensions are described in the Mirapoint and RazorGate documentation.

Implementation Notes

ADS does not allow changing a user's password except over a 128-bit SSL connection, bound as a user with password-changing privilege. The attribute unicodePwd must be base64-encoded and enclosed in quotes. This 128-bit limitation makes it difficult to deploy ADS in non-US markets with weak SSL.

Although ADS supports bind with user name and password (UPN), Mirapoint software does not. Only bind with distinguished name (DN) is supported.

ADS write performance adds per second is about 10% of OpenLDAP performance on a typical system. ADS search performance is comparatively even less than that.

It is not possible to host multiple domains on a single ADS server, so a hierarchical domain-oriented naming model is not possible on a single box.