Understanding Active Directory components

Active Directory components can be divided into two main categories:

• Logical components
• Physical components

When you design your Active Directory setup, you need to consider both components. The logical components of the Active Directory structure can change at any given time according to business requirements. But you won't be able to modify the physical components as easily as the logical components. The placement of these components will define the efficiency, security, reliability, and manageability of your identity infrastructure. So, it's crucial that we get it right at the beginning before we move on to advanced planning.

Logical components

Each business has its own hierarchical organization layout. It may contain multiple branch offices, multiple groups of companies, and many different departments. Each of these components in the business carries out different operations. Operations in the sales department are completely different from in the IT department. Everyone is bound to the company by following different operational guidelines and targets. When we design the Active Directory setup, we need to match it with the company hierarchical layout, in order to effectively manage resources and security. The logical components of Active Directory help you to structure the identity infrastructure by considering design, administration, extensibility, security, and scalability.

The Active Directory logical structure contains two types of objects. Objects can be either container objects or leaf objects. Container objects can be associated with other objects in the logical structure. Leaf objects are the smallest components in the logical structure. They will not have any other child objects associated with them.

In the following section, we are going to explore more about logical components in the Active Directory environment.

Forests

The Amazon is the world's largest rainforest. There are many different animal species, and more than 400 tribes live there. Each of these animal species is different. Reptiles, mammals, snakes, and fish all have different characteristics, and we can group each of them by considering their characteristics. The tribes that live in the forest also have their own languages, cultures, and boundaries. But all these animals and tribes share one forest. They use food, water, and other resources from the Amazon rainforest in order to survive. The Amazon rainforest has well-defined boundaries. Another forest 100 miles away from the Amazon is not called the Amazon rainforest. Its name and boundaries are unique.

The Active Directory forest can also be explained in a similar way. It represents a complete Active Directory instance. It is made of one or more domains and domain trees. We will explore what domains and domain trees are in the following sections. Each domain has its own characteristics, boundaries, and resources. But, at the same time, it shares a common logical structure, schema, and directory configuration within the forest. Similarly, tribes have a relationship with the forest and other tribes, and domains in the Active Directory forest will have a two-way trust relationship. Different tribes in the Amazon forest aren't named after the Amazon; each tribe has its own name. Similarly, domains in a forest can contain any domain name:

Figure 1.3: Domains in the rebeladmin.com forest

The first domain controller in the Active Directory service deployment is important. When you create the first domain, it will also create the forest. Then, the first domain will become the forest root domain. A domain tree contains its own root domain, but forests can contain multiple root domains.

In the previous diagram, Rebeladmin Corp. is an IT solution provider. rebeladmin.com is the forest root domain. It does have another two companies: one is Rebeladmin IT with the rebeladminit.com domain name, and it provides managed IT services. The other company is My training, with the mytraining.ca domain name, and it provides IT training to professionals. rebeladminit.com and mytraining.ca are both root domains in their own domain trees. Both domains in the forest will trust each other with two-way transitive trust.

When Microsoft releases a new Active Directory service version, new features are bound to the forest and domain functional levels. If you want to use Active Directory Domain Services 2016 forest-level features, your directory's Active Directory forest should use the Windows Server 2016 forest functional level. Before Windows Server 2012 R2, forest functional-level upgrades were one-way. Now, it is possible to roll back to the lower forest functional level as long as you are not using the features specific to the current functional level. The forest functional level is dependent on the oldest domain controller version in the network.

For example, if the forest functional level is Windows Server 2008, it is allowed to install the domain controller inside the forest with the operating system, Windows Server 2022. But this doesn't mean it can use the features provided by Windows Directory Services 2022 until it upgrades its domain and forest functional levels. If you upgrade the forest functional level to Windows Server 2016, you can only have domain controllers running a minimum of Windows Server 2022.

The following table explains the supported Domain Controller operating systems for each functional level.

Domains

Referring back to my example about the Amazon rainforest, we can say that there are more than 400 tribes living there. Each of these tribes is unique in certain ways. Each tribe has a different language and culture. Each tribe has its own territory for hunting, farming, and fishing. Each tribe knows its boundaries and does not cross others' boundaries as that can lead to war between tribes. Each tribe has its own tools and methods for hunting and farming. Also, each tribe has different groups assigned to different tasks. Some are good at hunting, some are good at farming, and some are good at cooking. All their contributions help them to survive and grow as a tribe.

The Active Directory domain can also be explained in a similar way. The domain contains the logical components to achieve the administrative goals of the organization. By default, the domain becomes the security boundary for the objects inside it. Each object has its own administrative goals. Individuals in tribes have different identities and responsibilities, but all of them are part of the tribe and the forest. In the same way, all the objects in the domain are part of a common database. Also, everyone in the tribe still needs to follow some of the common rules. Objects in the domain are also controlled by the defined security rules. These security rules are only applicable within that particular domain and are not valid for any object outside the domain boundaries. A domain also allows you to set smaller administrative boundaries within the organization. In the previous section, I explained that a forest can contain multiple domains.

Managing a forest is difficult, as its administrative boundary is large, but the domain allows you to set smaller administrative targets. Active Directory is divided into multiple partitions in order to improve its efficiency. The domain is also a partition of Active Directory. When I described the Active Directory forest, I mentioned that every domain inside the forest shared the same schema. Each of the domain controllers also has a copy of the domain partition, which is shared only by the domain controllers within the same domain tree. All the information about objects in that particular domain is saved in that domain partition. This ensures that only the required data is replicated across the domain trees and forests.

The Active Directory domain's functional levels define the Active Directory capabilities. With every new version of the directory services, new features are added to the domain's functional level. In order to use the features within the domain, the domain functional level needs to be upgraded. The version of the domain's functional level that you can run on the domain depends on the forest's functional level. You cannot have a domain's functional level that is higher than the forest's functional level.

Domain trees

A domain tree is a collection of domains that reflects the organization's structure. My parents and I are bound by a parent-child relationship. It is obviously different from other kinds of relationships. Similarly, domains inside the domain tree have a parent-child relationship. The first domain in the domain tree is called the parent domain. This is also the root domain. All other domains in the domain tree are called the child domains. There will be only one parent domain in a domain tree.

In some documentation, child domains are also called subdomains. When dealing with internet domains, the creation of an additional placeholder, a sub-URL, is sometimes required. For example, rebeladmin.com is the domain name that is used for the website and organization needed to host another website, in order to maintain support requests. But it needs to use the same contiguous namespace. To do that, we can create another folder in the domain root, and create a Domain Name System (DNS) record for the support.rebeladmin.com subdomain:

Figure 1.4: Subdomains in a contiguous namespace

An Active Directory forest can contain non-contiguous domain names. But within the domain tree, it will share the same contiguous namespace. In the previous example, rebeladmin.com is the parent domain for the domain tree. It has two child domains, it.rebeladmin.com and sales.rebeladmin.com. As you can see, it shares the same rebeladmin.com namespace. Similarly, when it goes down to the next level in the domain tree, it shares the namespace from the preceding level. Each child domain maintains its own domain partition.

This configuration data will be replicated only to the domain controllers of the same child domain. When the child domain is introduced to the domain tree, it will automatically create a trust relationship with the parent domain. If two child domains on different domain trees want to authenticate, authenticated traffic must pass through the forest root domains.

Organizational units

In the preceding section, I explained how we can group objects using domains and forests. But within the organization, objects can be categorized into different groups according to operations, organizational structure, geographical locations, or roles and responsibilities. As an example, organizations have multiple departments. We can convert each of these departments into child domains and group each of the department objects. But the child domain needs a separate domain controller, as it will have a separate domain partition.

Isn't there a better way to group these objects within the domain? That's where organizational units come in. Organizational units help group objects on a smaller scale within the domain. The most common way is to group objects that have similar security and administrative requirements together. For example, there are more than 50 users in the sales department. The sales department uses common shared folders and printers. Their security requirements for data and networks are similar. Therefore, we can create an organizational unit (OU) called sales and group all the sales department users into it. We can now apply security policies at the OU level, instead of the user level.

When deploying a domain controller, it creates a default OU structure to segment the most common object types, such as users, computers, and domain controllers. The administrator can add, remove, and delete an OU as required. An OU also helps to apply group policies to a selected group of objects. As an example, if an organization has an OU for each department, we can apply different group policies for each department by simply targeting the OU.

Once an object is assigned to an OU, it inherits the security settings and permissions that are applied to the OU level. If the same object is moved to a different OU, then it will apply the settings from the new OU, and discard the settings that were applied from the previous OU. OUs also help to delegate administrative control to individuals for specific tasks. Domain administrators have privileges that allow them to manage any object within the domain. But it's possible to create administrators and assign them to manage objects and resources at an OU level. For these administrators, the OU will be the security boundary. They will not be able to modify any other object outside that particular OU. I will be explaining delegated administration later in this book. OUs are container objects. They can be associated with similar or other objects. Similar to parent-child domains, OUs can also contain child OUs. These are also nested organization units.

OUs can also contain object types, such as users, groups, contacts, computers, organizational units, and printers:

Figure 1.5: Organizational unit hierarchy

In the previous example, Rebeladmin Corp. has a Sales department. In the OU hierarchy, the first thing you need to do is create an OU called Sales department. All the regional offices have their own sales department. Most of the security and administrative requirements for objects in the sales department are the same. But creating OUs based on geographical areas will allow domain administrators to delegate control over those objects to individuals or groups in the regional offices. Also, if a specific security policy needs to be applied to a regional office sales department, it can be applied on a relevant OU level, rather than applying it to the entire Sales department across the branch offices. All the child OUs inherit the permissions that are applied to its parent OU by default.

In the previous example, individuals or groups who have permission to control Sales department objects have control over the objects in the Europe, Asia, and North America OUs by default. The OU hierarchy is independent. It is not going to affect any other domain's OU hierarchy. The OU can also contain objects only from the same domain.

Physical components

In the previous section, I explained the logical components of Active Directory. Now, it's time to look into the physical components. Even though the logical and physical components are equally important in Active Directory Domain Services' design, they are independent. Replication is the core feature of Active Directory Domain Services. If a system has multiple domain controllers, changes made in one domain controller should be replicated to others. Physical component placement can affect Active Directory replications in certain ways. Logical components can easily be rearranged compared to physical components.

Domain controllers

The domain controller is a computer that runs a Windows Server operating system, and holds the Active Directory Domain Services role. It can be either a physical server or a virtual server.

The domain controller holds the directory partition that will be replicated to the other domain controllers in the same domain. The domain can have any number of domain controllers. The number of domain controllers is dependent on the enterprise's size, geographical placement, and network segmentation. In Windows NT, it uses multiple domain controllers, but it maintains a single-master schema. This means that directory changes can only be made from a specific domain controller. Since Windows 2000, there has been support for the multi-master mode. Any object-level changes made in one domain controller will be replicated to all other domain controllers (directory service-related).

That said, some of the Active Directory-related operational role changes can only be modified by the designated operation master role owner (FSMO roles).

The global catalog server

The global catalog server holds the full writable copy of objects in its host domain, and the partial copy of the objects in other domains in the same forest. The partial replica contains a copy of every object in the forest and the most commonly used attributes in queries. Applications and users in one domain can query for the objects in another domain (in the same forest) via the global catalog server. All domain controllers in the domain will not be global catalog servers by default. When installing the first domain controller, it will become the global catalog server, and other domain controllers can be promoted as global catalog servers according to the business requirements. Not every domain controller in the domain needs to be a global catalog server.

More details about global catalog servers and global catalog server placement can be found in Chapter 3, Designing an Active Directory Infrastructure.

Active Directory sites

The Active Directory site defines a physical topology of the network. Sites can be separate buildings in a campus network, with the branch office in a separate city or even in a separate country. For example, the head office of Rebeladmin Corp. is located in London, UK. It runs a few domain controllers (DC01 and DC02) within its physical network. It uses IP address allocation for the network with the subnets of 192.168.148.0/24, 10.10.10.0/24 and 172.25.16.0/24. Due to business requirements, the company opened a branch office in Toronto, Canada. It got its own domain controllers (DC03 and DC04) running, but logically, it is in the same Active Directory forest and domain. Both networks are interconnected with a leased line.

The Canada network uses the IP subnets of 10.11.11.0/24 and 172.0.2.0/24:

Figure 1.6: Active Directory connection

In the preceding diagram, the two offices can be identified as two sites. This is because there are clearly two network segments. Active Directory's logical design does not really consider physical network segmentation. Since they are in the same domain and forest, DC01 to DC04 should replicate changes to each other in order to maintain a healthy identity infrastructure.

Mainly, there are three benefits that we can identify:

• Replication: In a typical AD DS setup, all domain controllers are set to replicate changes between each other, assuming all are connected via fast network links. But in the real world, they're not. Sometimes, connections between two sites are 256 kbps or 512 kbps. The same links will also be used for other enterprise operations. Using AD DS sites, it's possible to perform bandwidth optimization and replication schedules for reliable replication across domain controllers.
• Service location: In an infrastructure, there can be Active Directory-integrated applications/services; for example, Active Directory certificate services and exchange services. Using sites and the subnet setup, we can point users to the nearest server for the services. So, users on the Toronto site are served by the Microsoft Exchange Server (mail server) on the Toronto site when they try to access an email, instead of passing the request to the London site.
• Authentication: When a user logs in to the domain, they need to communicate with the domain controller to gain authentication. In the preceding example, a user on the Toronto site does not need to connect to a domain controller on the London site for authentication. AD DS sites will allow you to ensure that users on the Toronto site will use the nearest domain controller for authentication. This will reduce latency and bandwidth through the site links.

More information about Active Directory sites is available in Chapter 11, Active Directory Services – Part 01.