Windows Server 2016: Understanding Microsoft’s Enhanced Security Administrative Environment

In today’s Ask the Admin, I’ll look at Microsoft’s recommendations for securing Active Directory forests using its Enhanced Security Administrative Environment (ESAE) model.

 

 

It is no secret that security is a major headache for organizations in today’s Internet-connected landscape but securing existing production Active Directory (AD) forests can be difficult for two reasons. In many cases, production forests may already be compromised. And the only way to be sure that hackers no longer have control is to rebuild the forest from scratch. This is a task that is costly and unrealistic in many cases. Secondly, it may not be possible to harden production forests enough to provide sufficient protection for highly privileged domain accounts. Doing so would break functionality in the domain.

To address these issues, new features in Windows Server 2016, including Shadow Principals and short-lived AD groups, help businesses take control of production Active Directory (AD) forests by implementing a specially hardened AD forest for administration. Microsoft’s complete solution for this is ESAE. Not only does ESAE allow better security to be applied to privileged accounts but it also allows the provisioning of standard user accounts in the administrative forest that are granted Just-in-Time (JIT) administrative access to production forests.

 

For more information on JIT administration, short-lived AD groups, and Privileged Identity Management (PIM) trusts, see Windows Server vNext Privileged Access Management and Windows Server 2016: Set Up Privileged Access Management on the Petri IT Knowledgebase.

ESAE Administration Forest Best Practices

In Windows Server 2016: Set Up Privileged Access Management on Petri, I outlined the technical steps for setting up an ESAE admin forest, configuring a PIM trust with an existing production forest, and setting up Shadow Principals to allow users in the ESAE admin forest to get time-limited access to the production forest.

Scope and Hardening

Because the admin forest controls access to production forests, it is essential to ensure that the admin forest is secure. One way of doing that is to limit its scope. The admin forest shouldn’t be used to host applications or services not related to the forest’s primary function. Keeping the scope of the admin forest limited to administration of privileged accounts also ensures that adding an additional forest doesn’t increase complexity in your environment beyond what is unavoidable.

The production forest should be configured with a one-way PIM cross-forest or domain trust to the admin forest. Some applications in the production forest may require that a two-way trust is established with the admin forest.

 

 

Users in the admin forest that are granted privileged access to production forests should never have privileged accounts in the admin forest. They should always be standard users. And administrative access to the admin forest must be strictly controlled using a manual process. The admin forest should be locked down using the security settings provided in Microsoft’s Security Compliance Toolkit and OS updates applied as soon as they are available.

Access to the admin forest should be performed from Privileged Access Workstations. I.e. workstations specially hardened for use with admin forest accounts. Other security best practices should be used to secure the admin forest, including BitLocker full-drive encryption, network isolation, USB port restrictions, Secure Boot, multi-factor authentication, physical security, and antimalware.

Group Policy

Using Shadow Principals, you can grant admin forest users BUILT-IN\Administrators or Domain Admins access to production forests. One restriction is that admin forest users granted this access won’t be able to modify Group Policy as users from an external forest. Because Domain Admins is a global group, users from external forests can’t be added. What this means in practice is that while you can add an admin forest user to a Shadow Principal that represents the Domain Admins group in a production forest, when the admin forest user logs in to the production domain, they will be assigned BUILT-IN\Administrators privileges.

To allow admin forest users to modify existing Group Policy Objects (GPOs), you will need to modify the security permissions on the AD container for each GPO (CN={GPO_GUID},CN=System,DC=domain…) using ADSI Edit. To ensure that admin forest users can create and modify new GPOs in the production forest, you will need to modify the DefaultSecurityDescriptor attribute on the Group Policy container classScema object in the production forest schema. For more information about changing GPO permissions, see Microsoft’s website here.

Microsoft Identity Manager

Privileged access to production forests should be controlled using a workflow. Microsoft Identity Manager (MIM) is naturally the recommended solution but it needs to be licensed separately.

MIM allows organizations to create groups with ‘prospective’ membership. When a user requires privileged access to a production forest, their prospective group membership in the admin forest can be ‘enabled’ for a limited period of time using MIM.

The technical components required to implement ESAE are included out-of-the-box in Windows Server 2016. The production forest must be running Windows Server 2012 R2 or Windows Server 2016 forest-level Active Directory. MIM isn’t a requirement. You could implement your own homegrown solution to implement a workflow or use a third-party identity management system.

Get a Grip on Security

In an ideal world, Active Directory and server security would be a top priority and baked in from the get-go. Complex enterprise systems often evolve without due consideration for security. And starting over is rarely an option. Microsoft’s ESAE solution is a compromise because while it adds complexity, which can be reined in by limiting the forest’s scope. It can also improve security for production domains.

ESAE may work for many companies but it won’t work everywhere. Not all applications can be managed by users from external forests. In these cases, you could consider a partial ESAE implementation. Microsoft isn’t sharing exactly how it does its own ESAE. And while the technical requirements are easy enough to implement, ESAE is only valuable if you carefully follow best practices to secure the admin forest.

If you want more information on how to set up ESAE using Windows Server 2016 Shadow Principals and a PIM trust, be sure to check out Windows Server 2016: Set Up Privileged Access Management on the Petri IT Knowledgebase.

Follow Russell on Twitter @smithrussell.