Diving into the AD Schema

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.)

   Previous  [1]  2  3  Next