A Grand Schema

The Schema controls how Active Directory operates. Here’s how it works and what’s new in Windows .NET.

• By Bill Boswell
• May 01, 2002

Have you ever noticed that a description of Active Directory sounds a little like a botany lesson? In botany, Mother Nature creates a huge variety of animals, from blue whales to salamanders to presidential candidates, using a limited palette of genetic material. AD pretty much works the same way. It can build millions, even billions, of database objects using a relatively short list of available attributes.

The structure and function of AD objects doesn’t really concern us too much during day-to-day systems administration. The AD management consoles, such as AD Users and Computers, demand certain inputs when creating objects, and we provide those inputs. You might get creative if you want to automate some of your administrative chores, but for the most part, it’s easy to be content to let AD do its job without peeking over its shoulder.

Once in a while, though, it becomes necessary to understand more about the basic nature of the universe. In botany, this generally happens when you’re trying to figure out why your lawn plays host to every known pest listed in the Federal Noxious Weed List (www.aphis.usda.gov/ppq/permits/fnws bycat-e.PDF), while your neighbor’s lawn looks like the 18th green at Pebble Beach. In AD, you’re forced to get serious about the fundamental operations of the AD database when you face the prospect of upgrading to a new operating system version.

Sometime later this year, Microsoft will release Windows .NET. The long list of new features and improvements in Windows .NET includes several improvements to AD. The forces that shape the structure of AD emanate from a special container called the Schema, and many of the new features in Windows .NET involve changes to this Schema. You’ll need to take a certain approach to upgrading to Windows .NET, and this requires knowing a few things about the way the Schema operates.

Schema Operation
Individual objects in AD are derived from an object class. For example, the User class represents individuals who log on to the domain and access network resources. Classes are really just bundles of attributes. The User class consists of nearly 60 attributes with nearly twice that number available to the class via inheritance from other classes. These attributes include items such as User Principal Name ([email protected]), SAM Account Name (bboswell), Unicode Pwd, User Account Control flags, and so on.

When you create a new instance of an object class, such as a new user account, AD obtains a template for the designated object class from the Schema. This template defines the attributes for the designated object class and defines where the object is permitted to be situated in the AD tree. There are also templates for creating the attributes that are placed into the object.

You can think of these Schema templates as scurrying little nanomachines dedicated to churning out AD objects. A short script shows the process schematically:

Set OU = GetObject("LDAP://ou=Phoenix,dc=Company,dc=com")
Set GroupObj = OU.Create ("Group", "cn=DemoGroup")
GroupObj.Put "Description", "Test Description"
GroupObj.Setinfo

When this script runs, AD goes to the Schema to find a template for the Group object class and creates an instance of the class with the common name “DemoGroup.” It then finds a template in the Schema for an attribute called Description and creates an instance of the attribute with the designated value “Test Description.” The Setinfo method takes these settings from memory and applies them to the AD database.

The Schema also imposes syntax rules on attribute values and structure rules on the position particular objects can have in relation to other objects. For example, the syntax rules prevent you from placing a date/time value inside the Distinguished Name attribute, while the structure rules prevent you from creating a User object under a Site container.

Schema Location
The templates that comprise the Schema are stored inside AD as objects. There are ClassSchema objects that form the templates for objects themselves and Attri-buteSchema objects that form the templates for the attributes that become part of objects. By storing the templates in AD, Microsoft avoided the need for a separate Schema definition file.

These Class and Attribute objects reside in a container called Schema. The full distinguished name of this container, which indicates its location in the AD tree, is cn=Schema,cn=Configuration, dc=, dc=. The Schema container forms a distinct replication unit called a naming context. Each domain controller in a forest hosts a replica of the Schema naming context. This ensures that objects created by one DC can be recognized by the other DCs in the forest, similar to the way a silver dollar from the Mandalay Bay casino in Las Vegas can be played in a slot machine at the Rio.

You can view the Class and Attribute objects in the Schema container using an MMC snap-in called Schema. This snap-in is part of the Adminpak.msi bundle of tools stored in the %systemroot%\System32 folder. To load the Schema snap-in, install the Adminpak bundle using the “Install All Of The Administrative Tools” option. Alternatively, you can manually register just the Schema management snap-in, Schmmgmt.dll. The syntax for selective registration is:

regsvr32 schmmgmt.dll

Run the Regsvr32 utility from the %systemroot%\System32 folder.

Once the Schema snap-in is installed, load it into an empty MMC console. The tree in the left pane shows two nodes: Classes and Attributes. These two nodes are actually filters that display the two different object types in the Schema, Class objects and Attribute objects. Double-click an icon to view its properties. Figure 1 shows an example of the properties of the User object in the Schema.

Figure 1. Properties of the User object in the Schema showing the structural rule definitions.

Schema Modifications
The database engine that controls AD is called the Extensible Storage Engine, or ESE. As the name implies, the structure of the database is “extensible,” meaning that new object classes and attributes can be added to the database. Each new class or attribute is defined by a new object in the Schema container. These objects can be modified in certain trivial ways, but for the most part their contents are immutable.

Furthermore, an object in the Schema container can’t be deleted or overwritten. This is a fundamental limitation to AD and remains unchanged in Windows .NET. It’s possible in Windows .NET to deactivate an object class so that a new object can be added with a different name and different attributes but the same Object ID. This helps internal developers and independent software vendors who need to modify the contents of a registered object class without creating a new class. (Note: The .NET features described throughout this article are based on .NET Server beta 3.)

The upgrade to Windows .NET involves an extensive set of changes to AD, some of which modify the Schema itself. In addition to adding new classes and attributes to the Schema, the upgrade affects settings on existing Schema objects. This includes changes to the index setting on attributes, which speed up LDAP searches, and the constituents of the Partial Attribute Set (PAS), which control the contents of the global catalog.

The setting that determines whether an attribute is indexed or included in the PAS is controlled by an attribute called SearchFlags. You can see the value of the SearchFlags attribute in the properties window for an attribute (see Figure 2).

Figure 2. Properties of an Attribute object in the Schema showing the SearchFlags settings.

Extending the Boundaries
Migrating an existing Windows 2000 domain to Windows .NET is a little tricky because of all the changes to AD and the Schema. The first step in the migration is to upgrade AD from version 13, the version in Win2K, to version 24 used by .NET. Microsoft provides a utility called ADPREP that performs this upgrade. ADPREP also creates new containers and objects in the Domain naming context to support the upgrade.

ADPREP is located in compressed form in the \I386 folder on the .NET Server CD. To install it, run winnt32/ checkupgradeonly from the .NET Server CD. This extracts ADPREP to the %systemroot%\System32 folder and copies over a set of LDAP Directory Interchange Format (LDIF) files that contains the Schema modifications along with updates to existing objects. There are 11 files, numbered Sch14.ldf through Sch24.ldf. The numbers correspond to schema version numbers.

The ADPREP utility has two switches, /forestprep and /domainprep, which must be run seperately prior to promoting a Windows .NET DC in a Win2K domain.

The /forestprep switch calls another utility, SCHUPGR, and feeds it the Sch##.ldf files in sequence. SCHUPGR uses information in the ldf files to modify the Schema and update the contents of the Configuration naming context, which is also held in common by every DC in the forest.

The /domainprep switch creates new attributes used by the Domain object to maintain trust quotas, a new feature in Windows .NET. The switch also adds a new container under the System container for tracking domain updates.

To run the /forestprep switch, all DCs in the Win2K forest must be at SP2 or higher. You must have administrator rights in the root domain of the forest and you must be a member of the Schema Admins group. To run the /domainprep switch, you must have Domain Admin rights in the domain.

Once the Schema has been modified and the domains prepped, you can promote a Windows .NET server to be a DC in a Win2K domain. This can be any Windows .NET server. There is no requirement to upgrade the PDC physically as there is when you upgrade an NT domain. Neglecting to run ADPREP before promoting the .NET server will get you an error message, and Dcpromo will refuse to continue.

Making the Final Transition
The new AD features in Windows .NET are controlled by a mode switch called Windows .NET Functional Level. This mode switch operates similarly to the Mixed/Native mode switch used for backward compatibility with NT. As long as you have Win2K DCs in a domain, the domain’s functional level is set to Win2K Compatible.

When all DCs in a domain have been upgraded to Windows .NET, the domain’s functional level can be shifted to Windows .NET, which enables some of the new features. When all domains are running at .NET functional level, the forest functional level can be shifted to Windows .NET. At that point, all the new features are enabled.

Wondering whether all this work to do the upgrade is worthwhile? Here’s a short list of the AD improvements in Windows .NET:

• No group membership limits. A Win2K group can have no more than 5,000 members, a limitation imposed by the maximum size of a replication packet. Also, the entire Member attribute is replicated whenever membership changes, so it’s possible for an administrator to overwrite membership changes made by another administrator in the same replication cycle. Windows .NET avoids both of these problems by treating individual membership entries as separate replication entities.
• Scalable site deployments. The calculations that determine inter-site connections were improved considerably in .NET. Enterprises with more than 100 sites, which are now forced to build and manage intersite connections manually, can let Windows .NET handle the operations automatically.
• More flexible inter-forest operations. Win2K requires that trusts outside forests be intransitive, one-way trusts based on NTLM authentication. Windows .NET permits transitive, two-way, Kerberos-based trusts between forests. This makes it possible to configure resource access quickly between all domains in two forests with a single trust.
• Global catalog flexibility. Adding or removing an attribute from the Partial Attribute Set in Win2K triggers a complete rebuild of the global catalog. This results in a full replication of the global catalog to all GC servers in the forest. In Windows .NET, a GC rebuild isn’t required when the GC contents change.
• InetOrgPerson support. Microsoft uses the User object class to represent users in AD. Other directory services such as Novell Directory Services (NDS) and Netscape Directory Services (the other NDS) use the InetOrgPerson class to represent users. This introduces subtle but significant interoperability issues. Windows .NET includes full support for the InetOrgPerson class. A user derived from this class is a Windows security principal with a SID so that it has access to secured resources.
• Dynamic AD entries. It’s difficult to use Win2K AD to “maintain state,” that is, to collect real-time information about the status of domain entities. Windows .NET includes support for RFC 2589, “LDAPv3: Extensions for Dynamic Directory Services.” This permits putting time-sensitive information in AD, such as a user’s current location. Dynamic entries automatically time out and are deleted if not refreshed.

Since Bill Gates’ recent “Trustworthy Computing” memo and subsequent halt of work on new products while Microsoft combs through code looking for security holes, Windows .NET may be delayed into the fall, winter or even later. However, if you want to set up a lab and begin interoperability testing right now, this article should give you enough information to get started.