Active Directory

AD DS structure

Active Directory is made up of forests and domains. A forest is a collection of Active Directory domains that share a schema and some security principals. The majority of organizations in the world have a single forest domain. Larger, geographically dispersed organizations generally use multiple domain forests.

Domains

For the majority of organizations in the world, a single domain would be sufficient. There are two general reasons for having multiple domains in a forest. The first is that your organization is geographically dispersed, and there are issues around domain replication traffic. The second is that your organization is very large. A single domain can hold a staggering number of objects. Unless your organization has tens of thousands of users, a single domain is usually more than enough.

A domain tree is a collection of domains that share a namespace in a parent-child relationship. For example, the domains australia.contoso.com and tonga.contoso.com would be child domains of the contoso.com domain.

You should always deploy at least two domain controllers per domain for redundancy purposes. Make sure that if you have a multidomain forest, you are making regular backups of the domain controllers in the root domain. There has been more than one organization with a multidomain forest that has had the root domain controllers fail irreparably, making it necessary to redeploy the entire forest from scratch.

Multidomain Active Directory environments

The majority of current AD DS deployments in small and medium-sized enterprises have a single domain. This hasn’t always been the case because earlier versions of the Windows Server operating system, such as Windows NT 4, supported far fewer accounts. Supporting a smaller number of accounts often necessitated the use of multiple domains, and it wasn’t unusual to see medium-sized organizations that used complicated domain structures.

Each Windows Server domain controller can create approximately 2.15 billion objects during its lifetime, and each domain supports the creation of up to approximately 2.15 billion relative identifiers (RIDs). Given this, however, few administrators implement multiple-domain forests because they need to support a large number of users.

There are many reasons why organizations implement multidomain forests. These can include (but are not limited to) the following:

• Historical domain structure Even though newer versions of the Windows Server operating system handle large numbers of objects more efficiently, some organizations have retained the forest structure that was established when the organization first adopted AD DS.

• Organizational or political reasons Some organizations are conglomerates, and they might be composed of separate companies that share a common administrative and management core. An example of this is a university faculty in Europe or Australia, such as a Faculty of Science, that consists of different departments or schools, such as the School of Physics and the Department of Botany. For political or organizational reasons, it might have been decided that each department or school should have its own domain that is a part of the overall faculty forest. AD DS gives organizations the ability to create domain namespaces that meet their needs, even if those needs might not directly map to the most efficient way of accomplishing a goal from a strict technical perspective.

• Security reasons Domains enable you to create authentication and authorization boundaries. You can also use domains to partition administrative privileges so that you can have one set of administrators who are able to manage computers and users in their own domain, but who are not able to manage computers and users in a separate domain. Although it’s possible to accomplish a similar goal by delegating privileges, many organizations prefer to use separate domains to accomplish this goal.

Domain trees

A domain tree is a set of names that share a common root domain name. For example, contoso.com can have pacific.contoso.com and atlantic.contoso.com as child domains, and these domains can have child domains themselves. A forest can have multiple domain trees. When you create a new tree in a forest, the root of the new tree is a child domain of the original root domain. In Figure 4-10, adatum.com is the root of the new domain tree in the contoso.com forest.

The depth of a domain tree is limited by a domain having a maximum fully qualified domain name (FQDN) length for a host of 64 characters.

Intra-forest authentication

All domains within the same forest automatically trust one another. This means that in the environment shown earlier in Figure 4-10, you can assign a user in the Australia.pacific.contoso.com permissions to a resource in the arctic.adatum.com domain without performing any extra configuration.

Because of the built-in automatic trust relationships, a single forest implementation is not appropriate for separate organizations, even when they’re in partnership with one another. A single forest makes it possible for one or more users to have administrative control. Most organizations aren’t comfortable even with trusted partners having administrative control over their IT environments. When you do need to allow users from partner organizations to have access to resources, you can configure trust relationships or federation.

Domain functional levels

The domain functional level determines which Active Directory features are available and which operating systems can participate as domain controllers within the domain. The domain functional level determines the minimum domain controller operating system. For example, if the domain functional level is set to Windows Server 2016, domain controllers must run Windows Server 2016 or later. This rule does not apply to member servers. You can have a domain running at the Windows Server 2016 functional level that still has servers running the Windows Server 2012 R2 operating system. Table 4-1 lists the maximum domain functional level given the minimum domain controller operating system. Assuming you are running supported versions of Windows Server and later, which means you are running domain controllers where the oldest operating system is Windows Server 2016, you can either have the domain functional level set to Windows Server 2016 or, if all your domain controllers are running Windows Server 2025, have the domain functional level set to Windows Server 2025.

Table 4-1 Maximum domain functional level

Minimum domain controller operating system	Maximum domain functional level
Windows Server 2016	Windows Server 2016
Windows Server 2019	Windows Server 2016
Windows Server 2022	Windows Server 2016
Windows Server 2025	Windows Server 2025

You can introduce a DC running Windows Server 2025 to a domain at the Windows Server 2016 functional level as long as all the appropriate updates are installed. You can also perform an in-place upgrade of a Windows Server 2012 R2 domain controller to Windows Server 2025. You can raise the functional level after you’ve retired existing domain controllers running older versions of the Windows Server operating system. If all your domain controllers are running Windows Server 2025, you should update your domain functional level to the Windows Server 2025 functional level.

Forests

A forest is a collection of domains that share a schema. There are automatic trust relationships between all domains in a forest. Accounts in one domain in a forest can be granted rights to resources in other domains. As mentioned earlier in this chapter, forests don’t need to have a contiguous namespace. For example, a forest can contain both the contoso.com and Adatum.com domains.

There are several reasons why an organization might have multiple forests with trust relationships configured between those forests. The most common is that one organization has acquired another, and multiple forests exist until such a time that the users and resources hosted in the forest of the acquired organization are moved to the forest of the acquiring organization. A less common one is that an organization is splitting off a part of itself, and users need to be migrated out of the existing forest and into a new forest prior to the split occurring.

Forest functional levels are determined by the minimum domain functional level in the forest. After you’ve raised the domain functional levels in the forest, you can raise the forest functional level. Unlike in previous versions of Active Directory, it’s possible to lower both the forest and domain functional levels after they have been raised. An important caveat with this is that the forest functional level must be lowered so that it’s never higher than the lowest intended domain functional level.

Account and resource forests

Organizations are increasingly deploying what are known as Enhanced Security Administrative Environment (ESAE) forests. In an ESAE forest design, all of the accounts used for administrative tasks in the production forest are hosted in a second forest known as the ESAE, bastion, or administrative forest. The ESAE forest is configured with one-way trust relationships with the production forest.

In their native administrative forest, the accounts used for administrative tasks in the production forest are traditional unprivileged user accounts. These accounts and the groups that they are members of in the administrative forest are delegated privileges in the production forest.

The advantage of this approach is that, should one of these accounts become compromised, it can’t be used to alter any permissions or settings in the administrative forest because the account only has privileges in the production forest.

Organizational units

The benefit of a comprehensive OU structure is that it simplifies the delegation of permissions over objects and allows you to apply GPOs closer to the accounts that they influence. While it’s possible to filter GPOs based on security groups or WMI queries, it’s important to remember that each GPO within a computer and user account’s scope must be checked to see if it applies. If you have all of your GPOs applied at the domain level and filtered on the basis of security group or WMI query, your Group Policy processing time at startup and sign-on is going to be substantially longer than if you apply GPOs as close to the accounts they influence as possible.

Better privilege delegation targeting is also a great reason to have a good OU structure. When delegating privileges, you want to ensure that you only delegate privileges over an appropriate set of objects. For example, imagine that you want to allow each department’s administrative assistant to have the ability to reset passwords for users within their respective department. If all the user accounts for your organization are located in one OU, you won’t be able to do this because, at best, you’ll provide each administrative assistant with the ability to reset every user’s password in the organization. If user accounts are located in department-specific OUs, you can then delegate the ability to reset passwords on a per-OU basis. This way, the administrative assistant for the Marketing department can be granted the ability to change passwords for user accounts located in the Marketing OU without granting them the ability to change passwords for user accounts located in the Accounting OU.

When you create OUs in Windows Server 2019 and later, the OUs are automatically configured so that accidental deletion protection is enabled.

Flexible Single Master Operations roles

The Flexible Single Master Operations (FSMO) roles are five special roles present on domain controllers. Two of these roles, the schema master and the domain naming master, are unique within each forest. The other three roles, PDC Emulator, infrastructure master, and RID master, must be present within each domain in the forest. For example, in a three-domain forest, there is only one schema master and domain naming master, but each domain in the forest has its own PDC emulator, infrastructure master, and RID master.

By default, FSMO roles are allocated to the first domain controller in a domain. After you have more than one domain controller in each domain, you should manually start to move the FSMO roles to other domain controllers. This protects you from a situation where the first domain controller deployed in each domain goes offline and all FSMO roles become unavailable. When you do need to take a domain controller offline for an extended period of time, ensure that you transition any FSMO roles that it hosts to another domain controller in the same domain.

Schema master

The schema master is the single server in the forest that is able to process updates to the Active Directory schema. The Active Directory schema defines the functionality of Active Directory. For example, by modifying the schema, you can increase the available attributes for existing objects as well as enable Active Directory to store new objects. Products, including Exchange Server and Configuration Manager, require that the default Active Directory schema be extended prior to product installation so that each product can store important data in Active Directory.

The domain controllers that host the schema master role should be located in the root domain of the forest. If you need to extend the schema prior to installing products such as Exchange Server, do so either on the computer that hosts the schema master role or on a computer in the same site. The account used to extend the schema needs to be a member of the Schema Admins security group.

You can determine which computer hosts the schema master role by running the following PowerShell command:

Domain naming master

The domain naming master is a forest-level role that is responsible for managing the addition and removal of domains from the forest. The domain naming master also manages references to domains in trusted forests. In a multidomain environment, the domain controller that hosts this forest-level role should be deployed in the root forest.

The domain naming master is also contacted when new instances of AD DS application directory partitions are added, such as when you configure a limited directory partition replication scope for an AD DS-integrated DNS zone. If you can’t add new domains or partitions, the computer hosting this FSMO role may not be available.

You can determine which server hosts the domain naming master role by running the following PowerShell command:

PDC emulator

The PDC emulator role is a domain-level FSMO role that is responsible for handling both changes to account passwords as well as domain time synchronization. PDC emulators in child domains synchronize time against the PDC emulator in the forest root domain. You should ensure that the PDC emulator in the forest root domain synchronizes against a reliable external time source. If users are unable to change passwords or accounts can’t be unlocked, the PDC emulator may have failed.

To determine which domain controller in a specific domain hosts the PDC emulator role, run the following PowerShell command:

Infrastructure master

The computer that hosts the infrastructure master role keeps track of changes that occur in other domains in the forest as they apply to objects in the local domain. The infrastructure master FSMO role holder updates an object’s SID (Security Identifier) and distinguished name in a cross-domain object reference. If group names or memberships for groups hosted in other domains don’t appear current in the local domain, it may be that the infrastructure master has failed.

You should avoid having the infrastructure master role co-located with a domain controller that hosts the global catalog server role unless all domain controllers in the domain are configured as global catalog servers. You can determine which computer in a domain hosts the infrastructure master role by running the following PowerShell command:

RID master

The RID master processes relative ID requests from domain controllers in a specific domain. Relative IDs and domain Security IDs are combined to create a unique Security ID (SID) for the object. There is an RID master in each domain in the forest. When a new security principal object, like a group or user account, is created, a unique SID is attached to that object. SIDs consist of

• The domain SID that will be the same for all SIDs created in the host domain

• An RID that is unique to each security principal SID created in a domain

Each AD DS DC has a pool of RIDs that it can allocate to security principals it creates. When this pool becomes exhausted, the DC will query the RID master for additional RIDs to add to this pool. If the RID master is not available, the pool cannot be replenished, and new accounts cannot be created.

You can use the following PowerShell command to determine which computer hosts the RID Master role:

Seizing FSMO roles

In some cases, a domain controller hosting an FSMO role fails, and you need to seize the FSMO role to move it to another domain controller. For example, to move the RID Master, Infrastructure Master, and Domain Naming Master roles to a domain controller named MEL-DC2, run the following command:

Trust relationships

Trust relationships allow security principals in one Active Directory environment to access resources in another Active Directory environment. Trusts make it possible for users in one domain to be authenticated by domain controllers in a separate domain. For example, if there is a bidirectional trust relationship between the domains contoso.local and adatum.remote, users with accounts in the contoso.local domain are able to authenticate in the adatum.remote domain. By configuring a trust relationship, it’s possible to allow users in one domain to access resources in another, such as being able to use shared folders and printers or being able to sign on locally to machines that are members of a different domain than the one that holds the user’s account.

Some trusts are created automatically. For example, domains in the same forest automatically trust each other. Other trusts, such as external trusts, realm trusts, shortcut trusts, and forest trusts, must be created manually. Trusts use the Kerberos V5 authentication protocol by default, and they revert to NTLM if Kerberos V5 is not supported. You configure and manage trusts using the Active Directory Domains and Trusts console or the netdom.exe command-line utility with the /trust switch.

Although trusts themselves are relatively easy to come to terms with, the terminology around trusts tends to confuse many people. It’s important that you understand the difference between a trusting and a trusted domain and how trust direction, incoming or outgoing, relates to which security principals are able to authenticate.

To understand trusts, you have to understand the difference between a trusting domain or forest and a trusted domain or forest. The trusting domain or forest contains the resources to which you want to grant security principals from the trusted domain or forest access. The trusted domain or forest hosts the security principals that you want to allow to access resources in the trusting forest. For example, if you want to grant users in the adatum.remote domain access to resources in the contoso.local domain, the adatum.remote domain is the trusted domain and the contoso.local domain is the trusting domain. In bidirectional trust relationships, a domain or forest is both trusting and trusted.

Trust transitivity

A transitive trust extends beyond the original trusting domains. For example, if you have a trust between two domain forests and that trust is transitive, all of the domains in each of the forests trust each other. Forest trusts are transitive by default. External trusts are not transitive by default. When you create a trust, keep in mind that there may be domains beyond the one you’re establishing the relationship with that may be included. You might trust the administrator of adatum.remote not to allow access by nefarious users, but do you trust the administrator of subdomain.adatum.remote?

Trust direction

When you create a new trust, you specify a trust direction. You can choose a two-way (or bidirectional) trust or a unidirectional trust, which is either one-way incoming or one-way outgoing.

When you configure a one-way incoming trust, users in the local domain are authenticated by their local domain and authorized for access to resources in the remote domain, realm, or forest. Remember that if you’re configuring a one-way incoming trust between the single domain forests contoso.local and adatum.remote, users with accounts in contoso.local can access resources in adatum.remote. Similarly, if you’re configuring a one-way outgoing trust between the single-domain forests contoso.local and adatum.remote, users with accounts in adatum.remote can access resources hosted in contoso.local.

The terminology around trusts can be a little confusing. The key thing to remember is that the direction of trust is the opposite of the direction of access, as shown in Figure 4-11. An outgoing trust allows incoming access, and an incoming trust allows outgoing access.

Forest trusts

When you configure a forest trust, one AD DS forest trusts the other one. Forest trusts are transitive. When you configure a forest trust, you can allow any domain in the trusting forest to be accessible to any security principal in the trusted forest. Forest trusts can be bidirectional or unidirectional. You are most likely to configure forest trusts if your organization has two or more AD DS forests. You can configure a trust between a forest hosted in Azure and one hosted on-premises.

You can configure one of two authentication scopes when you configure a forest trust. The type of authentication scope that you configure depends on your security requirements. The options are

• Forest-wide authentication When you choose forest-wide authentication, users from the trusted forest are automatically authenticated for all resources in the local forest. You should use this option when both the trusted and trusting forests are part of the same organization.

• Selective authentication When you configure this option, Windows does not automatically authenticate users from the trusted forest. You can then configure specific servers and domains within the forest to allow users from the trusted forest to authenticate. Use this option when the two forests are from different organizations, or you have more stringent security requirements.

Configuring selective authentication

Configuring selective authentication means granting specific security principals in the trusted forest the Allowed To Authenticate (Allow) permission on the computer that hosts the resource to which you want to grant access. For example, assume you had configured a forest trust with selective authentication. You want to grant users in the Research universal group from the trusted forest access to a Remote Desktop Services (RDS) server in the trusting forest. To accomplish this goal, you can configure the properties of the RDS server’s computer account in Active Directory Users And Computers and grant the Allowed To Authenticate permission to the Research universal group from the trusted forest. Doing this only allows users from this group to authenticate; you still have to grant them access to RDS by adding them to the appropriate local group on the RDS server.

External trusts

External trusts enable you to configure one domain in one forest to trust a domain in another forest without enabling a transitive trust. For example, you configure an external trust if you want to allow the auckland.fabrikam.com domain to have a trust relationship with the wellington.adatum.com domain without allowing any other domains in the fabrikam.com or adatum.com forests to have a security relationship with each other.

Shortcut trusts

Shortcut trusts enable you to speed up authentication between domains in a forest that might be in separate branches or even separate trees. For example, in the hypothetical forest shown in Figure 4-12, if a user in the canada.atlantic.contoso.com domain wants to access a resource in the arctic.adatum.com domain, authentication needs to travel up through the atlantic.contoso.com and contoso.com domains before passing across to the adatum.com domain and finally back to the arctic.adatum.com. If you implement a shortcut trust between the canada.atlantic.contoso.com and arctic.adatum.com domains, authentication traffic instead travels directly between these two domains without having to traverse the two domain trees in the forest.

You configure a shortcut trust using the Active Directory Domains And Trusts console by editing the properties of one domain and triggering the New Trust Wizard on the Trusts tab. Shortcut trusts can be unidirectional or bidirectional. As is the case with the creation of other trusts, ensure that you have name resolution working properly between the trusting and the trusted domains, either by having the DNS zones propagate through the forest, by configuring conditional forwarders, or by configuring stub zones.

Realm trusts

You use a realm trust to create a relationship between an Active Directory Domain Services domain and a Kerberos V5 realm that uses a third-party directory service. Realm trusts can be transitive or nontransitive. They can also be unidirectional or bidirectional. You’re most likely to configure a realm trust when you need to allow users who use a UNIX directory service to access resources in an AD DS domain or users in an AD DS domain to access resources in a UNIX Kerberos V5 realm.

You can configure a realm trust from the Active Directory Domains And Trust console. You do this by selecting the Realm Trust option, as shown in Figure 4-13. When configuring a realm trust, you specify a realm trust password that you use when configuring the other side of the trust in the Kerberos V5 realm.

Netdom.exe

You use netdom.exe with the trust switch to create and manage forest, shortcut, and realm trusts from the command line. When using netdom.exe, you specify the trusting domain name and the trusted domain name.

The syntax of netdom.exe with the /trust switch is shown in Figure 4-14.

PowerShell doesn’t include much in the way of cmdlets for creating and managing trust relationships beyond the Get-ADTrust cmdlet, which allows you to view the properties of an existing trust.

SID filtering

In a trusted domain, it’s possible, though extremely difficult, for a malicious administrator to add foreign SIDs (for example, Domain Admins from the resource forest) into a user’s sIDHistory. If those foreign SIDs aren’t filtered at the trust boundary, they would be honored in the user’s token and could grant unintended privileges.

To block this type of configuration, Windows Server enables SID filtering, also known as domain quarantine, on all external trusts. When you enable SID filtering on an external trust, the trusting domain accepts only SIDs from the directly trusted domain and drops all others (including foreign sIDHistory).

It’s possible to verify SID filtering settings on a trust using the Get-ADTrust cmdlet in a PowerShell session run by a user with administrative privileges. For example, to verify that SID filtering is enabled on the trust with the tailwindtraders.com forest, issue the following command:

To disable SID filtering for the trusting forest, use the netdom trust command with the following option:

/enablesidhistory:Yes

Enabling SID history allows you to use SIDs that don’t have the domain SID of the trusting domain. You enable or disable SID filtering on the trusting side of the trust. For example, if you are an administrator in the contoso.com domain and you want to disable SID filtering, you can issue the following command from an elevated command prompt:

In the same scenario, if you want to reenable SID filtering, you can issue the following command:

The default configuration, where SID filtering is enforced by default on trusts, is something that you should probably leave as it is. In the past, it was necessary to allow SID history when trusts were created with forests running Windows 2000 Server domain controllers. Since Windows 2000 is no longer supported by Microsoft, and SID history is not necessary for trust relationships with Windows Server 2003 or later domain controllers, you probably won’t need to disable it.

Name suffix routing

Name suffix routing enables you to configure how authentication requests are routed when you configure a forest trust between two AD DS forests. When you create a forest trust, all unique name suffixes are routed. Name suffix routing assists when users sign on with a UPN, such as rick_claus@contoso.com. Depending on the UPNs that are configured, you might want to allow or disallow the use of specific UPN suffixes. You do this by configuring name suffix routing on the Name Suffix Routing tab of the trust’s properties.