Microsoft Enhanced Security Administrative Environment (ESAE)

• Author
• Recent Posts

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

• Install Ansible on Windows - Thu, Jul 20 2023
• Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
• Azure Virtual Desktop: Getting started - Fri, Apr 14 2023

Microsoft has always been a company that "eats its own dog food." Not only does it use its own products and technologies internally, but it also consults with its customers to (a) gather a huge information and experience database and (b) distill best practices for accomplishing various IT goals.

Red teaming

According to Azure CTO Mark Russinovich (PDF), the Azure development group regularly conducts "red team vs. blue team" penetration tests against the Azure fabric to identify vulnerabilities. In IT security nomenclature, the "red team" consists of the security professionals who conduct the penetration tests.

The "blue team" represents the development and operations staff of the services being evaluated. ESAE calls the implementation of a dedicated administrative forest a "red forest" design. The red forest should be a regular target of penetration tests by red team members and protected by blue team members.

Don't get too hung up on the red/blue distinction. In ESAE, there's no "blue forest." Instead, the dedicated administrative forest is "red" because it contains the environment's most powerful credentials and should be protected and evaluated regularly.

Microsoft recommends that its customers utilize an "assume breach" posture in which they operate under the assumption that unauthorized parties have already penetrated their networks and resources. Given that assumption, their task is to resolve vulnerabilities and lock down the environment in accordance with the IT security principles of least privilege and least service.

So what is ESAE?

First, ESAE is not a single product offering. Instead, ESAE is a reference architecture that Microsoft's Cybersecurity Consulting Group uses in its work with its customers. In other words, you can engage with the Cybersecurity Group, and it will help you restructure your AD forest to comply with ESAE precepts.

You won't find much in the way of ESAE specifics online; my personal opinion is that Microsoft wants customers to engage with its Cybersecurity team for consulting guidance. According to Microsoft's marketing literature, the primary goal of the ESAE model is the protection of administration credentials.

I created a Microsoft Visio drawing that sums up the core principles behind an admittedly simplified ESAE forest design. Study the annotated diagram, and I'll explain the components below:

ESAE forest design - high-level overview

• A: This is the "red" forest in which we isolate Tier 0 assets, including administrative identities and groups, in their own Active Directory forest. Because this forest stores all high-value assets, we use it as the target of regular penetration tests.
• B: This is the production forest. Tier 1 assets are identities that control enterprise servers and applications. Tier 2 assets are identities that control user workstations and devices.
• C: We use a one-way forest trust and selective authentication to strictly control authentication flow and resource access. Remember that resources trust accounts, so the production forest trusts the administrative accounts stored in the administrative (red) forest.
• D: Not shown in this diagram is a separate privilege forest that implements Microsoft Identity Manager (MIM) and Privileged Access Management (PAM). The nutshell summary here is that MIM and PAM add fine-grained control and reporting to the use of privileged accounts.

ESAE isn't intended to be simply a theoretical construct. Microsoft recommends that you actually consider implementing this architecture in production. Of course, for many organizations, deploying one or more administrative forests is not trivial.

Regardless of whether you decide to investigate, I believe that Microsoft is correct in recommending that customers perform red/blue team penetration tests in order to evaluate how secure their administrative credentials and resources are.

Another aspect of the ESAE architecture is that of the privileged access workstation (PAW). After all, we AD administrators typically administer our infrastructure servers from our Windows Client–based workstations. Thus, we need to extend security to these administrative workstations as well. Remember, ESAE is fundamentally about protecting high-value credentials.

I wrote about this subject in a previous 4sysops blog post. Again, the nutshell summary is that administrators should use a separate computer for administrative access.

All systems in the ESAE environment, whether running Windows Server or Windows Client, must be deployed using the "clean source" principle. This means using verified installation media and ensuring that systems are dependent only on higher-trust and never on lower-trust systems.

Components of an ESAE solution

Let's see if we can round up the primary per-system ingredients of an ESAE solution. First, Microsoft assumes that all infrastructure servers support Secure Boot. As you may know, Secure Boot is part of the Unified Extensible Firmware Interface (UEFI) standard and ensures the integrity of the startup environment.

Your servers should also have Trusted Platform Module (TPM) chips installed on their motherboards, which store the decryption keys for BitLocker Drive Encryption (BDE) encrypted system and data volumes.

You can use The Microsoft Security Compliance Manager (SCM) to design and deploy Group Policy–based security baselines to all servers.

Of course, Windows Server Update Services (WSUS) allows you to screen and deploy security updates and updated antimalware definitions to your servers efficiently.

Windows Server 2016 and Windows 10 include Credential Guard, which protects in-memory LSASS credentials from "pass the hash" or "pass the ticket" attacks by storing them in a virtualized container.

To the point of in-memory vulnerabilities, Microsoft offers the Enhanced Mitigation Experience Toolkit (EMET). EMET is a small desktop application that makes it easier to guard against lower-level malware. For instance, EMET can enable Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), and other "programmery" mitigations.

If your business is willing to embrace Active Directory Federation Services (AD FS) and the Azure cloud, you can introduce multi-factor authentication (MFA) into your enterprise. Recall that two-factor authentication involves a secret each user knows (his or her password), as well as something he or she has (a personal identification number (PIN) delivered via a Short Message Service (SMS) text message to his or her mobile device).

Of course, Windows Server has supported smart card authentication for many years now. Windows Server 2016 and Windows 10 now support TPM-based virtual smart cards.

For protection against rogue application installation, there are couple "whitelisting" options. First, there's AppLocker—that technology is pretty mature at this point. The latest application whitelisting solution—much more difficult to deploy as of this writing—is Device Guard.

Finally, there's Advanced Threat Analytics (ATA). I look at ATA as a software-based intrusion detection/prevention system specifically for Active Directory.

Final thoughts

Yes, there certainly are many, many parts to the ESAE reference architecture. Rather than providing a model that businesses can implement themselves, I personally think that Microsoft intentionally keeps the ESAE details sparse and instead encourages businesses to engage with the Microsoft Cybersecurity team and its partners directly.

Nonetheless, the team makes enough guidance public to give us "boots on the ground" Windows system administrators some great inspiration and ideas for further hardening our Active Directory environments.