Today's enterprise must keep on hand an ocean of employee information and must be able to access that information quickly and easily. Windows 2000 Active Directory (AD) objects and attributes can serve as a central repository for such data. AD's standard directory definition—the schema—defines a standard set of object classes as well as attributes such as name, phone number, and postal address. When you install Microsoft Exchange 2000 Server, that application adds many new attributes—including 15 extension attributes—in which you can store additional information.
But the standard attributes and Exchange 2000 extension attributes aren't always sufficient for the specific information needs of a business or an application. These extension attributes can contain only one value, but your applications might require an attribute to hold several values (e.g., an array). Also, an attribute's syntax can restrict the type of information you can store in that attribute. For example, suppose you want to store employees' social security numbers in AD. If you've installed Exchange 2000, you can use an extension attribute for this task, but the attribute's syntax—a Unicode string—might pose a problem for a numeric entry such as a social security number.
To solve such dilemmas, Win2K lets you extend the schema. Extending the schema isn't a job you want to dive into unprepared, however. Incorrect schema manipulations can necessitate reinstallation of your entire AD forest—obviously something you want to avoid. Most schema changes are irreversible, so you must understand the objects the schema contains and how they relate to one another before you jump in.
What's in a Naming Context?
As Figure 1 shows, AD contains three naming contexts (NCs): the Domain NC, the Configuration NC, and the Schema NC. Each NC has a specific role and a proper replication scope.
The Domain NC. The Domain NC, also known as the Default NC, holds all the data in an AD domain; Win2K replicates this NC only between the domain controllers (DCs) that belong to the domain. (A Domain NC in a top tree domain of an AD forest might also be called the Root NC but will otherwise appear as a regular Domain NC.)
The Configuration NC. The Configuration NC contains key AD infrastructure objects (i.e., DCs, sites, subnets, site links, and other configuration objects). The Configuration NC clearly shows the topology of the AD forest; Win2K replicates this NC throughout the forest.
The Schema NC. The Schema NC—a sort of meta-NC—defines all AD objects and attributes. Win2K replicates the Schema NC throughout the forest.
To view an NC's content, you can use the Microsoft Management Console (MMC) ADSI Edit snap-in. (You can find ADSI Edit in the \support\tools folder on the Win2K Server CD-ROM.) Figure 2 shows ADSI Edit's display of the Schema NC.
You can also use this tool to discover the relationships between AD objects, but an easier way to study these relationships is to use the MMC Active Directory Schema snap-in, which Figure 3 shows. The snap-in shows two containers: Classes (which holds classSchema objects) and Attributes (which holds attributeSchema objects). This snap-in isn't available by default; to register it on the system, open a command prompt and type
regsvr32 %systemroot%\system32\schmmgmt.dll
The terminology that Microsoft uses to explain the contents of the Schema NC can be quite confusing. Therefore, you need to be sure you have a firm grasp on these terms: object, attribute, class, and instance.
Time for Class
Each AD object in the Domain NC or the Configuration NC is an occurrence, or instance, of an object class. (For example, a User object is an instance of the user class; a Computer object is an instance of the computer class.) A class describes the AD object and the associated properties, or attributes, that must be present to create an instance of the class (i.e., mandatory attributes) and that can be present in an instance of the class (i.e., optional attributes). The Schema NC contains the definitions of all the classes and attributes that exist in the other AD NCs. Confusingly, AD also stores and refers to these definitions as objects. Therefore, you need to keep in mind at all times the difference between an object that's an occurrence of a class (i.e., an object instance in the Configuration NC or the Domain NC) and an object that's the definition of a class or attribute (i.e., a schema object in the Schema NC). Two types of schema objects exist: classSchema objects define classes, and attributeSchema objects define attributes. (All attributes have only one definition but can be used with multiple classes.)
For example, suppose you create a User object called James Bond. This object is an instance of the user class, which the Schema NC defines through a specific classSchema object called user. AD stores James Bond's logon name, BondJ, in an attribute called sAMAccountName, which the Schema NC defines through a specific attributeSchema object called sAMAccountName. The classSchema object user defines the association of sAMAccountName and the user class. (To be exact, sAMAccountName is the attributeSchema object's Lightweight Directory Access Protocol—LDAP—display name. The object's actual name is its common name—cn—attribute, SAM-Account-Name.)
Defining Objects: classSchema Objects
Schema NC classSchema objects contain class definitions. These definitions specify the following information:
- the rules that define where you can create an AD object (e.g., in an organizational unit—OU)
- the relationships, or class derivations, between classSchema objects (e.g., the class's parent class, called a superclass)
- the relationships between attributes and classSchema objects (e.g., the class's mandatory and optional attributes)
Table 1, page 53, shows mandatory and optional attributes that AD typically uses to create a classSchema object. (For a complete list of available attributes, visit the Microsoft Developer Network—MSDN—at http://msdn.microsoft.com/library/psdk/adsi/glschema3_88fn.htm.) Each classSchema object falls into one of three class categories: abstract, auxiliary, and structural.
Abstract class. classSchema objects (i.e., classes) that belong to the abstract category serve as placeholders; you can't use these classes to create an object instance in another AD NC. AD uses abstract classes primarily as parent classes, or superclasses, for other classes so that you can create a hierarchical structure of object classes and define a system of attribute inheritance between classes. (A class's subClassOf attribute names its superclass.) Inheritance isn't dedicated to the abstract classes, but it's their primary purpose. Abstract classSchema objects have an objectClassCategory attribute value of 2.
Auxiliary class. Auxiliary classSchema objects are similar to abstract classes in the sense that you don't use these classes to create AD object instances. Auxiliary classes are similar to include or header files: You can use this category of classes to include a set of multiple attributes in another class's definition. (The systemAuxiliaryClass and auxiliaryClass attributes are multivalue attributes; in other words, many auxiliary classes can exist for one classSchema object. A single-value attribute can contain only one value; a multivalue attribute can contain multiple values.)
When you install Exchange 2000 in an AD forest, the Exchange 2000 Setup adds many classes to the AD schema. Some of these classes belong to the auxiliary category and define attributes that are specific to Exchange 2000. A classSchema object's systemAuxiliaryClass or auxiliaryClass attributes define any applicable auxiliary class objects. Auxiliary classes have an objectClassCategory attribute value of 3.
Structural class. The structural class is the only class type you can use to create object instances in other AD NCs. Structural classSchema objects use the systemPossSuperiors and possSuperiors attributes to define the classes under which a created instance of the class can reside. (For example, the user class's systemPossSuperiors attribute defines the organizationalUnit class as a possible container for instances of the user class, so you can create a User object in an instance of the organizationalUnit class.) These definitions are known as instantiation rules. A structural classSchema object's objectClassCategory attribute value is 1.
Figure 4 shows how the three class types work together. Top is an abstract classSchema object that serves as the superclass of the abstract classSchema object Person. Person, in turn, serves as the superclass of the abstract classSchema object organizationalPerson. That object serves as the superclass of the user class (i.e., the classSchema object user). The classSchema object user is a structural class object that defines User objects (i.e., instances of the user class).
As Figure 4 shows, the user class inherits attributes from its superclasses and from various auxiliary classes. All objects have a set of mandatory attributes and a set of optional attributes. A classSchema object's systemMustContain and mustContain attributes define these mandatory attributes; a classSchema object's systemMayContain and mayContain attributes define the object's optional attributes. ADSI Edit shows no defined value for the user class's systemMustContain and mustContain attributes. This fact doesn't mean the user class has no mandatory attributes. Rather, the user class inherits the mandatory attributes of its superclasses (e.g., Person) and auxiliary classes (e.g., mailRecipient).
Defining Attributes: attributeSchema Objects
Schema NC attributeSchema objects define the attributes available in AD. As with classSchema objects, each attribute-Schema object has a set of attributes that defines its characteristics. Table 2 describes the mandatory and optional attributes that AD typically uses to create an attributeSchema object. (For a complete list, visit the MSDN site at http://msdn.microsoft.com/library/psdk/adsi/glschema3_92yb.htm.)
Every attribute in the AD schema has a predefined syntax that specifies the type of information the attribute can store. (For example, attributes store telephone numbers differently from binary values or strings.) An attributeSchema object's attributeSyntax attribute uses an Object Identifier (OID) to specify the syntax, and the object's oMSyntax attribute uses the X/Open Object Model designation to specify the syntax. The object's oMObjectClass attribute also specifies the syntax, albeit in a different form, whenever the oMSyntax attribute uses a value of 127. (This value indicates that the syntax references an object data type.) In these cases, you must ensure that the object's oMObjectClass attribute displays the correct value for the chosen syntax, as Table 3, page 58, shows. Table 3 lists the available syntaxes and their corresponding OID, oMSyntax attribute, and oMObjectClass attribute values. As of this writing, you can't add new attribute syntaxes to AD.
Identify Yourself
Every AD class and attribute must be unique, so you must assign a unique OID to each class and attribute definition. OIDs are represented as dotted decimal strings, similar to IP addresses. (Table 4, page 58, shows the OIDs for several object classes.) A classSchema object's OID resides in its governsID attribute; an attributeSchema object's OID resides in its attributeID attribute.
The International Organization for Standardization (ISO) Name Registration Authority issues these identifiers; OIDs aren't Microsoft specific. (For information about the ISO Name Registration Authority and OIDs, visit http://web.ansi.org/public/services/reg_org.html or http://www.iso.ch/members/index.html.)
OID numbering uses a tree structure. Well-defined authorities in a naming tree can allocate branches, or arcs, of that tree to subauthorities, which can then allocate subbranches to other subauthorities. Table 5 shows the OID tree structure for the builtinDomain object class in the AD schema. (Note that as Table 4 shows, the organizationalUnit class doesn't use the Microsoft base OID. Another entity owns the organizationalUnit OID definition.) A company that wants to add a new schema attribute can apply to the ISO Name Registration Authority to register an OID or can use the Microsoft Windows 2000 Server Resource Kit's oidgen.exe tool to create a new OID below the Microsoft arc.
Don't confuse OIDs with globally unique IDs (GUIDs). An OID uniquely identifies a class; a GUID uniquely identifies an object instance. For example, the user class has the OID 1.2.840.113556.1.5.9; every User object that you create from this class has a unique GUID but comes from the same class (i.e., the class that uses the OID 1.2.840.113556.1.5.9).
The Object Category
Win2K ships with a base schema that provides all the classSchema objects and attributeSchema objects that AD needs to deliver basic features and structure. These objects are part of the base Directory Information Tree (DIT) in the ntds.dit database file. These base classes and attributes are known as Category 1 objects. Classes or attributes that applications or an administrator adds to the base DIT (e.g., attributes that Exchange 2000 Setup adds) are known as Category 2 objects.
The object category definition resides in classSchema and attributeSchema objects' systemFlags attribute. As its name implies, the systemFlags attribute contains bit flags that are on or off. The systemFlags attribute is 4 bytes long; bit 4 defines the category type. For a Category 1 object, bit 4 is set to on (i.e., it has the value 16 in decimal format); for a Category 2 object, the bit is set to off. If no other bit flags need to be set in a Category 2 object's systemFlags attribute, the attribute can be empty (i.e., not set). In ADSI Edit, the systemFlags attribute will then show a value of <not set>, which indicates that the object category is 2.
The object category is important because it reduces the chances that any schema changes an application makes will interfere with other applications. The category also restricts the type of schema changes that an application can make. (I'll discuss these restrictions in my next article.)
More Schema Help
The AD schema contains an abundance of data. Understanding schema objects and their interrelationships isn't easy but is worth the effort. Compaq has scripts that load information about all the schema objects into a Microsoft Excel spreadsheet. These scripts are part of a two-part white paper titled "Understanding the Microsoft Windows Script Host and the Active Directory Service Interfaces in Windows 2000" (Part 1) and "The Powerful Combination of Windows Script Host and Active Directory Service Interfaces under Windows 2000" (Part 2). To download the papers and scripts, visit Compaq's ActiveAnswers Web site (http://activeanswers.compaq
.com/aa_asp/solution_list.asp). Scroll down to Knowledge Mgmt. & Messaging, then Mail and Messaging. Click Microsoft Exchange Server. In the Available Information scroll box, choose Technology. (You might need to register as a user before you can access this site.) Click Windows 2000 and Exchange. For additional schema information sources, see the sidebar "Schema Details."
Now you have an insight into the AD schema's structure. Although Microsoft's terms can be confusing, perfecting your understanding of schema objects and how they relate to one another will give you the confidence you need to modify the schema to fit your business application requirements. My next article will explain the steps to take when you're ready to move ahead with schema extensions. Although you'll need to dedicate time to planning and testing your extensions, it will be time well spent.
