Active Directory, 5th Edition

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.

Querying RootDSE with LDP

ldp.exe is included with Windows Server 2008 and newer and is part of the Support Tools for Windows 2000, XP, and 2003. You can use LDP to view raw data from any LDAP server. We will leverage LDP throughout this book when appropriate. Unless otherwise noted, you should assume that the version of LDP we are using is the version that ships with Windows Server 2012.

The RootDSE is viewable by anonymously binding to any domain controller in the forest. The steps to use LDP to view this information are:

1. Launch LDP by running ldp.exe.

2. Click Connection→Connect, enter the name of a domain controller, and click OK. Figure 4-1 shows connecting to the domain controller k8devdc01 on port 389 (the LDAP port).

3. LDP will connect to the domain controller and immediately display all of the anonymously viewable RootDSE output, as shown in Figure 4-2.

There is a great deal of data displayed in this screen, and we will not cover it all at this time. A good deal of the information will be covered throughout this book when it is relevant. The information of particular interest to us right now is the data corresponding to the attributes in Table 4-1.

We can see the distinguished name of the root domain in this forest (DC=k8dev01,DC=brianlab,DC=local), the DNs of the application partitions hosted on this domain controller (such as DC=DomainDnsZones,DC=k8dev01,DC=brianlab,DC=local), and so forth.

This output is particularly useful when writing scripts and programs that query Active Directory. By utilizing the RootDSE attributes, you can avoid hardcoding paths into your code.

Figure 4-1. LDP connection dialog

Figure 4-2. LDP RootDSE output on a Windows Server 2008 domain controller

Table 4-1. RootDSE attributes pertaining to naming contexts

Attribute Name	Description
namingContexts	List of DNs of all the naming contexts and application partitions maintained by the DC
defaultNamingContext	DN of the Domain NC the DC is authoritative for
configurationNamingContext	DN of the Configuration NC
schemaNamingContext	DN of the Schema NC
rootNamingContext	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.

Note

To start ADSI Edit, go to Start→Run→adsiedit.msc.

Table 4-2. Default top-level containers of a Domain NC

Relative distinguished name	Description
cn=Builtin	Container for predefined built-in local security groups. Examples include Administrators, Domain Users, and Account Operators.
cn=Computers	Default container for computer objects representing member servers and workstations. You can change the default container with the redircmp.exe utility.
ou=Domain Controllers	Default organizational unit for computer objects representing domain controllers.
cn=ForeignSecurityPrincipals	Container for placeholder objects representing members of groups in the domain that are from a domain external to the forest.
cn=LostAndFound	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.
cn=Managed ServiceAccounts	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.
cn=NTDS Quotas	Container to store quota objects, which are used to restrict the number of objects a security principal can create in a partition or container.
cn=Program Data	Container for applications to store data instead of using a custom top-level container.
cn=System	Container for miscellaneous domain configuration objects. Examples include trust objects, DNS objects, and group policy objects.
cn=TPM Devices	Container for recovery information for Trusted Platform Module (TPM) keys.
cn=Users	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 located at cn=configuration,dc=mycorp,dc=com.

Table 4-3 contains a list of the default top-level containers found in the Configuration NC.

Table 4-3. Default top-level containers of the Configuration NC

Relative distinguished name	Description
cn=DisplaySpecifiers	Container that holds display specifier objects, which define various display formats for the Active Directory MMC snap-ins.
cn=Extended-Rights	Container for extended rights (controlAccessRight) objects.
cn=ForestUpdates	Contains objects that are used to represent the state of forest and domain functional level changes.
cn=LostAndFoundConfig	Container for orphaned objects.
cn=NTDS Quotas	Container to store quota objects, which are used to restrict the number of objects that security principals can create in a partition or container.
cn=Partitions	Contains objects for each naming context, application partition, and external LDAP directory reference.
cn=Physical Locations	Contains location objects (physicalLocation), which can be associated with other objects to denote the location of the object.
cn=Services	Store of configuration information about services such as the File Replication Service, Exchange, and Active Directory itself.
cn=Sites	Contains all of the site topology and replication objects. This includes site, subnet, siteLink, server, and nTDSConnection objects, to name a few.
cn=WellKnown Security Principals	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 cn=schema,cn=configuration,dc=mycorp,dc=com. 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.

Figure 4-3. ADSI Edit view of the Configuration and Schema naming contexts

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 classSchema, attributeSchema, and 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.

Note

Chapters 5 and 17 deal with the schema in more depth.

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 dc=apps,dc=mycorp,dc=com. Application partitions can be rooted under domains, as shown in the previous example, or they can be nested under other application partitions (for example, dc=sales,dc=apps,dc=mycorp,dc=com), or 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 .

Creating Application Partitions

Application partitions are commonly managed with the ntdsutil utility. With ntdsutil, you can manage application partitions in Active Directory and AD LDS. The types of operations you can perform include creating and deleting new application partitions, and adding and removing domain controllers and AD LDS instances to and from the list of replicas for an application partition.

In this example, we will create an application partition under the cohovines.com domain called MyPart. This domain is at the Windows Server 2008 functional level. We will enable the application partition to replicate to domain controllers dc01 and dc02.

Here are the steps required to create the application partition:

1. From a command prompt, launch ntdsutil.

2. Enter partition management mode by entering partition management.

3. Enter the distinguished name of the application partition and a server to create the partition on:

   create nc "dc=MyAppPart,dc=cohovines,dc=com" dc01.cohovines.com

4. Enter quit to exit the partition management menu, and then enter quit again to exit ntdsutil.

Here’s how to add the dc02 replica:

1. From a command prompt, launch ntdsutil.

2. Enter partition management mode by entering partition management.

3. Enter connections to move to the connections submenu.

4. Enter connect to server dc02. You must always connect to the server to which you will be adding the replica.

5. Enter quit to return to the partition management menu.

6. Enter the following NC replica to add the replica to dc02:

   add nc replica "dc=MyAppPart,dc=cohovines,dc=com" dc02.cohovines.com

7. Enter quit to exit the partition management menu, and then enter quit again to exit ntdsutil.

On Windows Server 2003, you should replace the partition management command with the domain management command. The rest of the syntax is identical.

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.

Note

The default TTL and minimum TTL can be modified by changing the DynamicObjectDefaultTTLSeconds and DynamicObjectMinTTLSeconds values in the ms-DS-Other-Settings attribute of the CN=DirectoryService,CN=WindowsNT,CN=Services,CN=Configuration,DC=... object.

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).

Warning

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.

4.5. Summary

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.