Chapter 4. Naming Contexts and Application Partitions
Due to the distributed nature of Active Directory, it is necessary to segregate data into partitions. If data partitions were not used, every domain controller would have to replicate all the data within a forest. Often it is advantageous to group data based on geographical or political requirements. Think of a domain as a big data partition, which is also referred to as a naming context (NC). Only domain controllers that are authoritative for a domain need to replicate all of the information within that domain. Information about other domains is not needed on those domain controllers. On the other hand, there is some Active Directory data that must be replicated to all domain controllers within a forest. There are three predefined naming contexts within Active Directory:
A Domain naming context for each domain
The Configuration naming context for the forest
The Schema naming context for the forest
Each of these naming contexts represents a different type of Active Directory data. The Configuration NC holds data pertaining to the configuration of the forest (or of forest-wide applications), such as the objects representing naming contexts, LDAP policies, sites, subnets, Microsoft Exchange, and so forth. The Schema NC contains the set of object class and attribute definitions for the types of data that can be stored in Active Directory. Each domain in a forest also has a Domain NC, which contains data specific to the domain—for example, users, groups, computers, etc.
Beginning with Windows Server 2003 Active Directory, Microsoft extended the naming context concept by allowing user-defined partitions called application partitions. Application partitions can contain any type of object except for security principals. A major benefit of application partitions is that administrators can define which domain controllers replicate the data contained within these partitions. Application partitions are not restricted by domain boundaries, as is the case with Domain NCs; they can exist on any domain controller running Windows Server 2003 or later in a forest, regardless of the domain the DC hosts.
You can retrieve a list of the naming contexts and application partitions a specific domain controller maintains by querying its RootDSE entry. You can view the RootDSE attributes by opening the LDP utility. To see how to view the RootDSE information, see the sidebar Querying RootDSE with LDP.
List of DNs of all the naming contexts and application partitions maintained by the DC
DN of the Domain NC the DC is authoritative for
DN of the Configuration NC
DN of the Schema NC
DN of the Domain NC for the forest root domain
In this chapter, we will review each of the three predefined naming contexts and describe the data contained within each, and then cover application partitions and sample uses of them.
4.1. Domain Naming Context
Each Active Directory domain has a Domain naming context, which
contains domain-specific data. The root of this NC is represented by a
domain’s distinguished name (DN) and is typically referred to as the
NC head. For example, the
mycorp.com domain’s DN would be
dc=mycorp,dc=com. Each domain controller in the
domain replicates a copy of the Domain NC.
Table 4-2 contains a list of the default top-level containers found in a Domain NC. Note that to see all of these containers with the Active Directory Users and Computers (ADUC) snap-in, you must select View→Advanced Features. Alternatively, you can browse all of these containers with LDP or ADSI Edit.
To start ADSI Edit, go to Start→Run→
Relative distinguished name
Container for predefined built-in local security groups. Examples include Administrators, Domain Users, and Account Operators.
Default container for computer objects representing member servers and workstations. You can change the default container with the redircmp.exe utility.
Default organizational unit for computer objects representing domain controllers.
Container for placeholder objects representing members of groups in the domain that are from a domain external to the forest.
Container for orphaned objects. Orphaned objects are objects that were created in a container that was deleted from another domain controller within the same replication period.
Container for managed service accounts. Managed service accounts are a special type of security principal that rotate their own password. For more information on managed service accounts, refer to Chapter 10.
Container to store quota objects, which are used to restrict the number of objects a security principal can create in a partition or container.
Container for applications to store data instead of using a custom top-level container.
Container for miscellaneous domain configuration objects. Examples include trust objects, DNS objects, and group policy objects.
Container for recovery information for Trusted Platform Module (TPM) keys.
Default container for user and group objects. You can change the default container with the redirusr.exe utility.
4.2. Configuration Naming Context
The Configuration NC is the primary repository for configuration
information for a forest and is replicated to every domain controller in
the forest. Additionally, every writable domain controller in the forest
holds a writable copy of the Configuration NC. The
root of the Configuration NC is found in the Configuration container,
which is a subcontainer of the forest root domain. For example, the
mycorp.com forest would have a Configuration NC
Table 4-3 contains a list of the default top-level containers found in the Configuration NC.
Relative distinguished name
Container that holds display specifier objects, which define various display formats for the Active Directory MMC snap-ins.
Container for extended
Contains objects that are used to represent the state of forest and domain functional level changes.
Container for orphaned objects.
Container to store quota objects, which are used to restrict the number of objects that security principals can create in a partition or container.
Contains objects for each naming context, application partition, and external LDAP directory reference.
Contains location objects
Store of configuration information about services such as the File Replication Service, Exchange, and Active Directory itself.
Contains all of the site
topology and replication objects. This includes
Holds objects representing commonly used foreign security principals, such as Everyone, Interactive, and Authenticated Users.
4.3. Schema Naming Context
The Schema NC contains objects representing the classes and
attributes that Active Directory supports. The schema is defined on a
forest-wide basis, so the Schema NC is replicated to every domain
controller in the forest. However, recall that the Schema NC is writable
only on the domain controller holding the schema
master FSMO role. The root of the Schema NC can be found in the Schema
container, which is a child of the Configuration NC. For example, in the
mycorp.com forest, the Schema NC would be located at
Although the Schema container appears to be a child of the Configuration
container, it is actually a separate naming context in its own right.
Figure 4-3 shows how the
Schema and Configuration NCs are segregated in the ADSI Edit tool.
You may be wondering why the schema isn’t just contained within the Configuration NC. As we discussed in Chapter 2, there is a schema master FSMO role that is the single master for updates to schema objects. This role is necessary due to the highly sensitive nature of the schema. Schema modifications need to be processed prior to any updates that utilize the schema. The mechanism to most easily guarantee this with the replication model AD uses is to put the schema into its own partition so it can replicate separately prior to other changes.
Unlike the Domain and Configuration NCs, the Schema NC does not
maintain a hierarchy of containers or organizational units. Instead, it is
a single container that has
subSchema objects. The
classSchema objects define the different types
of classes and their associated attributes. The
attributeSchema objects define all the
attributes that are used as part of
classSchema definitions. There is also a single
subSchema instance that represents the
abstract schema as defined in the LDAPv3 RFC.
4.4. Application Partitions
Application partitions enable administrators to create areas in Active Directory to store data on specific domain controllers they choose, rather than on every DC in a domain or forest. You can define which domain controllers hold a copy of each application partition, which is known as a replica. There is no limitation based on domain or site membership, which means that you can configure any domain controller running Windows Server 2003 or later within a forest to hold any application partition replica. The existing site topology will be used to automatically create the necessary connection objects to replicate among the servers that hold replicas of an application partition. Domain controllers will also register the necessary Service Location (SRV) records (explained in more detail in Chapter 8), so that clients can use the DC locator process to find the optimal domain controller for an application partition, just as they would for a domain.
There are a few limitations to be aware of regarding application partitions:
Application partitions cannot contain security principals, which most notably includes user,
inetOrgPerson, group, and computer objects. Any other type of object can be created in an application partition.
None of the objects contained in an application partition are replicated to the Global Catalog. Even if a domain controller that holds a replica of an application partition is also a Global Catalog server, the domain controller will not return any objects from the application partition during a Global Catalog search.
Objects in an application partition cannot be moved outside the partition. This is different from objects contained in domains, which can be moved between domains.
Application partitions are named similarly to domains. For example,
if you created an application partition called “apps” directly under the
mycorp.com domain, the DNS name would be
apps.mycorp.com and the distinguished name would be
partitions can be rooted under domains, as shown in the previous example,
or they can be nested under other application partitions (for example,
be part of a new domain tree (for example,
dc=apps,dc=local). For more information on
creating and managing application partitions, refer to the sidebar .
Application partitions tend to store dynamic data—that is, data that has a limited lifespan (see the section on Storing Dynamic Data for more on this). Dynamic data from network services such as DNS and the Dynamic Host Configuration Protocol (DHCP) can reside in an application partition in AD. This allows uniformity of access from applications via a single methodology, which in turn enables developers to write to a special area only available on specific servers rather than into a domain partition that is replicated to every DC. In fact, application partitions could allow multiple versions of COM+ applications to be installed and configured on the same computer, resulting in more cost-effective management of server applications.
The availability of Active Directory Lightweight Directory Services (AD LDS) has given administrators another option for storing directory data outside of the normal domain-naming contexts while still using Windows security and authentication. Instead of putting application data in an application partition, you can place that data in a dedicated AD LDS instance. This allows you to offload administrative control of that information to application owners or other administrators, as well as lessening the chance of an application negatively impacting a domain controller’s primary NOS function. We discuss AD LDS specifics in Chapter 20.
Storing Dynamic Data
Although application partitions give administrators more control over how to replicate application data, the problem of data cleanup still exists. That is, applications that add data to Active Directory are not always good about cleaning it up after it is no longer needed. That’s why the ability to create dynamic data was also added as a feature in Windows Server 2003 Active Directory. Dynamic objects are objects that have a time-to-live (TTL) value that determines how long they will exist before being automatically deleted by Active Directory. Dynamic objects typically have a fairly short lifespan (i.e., days or less). An example use of dynamic objects is an ecommerce website that needs to store user session information temporarily. Because a directory is likely going to be where the user profile information resides, it can be advantageous to use the same store for session-based information, which is generally short-lived. The default TTL that is set for dynamic objects is 1 day, but can be configured to be as short as 15 minutes.
The default TTL and minimum TTL can be modified by changing the
Seconds values in the
Settings attribute of
To create a dynamic object, you simply have to add
dynamicObject to the
objectClass attribute when creating the
object. Microsoft has specifically disabled the ability to add this to
existing objects for safety reasons. This is why you cannot convert
existing static objects into dynamic objects. The
entryTTL attribute can also be set at creation
time to set the TTL to something other than the one-day default. To
prevent a dynamic object from being automatically deleted, you can
“refresh” the object by resetting the
entryTTL attribute for the object to a new TTL
value (time specified in seconds).
Dynamic objects do not get tombstoned like normal objects when they are deleted; they are just removed from the directory. A tombstone is not needed since the TTL mechanism allows them to be immediately removed from all domain controllers simultaneously. For more information on tombstones, see the section Preserving attributes in a tombstone in Chapter 5.
In this chapter, we covered how objects are grouped at a high level into naming contexts and application partitions, which are used as replication boundaries. The Domain NC contains domain-specific data such as users, groups, and computers. The Configuration NC contains forest-wide configuration data such as the site topology objects and objects that represent naming contexts and application partitions. The Schema NC contains all the schema objects that define how data is structured and represented in Active Directory.
Application partitions provide a way for administrators to define their own groupings of objects and, subsequently, replication boundaries. Storage of DNS data for AD-integrated DNS zones is the classic example of when it makes sense to use application partitions due to the increased control they give you over which domain controllers replicate the data. Dynamic objects allow you to create objects that have a TTL value. After the TTL expires, Active Directory automatically deletes the object.