This chapter is from the book
This chapter is from the book
This chapter is from the book
Schema
In this section we explain the role of the schema, its location, and its inspection. We also explain briefly the topics of subschema subentry and schema cache.
Role of the Schema
The schema contains rules for object instantiation—that is, it dictates which objects a directory can contain, their relationships, and their possible content. (This is true for other directory services as well as Active Directory.) In other words, the schema governs the structure and content of Active Directory with structure and content rules. Table 8.1 explains these uses of the schema.
Table 8.1 describes why the schema is necessary to maintain a directory. In addition, the schema contains information that helps to maintain the schema itself. This is described in Table 8.2. We explore the topics introduced in Table 8.1 and Table 8.2 in the later sections "Classes" and "Attributes and Syntaxes."
TABLE 8.1 Uses of the Schema
|
Category |
Description |
|
Structure rules |
|
|
Content rules |
|
|
Miscellaneous |
|
TABLE 8.2 Inside Uses of the Schema
|
Category |
Description |
|
Naming and identification |
|
|
Schema class hierarchy |
|
|
Protection |
|
Location of the Schema
Because everything in Active Directory is stored in objects, the schema is implemented as a number of objects. There is one object for each class in the schema (classSchema objects) and one for each attribute (attributeSchema objects). However, there are no objects for the syntaxes; they are hard-coded into Active Directory. This means that classes and attributes can be created and modified, but syntaxes cannot.
NOTE
A directory service vendor could implement the schema as a long text file. Microsoft chose to implement the Active Directory schema as Active Directory objects. This enables administrators and applications to query the schema contents and add or modify classes and attributes using the same object manipulation techniques as would be used with any Active Directory objects.
Consequently, the location of the schema is the location of the schema objects.
The Physical Location of the Schema
As you learned in Chapter 5, every domain controller stores a full replica (or copy) of three partitions (or replication units): the schema, configuration, and domain partitions. Obviously, the schema (i.e., the schema objects) is physically located in the schema partition.
You also learned that the schema partition is replicated to every domain controller in a forest, so that all domain controllers contain identical information. Any changes to the schema would have to be initiated on the domain controller that holds the schema master role (as explained in Chapter 5).
Even though there are three separate partitions, their replicas in a given domain controller are stored in the same database table. That table resides in the Active Directory database file, which is called ntds.dit. The default location for the file is the folder C:\Winnt\NTDS.
There is another ntds.dit file located in C:\Winnt\System32. That file serves as the initial database file and it is copied to C:\Winnt\NTDS (or whatever location you choose) during the DCPromo process.
NOTE
You may also come up with a file schema.ini (in C:\Winnt\System32). Despite its name, it doesn't initialize the schema in any way. Instead, it contains the information for the initial objects in your tree—mostly for the domain and configuration partitions.
The Logical Location of the Schema
All the 1,005 schema objects (142 classes and 863 attributes) are located in the Schema container. That container is of class dMD (the letters stand for "directory management domain") and its distinguished name is CN=Schema, CN= Configuration, DC=forest_root_domain. Figure 8.3 shows the location of the schema container in the directory tree.
){kind=link}
Figure 8.3 The schema container is logically under the configuration container, which in turn is under the forest root domain. Physically, however, the three are different partitions.
NOTE
Although there seems to be a CN=Configuration object under your root domain, you won't see it in the Users and Computers snap-in, even with Advanced Features turned on. That snap-in is meant to show contents of only domain partitions.
Inspecting the Schema with ADSI Edit
Now that you know that the schema is implemented as a number of objects and you know where to find them, we can start studying them in the user interface. The two main tools for the job are as follows:
ADSI Edit, a general tool for viewing all the objects in Active Directory
The Schema Manager snap-in, a specialized tool for viewing and managing the schema
We begin our discussion of these two tools with ADSI Edit. Because it is a general tool, it nicely shows you the general picture and the location of the schema objects, not just the schema contents.
NOTE
There are other tools that you can use to view the schema. For example, Support Tools contains LDP, which enables you to do various LDAP operations—among others, to view the schema.
We mentioned previously that with the Users and Computers snap-in you see only part of the objects and only part of the attributes of each object. With ADSI Edit you see all the objects and all of their attributes.
ADSI Edit is part of Support Tools, which you have to install separately. Locate the folder Support\Tools on your Windows 2000 CD and run Setup.Exe. After the installation, you will find the tool by clicking the Start button and then selecting Programs, Windows 2000 Support Tools, Tools.
Figure 8.4 shows the screen that opens when you launch ADSI Edit. ADSI Edit shows container objects with yellow folder icons and leaf objects with white icons similar to the icons used for text documents in Windows Explorer. The left pane shows only container objects, and the right pane shows both container and leaf objects.
){kind=link}
Figure 8.4 When you first start ADSI Edit, it shows three partitions (aka naming contexts). Under the Schema container you can see all the class and attribute objects.
To familiarize yourself with ADSI Edit, it's a good idea to first check the properties (or attributes) of one of your users before you start to explore the schema objects.
Inspecting Attributes of Classes and Attributes
When you are ready to move to the schema objects, you can start inspecting their attributes. For example, you can check the attributes of the user class schema object (see Figure 8.5).
){kind=link}
Figure 8.5 When you select Properties in the context menu of any object, ADSI Edit opens a dialog box that enables you to browse all the attributes of that object. From the first drop-down list, you can choose Mandatory, or Optional, or Both.
WARNING
ADSI Edit enables you to change the attribute values. When you study schema objects, be sure to click Cancel at the end. Do not click OK or Apply.
Note that because all objects contain attributes, classSchema and attributeSchema objects also contain attributes. For example, the object CN=Jack Brown has an attribute givenName, with the value "Jack." The schema contains the object CN=Given-Name, which in turn contains such attributes as schemaIDGUID and attributeSyntax.
We discuss the contents of classSchema objects a little later in the section "Classes" and attributeSchema objects in the section "Attributes and Syntaxes."
NOTE
ADSI Edit displays all the attributes of a class or attribute object, but only some of them are meaningful to the schema. Most of the attributes are the same ones that all objects in Active Directory have, such as uSNChanged, which helps to track replication.
TIP
SchemaIDGUID and some other attributes use OctetString syntax, which is about the same as binary. If you want to see just the bytes without "0x"s, you can copy and paste the string to Notepad and then replace all "0x"s with nothing.
Various Attribute Names
You may have noticed that each attribute has two slightly different names. Table 8.3 summarizes the two naming conventions together with the administrative tool name.
TABLE 8.3 Various Attribute Names
|
Name |
Example |
Naming Convention |
Where to Find |
|
Common name |
Facsimile-Telephone- Number |
Each word starts with an uppercase letter; a dash occurs between words |
The common name of the attributeSchema object. |
|
LDAP name |
facsimileTelephoneNumber |
Name starts with a lowercase letter; each subsequent word starts with an uppercase letter; no dash between words |
The lDAPDisplayName attribute of the attributeSchema object. |
|
Name in admin tools |
Fax Number |
Any name that is descriptive and consistent |
See the explanation in the text. |
NOTE
Unlike the example in Table 8.3, the three attribute names may be quite different, such as "Surname"—"sn"—"Last name" or "WWW-Page-Other"—"url"—"Web Page Address (Others)." This is the case especially with attributes that have long-established X.500 names.
Just as attributes do, classes have both common names and LDAP names.
Sometimes the common name and LDAP name are the same, but they refer to different attributes. Table 8.4 gives two examples of this (using four attributes).
TABLE 8.4 Some Confusing Name Pairs
|
LDAP Name |
Common Name |
|
info |
Comment |
|
comment |
User-Comment |
|
street |
Street-Address |
|
streetAddress |
Address |
The attribute names that you see in administrative snap-ins, such as Users and Computers, are not usually stored in the schema. Instead, you find them under the DisplaySpecifiers container, which in turn is under the Configuration container. In this container, first locate the object with your locale identifier (e.g., 409 for "English (United States)"). Then open the properties for CN=user-Display and select the attribute attributeDisplayNames. It is a multivalued attribute that contains pairs of LDAP names and display names.
NOTE
The list of name pairs is not likely to contain display names for all attributes. For names that are not on the list, each attribute schema object has an attribute adminDisplayName, which the administrative tools can use instead.
NOTE
In reality, the Users and Computers snap-in doesn't use all the display specifier attributes (even though it is suggested here and in Microsoft's documentation). For example, most of the field names in user properties (such as Description or Office) are hard-coded in the tool instead of readable from the attributeDisplayNames attribute.
We use mainly LDAP names in this book for three reasons:
If you use ADSI scripts, you need LDAP names.
If you use LDAP filters, you need LDAP names.
The Schema Manager snap-in, Replication Monitor, and many other administration tools use LDAP names.
Inspecting the Schema with the Schema Manager Snap-In
The Schema Manager snap-in is made specifically for viewing and managing the schema. Because Microsoft doesn't make it available to casual users, you have to take some extra steps to access it.
WARNING
Just as with ADSI Edit, do not select OK or Apply in the Schema Manager snap-in dialog boxes. Always exit by clicking Cancel.
TIP
If you want to run the Schema Manager snap-in in a workstation, you must first install the Admin Pak. Locate the file AdminPak.MSI in the I386 folder of a Windows 2000 Server CD. When you double-click that file, it will install the Admin Pak.
In the Run window (click the Start button and select Run) or at the command prompt, enter the command regsvr32 schmmgmt.dll and press Enter. You should get a message indicating that the registration was successful.
Start MMC (Microsoft Management Console) by typing mmc and press Enter (again, either in the Run window or at the command prompt).
In the Console menu, select Add/Remove Snap-in. In the dialog box that opens, click Add.
From the list of snap-ins, select Active Directory Schema, click Add, and click Close. Click OK to close the original dialog box.
To save what you just did, in Console menu select Save As, select the name and location of the .msc file that you want, and click Save. Next time you want to start the snap-in, double-click the .msc file you just saved.
Now you are ready to take a look at your schema from a slightly different view than what you saw with ADSI Edit. Figure 8.6 and Figure 8.7 illustrate this view.
){kind=link}
){kind=link}
Figure 8.6 When you start the Schema Manager snap-in, it shows two containers: one for all the classes and one for attributes. Unlike with ADSI Edit, the objects are listed by their LDAP names.
Figure 8.7 When you select a class in the left pane, the right pane shows the attributes for that class. Again, they are listed by their LDAP names. The text in the description column is usually the same as the common name you can see with ADSI Edit.
Using the Schema Manager snap-in, you can also see the mandatory and optional attributes for any class, which would be quite cumbersome with ADSI Edit. Note that this time we don't mean the attributes of a classSchema object, such as schemaIDGUID, but the attributes that the instances of the class may use, such as homeDirectory or givenName.
In addition to the lists in the screen shots in Figure 8.6 and Figure 8.7, you can open a properties dialog box for any class or attribute. We show those dialog boxes and discuss them in the later sections "Classes" and "Attributes and Syntaxes."
NOTE
You must select an attribute in the Attributes container to be able to open the properties dialog box for it. If you select the attribute from the list shown in Figure 8.7, you will see just one item, Help, when you right-click the attribute.
Dumping the Schema to a Spreadsheet
Although the two graphical tools we just described are nice to use to explore the schema, they both have one problem: You can see the attributes for only one classSchema or attributeSchema object at a time.
In this section we explain how you can dump all the information in your schema to a spreadsheet. It allows a broader view to the schema contents. Also, you can sort and filter the data, which gives you a better idea of how the various attributes are used. As you read on in this chapter, you can use the tables created here as a reference.
We use Excel in our explanation of how to dump the schema into a spreadsheet, but you can use other spreadsheet and database applications. First, you dump all your classSchema and attributeSchema objects into two text files, and then import those text files to Excel.
At a domain controller, you must type the following two commands at the command prompt (click the Start button and select Programs, Accessories, Command Prompt) and press Enter after each command:
C:\>csvde -f classes.txt -d cn=schema,cn=configuration,dc=sanao,dc=com -r (objectCategory=classSchema) C:\>csvde -f attributes.txt -d cn=schema,cn=configuration,dc=sanao, dc=com -r (objectCategory=attributeSchema)
You should see output like the following for each command:
Connecting to "(null)" Logging in as current user using SSPI Exporting directory to file classes.txt Searching for entries... Writing out entries............................. ................................................ Export Completed. Post-processing in progress... 142 entries exported The command has completed successfully
Each of the two commands specifies an output file, a base distinguished name from which to dump, and an LDAP filter.
NOTE
You can also use the CSVDE tool on a workstation. See its online help for more information.
Next you must launch Excel and perform the following steps for both of your text files:
Select File, Open.
Select one of your newly created text files and click Open. A text import wizard should start up.
Specify that your data is delimited (instead of fixed width).
Specify that the delimiter is a comma.
Click Finish to complete the wizard. You should now have about 30 columns of data, one column for each attribute.
Click cell A2 to activate it. Choose Freeze Panes in the Window menu. Now your first row with the column labels (i.e., attribute names) stays visible, even if you scroll down the sheet.
Adjust the width of each column as you like. You can also double-click the right border of each column header (F, G, H, and so on) to autosize the columns. Note that some of the data values may be longer than the width of your screen. If you cannot resize a wide column by dragging its right border with a mouse, you can use the Format menu option Column, Width.
If they are present, remove the columns uSNChanged, uSNCreated, whenChanged, whenCreated, dITContentRules, extendedClassInfo, modifyTimeStamp, and extendedAttributeInfo. You are not interested in them because they don't define schema characteristics.
Open the Data menu and select Filter, AutoFilter. This turns each column header into a drop-down list filter. When you open a list, you see all the distinct values for that column (i.e., attributes). If you select a value, your sheet will be filtered to show only the lines with that value.
Save the sheet in XLS format.
Figure 8.8 shows an Excel sheet that results from the preceding steps. We haven't sorted the lines—you might want to sort them by the lDAPDisplayName column (using the Sort feature in the Data menu of Excel).
){kind=link}
Figure 8.8 After you have all the class definitions in Excel, you can filter in just the classes you specify—for example, classes that have defaultHidingValue = False.
Subschema Subentry
Active Directory supports LDAPv3, which requires a directory service to expose its schema in a single subSchema object. Active Directory stores this object in the Schema container with the name CN=Aggregate.
The Aggregate object contains some multivalued attributes, which list the classes and attributes available in the schema. If you want to take a look, those attributes are as follows:
- objectClasses
- attributeTypes
- extendedClassInfo
- extendedAttributeInfo
- dITContentRules
In Chapter 10 and Chapter 11, we use the ADSI interface for directory access. When you specify a path such as LDAP://sanao.com/schema for ADSI, or just LDAP://schema, ADSI will expose the subSchema object as one container with 142 classes, 863 attributes, and 33 syntaxes under it. The properties for these "virtual objects" are more limited than those with the real Schema container, but they have some advantages for scripting.
NOTE
Active Directory supports 23 syntaxes, as discussed later in this chapter. The ADSI interface is using 33 syntaxes because it must support other environments also—most notably, NetWare. The ADSI syntaxes are listed in Chapter 10.
Schema Cache
Because the schema guards the structure and content of Active Directory objects, it is needed every time any object (such as the user Jack Brown) is added or modified. Accessing the schema from the ntds.dit file would be too slow; therefore, every domain controller holds a copy of the schema in RAM. This copy is called the schema cache.
Internally the schema cache is not an identical copy of the bytes on disk; it is structured a little differently for easy and fast access.
Naturally the schema cache is built based on the information in the disk version each time the domain controller starts. If a change is made to the schema on the schema master, the change starts to replicate to other domain controllers, just as any change to Active Directory does. In each domain controller, the change goes first to the schema on disk and then, after a 5-minute delay, the schema cache is updated.
You cannot use most of the schema changes until they are in the schema cache of the domain controller you are using. Consequently, there is an additional 5-minute wait after the possible replication latency from the schema master to your domain controller. During this waiting period, applications continue to use the old schema cache.
The 5-minute delay here is for the same reason as with replication. After one change, usually more changes soon follow. Because each schema cache update consumes quite a few bytes of memory, it is more efficient to wait a little and make them all at once.
NOTE
The 5-minute period is counted from the first change, and it doesn't reset if there is another change 1 minute later. Therefore, that latter change has to wait only 4 minutes to get into the schema cache.
The extra memory consumption in schema reload is due to the fact that when a new schema version is reloaded in cache, the old schema cache stays in memory for all the threads that were already running. Once all the old threads have exited, the older schema cache copy is released from memory. This also means that if you test schema changes, you probably need to restart your admin tools, so that they start to use the new schema cache and therefore can see the changes.
Triggering the Schema Cache Update
If 5 minutes is too long for you to wait, you can trigger the cache update immediately with the Schema Manager snap-in. In the left pane, right-click the node Active Directory Schema and select Reload the Schema. There is also a programmatic way to trigger the schema cache update. You must write the value 1 to an attribute schemaUpdateNow residing in a special rootDSE virtual object. We cover this in later chapters:
Chapter 9 contains an example of adding a new attribute and class to the schema and triggering the update using the LDIFDE tool.
Chapter 10 describes the rootDSE object in more detail.
Chapter 11 contains an example of adding a new attribute and class to the schema and triggering the update using the ADSI interface in a script.
Before we conclude our discussion about the schema in general, we'll mention the constructed attributes.
Constructed Attributes
Not all attributes for an object are stored in the schema on disk. Instead, they are built from other attributes. Twenty-two of the 863 attributes in the base schema are constructed.
The 22 constructed attributes are as follows: