Principles of Modern AD Design

To create and implement a modern AD design, you need to be aware of today's requirements and understand how these have changed for both organizations and end users over the past 20 years. In the late 1990s, when Microsoft designed Active Directory, all office workstations were hardwired and often had static IP addresses – even in larger organizations. Company sites were usually connected by lines with high latency and low bandwidth. The complete failure of a site connection for several days was an event that was to be expected not only theoretically but also practically. At the same time, all key business applications relied on centralized services such as AD and good connectivity to the back end.

Today, operators of centralized services in organizations need to meet different requirements. With many enterprise applications moving to the public cloud, the autonomy of internal systems is often less important in the event of a site connection failure. In many IT organizations, traditional AD is still the leading identity store, but most logins take place against cloud directories such as Entra ID that sync with AD. At the same time, users' work devices have become more mobile. Even at company sites, it is common practice to take a laptop to meetings in other teams' offices and conference rooms. The ability to work permanently without a connection to core systems such as Active Directory was something most organizations had to establish during the COVID-19 pandemic at the latest.

Another factor that plays a far greater role today than it did 20 years ago is mergers and acquisitions or divestitures. Although companies were also acquired by other entities in the last century, and public offices were merged or specialist departments separated, it was not nearly as important then to harmonize and ultimately merge the IT systems of the merging organizations as quickly as possible. Experience has shown that identity and associated services such as messaging and groupware, and authorization for these and other applications, are at the forefront of this process.

However, the threat situation to which central IT services are exposed has also changed fundamentally. Although firewalls, virus scanners, and encryption existed in 2000, fire and flooding were at the top of the list of specific threats to an AD infrastructure at the time, followed by hard disk failure and human error. Access to the Internet at an office or production site and an email inbox for every employee were not automatic. When professional hackers broke into a system, they usually had the specific task of stealing information. Today, the Internet, email, and instant messaging are ubiquitous, and criminals have discovered that it is far easier to get the money from the target themselves if they completely encrypt the target's data indiscriminately.

Many of the new requirements initially relate to client management and only affect AD to the extent that settings in group policies and configuration settings in AD need to be synchronized with mobile device management such as Intune. However, today's improved connectivity between locations and the relocation of some applications to the cloud offer an opportunity to streamline the design of Active Directory forests radically and therefore indirectly make them more secure.

Topology and Security Are Connected

The eighth law of the Immutable Laws of Security Administration I mentioned earlier states that the more complex the network design, the more difficult it will be to defend. In terms of Active Directory, the domain topology in a forest is a prime example of this statement. Not only does each additional domain create potential enterprise admins that security managers need to keep an eye on and limit their reach in some way, but a multidomain forest is more difficult to manage in every other aspect.

The disadvantages of this topology decision become particularly apparent if the forest is completely destroyed (e.g., by ransomware or a wiper) and needs to be restored as quickly as possible. A single-domain forest already has the entire database with the first DC restored from the backup, and only a metadata cleanup is required to restore the forest's health state. Strictly speaking, the global catalog is not necessary because it does not provide any new information compared with direct LDAP queries. In a forest with multiple domains, however, you might need to restore, clean up, and reconnect each domain to the rest of the forest. The official forest recovery manual [4] has now grown to 54 pages. Adding this manual to your emergency folder is a good idea, and depending on the complexity of the original forest, you can work through it in an emergency.

What used to be a very common sight with an empty forest root domain and all production objects residing in other domains seems particularly absurd in today's context when it comes to emergency recovery. Recovering the entire forest depends on successful recovery of the root domain, without it contributing anything to operations in terms of content.

Check whether a design that only contains single-domain forests is possible. Structuring by forest is an approach primarily taken because high security – Red Forest (i.e., the Enhanced Security Admin Environment, or ESAE) for classified information, research, and development, also called the admin forest, hardened forest, or the Bastion Forest – or particularly insecure (Exchange) applications need to be confined to separate forests. This approach also can be considered if business units are earmarked for divestment or if parts of the infrastructure are located in places with extremely poor connectivity so that replication and accessibility of the flexible single master operations (FSMO) roles are a problem.

A Walk in the Red Forest

You will definitely want to think about a Red Forest to secure your administrative credentials. The often-quoted statement that Microsoft classifies the ESAE model, administrative tiering, and all other components as obsolete and no longer recommends them is not entirely correct. It is simply no longer the security architecture that Microsoft would unquestioningly recommend as the standard.

The box on the front page of ESAE [5] is also interesting in this context. Although it does not recommend an isolated hardened forest model for most scenarios in organizations, Microsoft works with a similar architecture internally (with associated support processes and people) because of the extreme security requirements for providing trusted cloud services to companies around the world.

Like any security mechanism, IT managers need to operate a Red Forest correctly to improve the security of the entire infrastructure. This process involves setting up a unidirectional privileged access management (PAM) trust [6] to the Red Forest. You might also want to consider the use of smart cards for Red Forest logins and use shadow principals to assign principals from the Red Forest permissions in a Golden Forest. For further hardening, you need to restrict the permissions of Authenticated Users in the Red Forest to ensure that privileges cannot be escalated and prevent searching for and displaying objects and attributes. The trust object from the trusted forest could otherwise be exploited to get a foot in the door of the trusted forest. Windows Server 2025 closes this uncommon but easily exploitable gap.

If your AD infrastructure comprises more than one forest (including the Red Forest), you need to make sure the names of the AD sites and their assignments to the subnets match. This arrangement significantly streamlines cross-forest logins and other AD access, because the domain controller (DC) locator process starts the search for a suitable DC for the user with the site name that has already been determined for the computer from its forest. If your site and subnet topology is dispersed, you do not need to recreate it completely in every forest. You can also leave out any sites from which no logins are ever made to the forest, including the subnets assigned to them.