Privileged Access Management (PAM) is a new feature in Windows Server 2016 that can secure environments even in cases where AD is already compromised. In this blog, I’ll describe the architecture requirements for setting up PAM solutions.
Many organizations struggle to secure their systems because Active Directory is already compromised. Insiders often initiate attacks, whether intentionally or by accident. And while a firewall and other boundary defenses are essential, they don’t provide adequate protection by themselves.
Discovering a domain administrator password – or hijacking a domain administrator’s Kerberos token or password hash – isn’t as difficult as you might think
Hackers target AD because it holds the keys to accessing all your sensitive systems. Discovering a domain administrator password – or hijacking a domain administrator’s Kerberos token or password hash – isn’t as difficult as you might think since organizations rarely follow security best practices. For example, it’s relatively simple to demonstrate an attack.
First an employee’s device is compromised. If a domain admin previously logged into the device, it’s not difficult to get the password hash. Or if another user that had local administrator privileges was logged in, through a series of steps the attacker can harvest the Kerberos ticket of a domain administrator logged in to another PC. The ticket can then be used to log in to a domain controller.
Attacks like this are much harder to execute if users, including IT staff, are issued with standard user accounts. And other best practices, such as restricting the use of domain administrator accounts to domain controllers, prevent the compromise of privileged credentials on devices that are less trusted than domain controllers.
Enhanced Security Administrative Environment
But IT is left in a chicken and egg situation because you can argue that there’s little point in implementing best practices in a domain that is already compromised. And migrating an organization to a new AD forest is a serious undertaking that has its own risks. So, Microsoft has come up with a solution that leverages some of the new features in Windows Server 2016.
The Enhanced Security Administrative Environment (ESAE) is designed to help organizations take control of potentially compromised AD forests and start implementing security best practices to ensure that AD can’t be easily breached. ESAE uses a specially hardened (bastion) AD forest for administration of privileged accounts in existing production forest(s), reducing the chances of attack, such as Pass-the-Hash (PtH), Kerberos Pass-the-Ticket, Kerberos compromises, and social engineering.
Using a Privileged Identity Management (PIM) trust, shadow principles, Just-In-Time (JIT) administration, and Microsoft Identity Manager (MIM), organizations can implement workflows that allow accounts in the bastion forest to manage the production forest.
Users that will manage the production domain must be restricted to the bastion forest’s Domain Users group. Privileged access to the bastion forest should be granted via a strict process and accounts limited to use on Privileged Access Workstations (PAWs). I.e. devices that are hardened to the same level as domain controllers in the bastion forest.
PIM Trusts and Shadow Principals
PIM trusts are new in Windows Server 2016 but can be established from Windows Server 2012 R2 level forests. The trust should be established from the existing production forest to the bastion forest. Once the trust has been created, shadow principals are created in the bastion forest to represent entities in the production forest.
For example, a shadow principle might be created to represent the BUILT-INAdministrators group in the production forest. When a bastion forest user is added to the new shadow principle, the user can log in to the production domain with administrator privileges using their bastion forest account.
Shadow principals are created using the New-ADObject PowerShell cmdlet and users can be added to a shadow principle using the Set-ADObject cmdlet. When adding a user to a shadow principle, it is also possible to specify a time-to-live (TTL) value so that the user’s access is revoked after a period of time.
Microsoft Identity Manager
The final piece of the puzzle is setting up a workflow for granting access to the production forest to privileged accounts. Because access is managed using PowerShell cmdlets, organizations can create their own management system. But Microsoft Identity Manager supports the ESAE model out-of-the-box but it does require licensing separately.
MIM allows users to be potential group members and users can be granted fully signed up group membership status when certain conditions are met. This makes the process of granting privileged access to the production forest simpler.
Monitoring ESAE
For the ESAE model to be effective, the production forest should be monitored to ensure the Administrators group, and other privileged AD groups, stay empty most of the time. It’s also worth noting that when you add a bastion forest user to a shadow principle that represents a group in the production forest, like Administrators, the account will not be listed in the group in Active Directory Users and Computers (ADUC). Shadow principles are located in the Shadow Principal Container in AD, and the member attribute lists any objects added to the principle.
For more detailed information on securing privilege access to AD and ESAE, see Microsoft’s website here.
