O'Reilly logo

Active Directory, 5th Edition by Alistair G. Lowe-Norris, Joe Richards, Robbie Allen, Brian Desmond

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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.

LDP connection dialog
Figure 4-1. LDP connection dialog
LDP RootDSE output on a Windows Server 2008 domain controller
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.

ADSI Edit view of the Configuration and Schema naming contexts
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 .

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.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required