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
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.
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@example.com),
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
Set OU = GetObject("LDAP://ou=Phoenix,dc=Company,dc=com")
Set GroupObj = OU.Create ("Group", "cn=DemoGroup")
GroupObj.Put "Description", "Test Description"
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.
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
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.
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
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
Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.