Windows Server 2016: Set Up Privileged Access Management

Last Update: Sep 04, 2024 | Published: Oct 02, 2017

SHARE ARTICLE

windows server network controller

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.

Just-In-Time Administration

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:

  1. Prevent privilege creep where users are granted elevated privileges for much longer than necessary
  2. Avoid permanently assigning privileges that might only be required for short periods of time

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 and PIM Trust

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.

Create a New Bastion Forest

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.

Enable Privileged Access Management in Windows Server 2016 (Image Credit: Russell Smith)
Enable Privileged Access Management in Windows Server 2016 (Image Credit: Russell Smith)

 

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

Create a PIM Trust

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
Establish a Privileged Identity Management (PIM) trust (Image Credit: Russell Smith)
Establish a Privileged Identity Management (PIM) Trust (Image Credit: Russell Smith)

 

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:

  • Open Active Directory Users and Computers in from the Tools menu in Server Manager.
  • Check Advanced Features in the View menu.
  • Click the System container in the list of objects on the left.
  • Double click the trust object for the production domain in the list on the right. In my case, the trust object is ad.contoso.com.
  • In the Properties dialogue on the General tab, check The other domain supports Kerberos AES Encryption and then click OK.
  • Close Active Directory Users and Computers.
Enable Kerberos AES Encryption support on the trust (Image Credit: Russell Smith)
Enable Kerberos AES Encryption Support on the Trust (Image Credit: Russell Smith)

Create Shadow Principals

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}
Create a Shadow Principal in the bastion forest (Image Credit: Russell Smith)
Create a Shadow Principal in the Bastion Forest (Image Credit: Russell Smith)

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}

Grant Privileged Access to the Production Domain

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>"}

Optional Step

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.

Grant privileged access to the production domain (Image Credit: Russell Smith)
Grant Privileged Access to the Production Domain (Image Credit: Russell Smith)

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.

Test Log In

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 in to the production domain with domain admin privileges (Image Credit: Russell Smith)
Log Iinto the Production Domain with Domain Admin Privileges (Image Credit: Russell Smith)

 

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.

SHARE ARTICLE