Active Directory Schema

This chapter is from the book

Inside Active Directory: A System Administrator's Guide

Learn More Buy

This chapter is from the book

This chapter is from the book 

Inside Active Directory: A System Administrator's Guide

Learn More Buy

Classes

In the overview section of this chapter we introduced classes, and in the "Schema" section we mentioned that there is a class schema object for each class. In this section we examine classes and their schema objects in more detail.

Each class is defined by the attributes of its schema object. This means that examining classes actually means examining those attributes. Each classSchema object may contain at most 95 attributes. However, remember that many of these attributes are not related to defining the schema, but instead are "normal" attributes for any object. Examples of these normal attributes are wWWHomePage and uSNChanged. Here we discuss 36 attributes and omit 59 normal "uninteresting" attributes.

Classes can inherit from other classes attributes their instances must and may contain. Of the 95 classSchema attributes, 22 are the class' own attributes and 73 are inherited from the top class. In the list of 36 attributes in Table 8.5, 22 are the class' own attributes and 14 are inherited attributes.

TABLE 8.5 Attributes of a classSchema Object

We have divided the 36 attributes into four categories. These categories resemble those listed in the "Role of the Schema" section earlier in this chapter (see Table 8.1 and Table 8.2).

• Names and identifiers. There are 14 of these attributes (plus 1 naming-type attribute). Fortunately, not all of them are used.

• Structure and containment rules. These 7 attributes define where in the tree each object may be created (or instantiated) and which attribute values it must and may contain.

• Class inheritance. A class may inherit containment from another class. The 4 attributes in this category define how this happens.

• Miscellaneous. The remaining 10 attributes provide some defaults, for example, to the objects that will be created to the corresponding class.

Table 8.5 lists the 36 attributes by their LDAP names. If the common name has no resemblance to the LDAP name, the common name appears in parentheses (such as "distinguishedName (Obj-Dist-Name)"). The Type column indicates whether the attribute is mandatory or optional. The Source Class column indicates either classSchema or top, the latter meaning the attribute was inherited from the top class. The Base Schema Classes column gives a summary of the kind of values the 142 classes have for the attributes in the table. Finally, the user Class Example column lists the values for the user class.

In the remaining subsections, we examine each of the four categories.

Names and Identifiers

The various names and identifiers identify the classes by both people and Active Directory. This category of 15 attributes includes nine different names, two descriptions, and three identifiers. The fifteenth attribute (rDNAttID) is none of these, but we include it in this category because it is name-related.

Table 8.6 describes the 15 attributes. Fortunately, Active Directory doesn't use quite all of them, as indicated in the table. Consequently, we are left with "only" six different names and one description. Furthermore, canonicalName, distinguishedName, and RDN are redundant with cn, because you can derive them directly from cn. This leaves us with three "nonredundant" names (the first three in Table 8.6) and one description.

TABLE 8.6 Name and Identifier Attributes of a classSchema Object

Object Identifiers

As you see in Table 8.6, one of the many identifiers for each class schema object is an object identifier (OID). An OID consists of numbers that have dots in between them, such as 1.3.6.1.4.1.123123. The number is hierarchical, so the first number in an OID is the highest level of the tree.

Anyone who "owns" a certain OID can allocate new child OIDs to it. For example, if you have the base OID 1.2.3, you could allocate to it OIDs, such as 1.2.3.1, 1.2.3.77, and 1.2.3.77.4.3.2.1.

Just like IP addresses, OIDs are administered globally so that no two organizations in the world can have the same base OID. OIDs allow unique identification of all kinds of things—they are used to identify classes, attributes, and syntaxes in X.500 directories and variables in Simple Network Management Protocol (SNMP), among other things.

Microsoft uses the base OID 1.2.840.113556.1 in many Active Directory classes (and attributes). Table 8.7 describes the history of that OID.

TABLE 8.7 Microsoft Active Directory OIDs

Another base OID that Microsoft owns is 1.3.6.1.4.1.311. Each numeric part has a name, so we can express this same base OID as iso.org.dod.internet. private.enterprise.microsoft. "Org" in the name indicates an "identified organization" that ISO acknowledges and "dod" indicates the U.S. Department of Defense. These "private enterprise numbers" are currently assigned by the Internet Corporation for Assigned Names and Numbers (ICANN, http://www. icann.org/). In addition to assigning enterprise OID numbers, ICANN coordinates the assignment of Internet domain names and IP address numbers. You can see the current list of assigned private enterprise numbers at ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers.

Recall that we discussed the X.500 standards in Chapter 1. OIDs have similar roots, as they were first defined in ITU-T X.208, which corresponds to ISO/IEC 8824. However, X.208 has been superseded by the ITU-T recommendation X.680 (12/97): "Abstract Syntax Notation One (ASN.1): Specification of basic notation."

In addition to the OID notation, X.680 specifies the following base OIDs:

• 0: ITU-T assigned.

• 1: ISO assigned.

• 2: Joint ISO/ITU-T assigned. Active Directory contains some classes and attributes from X.500, and they use the base OIDs 2.5.6 and 2.5.4, respectively. There is also one "2.5.20" class ("X.500 schema object class") and six "2.5" attributes other than 2.5.4.

You can inspect various assigned OIDs at http://www.alvestrand.no/domen/objectid/top.html.

Obtaining a Base OID

If your organization needs to add classes or attributes to the schema, it must obtain a base OID. This need could rise from two situations.

• You need to modify the Active Directory schema of your organization.

• You sell applications to other organizations, and those applications need to modify the schema of the customer Active Directory.

There are three ways to get a base OID.

• Run the OIDGEN utility included in the Windows 2000 Resource Kit. It generates one base OID for classes and another for attributes. A resulting OID could be 1.2.840.113556.1.4.7000.233.28688.28684.8.96821.760998.1196228.1142349. You can use these OIDs in your tests, but for a production network you should register a base OID, as explained in the next two choices.

• Apply for a free private enterprise number from ICANN using the form at http://www.isi.edu/cgi-bin/iana/enterprise.pl. You should receive a number (1.3.6.1.4.1.something) in a few days by e-mail.

• Apply for a base OID from another issuing authority, perhaps for a fee. Many countries have a country-specific organization to issue OIDs. For organizations in United States, you can try ANSI and the Web page http://web.ansi.org/public/services/reg_org.html. (However, ANSI seems not to be very responsive. We sent e-mail to three people whose e-mail addresses appeared on the ANSI Web page regarding OIDs, but we have not received an answer from them in 6 months.)

Once you get the base OID, you should establish the policy regarding administration of the numbers in your organization, just like you probably have had to do with IP addresses. For example, you can dedicate the branch ".1" to new classes and ".2" to new attributes. Because OIDs are a general standard, you may also need the base OID for uses other than Active Directory.

Structure and Containment Rules

The main job of the schema is to establish the structure and content rules for Active Directory. This is done with the first six attributes described in Table 8.8. They consist of three pairs of a normal attribute and a system attribute (mustContain + systemMustContain, mayContain + systemMayContain, and possSuperiors + systemPossSuperiors).

When creating classes, administrators can set all six attributes. For existing classes, they can change only the three normal attributes, not their system counterparts. The base schema uses only the three system attributes; it does not use their normal counterparts. This way, Active Directory can protect the base schema definitions. You cannot remove base schema attributes from any base schema class, nor can you remove possible parent classes.

Because all seven attributes here are multivalued and use the OID string syntax, Table 8.8 does not include this information. Table 8.8 indicates if each attribute is constructed and if only the system, but not an administrator, can alter the value.

Figure 8.9 illustrates the role of the structure and containment attributes. The systemMayContain attribute of a classSchema object lists some of the attributes (inheritance may list more) that the instances of that class may contain (i.e., optional attributes). SystemPossSuperiors specifies some of the possible parents that the instances may have, and possibleInferiors displays the list of possible children.

Figure 8.9 The main job of the schema is to establish the structure and content rules for Active Directory.

Four constructed attributes that are based on the attributes in Table 8.8 reside in the normal objects, such as users. Therefore, these attributes are not part of the schema, but still, you can study the schema by studying them.

TABLE 8.8 Structure and Containment Attributes of a classSchema Object

• AllowedChildClasses and allowedChildClassesEffective both contain the same information as possibleInferiors (mentioned in Table 8.8), but they reside in normal objects, such as the user Jack Brown.

• AllowedAttributes and allowedAttributesEffective both contain a list of all mandatory and optional attributes of an object. For example, with Jack Brown, these two attributes both contain a list of 207 attributes, the number of mandatory and optional attributes of any user class object.

These four constructed attributes also take into account class inheritance.

Class Inheritance

A class gets most of its characteristics from the corresponding class schema object. However, a class inherits some features from several class schema objects, using class inheritance. We can also say that a class is derived from another class.

In this section we explain how, by means of inheritance, the list of possible superiors, mandatory attributes, and optional attributes are built from the information in several objects.

Class inheritance makes defining new classes easier, because they can build on existing classes. There is no need to list all possible superiors and attributes from the ground up. Table 8.9 lists the four attributes relevant to class inheritance.

TABLE 8.9 Class Inheritance Attributes of a classSchema Object

User Class Example

Figure 8.10 illustrates the way the three lists (possible superiors, mandatory attributes, and optional attributes) are built up for the user class. We picked the user class as an example because it is by far the most intuitive.

Figure 8.10 he list of possible superiors, mandatory attributes, and optional attributes for each class is the sum of its own list and the lists of all its superclasses. Also, auxiliary classes may add attributes to the list of mandatory and optional attributes.

The inheritance chain in Figure 8.10 (top—person—organizationalPerson—user) has nothing to do with the hierarchy of the schema objects. They all exist as siblings in CN=Schema, CN=Configuration, DC=sanao, DC=com. Nor is there any connection with the normal directory hierarchy (domain—OU—user).

Figure 8.10 requires several explanatory comments.

• To save space, we abbreviated attribute names—sMayContain instead of systemMayContain, and so on.

• In addition to the system attributes shown in Figure 8.10, mustContain, mayContain, and possSuperiors also will inherit. This base schema example just doesn't happen to use them.

• Top has 69 optional attributes and person has 4 of its own. Still, the sum is 72 instead of 73 because there is 1 common attribute. For the same reason, the other sums may be a little less than you might expect.

• The two auxiliary classes securityPrincipal and mailRecipient are also subclasses of top. To keep the figure simple, and because this relationship has no effect, Figure 8.10 does not show this relationship.

• In Figure 8.10, only the user class happens to use auxiliary classes. Any superclass could also use auxiliary classes, in which case those attribute lists would also affect the subclasses.

• We show LDAP names (such as mailRecipient) as object names, even though to be precise the object names should be common names (such as Mail-Recipient). LDAP names appear because in this book we systematically call classes and attributes by their LDAP names.

Class Categories

Each class in Figure 8.10 was marked to be in one of three categories: structural, abstract, or auxiliary. Active Directory classes belong to four categories, as Table 8.10 describes. Figure 8.11 shows three categories of classes and their relationships as superclasses and subclasses.

Figure 8.11 A class of any category can be inherited, or derived, from an abstract class. Only an auxiliary class can be inherited from another auxiliary class and only a structural class can be inherited from another structural class. In addition, the attribute lists in auxiliary classes can be used in abstract and structural classes (indicated by the dashed arrows).

TABLE 8.10 Class Categories

Miscellaneous Characteristics of Classes

As the last set of class characteristics, we discuss ten miscellaneous attributes. Three of them provide defaults for objects to be created and four are quite general attributes that any Active Directory object will have. See Table 8.11 for details.

Table 8.11 introduces the following four concepts:

• showInAdvancedViewOnly

• Category 1 and 2 schema objects

• objectCategory

• Security Descriptor Definition Language (SDDL)

ShowInAdvancedViewOnly

All Active Directory objects have a showInAdvancedViewOnly attribute, which is derived from the top class. If the value of this attribute is set to True, an administrative snap-in can choose not to show the object in the user interface. If the attribute value is False or missing, an administrative snap-in should show the object.

Many objects are not interesting even to administrators, so setting this attribute helps to hide those objects. When you turn on Advanced Features in the Users and Computers snap-in, you make visible those objects that have the showInAdvancedViewOnly attribute set to True.

Category 1 and 2 Schema Objects

One bit in the systemFlags attribute tells whether the class belongs to category 1 or 2. Category 1 classes and attributes are part of the base schema, and category 2 schema objects are something that you or your application have added. In other words, category 2 schema objects are part of the schema extensions.

The reason for the two categories is that there can be (and there are) stricter rules for modifications of category 1 schema objects.

Object Category

You have seen the word "category" used in more than one context in this chapter. Here is one more: As you know, each object belongs to some class—to be exact, it also belongs to all superclasses of the main class. For example, the object Jack Brown belongs to the classes user, person, organizationalPerson, and top. To be able to contain this list, the objectClass attribute is multivalued.

Each object belongs also to some object category, as expressed with a single-valued attribute objectCategory. The object category is usually the same as the class, but it may be different, most likely one of the superclasses. For example, the objectCategory of most user class objects is person, which is two steps up in the class hierarchy.

As you can see in Table 8.11, the schema defines only the defaultObjectCategory of each class, but the actual objectCategory attribute is per object. Consequently, two objects of the same class could belong in theory to two categories. However, this would only make things more confusing when you used the category as a search criterion. Also, Active Directory doesn't allow changing the defaultObjectCategory of any base schema object or the objectCategory of any existing object, which fortunately makes this confusing situation difficult to achieve.

Using object categories in LDAP filters and queries has the following advantages over using object classes.

• ObjectCategory is an indexed attribute, whereas objectClass is not. Therefore, LDAP filters and queries that use objectCategory are much faster than those that use just objectClass.

• Objects of several classes can use the same category. If you use a filter or query objectCategory=person, you will get a list of all people, regardless of whether they are users or contacts. Apart from this "person = user + contact," however, the base schema doesn't contain practical examples of several classes using the same object category.

Security Descriptor Definition Language

Microsoft uses Security Descriptor Definition Language (SDDL) whenever a security descriptor should be described in a string format. Two examples of this are as follows:

• The defaultSecurityDescriptor attribute, mentioned in Table 8.11

• Security templates, which are INF files in C:\Winnt\Security\Templates

TABLE 8.11 Miscellaneous Attributes of a classSchema Object

We explain SDDL briefly here by interpreting the defaultSecurityDescriptor for the group class (i.e., for each new group that you create). We don't use the user class as an example because the string would be ten times longer. For a detailed description of SDDL, refer to the Microsoft Platform SDK (software development kit) at http://msdn.microsoft.com/library.

The SDDL string for the group class is

D:
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)
(A;;RPLCLORC;;;PS)
(OA;;CR;ab721a55-1e2f-11d0-9819-00aa0040529b;;AU)

To interpret the string, you must be familiar with the contents of a security descriptor, as discussed in Chapter 4.

The D: in this string means that the subsequent data is a discretionary ACL. The owner, group, and system ACL are not included in this case.

The rest of the string consists of six pairs of parentheses, each of which is one ACE. The ACE in turn consists mostly of two-letter acronyms specifying who has what permissions.

The semicolons divide each ACE into six fields:

• ACE type
• ACE flags
• Permissions
• Object GUID
• Inherit object GUID
• Account SID

Table 8.12 shows the interpretation of the six ACEs. You can compare its elements to the SDDL string. Table 8.13 lists the SDDL acronyms, their spelled-out names, and their corresponding permission names in the user interface (i.e., in ACL Editor).

TABLE 8.12 Default ACEs for a Group Object

TABLE 8.13 SDDL Permissions

ClassSchema Object Property Pages

We conclude our discussion on classes by showing the Schema Manager snap-in property pages for a classSchema object. We picked (once again) the user class as an example.

We show three screen shots (Figure 8.12 through 8.14)—one for each property page. We exclude the Security tab because it is a normal access control screen. For each screen, we list the attributes that correspond to the fields in the screen.

In the course of this section we have discussed 38 attributes of a class. The screens in Figure 8.12 through 8.14 show the values for only 12 of them (13 if you count the Security tab) corresponding to the nTSecurityDescriptor attribute. To see the remaining attributes, you need to use ADSI Edit.

Figure 8.12 With the Schema Manager snap-in you can see the attributes of various classes, such as the user class.

Figure 8.12 shows the General tab. The corresponding attributes from top to bottom are as follows (the values are shown in parentheses):

• lDAPDisplayName ("user")

• adminDescription ("User")

• cn ("User")

• governsID ("1.2.840.113556.1.5.9")

• objectClassCategory ("Structural")

• defaultObjectCategory ("person")

• showInAdvancedViewOnly (Note that the snap-in shipping with the original Windows 2000 has a bug so that setting this check box doesn't have the desired effect. The check box should control defaultHidingValue, which in turn controls the showInAdvancedViewOnly attribute of the objects to be created.)

• isDefunct ("not set")

Figure 8.13 shows the Relationship tab. The corresponding attributes from top to bottom are as follows (the values are shown in parentheses):

Figure 8.13 The Relationship tab shows both the inheritance hierarchy in the schema and the possible superiors in the normal directory tree.

• subClassOf ("organizationalPerson")

• auxiliaryClass, systemAuxiliaryClass ("mailRecipient, securityPrincipal")

• possSuperiors, systemPossSuperiors ("builtinDomain, domainDNS, organizationalUnit")

Figure 8.14 shows the Attributes tab. The corresponding attributes from top to bottom are as follows (the values are shown in parentheses):

Figure 8.14 The Attributes tab lists the mandatory and optional attributes for the class, excluding inherited attributes.

• mustContain, systemMustContain (empty list)

• mayContain, systemMayContain (a number of attributes)

Now that we have covered the different aspects of schema classes, we are ready to move on to the attributes and syntaxes. Attribute characteristics have something in common with class characteristics, but obviously there are also quite a few differences.