Understanding Active Directory Schema

When discussing directory service structure and operation up to this point, I’ve used general terms that are applicable to just about any LDAP implementation. It’s now time to spend a while looking at specific features in Active Directory. You may find this information to be a little too much detail for helping you manage day-to-day operations in Windows Server 2003. However, it’s good to know some of the important functional and operational details of the directory service to help you create reliable domain designs and to troubleshoot problems that arise.

As a quick review, the object-oriented LDAP database that comprises Active Directory is structured around a set of object classes and their associated attributes. Individual objects are instances of specific object classes. The schema defines the available object classes, their associated attributes, the data types and permitted ranges for those attributes, and the rules for arranging and managing objects within the Active Directory database.

Schema Functional Operation

To visualize how the schema works, consider a simple, paper-based directory. Every month or so I get a catalog from Land’s End, the clothing retailer. This catalog is a database of sorts, similar to a directory service except that it guides the user to a garment instead of a network entity. Consider this:

• The schema for this directory defines a set of object classes with the scope “Garments Sold by Land’s End.” These classes represent objects of interest to garment purchasers, such as Sweaters, Suits, Blazers, Accessories, and so forth.
• The schema also defines the available attributes that can be associated with the object classes, such as Size, Color, Inseam-Length, and Price, along with more subtle attributes specific to the directory itself, such as Picture-Of-Garment.
• The schema has content rules that define what attributes can be associated with a class. Some attributes, like Size and Color, might be associated with nearly every class. An attribute like Inseam-Length, however, might only be associated with classes like Slacks and Jeans, not Sport-Coats or Shoes.
• Some garment classes have attributes that are nearly identical. For example, the attributes that define the Polo-Shirts class differ only slightly from the attributes that define the Sport-Shirts class. The Polo-Shirts class derives from the Sport-Shirts class and inherits the attributes associated with its parent. The new attributes are then just tacked on to the new class.
• Class inheritance makes it important to have structure rules that keep the directory aligned with the real world. For example, a structure rule prevents placing an object from the Bathrobe class under a container from the Shoe class.
• A particular garment is an instance of its garment class. For example, an instance of the Blazer class would be the solid red blazer with green plaid lining that I gave my brother for Christmas last year. (The snide thank you note I received in return came from the Hallmark directory service as an instance of the Ungrateful-Sibling class.)
• The Land’s End schema has syntax rules that define the values that can be associated with an attribute. For example, the Size attribute must have whole integer values while the Shoe-Size attribute can have real number (fractional) values.
• Because the garment classes and their attributes can change, the Land’s End directory is extensible. For example, a new attribute called Number-Of-Sleeve-Buttons can be added and the Blazers class modified to include that attribute.
• For flexibility, certain special object classes can be dynamically assigned to a specific object. This makes it possible to create special bundles of attributes for a certain object like a Rad-Phat T-shirt object without altering all other instances of the T-shirt class.

I know this was a long example, so here are the key terms and concepts:

• Object Classes. Define the objects that can appear in Active Directory and their associated attributes.
• Class Derivations. Define a method for building new object classes out of existing object classes.
• Object Attributes. Define the available attributes. This includes extended attributes that govern actions that can be taken on object classes.
• Structure Rules. Determine possible tree arrangements.
• Syntax Rules. Determine the type of value an attribute is capable of storing.
• Content Rules. Determine the attributes that can be associated with a given class.
• Extensible schema. Additions can be made to the list of available classes and attributes.
• Dynamic class assignments. Certain classes can be dynamically assigned to a specific object rather than an entire class of objects.

Object Classes and Class Derivations

An object class is nothing more than a bundle of attributes with a name. The User class, for example, has certain attributes that, taken together, make it distinct from the Organizational-Unit class or the Server class. The X.500/9594 standard as modified by RFC 2256, “A Summary of the X.500(96) User Schema for use with LDAPv3,” defines 21 classes and 55 attributes in a standard LDAP directory schema.

The Active Directory schema extends this list quite a bit, out to nearly 200 classes and just under 1700 attributes. If you want a complete list, check out the Windows Server 2003 Platform SDK or look at the MSDN web site, msdn.microsoft.com.

Standard LDAP Classes and Attributes in Active Directory

The Active Directory schema includes all RFC 2256 classes, except for Alias and Strong-Authentication-User, and all attributes, except for Aliased-Object-Name. The exclusion of Alias was deliberate. Aliases are a notorious source of performance difficulties and integrity problems in directory services. In addition, most of the object classes that would normally be given aliases are required to have unique names in Active Directory. This includes Users, Computers, and Groups.

Windows .NET includes the inetOrgPerson class as defined in RFC 2798, “Definition of the inetOrgPerson Object Class.” This makes Active Directory more compatible with Netscape Directory Services and Novell Directory Services, both of which derive their User class from inetOrgPerson.

Schema Rules

It’s not enough to define schema components in terms of objects, actions, and relationships. Laws and customs are also necessary to avoid anarchy. These take the form of schema rules. Directory service designers build certain rules into the schema that determine how classes and attributes are used, what kind of values they can have, and what relationship they have to each other. These rules fall into three categories:

• Structure Rules
• Content Rules
• Syntax Rules

Structure Rules

Frank Lloyd Wright established the design paradigm for twentieth century architecture by declaring that form should always follow function. He was a building architect rather than directory services architect, of course, but Active Directory is as much of a monument to form and function as a prairie house, and it is the structure rules that accomplish this.

There is really only one structure rule in Active Directory: Each object class has only certain classes that can be directly above it, called Possible Superiors. This structure rule is very important because classes inherit attributes from their parents. Structure rules prevent putting a User class object under a totally unrelated container class, like IPSEC-Base or NTDS Settings.

Content Rules

Every object class has certain attributes with values that cannot be left blank when an object is instantiated. These are called must-contain attributes. For example, every instance of the User class must have a value for the Common-Name attribute. Other attributes are optional and are designated may-contain attributes.

An important design principle of Active Directory is that only attributes with values are stored in the database. This greatly reduces the size and complexity of the database. Because attributes can be added after an object is created and then later removed if they are set to null, the database engine must constantly pack and repack the data. This is done by a garbage collection service that runs every 12 hours.

Syntax Rules

Attributes store data. Data must have a data type to define the storage requirements. Real numbers have a different form from integers, which are different from long integers, which are different from character strings.

An attribute can have only one data type. It cannot hold a string when associated with one object class and an integer when associated with another. The syntax rules in the schema define the permissible values types and ranges for the attributes.

Schema Definition Objects

Individual objects are always instances of an object class. Achieving this design principle involves using a template that defines the attributes, schema rules, and class hierarchy for the objects within an object class. The same applies for attributes, which require a template to define the syntax rules. This suite of templates makes up the schema definitions for a directory service information store.

Some directory services put the schema definitions into a separate file that is loaded at boot time or whenever the schema requires changing. In contrast, the Active Directory schema is self-referential. That is to say, all class definitions, attribute definitions, and schema rules are part of the schema itself. An appropriate title for an Active Directory schema self-help book would be Everything I Need to Know I Learned from Myself.

The Active Directory schema contains two schema object classes, ClassSchema and AttributeSchema. Objects derived from these classes act like patterns in a lathe to turn out other objects. The schema objects are stored in the directory in the cn=Schema,cn=Configuration,dc=<domain_name>,dc=<domain_root> container.

In addition to ClassSchema and ClassAttribute classes, the Schema container holds a class called SubSchema with one instance, an object called Aggregate. The distinguished name of this object is cn=aggregate,cn=schema,cn=configuration,dc=company,dc=com. The purpose of Aggregate is to provide a single point for LDAP clients to discover information about the Active Directory schema. Without this object, clients would be forced to perform expensive scans of the entire Schema container.

Identifying Objects

We’ve completed the overview of the schema structure, function, and rules. Before moving forward, let’s look at how Active Directory uniquely identifies objects. This information is crucial to understanding the more advanced Active Directory tools. Here is a brief attribute listing for a sample User object made using the LDIFDE utility. The unique identifiers are highlighted:

C:>ldifde -d cn=bgates,cn=users,dc=dotnet,dc=com -f con
Connecting to "DC01.Company.com"
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries...
Writing out entries.dn: CN=bgates,CN=Users,DC=dotnet,DC=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: bgates
distinguishedName: CN=bgates,CN=Users,DC=dotnet,DC=com
   instanceType: 4
   whenCreated: 20020812134034.0Z
   whenChanged: 20020812134034.0Z
   uSNCreated: 13772
   uSNChanged: 13774
   name: bgates
   objectGUID:: 7swJ8PXwqkWu8N2Qv+jQ+Q==
   userAccountControl: 512
   badPwdCount: 0
   codePage: 0
   countryCode: 0
   badPasswordTime: 0
   lastLogoff: 0
   lastLogon: 0
   pwdLastSet: 126736332347481024
   primaryGroupID: 513
   objectSid:: AQUAAAAAAAUVAAAAdbl1VBUlr0cWwOoyVQQAAA==
   accountExpires: 0
   logonCount: 0
   sAMAccountName: bgates
   userPrincipalName: bgates@dotnet.com
   sAMAccountType: 805306368
   objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=dotnet,DC=com

Distinguished Name

Because LDAP uses an object-oriented database, it is important that each object has a unique path in the namespace, similar to the way that a filename and path must be unique in a file system.

The Distinguished Name (DN) attribute of an object defines the LDAP path all the way to the root of the namespace; therefore, the DN must be unique. If you move an object to a different container in Active Directory, in reality, you are simply changing the DN.

Globally Unique Identifier (GUID)

In classic Exchange, Microsoft used the DN as the unique database row identifier for objects in the directory service store. This unfortunate engineering decision created a configuration problem for Exchange. When an object is moved, its DN changes, but a unique row identifier in a database cannot ever change. For this reason, in Exchange 5.5 and earlier, mailbox recipients cannot be moved but must be freshly created and then linked to a User account in the SAM.

To avoid that problem in Active Directory, Microsoft used a different unique row identifier called the Globally Unique Identifier, or GUID . A GUID is created using an algorithm that virtually guarantees its uniqueness within a system.

Using a GUID permits you to move objects at will between containers in Active Directory without changing the unique row numbers for the objects, thereby maintaining internal referential integrity in the database. Keep this behavior in mind, because you’ll see it at work when we discuss the role of the Infrastructure Master in keeping track of group members from other domains.

Other Uses for GUIDs

Microsoft uses the GUID algorithm in a variety of different circumstances. You will see them in designators used to identify COM objects and OLE registrations. Group policies use the GUID algorithm to create a unique folder name for each policy. The operating system identifies hardware using GUIDs during Plug-and-Play enumeration. GUIDs also go by the names Universally Unique Identifier (UUID) and Class ID (CLSID).

Security Identifier (SID)

Three classes of Active Director objects can be placed on the access control lists (ACLs) used to protect security objects. These object classes are User, Computer, and Group. Together, they are termed security principals.

A security principal is assigned a unique number called a Security Identifier, or SID. This is exactly the same SID used by NT to identify users, groups, and computers. A SID for a security principal is made up of the SID of the security principal’s domain and a unique suffix, called a Relative ID, or RID. The series of RIDs for security principals that can be created by an administrator start at decimal 1000. For example, the first User account created following the creation of a domain would be given RID 1000. The next object, call it a group, would be RID 1001, and so forth.

The combination of a domain SID and a RID form a unique number within a domain and within a forest. The pool of RIDs is maintained by a specially designated Windows Server 2003 domain controller called a RID Master.

SAM Account Name

In an NT domain, every object in the SAM must have a unique name. This is true for computers, users, and groups. A unique name guarantees that the object will have a unique NetBIOS presence in the network as well as a one-to-one correspondence between the logon name (in the case of users and computers) and the SID used to control resource access.

The same restriction is left in place in Windows 2000 and Windows Server 2003. Every user, computer, and group in a domain must have a unique name. This attribute is called SAMAccountName, although you might hear it called logon name or flat name. When you create a new security principal, regardless of the container where you place the object, it must have a unique flat name in the domain.

User Principal Name (UPN) and Service Principal Name (SPN)

Just as unique flat names identify security principals in NetBIOS, User Principal Names (UPNs) identify security principals within the hierarchical LDAP namespace in Active Directory. A UPN takes the form User@Company.com.

Unique UPNs ensure that users can log on with their UPN rather than the classic domainusername construct. The Global Catalog is used to “crack” the UPN into its constituent parts.

To assure uniqueness, when a security principal is created, the system refers to the Global Catalog to verify that the UPN has not already been used. If a GC server is not available, the system displays an error message prompting the administrator to wait until a GC is available so that uniqueness can be verified.

In a Parent/Child trust configuration, the UPN suffix of the root domain is assigned to every security principal. In a Tree Root trust configuration, you must manually assign a common UPN suffix. This is done using the Properties window of the domain tree in the AD Domains and Trusts console.

Object Identifier (OID)

In addition to the attributes that assure uniqueness of a particular object, Active Directory needs a way to assure that objects of the same class all come from the same Schema object. This is done by assigning a unique Object Identifier, or Object Identifier (OID) to each object in the Schema naming context. ISO defines the structure and distribution of OIDs in ISO/IEC 8824:1990, “Information Technology—Open Systems Interconnection—Specification of Abstract Syntax Notation One (ASN.1).”

ASN.1 provides a mechanism for standards bodies in various countries to enumerate standard data items so that they do not conflict with one other. ASN.1 governs more than just directory services classes and attributes. For example, OIDs are used extensively in SNMP to build hierarchies of Management Information Base (MIB) numbers. They are also assigned to many items associated with the Internet.

If you ever need to create a new attribute or object class in Active Directory, you must have a unique OID. There are a couple of ways to get one. The first is to apply to ANSI for your own numerical series. This costs a few thousand dollars and takes a while to process. The other is to use the OIDGEN utility from the Resource Kit. This will generate a Class and an Attribute OID out of Microsoft’s address space. The disadvantage to using OIDGEN is that the resultant number is very, very, very long. Here is an example:

C:>oidgen
Attribute Base OID:
1.2.840.113556.1.4.7000.233.180672.443844.62.26102.2020485.1873967.207938
    Class Base OID:
1.2.840.113556.1.5.7000.111.180672.443844.62.199519.642990.1996505.1182366

How to migrate your Active Directory Domain to Windows Server 2008

Windows Server 2008 includes a handful of important upgrades to your Active Directory domain infrastructure. The most useful are these:

• Read-Only Domain Controllers: RODCs are a new type of domain controller that doesn’t allow updates but does provide authentication and directory services. This reduces the risk of an Active Directory security compromise (especially for branch offices with poor physical security) because an attacker with access to an RODC would have a very difficult time using that access to update the Active Directory.
• Flexible Password Policies: You can assign different password policies to different sets of users within a single domain—finally! If you have created separate domains to work around this restriction in the past, get rid of those redundant domains after the upgrade.
• Auditing: Active Directory auditing is much more granular in Windows Server 2008, allowing you to closely track changes on just the objects you’re interested in (including recording both the old and new values). You can separately audit read accesses and replication.

You can take advantage of these improvements only by upgrading every domain controller in a domain to Windows Server 2008, and then upgrading the domain functional level. That sounds easy, but if you don’t plan it properly, you could be left with a broken Active Directory and thousands of angry users. Follow these tips to upgrade without fear.

1. Back up your domain controllers

While most upgrades go smoothly, there’s the possibility of creating an outage that could affect your entire domain — potentially preventing users from accessing network resources. The more customized your Active Directory schema and permissions, the more likely you are to have problems. Therefore, you should plan your upgrade during nonpeak hours and have a full backup (including System State) of at least two domain controllers in case you need to roll back to an earlier version.

2. Verify upgrade requirements

Before you can upgrade the domain functional level, all domain controllers in the domain must be running Windows Server 2008. This allows you to take advantage of the new features but prevents you from adding any domain controllers running earlier versions of Windows.

Before you start upgrading, verify that your domain controllers meet these requirements:

• The hardware exceeds the Windows Server 2008 requirements.
• All hardware and software is compatible with Windows Server 2008, including antivirus software and drivers.
• Sufficient disk space is free to perform the operating system and Active Directory upgrade. Specifically, verify that your free space is at least twice the size of your Active Directory database.
• The current domain functional level is Windows 2000 Native or Windows Server 2003. You cannot upgrade directly from Windows NT 4.0, Windows 2000 Mixed or Windows Server 2003 Interim domain functional levels.
• All Windows 2000 Server domain controllers have Service Pack 4 installed.

3. Test your domain

Active Directory domains are very resilient and can continue to function even when a variety of problems exist. Even if your Active Directory seems to be working, you might have logon delays, replication failures or Group Policy settings that aren’t being applied. These conditions can cause problems during an upgrade, so it’s important to resolve them now.

These tools will help you identify and diagnose any problems:

• Dcdiag.exe. Run this tool to analyze your Active Directory for common problems; it’s included with Windows Server 2003 and Windows Server 2008.
• Repadmin.exe. Use Repadmin.exe to identify Active Directory replication problems; it’s included with Windows Server 2003 and Windows Server 2008.
• Gpotool.exe. Use this tool to verify that Group Policy is consistent amongdomain controllers, it’s included with the Windows Server 2003 Resource Kit tools, available at http://go.microsoft.com/fwlink/?linkid=27766.
• Event Viewer. Review the Directory Services log file for errors that might indicate problems.

4. Prepare your schema

Just as when upgrading to a Windows Server 2003 functional level, you must use the Adprep.exe tool to prepare your forest and domain schema. Note that you must use the version of Adprep included on the Windows Server 2008 media in the sourcesadprep folder, even though you will need to run it from an existing Windows Server 2003 domain controller. Be sure to use 32-bit media when running Adprep from a 32-bit domain controller, and use 64-bit media for 64-bit domain controllers.

To prepare your Active Directory schema, follow these steps for each domain that you plan to upgrade:

1. Run Adprep/forestprep on your Schema Master with Enterprise Admins, Schema Admins and Domain Admins privileges. Wait for changes to replicate.
2. Run Adprep/domainprep/gpprep on the Infrastructure Master with Domain Admin privileges. On Windows Server 2003 domains, you’ll receive an error message caused by the unnecessary /gpprep parameter that you can ignore.
3. On Windows Server 2003 domains, run Adprep/rodcprep on the Domain Naming Master with Domain Admin privileges.

Note: As long as your domain and forest are at the Windows Server 2003 functional level and you’ve prepared the schema, you don’t need to upgrade your entire domain to install a Windows Server 2008 RODC.

5. Migrate your domains

Before you upgrade a domain, be sure that you don’t plan to add domain controllers running Windows 2000 Server or Windows Server 2003. While you can always upgrade the domain functional level, you can never downgrade it.

The easiest way to migrate your domain to the Windows Server 2008 functional level is to follow these steps:

1. Install a new Windows Server 2008 computer, and then run Dcpromo.exe. You can configure either a Full Server or a Server Core as a domain controller. On Full Servers, you also have the option of adding the Active Directory Domain Services role using Server Manager.
   Tip: You can use command-line parameters to run Dcpromo.exe unattended (with or without an answer file). For detailed information, run Dcpromo/?.
2. Wait for replication to occur.
3. Retire or upgrade all Windows 2000 Server and Windows Server 2003 computers. To upgrade a Windows 2000 Server, upgrade it to Windows Server 2003, and then upgrade it to Windows Server 2008.
4. Upgrade the domain functional level using the Active Directory Domains and Trusts tool. Right-click the domain, and then click Raise domain functional level.

Now, test any applications that depend on Active Directory, including user logons and Exchange Server. If you run into problems, restore your domain controllers from backups, and head back to the lab for more testing. If everything goes well, wait a couple of weeks for the environment to stabilize before you make any other major changes.

6. Upgrade your forest

There are no new features available if you upgrade your forest to the Windows Server 2008 functional level — it just causes any new domains that are added to the forest to be at the Windows Server 2008 domain functional level by default. Still, it’s a worthwhile step to save yourself the trouble of upgrading a new domain that you accidentally added at the wrong functional level.

Summary

Microsoft must have been listening to the complaints about Active Directory limitations because Windows Server 2008 allows multiple password policies within a domain, read-only domain controllers and auditing that’s actually useful. If you follow these steps, you’ll be finished with your upgrade in no time.