13.2 Structural Components of Active Directory

You must understand how Active Directory is put together to make good security decisions. Five key structural components make up Active Directory. Each component has a distinct function and security considerations that follow. To understand how each component fits into the overall scheme of Active Directory, you must first understand the details about each component. Then we can start to put the different components together with regard to functionality and security. The key components include domain, tree, forest, organizational unit, and site.

As you read through each structural component description, consider that domains, trees, forest, and sites are not only integral with Active Directory but also integral with DNS. Active Directory relies on DNS to ensure that the information stored in the DNS database is reliable and secured. If DNS is compromised or becomes unstable, aspects such as name resolution, domain controller location, Kerberos, and GPOs would fail. This will leave the IT infrastructure vulnerable and in a state of weakened security.

13.2.1 Domains

The domain is foundational for Active Directory. In all versions of Windows, the domain is the key administrative component that most administrators deal with day in and day out. To understand domains, we need to investigate what a domain is and what a domain is not. If we look at the configuration options required during setup of a domain, we can understand much of what is included in the domain. First off, you are required to give a domain a name. With Active Directory, there are two names for every domain:

NetBIOS domain name: This is the downlevel domain name used to communicate with client computers and applications that don't use DNS to find domain services, such as domain controllers, but instead use NetBIOS. Operating systems that rely on the NetBIOS domain name include Windows 95, 98, and NT.
DNS domain name: The DNS domain name is used throughout the administration tools, as well as by client computers during authentication. Only clients that support Kerberos can use the DNS domain name when they authenticate to Active Directory. Operating systems that rely on the DNS domain name include Windows 2000, XP, Server 2003, and earlier Windows operating systems running DSCLIENT.

Next, the domain is a policy and replication boundary for Active Directory. When we get to the forest definition, we will see how the forest provides a security boundary, but the domain does provide a replication boundary for policy-based security settings, including Account Policy, Group Policy Objects, and replication.

Account Policy: The Account Policy for domain users is established at the domain level. The Account Policy for the domain level includes control over passwords, account lockout, and Kerberos authentication. This means that domain user accounts cannot be controlled at the organizational unit level; they must be controlled at the domain level. Also, the Account Policy is not inherited from the parent domain, if we are focusing in on a child domain. There is no possible way to get a parent domain to push down Account Policies to child domains.
Group Policy Objects: GPOs are the main form of pushing out security to computers in the domain. However, GPOs that are configured within a domain do not and cannot span multiple domains by inheritance or hierarchy. The GPOs can be available to other domains, but there is no option to configure GPOs to span domains with a single configuration.
Replication boundary for the domain naming context: Active Directory's database is split into four main contexts: domain naming, configuration, schema, and application directory. The domain naming context is responsible for user accounts, group accounts, and computer accounts. When domain controllers replicate to exchange and synchronize the changes from other domain controllers, the domain naming context is synchronized with only domain controllers in the same domain. This provides security in that user accounts that are configured in one domain don't have access to resources in other domains until an administrator configures that access. The Application Directory Partition is new for Windows Server 2003 domain controllers and can be used to handle dynamic data. Most Active Directory installations that use this partition use it to store DNS information.

13.2.2 Trees

The concept of an Active Directory tree is tied to DNS namespace. When you bring a new domain into an existing Active Directory forest, you are forced to indicate where the new domain name will be located in comparison to the other domain names that are in Active Directory. You can either locate the new domain name under an existing domain name, making it a child domain, or you can place the new domain name adjacent to the first domain name you created (forest root domain). Figure 13-2 illustrates both of these options.

Figure 13-2. Two domain trees in a single forest

The main item to notice in the representation of an Active Directory tree is the contiguous namespace. Figure 13-2 shows two trees. One tree has the namespace contoso.com, and the other tree has the namespace woodgrovebank.com. You can see that the child domain to contoso.com shares the same DNS extension as the parent. From a security standpoint, there is really no difference between having a child domain or a domain that starts a new tree, as woodgrovebank.com does. So, in essence, the definition of an Active Directory tree is contiguous namespace, that is all!

To reiterate the point from our discussion about domains, the domain administrators in the contoso.com domain would not have any administrative capabilities in the child.contoso.com domain nor the woodgrovebank.com domain.

What all the domains do have in common is connected access by the automatic, two-way, transitive trusts that are created by being installed into the same forest. These trust relationships provide a means for administrators to allow users from other domains to access resources in their domain. The key to remember is that the access for users is not available by default; it must be granted by the administrator of the resource first.

13.2.3 Forests

A forest contains at least one Active Directory tree. The forest structure is also determined at the installation of the first domain controller for a new domain. When the domain controller is configured, the wizard will ask if you want to have a new forest of domains, and you will respond with a yes. At this time, you have made a distinct decision to disjoin the new domain from the other domains in almost every way. Without good documentation or a tool that can graphically represent the forest structure, you will have a difficult time determining where a forest ends and where the next forest begins. Figure 13-3 illustrates graphically what multiple forests would look like.

Figure 13-3. Two Active Directory forests

It is very important to note that there is no trust relationship between the two forests in the figure. This is the true separation of domains in different forests. If there is no trust between domains in different forests, it is clear that the users in one forest don't have access to resources in the other forest. For many companies, this is the driving decision to create different forests. For some business or political reasons, some of the users and resources need to be completely disjoined from one another.

From the ultimate security standpoint of domains, trees, and forests, the forest is the true security boundary among the Active Directory structural components. Nothing is shared between forests, not the schema, GPOs, or administration. Some functions, however, do have forestwide effects, including the following:

Global catalog: The global catalog is the "phone directory" for the forest. Every object from every domain is represented in the global catalog, just not every attribute of every object. The attributes that users would need to search for are included in the global catalog. Some of these attributes include phone number, address, and email address. When a user does a search for an object in the Active Directory using the built-in search tool, the global catalog is referenced to help find the object.
Schema: As noted earlier, the schema is the foundation of object structures for the entire forest. Every domain in the forest shares the same set of object structures that are defined in the schema. If an attacker accesses or modifies the schema, every domain in the forest will be affected. The schema is one-third of the directory database, which is stored on all domain controllers in every domain. Only one domain controller in the forest can update the schema?the Schema Master.
Configuration context: One-third of the directory database is the configuration context. The configuration context is responsible for tracking forestwide information, such as sites and subnets related to the site configuration. The configuration context is stored on all domain controllers in every domain.

13.2.4 Organizational Units

Organizational units (OUs) are objects within a domain that help organize the other objects in the domain. OUs can't span multiple domains, but they can be configured in a hierarchy within the domain.

There are two primary reasons, both security focused, for designing and implementing OUs. The first is delegation, which as we have already seen helps administrators to delegate administrative tasks to other administrators or even employees. The other is the deployment of GPOs. GPOs span security settings, software deployment, desktop configuration, folder redirection, and more.

Delegation: By far one of the most important features of Active Directory is delegation. However, delegation without a solid OU design is almost impossible to implement. OUs need to be designed to delegate administration. The key to delegation is to have the OU contain the objects that the delegate will control. For example, if you have delegated the ability for the HR manager to reset passwords for only the HR employees, then there needs to be an OU for these user accounts. A good design would have an OU named HR_employees, which contains only the user accounts of the HR employees. The design would have this OU low in the OU hierarchy, so that no other OUs are below it. In that design, the HR manager will not have control over any other user accounts by default.
GPO deployment: Many administrators leave out the consideration of GPO deployment when they design OUs. This is a mistake, mainly for security reasons. The GPO deployment should be interwoven with delegation considerations. If there is a conflict between the two design needs, the delegation needs usually win. In this case, the GPO deployment will be taken care of by filtering the GPO (setting permissions on the GPO). An example of a typical GPO design would be the configuration of the Internet Explorer proxy settings for a branch office. All employees in the branch office need to have the same proxy settings for IE, which can easily be set by using GPOs. In this case, there would be an OU named Branch1_employees, which contains the user accounts for only the branch office. This OU would be low in the OU hierarchy, with no other OUs below it.

An error that many companies make is to duplicate their company's organizational chart for their OU design. The OUs are not well suited for this model, since this model usually breaks how the administration of objects and deployment of GPOs are implemented. This is not to say that a small percentage of companies have not successfully used the org chart for the OU design, but in most cases it will cause more anguish than benefit.

OUs should not be confused with containers. A container is a default folder in Active Directory. Default containers include Users and Computers. These are used by Active Directory to store the default user accounts and computer accounts. The main difference between OUs and containers is that GPOs can be linked only to OUs, not containers.

13.2.5 Sites

Although sites don't directly affect security, the reasons for and implementation of them are important to the overall Active Directory structure. If you are using VLANs for security reasons, the design of your VLANs could impact the design of your sites. So security of other network criteria might play a part in the site design. Sites themselves are designed primarily to control replication between domain controllers. A secondary reason for sites is to control access to resources, by directing users to resources in their site, before going across the WAN. By default, domain controllers in the same site replicate every 15 seconds and have a convergence time of 45 seconds within a default Active Directory environment. This is usually a good design, as long as the domain controllers have enough bandwidth between them and the bandwidth is available for this schedule of replication.

If sufficient bandwidth is not available, a less frequent replication schedule is desired. With the default site configuration of only a single site, there is no method to reduce the replication that occurs between domain controllers. To solve this, additional sites are created and domain controllers are moved to sites, which allows for controlled replication between the domain controllers in the sites.

Here are some characteristics of sites:

Sites can contain domain controllers from different domains.
Sites are represented by subnets. The subnets are extremely important for sites, since this is how the client computers track down resources in their own site using DNS.
Sites are typically associated with regions, but not always. Sites are usually configured for networks that are "highly connected"?usually defined as 10 Mbps or higher.

When designing and implementing sites, key configurations need to be addressed:

The schedule of the replication needs to be defined. The default schedule is to have the sites replicate every three hours. For most cases, this may be sufficient, but if sites are in close proximity to one another or on different floors of the same building, this may not be fast enough.
The domain controllers need to be located in the sites. If a domain controller fails to be placed in a site, it will most likely not be used by the network clients, because the IP address will not fall into the correct subnet configured for the site.
The subnets need to be configured for the sites. A single subnet can't span multiple sites, but a site can, and usually does, contain multiple subnets.
The overall convergence time needs to be considered. If numerous sites are configured, how the sites will replicate to one another needs to be considered, which will help determine how long it will take a change to replicate to all the domain controllers in each site.