Last Update: Sep 04, 2024 | Published: Oct 02, 2017
In today’s Ask the Admin, I’ll show you how to implement Privileged Access Management (PAM) in Windows Server 2016.
Privileged access to Active Directory (AD) and other sensitive systems is often granted to IT staff permanently. Hackers target these users as they provide an easy way to compromise an entire network. To help combat the problem, Microsoft recommends organizations adopt its Enhanced Security Administrative Environment (ESAE) model where a hardened administrative forest (bastion forest) is dedicated to managing AD and enables organizations to regain control over already compromised domains.
As part of the ESAE initiative, Just-in-Time (JIT) administration was introduced in Windows Server 2016 and it allows system administrators to grant users privileges to resources for a limited period of time. Adding to Just-Enough-Administration (JEA), which restricts users to a pre-defined list of PowerShell cmdlets, parameters, and modules in a PowerShell session, the JIT model has two objectives:
For more information on using JEA, see PowerShell 5.0 Just Enough Administration (JEA) Part 1: Understanding JEA and Configuring the Demo Toolkit and PowerShell 5.0 Just Enough Administration (JEA) Part 2: Creating Toolkits and Understanding Logs on the Petri IT Knowledgebase.
Shadow Principals are new in Windows 2016 and are created in the bastion forest. Shadow Principals mirror objects in your production forest, like the Domain Admins group and accounts of IT personnel. Administrative access to the production forest is managed using Shadow Principals in the bastion forest. Managing AD using Shadow Principals in a bastion forest helps reduce the risk of many common attacks, including pass-the-hash, pass-the-ticket, Kerberos compromises, spear phishing, and more.
The bastion forest should be built from scratch, enforce strong authentication, and be connected to the production forest using a Privileged Identity Management (PIM) trust. When Shadow Principal users are added to Shadow Principal groups in the bastion forest, a time-to-live (TTL) value can be added to ensure that they are later removed.
To fully implement Microsoft’s ESAE model, Microsoft Identity Manager (MIM) is recommended. MIM is used to implement workflows so that users can request temporary access to privileged groups in the production forest. If you implement your own workflow solution, MIM is not required.
For more information on PAM in Windows Server 2016 and Microsoft’s recommendations for implementing JIT administration, see Windows Server vNext Privileged Access Management on the Petri IT Knowledgebase.
In this demo, I already have a production domain (ad.contoso.com). At least one Windows Server 2012 R2 or Windows Server 2016 domain controller is required in the production domain to enable the PIM trust. I will create a new bastion forest (pim.contoso.com) to securely administer my existing production domain.
The bastion forest must be set to Windows Server 2016 forest functional level and the AD Privileged Access Management feature enabled. Open a PowerShell session and use Install-WindowsFeature and Install-ADDSForest to install Active Directory Directory Services (ADDS) and configure the bastion forest in Windows Server 2016.
$domainName = 'pim.contoso.com' $password = 'PassW0rd!' $passwordsec = convertto-securestring $password -asplaintext -force Install-WindowsFeature –Name AD-Domain-Services -IncludeManagementTools Install-ADDSForest -DomainName $domainName -InstallDns -Force -Confirm:$false -SafeModeAdministratorPassword $passwordsec
The default forest functional level in Windows Server 2016 is Windows2016Forest. You can check the forest functional level using Get-ADForest.
Get-ADForest
For more information on changing the forest functional level, see Raise Active Directory Domain and Forest Functional Levels using PowerShell on Petri.
Next, you need to enable Privilege Access Management in the bastion forest using Enable-ADOptionalFeature. This adds the necessary objects to the AD schema and is irreversible.
Enable-ADOptionalFeature ‘Privileged Access Management Feature’ -Scope ForestOrConfigurationSet -Target pim.contoso.com
The PIM trust is a one-way cross-forest trust established from the production domain (ad.contoso.com) to the bastion domain (pim.contoso.com). Make sure that name resolution is working between the production and bastion forests using conditional DNS forwarders and then run netdom in the production domain to set up the trust. For more information on configuring DNS, see Configure DNS forwarders in Windows Server 2012 R2 on Petri.
netdom trust ad.contoso.com /Domain: pim.contoso.com /Add /UserD:[email protected] /PasswordD:PassW0rd! /UserO:[email protected] /PasswordO:PassW0rd! netdom trust ad.contoso.com /domain:pim.contoso.com /ForestTRANsitive:Yes netdom trust ad.contoso.com /domain:pim.contoso.com /EnableSIDHistory:Yes netdom trust ad.contoso.com /domain:pim.contoso.com /EnablePIMTrust:Yes netdom trust ad.contoso.com /domain:pim.contoso.com /Quarantine:No
Now run netdom in the bastion domain:
netdom trust pim.contoso.com /domain: ad.contoso.com /ForestTRANsitive:Yes
To complete the process, enable Kerberos AES Encryption on the trust in the bastion domain for maximum security:
We will create Shadow Principals in the bastion domain to mirror the production domain’s Domain Admins group and the account of an IT staffer, russells. Let’s create a Shadow Principal (PROD-Domain Admins) in the bastion domain (pim.ad.contoso.com) for the Domain Admins group in the production domain (ad.contoso.com).
$ProdPrincipal = ‘Domain Admins’ $ProdDC = ‘dc1.ad.contoso.com’ $ShadowSuffix = ‘PROD-‘ $ProdShadowPrincipal = Get-ADGroup -Identity $ProdPrincipal -Properties ObjectSID -Server $ProdDC $ShadowPrincipalContainer = ‘CN=Shadow Principal Configuration,CN=Services,’+(Get-ADRootDSE).configurationNamingContext New-ADObject -Type msDS-ShadowPrincipal -Name "$ShadowSuffix$($ProdShadowPrincipal.SamAccountName)" -Path $ShadowPrincipalContainer -OtherAttributes @{'msDS-ShadowPrincipalSid'= $ProdShadowPrincipal.ObjectSID}
Shadow Principals can also be created based on user account objects. In ad.contoso.com, I have an IT staffer with an account name russells. Let’s create a Shadow Principal (PROD-russells) in the bastion domain for the russells production domain account. The only change from the code above is that the $ProdPrincipal name is now that of a user (russells) and we substitute Get-ADGroup for Get-ADUser.
$ProdPrincipal = ‘russells’ $ProdDC = ‘dc1.ad.contoso.com’ $ShadowSuffix = ‘PROD-‘ $ProdShadowPrincipal = Get-ADUser -Identity $ProdPrincipal -Properties ObjectSID -Server $ProdDC $ShadowPrincipalContainer = ‘CN=Shadow Principal Configuration,CN=Services,’+(Get-ADRootDSE).configurationNamingContext New-ADObject -Type msDS-ShadowPrincipal -Name "$ShadowSuffix$($ProdShadowPrincipal.SamAccountName)" -Path $ShadowPrincipalContainer -OtherAttributes @{'msDS-ShadowPrincipalSid'= $ProdShadowPrincipal.ObjectSID}
Now that the Shadow Principals have been created, let’s add the bastion domain user (PIM-russells) to the Shadow Principal group PROD-Domain Admins. I have already created the PIM-russells account and PROD-Shadow Organizational Unit (OU) in pim.contoso.com.
Set-ADObject -Identity "CN=PROD-Domain Admins,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=pim,DC=contoso,DC=com" -Add @{'member'="<TTL=300,CN= PIM-russells,OU=PROD-Shadow,DC=pim,DC=contoso,DC=com>"}
The next step is optional. We can also give PIM-russells the permissions of [email protected] using the Shadow Principal object (PROD-russells) for that account.
Set-ADObject -Identity "CN=PROD-russells,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=pim,DC=contoso,DC=com" -Add @{'member'="<TTL=300,CN=PIM-russells,OU=PROD-Shadow,DC=pim,DC=contoso,DC=com>"}
PIM-russells will get domain administrator permissions for 5 minutes in the production domain, although the user object will never be a member of the production domain’s (ad.contoso.com) Domain Admins group. PIM-russells will also get the permissions of [email protected] if you followed the optional steps. The time limit is set in seconds using the TTL value.
Open ADSI Edit from Tools in Server Manager in the bastion domain, connect to the Configuration naming context, and navigate to Services > Shadow Principal Container. Open the PROD-Domain Admins Shadow Principal and scroll down to the member attribute where yo willl see PIM-russells is a member.
Because the production domain is potentially compromised, we will use accounts in the trusted bastion domain for AD management. Instead of using [email protected] or the account of another IT staffer, I will use [email protected].
Log into a computer in the production domain and open a command prompt as [email protected]. You can use whoami to confirm the user’s permissions in the production domain. You can see that [email protected] is a member of ADDomain Admins and if you followed the optional step above, is also ADrussells.
Don’t forget we set a TTL of 5 minutes, so you will need to check within that timeframe. To confirm that the PIM-russells permissions were revoked after five minutes, close the command prompt and reopen it as PIM-russells and run whoami again. If you are opening the command prompt on a domain controller, PIM-russells will be denied access if the account does not have domain administrator rights.
In this Ask the Admin, I showed you how to set up and use Privileged Access Management in Windows Server 2016.