Active Directory components

Active Directory components can be divided into two main categories:

• Logical components
• Physical components

When you design your identity infrastructure, you need to consider both components. Logical components of the Active Directory structure can change at any given time according to business requirements. But you won't be able to easily modify the physical components compared to 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 in the beginning before we move on to advanced identity infrastructure 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 the IT department. Everyone is bound to the company by following different operational guidelines and targets. When we design the identity infrastructure, we need to match it with the company hierarchical layout in order to manage resource and security effectively. Logical components of the Active Directory help you 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.

Forests

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

The Active Directory forest also can be explained in a similar way. The Active Directory forest represents a complete Active Directory instance. It is made of one or more domain and domain trees. I will be explaining what domain and domain trees are in detail later in this chapter. Each domain has its own characteristics, boundaries, and resources allocated. 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 different 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 Amazon. Each tribe have its own name. Similarly, domains in a forest can contain any domain name:

The first domain controller in the Active Directory service deployment is important. When you create the first domain, it will create the forest as well. 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. The rebeladmin.com is the forest root domain. It does have another two companies: one is Rebeladmin IT with the domain name rebeladminit.com, and it provides managed IT services. The other company is My training, with the domain name mytraining.ca, and it provides IT training to professionals. The rebeladminit.com and mytraining.ca both are root domains in their own domain trees. Both domains in the forest will trust each other with two-way transitive trust.

Two-way transitive trust is a logical link between domains where the trusting domain honors the logon authentication of the trusted domain. When considering the previous example, users in rebeladminit.com can authenticate into mytraining.ca domain and vice versa. Any object located in domain inherently trusts other objects in other domains in the same forest. This is not the same as when considering authentication between forests. For that, it may (depending on the trust method) require additional login credentials. An organization can have a single forest or multiple forests based on the company's business requirements.

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 if required. This is if the forest function level is lower it allowed to add the latest domain controller version. For example, if the forest function level is Windows Server 2008, it is allowed to install the domain controller inside the forest with the operating system Windows Server 2016. But this doesn't mean it can use features provided by Windows Directory Services 2016 until it upgrades its domain and forest functional levels. If you upgrade the forest function level to Windows Server 2016, you can have only domain controllers running a minimum of Windows Server 2016.

Domains

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

The Active Directory domain too can be explained in a similar way. The domain contains the logical components to achieve administrative goals in the organization. By default, the domain become 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 security rules defined. 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 to improve efficiency. The domain is also a partition of Active Directory. When I described the Active Directory forest, I had mentioned that every domain inside the forest shared the same schema. Each of the domain controllers also has a copy of the domain partition, and it 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 need to be upgraded. The version of domain function level you can run on the domain depends on the forest functional level. You cannot have a domain functional level higher than the forest functional level.

Domain trees

I am 33 years old and am living in the UK with my daughter and wife. My parents are still living in Sri Lanka, where you can find sunshine all year and white beaches. After our wedding, I moved into new a house, but that didn't mean I was not a part of the family anymore. I am still the son of my parents. I carry my father's surname. I also inherit traditions and characteristics from my parents. My children will have their own families one day, but in the end, we all are part of the same family tree. 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 the root domain as well. All other domains in the domain tree are called the child domain. There will be only one parent domain in a domain tree.

In some documentations, the child domain is also called a subdomain. When dealing with internet domains, sometimes, it is required to create additional place holder, a sub URL. For example, rebeladmin.com is the domain name 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 DNS record for the support.rebeladmin.com subdomain:

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 in the next level in the domain tree, it shares the namespace from the preceding level. Each of the child domain maintains its own domain partition. This configuration data will be replicated only to the domain controllers in 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.

All domain trusts within the Active Directory forest are two-way transitive trusts. Two-way trust means the authentication requests can be processed between two domains in both ways. Transitive means it goes beyond the initial two-way trust between domains and trusts its child domains too even though there is no direct connection.

Organizational units

In the preceding section I explained, how we can group the objects using domains and forests. But within the organization, objects can be categorized into different groups considering the 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 network are similar. We can create an organizational unit (OU) called sales and group and put all the sales department users into it. We can apply security policies to the OU level now 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 OU as required.

Sometimes, I have seen engineers removing/modifying the default OU structure. All these default OUs have different security policies attached. If it really needs to be changed, it is important to compare the security policies applied and reattached to the new OU if required. I highly recommend that you do not modify/remove domain controllers' default OU at least. That said, you are still allowed to add or change security policies applied to default OUs.

Once an object is assigned to an OU, it inherits security settings and permissions applied on 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. Organization units also help delegate administrative control to individuals for specific tasks. Domain administrators have privileges to manage any objects within the domain. But it's possible to create administrators and assign them to manage objects and resources on an organization level. For these administrators, the OU will be the security boundary. They will not be able to modify any other objects outside that particular OU. I will be explaining delegated administration later in this book. Organizational units are container objects. They can be associated with similar or other objects. Similar to the domain parent-child relationship, OUs also can contain child OUs. These are also called nested organization units.

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

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 too 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 office. 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 departments across the branch offices. All the child OUs inherit the permissions applied from 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 Europe, Asia, and North America OUs by default. The OU hierarchy is independent. It is not going to affect any other domain OU hierarchy. The OU also can contain objects from the same domain only.

Physical components

In the previous section, I explained the logical components of the Active Directory. Now it's time to look into the physical components. Even though logical and physical components are equally important in the Active Directory Domain Service design, they are independent. Replication is the core feature of the 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. Logically, components can be easily 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.

Virtualized domain controllers are not always suited for the infrastructures. I have seen some engineers host domain controllers in virtualized environments while the same virtualized environment (cluster) build uses the same domain. If virtualized domain controllers go down with the cluster, authentication will not work either. In such an environment, physical domain controllers are important for a reliable identity infrastructure.

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 be made from a specific domain controller only. After 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 operations role changes can be modified by the designated operation master role owner (FSMO roles) only.

Before Windows 2000 domain services, one of the domain controllers acted as the primary domain controller (PDC) and all other additional domain controllers were called backup domain controller (BDC). Some people still use this terminology to describe the operations of the domain controllers in the infrastructure. But after Windows Server 2000, the only difference between domain controllers was either their Flexible Single Master Operation (FSMO) role holder or the global catalog server. Some documentation listing read-only domain controllers and read/write domain controllers are two different categories, but for me it's rather an operation change than category. Read-only domain controllers are used with specific administrative requirements when you do not trust the security of the domain controller.

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 used by queries. Applications and users in one domain can query for the objects in another domain (same forest) via the global catalog server. All domain controllers in the domain will not be a global catalog server by default. When installing the first domain controller, it will become the global catalog server, and other domain controllers can promote them as global catalog servers according to business requirements. Every domain controller in the domain does not need to be a global catalog server.

Active Directory sites

The AD DS site defines a physical topology of the network. Sites can be separate buildings in a campus network and branch office in a separate city or even in a separate country. As an example, Rebeladmin Corp. has its head office located in London office, UK. It is running a few domain controllers (DC01 and DC02) within its physical network. It uses IP address allocation for the network with subnets 192.168.148.0/24, 10.10.10.0/24 and 172.25.16.0/24. Due to the 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 IP subnets 10.11.11.0/24 and 172.0.2.0/24:

In the preceding diagram, the two offices can be called the two sites. This is because it is clearly two network segments. The Active Directory 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 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 be used for other enterprise operations as well. Using AD DS sites, it's possible to perform bandwidth optimization and replication schedule changes for reliable replication across domain controllers.
• Service location: In the Active Directory setup, there are other services integrated that help in company operations, 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 in the Toronto site are severed by the Microsoft Exchange Server (mail server) in Toronto site when they try to access an email instead of passing the request to the site in London.
• Authentication: When a user logs in to the domain, they need to communicate with the domain controller for authentication. In the preceding example, a user on the Toronto site does not need to connect to a domain controller in the London site for authentication. AD DS sites will allow you to ensure that users in the Toronto site will use the nearest domain controller for authentication. This will reduce latency and bandwidth through the site links.

Since AD DS sites represent a physical network topology, when changes are made to the physical topology, they needs to be updated on the AD DS site configuration as well. A great example is when the IP address subnet is added to the network. If a new subnet is added, this information needs to be updated in the AD DS site subnet section too. Sometimes, engineers forget to do that, and this will prevent infrastructures from having full benefits of AD DS sites.