Windows Server 2012 R2 Inside Out: Active Directory Architecture

Active Directory logical architecture

The logical layer of Active Directory determines how you see the information contained in the data store and also controls access to that information. The logical layer does this by defining the namespaces and naming schemes used to access resources stored in the directory. This provides a consistent way to access directory-stored information regardless of type. For example, you can obtain information about a printer resource stored in the directory in much the same way that you can obtain information about a user resource.

To better understand the logical architecture of Active Directory, you need to understand the following topics:

• Active Directory objects
• Active Directory domains, trees, and forests
• Active Directory trusts
• Active Directory namespaces and partitions
• Active Directory data distribution

Active Directory objects

Because so many types of resources can be stored in the directory, a standard storage mechanism was needed and Microsoft developers decided to use the LDAP model for organizing data. In this model, each resource that you want to represent in the directory is created as an object with attributes that define information you want to store about the resource. For example, the user object in Active Directory has attributes for a user’s first name, middle initial, last name, and logon name.

An object that holds other objects is referred to as a container object or simply a container. The data store itself is a container that contains other containers and objects. An object that can’t contain other objects is a leaf object. Each object created within the directory is of a particular type or class. The object classes are defined in the schema. Some of the object types include:

• User
• Group
• Computer
• Printer

When you create an object in the directory, you must comply with the schema rules for that object class. Not only do the schema rules dictate the available attributes for an object class, they also dictate which attributes are mandatory and which attributes are optional. When you create an object, mandatory attributes must be defined. For example, you can’t create a user object without specifying the user’s full name and logon name. The reason is that these attributes are mandatory.

Some rules for attributes also are defined in policy. For example, the default security policy for Windows Server specifies that a user account must have a password and that the password must meet certain complexity requirements. If you try to create a user account without a password or with a password that doesn’t meet these complexity requirements, the account creation will fail because of the security policy.

The schema also can be extended or changed. This allows administrators to define new object classes, add attributes to existing objects, and change the way attributes are used. However, you need special access permissions and privileges to work directly with the schema. Specifically, you must be a member of the Schema Admins group.

Active Directory domains, trees, and forests

Within the directory, objects are organized using a hierarchical tree structure called a directory tree. The structure of the hierarchy is derived from the schema and is used to define the parent–child relationships of objects stored in the directory.

A logical grouping of objects that allows central management of those objects is called a domain. In the directory tree, a domain is itself represented as an object. In fact, it’s the parent object of all the objects it contains. An Active Directory domain can contain millions of objects. You can create a single domain that contains all the resources you want to manage centrally. In Figure 10-8, a domain object is represented by a large triangle and the objects it contains are as shown.

Domains are only one of several building blocks for implementing Active Directory structures. Other building blocks include the following:

• Active Directory trees, which are logical groupings of domains
• Active Directory forests, which are logical groupings of domain trees

As described, a directory tree is used to represent a hierarchy of objects, showing the parent–child relationships between those objects. Thus, when we’re talking about a domain tree, we’re looking at the relationship between parent and child domains. The domain at the top of the domain tree is referred to as the root domain (think of this as an upside-down tree). More specifically, the root domain is the first domain created in a new tree within Active Directory. When talking about forests and domains, there is an important distinction made between the first domain created in a new forest—a forest root domain—and the first domain created in each additional tree within a forest—a root domain.

In the example shown in Figure 10-9, cohovineyard.com is the root domain in an Active Directory forest with a single tree—that is, it’s the forest root domain. As such, cohovineyard.com is the parent of the sales.cohovineyard.com domain and the mf.cohovineyard.com domain. The mf.cohovineyard.com domain itself has a related subdomain: bottling.mf.cohovineyard.com. This makes mf.cohovineyard.com the parent of the child domain bottling.mf.cohovineyard.com.

The most important thing to note about this and all domain trees is that the namespace is contiguous. Here, all the domains are part of the cohovineyard.com namespace. If a domain is a part of a different namespace, it can be added as part of a new tree in the forest. In the example shown in Figure 10-10, a second tree is added to the forest. The root domain of the second tree is cohowinery.com, and this domain has cs.cohowinery.com as a child domain.

You create a forest root domain by installing Active Directory on a stand-alone server and establishing the server as the first domain controller in a new forest. To add a tree to an existing forest, you install Active Directory on a stand-alone server and configure the server as a member of the forest, but with a domain name that is not part of the current namespace being used. You make the new domain part of the same forest to allow associations called trusts to be made between domains that belong to different namespaces.

Active Directory trusts

In Active Directory, two-way transitive trusts are established automatically between domains that are members of the same forest. Trusts join parent and child domains in the same domain tree and join the roots of domain trees. Trusts are transitive, which means that if domain A trusts domain B and domain B trusts domain C, domain A trusts domain C. Because all trusts in Active Directory are two-way and transitive, by default every domain in a forest implicitly trusts every other domain. It also means that resources in any domain are available to users in every domain in the forest. For example, with the trust relationships in place, a user in the sales.cohovineyard.com domain could access a printer or other resources in the cohovineyard.com domain—or even the cs.cohowinery.com domain.

However, the creation of a trust doesn’t imply any specific permission. Instead, it implies only the ability to grant permissions. No privileges are automatically implied or inherited by the establishment of a trust relationship. The trust doesn’t grant or deny any permission. It exists only to allow administrators to grant permissions.

Several key terms are used to describe trusts, including the following:

• Trusting domain. A domain that establishes a trust is referred to as a trusting domain. Trusting domains allow access by users from another domain (the trusted domain).
• Trusted domain. A domain that trusts another domain is referred to as a trusted domain. Users in trusted domains have access to another domain (the trusting domain).

To make it easier for administrators to grant access throughout a forest, Active Directory allows you to designate two types of administrators:

• Enterprise administrators. These are the designated administrators of the enterprise. Enterprise administrators can manage and grant access to resources in any domain in the Active Directory forest.
• Domain administrators. These are the designated administrators of a particular domain. Domain administrators in a trusting domain can access user accounts in a trusted domain and set permissions that grant access to resources in the trusting domain.

Going back to the example, Tom, an enterprise administrator in this forest, could grant access to resources in any domain in the forest. If Jim, in the sales.cohovineyard.com domain, needed access to a printer in the cs.cohowinery.com domain, Tom could grant this access. Because in this example cs.cohowinery.com is the trusting domain and sales.cohovineyard.com is the trusted domain, Sarah, a domain administrator in the cs.cohowinery.com domain, also could grant permission to use the printer. Bob, a domain administrator for sales.cohovineyard.com, could not grant such permissions, however, because the printer resource exists in a domain other than the one he controls.

To continue working with Figure 10-10, take a look at the arrows that designate the trust relationships. For a user in the sales.cohovineyard.com domain to access a printer in the cs.cohowinery.com domain, the request must pass through the following series of trust relationships:

1. The trust between sales.cohovineyard.com and cohovineyard.com
2. The trust between cohovineyard.com and cohowinery.com
3. The trust between cohowinery.com and cs.cohowinery.com

The trust path defines the path that an authentication request must take between the two domains. Here, a domain controller in the user’s local domain (sales.cohovineyard.com) would pass the request to a domain controller in the cohovineyard.com domain. This domain controller, in turn, would pass the request to a domain controller in the cohowinery.com domain. Finally, the request would be passed to a domain controller in the cs.cohowinery.com domain, which would ultimately grant or deny access.

In all, the user’s request has to pass through four domain controllers—one for each domain between the user and the resource. Because the domain structure is separate from the network’s physical structure, the printer could actually be located right beside the user’s desk and the user would still have to go through this process. If you expand this scenario to include all the users in the sales.cohovineyard.com domain, you could potentially have hundreds of users whose requests have to go through a similar process to access resources in the cs.cohowinery.com domain.

Omitting the fact that the domain design in this scenario is very poor—because if many users are working with resources, those resources are ideally in their own domain or in a domain closer in the tree—one solution for this problem would be to establish a shortcut trust between the user’s domain and the resource’s domain. With a shortcut trust, you could specify that cs.cohowinery.com explicitly trusts sales.cohovineyard.com. Now when a user in the sales.cohovineyard.com domain requests a resource in the cs.cohowinery.com domain, the local domain controller knows about cs.cohowinery.com and can directly submit the request for authentication. This means that the sales.cohovineyard.com domain controller sends the request directly to a cs.cohowinery.com domain controller.

Shortcut trusts are designed to help make more efficient use of resources on a busy network. On a network with a lot of activity, the explicit trust can reduce the overhead on servers and on the network as a whole. You shouldn’t implement shortcut trusts without careful planning. You should use them only when resources in one domain will be regularly accessed by users in another domain. They don’t need to be used between two domains that have a parent–child relationship because a default trust already exists explicitly between a parent domain and a child domain.

With Active Directory, you can also make use of external trusts. External trusts are manually configured and are always nontransitive. External trusts can be either one-way or two-way trusts. When you establish a trust between a domain in one forest and a domain in another forest, security principals from the external domain can access resources in the internal domain. In the internal domain, Active Directory creates a foreign security principal to represent each security principal in the external domain. Foreign security principals can be added to domain local groups in the internal domain.

Active Directory namespaces and partitions

Any data stored in the Active Directory database is represented logically as an object. Every object in the directory has a relative distinguished name (RDN). That is, every object has a name relative to the parent container in which it’s stored. The relative name is the name of the object itself, and it’s also referred to as an object’s common name (CN). This relative name is stored as an attribute of the object and must be unique for the container in which it’s located. Following this, no two objects in a container can have the same common name, but two objects in different containers could have the same name.

In addition to an RDN, objects have a distinguished name (DN). An object’s DN describes the object’s place in the directory tree and is logically the series of containers from the highest to the lowest of which the object is a part. It’s called a distinguished name because it serves to distinguish like-named objects and, as such, must be unique in the directory. No two objects in the directory will have the same distinguished name.

Every object in the directory has a parent, except the root of the directory tree, which is referred to as the rootDSE. The rootDSE represents the top of the logical namespace for a directory. It has no name per se. Although there is only one rootDSE, the information stored in the rootDSE specifically relates to the domain controller on which the directory is stored. In a domain with multiple domain controllers, the rootDSE will have a slightly different representation on each domain controller. The representation relates to the capability and configuration of the domain controller in question. In this way, Active Directory clients can determine the capabilities and configuration of a particular domain controller.

Below the rootDSE, every directory tree has a root domain. The root domain is the first domain created in an Active Directory forest and is also referred to as the forest root domain. After it’s established, the forest root domain never changes, even if you add new trees to the forest. The LDAP distinguished name of the forest root domain is DC=ForestRootDomainName, where DC is an LDAP identifier for a domain component and ForestRootDomainName is the actual name of the forest root domain. Each level within the domain tree is broken out as a separate domain component. For example, if the forest root domain is cohovineyard.com, the domain’s distinguished name is DC=cohovineyard,DC=com.

When Active Directory is installed on the first domain controller in a new forest, three containers are created below the rootDSE:

• The Forest Root Domain container, which is the container for the objects in the forest root domain
• The Configuration container, which is the container for the default configuration and all policy information
• The Schema container, which is the container for all objects, classes, attributes, and syntaxes

From a logical perspective, these containers are organized as shown in Figure 10-11. The LDAP identifier for an object’s common name is CN. The DN for the Configuration container is CN=configuration,DC=ForestRootDomainName, and the DN for the Schema container is CN=schema,CN=configuration,DC=ForestRootDomainName. In the cohovineyard.com domain, the DNs for the Configuration and Schema containers are CN=configuration,DC=cohovineyard,DC=com and CN=schema,CN=configuration,DC=cohovineyard,DC=com, respectively. As you can see, the distinguished name allows you to walk the directory tree from the relative name of the object you are working with to the forest root.

As shown in the figure, the Forest Root Domain container and the Configuration and Schema containers exist within their own individual partitions. Active Directory uses partitions to logically apportion the directory so that each domain controller does not have to store a complete copy of the entire directory. To do this, object names are used to group objects into logical categories so that the objects can be managed and replicated as appropriate. The largest logical category is a directory partition. All directory partitions are created as instances of the domainDNS object class.

As far as Active Directory is concerned, a domain is a container of objects that is logically partitioned from other container objects. When you create a new domain in Active Directory, you create a new container object in the directory tree, and that container, in turn, is contained by a domain directory partition for the purposes of management and replication.

Active Directory data distribution

Active Directory uses partitions to help distribute three general types of data:

• Domainwide data, which is data replicated to every domain controller in a domain
• Forestwide data, which is data replicated to every domain controller in a forest
• Application data, which is data replicated to an arbitrary set of domain controllers

Every domain controller stores at least one domain directory partition and two forestwide data partitions: the schema partition and the configuration partition. Data in a domain directory partition is replicated to every domain controller in the domain as a writeable replica.

Forestwide data partitions are replicated to every domain controller in the forest. The configuration partition is replicated as a writeable replica. The schema partition is replicated as a read-only replica, and the only writeable replica is stored on a domain controller that is designated as having the schema operations master role. Other operations master roles also are defined.

Active Directory can replicate application-specific data that is stored in an application partition, such as the default application partitions used with zones in Domain Name System (DNS) that are integrated with Active Directory. Application partition data is replicated on a forestwide, domainwide, or other basis to domain controllers that have a particular application partition. If a domain controller doesn’t have an application partition, it doesn’t receive a replica of the application partition.

In addition to full replicas that are distributed for domains, Active Directory distributes partial replicas of every domain in the forest to special domain controllers designated as global catalog servers. The partial replicas stored on global catalog servers contain information on every object in the forest and are used to facilitate searches and queries for objects in the forest. Because only a subset of an object’s attributes is stored, the amount of data replicated to and maintained by a global catalog server is significantly smaller than the total size of all object data stored in all the domains in the forest.

Every domain must have at least one global catalog server. By default, the first domain controller installed in a domain is set as that domain’s global catalog server. You can change the global catalog server, and you can designate additional servers as global catalog servers as necessary.