Disclaimer: This blog post is not a complete guide on deploying Privileged Access Workstations (PAWs) that work in any environment. The information contained here defines the concept behind Privileged Access Workstations and presents a working generic implementation. Complete implementation requires deep knowledge of the specific infrastructure and definition of all the tasks to ensure that any other activity is denied execution on the machine, which reduces the likelihood of a potential compromise of it, significantly.
It is assumed that network segregation and access control lists are already implemented in your environment, as they are a fundamental part of ensuring the effectiveness of Privileged Access Workstations and the Active Directory Tier model.
The blog post is split in the following sections:
- Section 1 - Introduction to Privileged Access Workstation
- Section 2 - Deployment of (generic) Privileged Access Workstation
Introduction to Privileged Access Workstation
Privileged Access Workstations (PAWs), is a dedicated workstation for administrative purpose. It is a security hardened, feature and functionality locked-down and is forbidden direct internet access (unless certain cloud-based providers are used by the organization and access is given only to them). PAW should only be used to access or administrate critical infrastructure and perform sensitive tasks.
PAW can be a physical workstation or a virtual machine (VM). Using a VM may weaken the overall security of the PAW and the enterprise architecture behind it, since the virtualization hypervisor is the security boundary, not the PAW itself. Additional security features are also required - the PAW must be a Shielded VM or similar, due to the fact that hypervisor administrators have the ability to access the PAW (and/or its storage files) through the hypervisor console or by access the datastore.
My recommendation is using a physical workstation, therefore this post includes details about physical PAWs. If you nonetheless decide to go for the VM approach, remember to secure the hypervisor, use full disk encryption and shield the VM.
The most common usage is for Active Directory Tier 0 management and administration, however PAW can be used in a plethora of ways, e.g. in Industrial Control System environments or for Cloud Solutions such as Microsoft 365.
Since PAW implementation is not a one-click implementation, I will be outlining it’s deployment in Active Directory and as such the main purpose of the implementation of the machine is to lock it down to allow only Tier 0 access. The overall actions can be reproduced for creating a PAW for another environment (Azure, AWS, ICS etc.).
Alternatives
An alternative of PAW is the classic “Jump Server”. Jump servers is typically a virtual RDS/Terminal Windows server installed with RSAT and other needed applications required to support and maintain the domain infrastructure.
The jump server should only be accessible for administrators, but the jump server design features a critical caveat. This caveat is called “Clean Source principal” which renders the jump server solution insecure. The clean source principal requires the source to be as secure as the object being accessed.
Administrators would be able to access this jump server from the same workstation, they use to browse the internet and access productions-level applications such as Microsoft Office. Using the same workstation for production use and Active Directory management is the exact problem PAW aims to eliminate by providing a single, secure and one-task designed workstation to the administrators.
If an administrator’s workstation is compromised, his “source” will not be “clean” and thus will his connection to the jump server, shared with other administrators, potentially be compromised. An attacker can keylog (capture physical keyboard keystrokes) the administrator’s credentials, initialize a connection to the jump server, provide the administrators credentials and effectively be domain admin.
A (brief) note on Tiers in Active Directory
The Tier model is 3 layered architectural concept for designing and configuring Active Directory. The tiers are defined as follows:
Tier 0 – Includes identities and systems in control of the Active Directory forest or domain.
Tier 1 – Includes identities and systems associated with the application level, e.g. IIS servers and DBA’s.
Tier 2 – includes identities and workstations associated with the production users and help desk.
The Tier model is meant to be a guideline and used based on system criticality. For example, a domain critical server such as ADCS/PKI would be treated as a Tier 0 system, although it is a member server of the domain.
Deployment of Privileged Access Workstation
So, you’ve decided that you want to deploy PAW in your environment, but how does this theoretical concept convert into an actual physical machine?
Several things need to be present before your PAW journey can be initiated.
A physical workstation with Windows 10 Enterprise – Download the latest Windows 10 Enterprise (currently version 1809) from Microsoft and verify the checksum. Make sure the ISO has not been tampered with.
A secure windows configuration – I recommend implementing Microsoft’s Security Baseline and Sean Metcalf’s guide to developing a secure baseline. This (1809 in my case) baseline by itself does not guarantee complete lock-down, but it is a great start for a the PAW configuration baseline.
Active Directory Users, Groups and OU’s.
Additionally, the workstation used for PAW should support Virtualization, Secure boot, TPM 1.2/2.0, 64-bit CPU and UEFI.
Go through the following steps as a starter:
Install Windows 10 Enterprise on the machine. Remember to use a strong password for the built-in user. Once installed, update the Operating System to the latest patch releases via Windows Update servers and not an internal WSUS.
Do not join the PAW to the domain at this point.Create a Central Store with the latest (1809 in my case) ADMX templates on your Domain Controller.
Download the Microsoft (1809 in my case) security baseline and import the GPO’s to Group Policy Management Console.
Import the GPO configuration settings to newly created GPO’s with naming convention “PAW – Secure Baseline” and “PAW – Windows Defender Antivirus”
The GPO’s required for this step are:MSFT Windows 10 1809 – Computer
MSFT Windows 10 1809 and Server 2019 – Defender Antivirus
Download the Firewall profile from https://gallery.technet.microsoft.com/Privileged-Access-3d072563. Create a GPO “PAW – Windows Defender Firewall” and import the firewall settings.
Create a new AD user, only to be used for the PAW, with a strong, 24 character or more password.
Create Domain Local security group “PAW-Users” and add the newly created user account to this group.
Create a separate OU just for PAW and link the imported GPOs to it in the Group Policy Management console.
At this point all the above points should be fulfilled. My PoC Active Directory for this PAW solution is structured as follows:
GPO’s:
OU:
Get-ADOrganizationalUnit -Identity
"OU=PAW,OU=Tier 0,OU=IMPROSEC,DC=AD,DC=IMPROSEC,DC=COM"
Group:
Get-ADGroup PAW-Users
User:
Get-ADUser paw.nfp -Properties * | Format-List Enabled, Name, SID, MemberOf
We’re now ready to install the required tools to perform the administrative tasks. For this we’re going to need Remote Server Administration Tools (RSAT).
Return to the PAW and run the following PowerShell command to enable RSAT on Windows 10 - 1809 release:
Get-WindowsCapability -Online | ? Name -like 'RSAT*'| where {$_.State -eq 'NotPresent'} | foreach {Add-WindowsCapability -Online -Name $_.Name}
The needed tools for administration should now be installed, and we’re ready to create a Windows Defender Application Control (WDAC) policy.
WDAC is used for Application Whitelisting/Control and since this PAW is designed for one specific task, administration of Active Directory, we want to make sure that no unwanted applications are allowed to run. Unlike other solutions such as AppLocker, when the WDAC policy is signed, an administrator cannot disable it. WDAC is hardware integrated to ensure that even users whom successfully escalate to NT\SYSTEM won’t be able to disable the policy.
Another benefit is that WDAC will ensure that PowerShell is limited to Constrained Language mode, which limits its functionality on the local machine to few core functions, which are enough for the purpose of the machine.
Proceeding with the implementation, save the recommended block rules from Microsoft to ‘.\BlockRules.xml’ and create a WDAC signing certificate.
To create a WDAC policy, use the following PowerShell commands:
New-CIPolicy -FilePath '.\CIWin.xml' -Level Publisher -UserPEs -ScanPath 'C:\Windows\System32'
New-CIPolicy -FilePath '.\CIProgram.xml' -Level Publisher -UserPEs -ScanPath 'C:\Program Files' -NoScript
New-CIPolicy -FilePath '.\CIProgram86.xml' -Level Publisher -UserPEs -ScanPath 'C:\Program Files (x86)' -NoScript
Merge-CIPolicy -PolicyPaths '.\CIWin.xml', '.\CIProgram.xml', '.\CIProgram86.xml' ‘.\BlockRules.xml’ -OutputFilePath '.\CIFinal.xml'
Set-RuleOption -FilePath '.\CIFinal.xml' -Option 0
Set-RuleOption -FilePath '.\CIFinal.xml' -Option 3 -Delete
Set-RuleOption -FilePath '.\CIFinal.xml' -Option 6 - Delete
Add-SignerRule -FilePath '.\CIFinal.xml' -CertificatePath ‘.\ImproWDACSignCert.cer’ -Kernel -User -Update
ConvertFrom-CIPolicy '.\CIFinal.xml' '.\PAW-WDAC.bin'
.\SignTool.exe sign -v /n “ImproWDACSignCert” -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 '.\PAW-WDAC.bin'
Now, create a new GPO “PAW - WDAC Policy”, copy the *.BIN file to the Domain’s SYSVOL and then deploy it to all PAWs with the following GPO setting:
Computer Configuration\Policies\Administrative Templates\System\Device Guard\ Deploy Windows Defender Application Control
Go back to Group Policy Management console and edit the “PAW – Secure Baseline” GPO with the following settings:
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
Access this computer from the network
Allow log on locally
Allow log on through Terminal Services
Debug programs
Deny access to this computer from the network
Deny log on as a batch job
Deny log on as a service
Deny log on locally
Deny log on through Terminal services
Configure the above deny settings with the following values:
For simplicity I’ve only added “IMPROSEC\Domain Admins” and “IMPROSEC\Enterprise Admins” to the deny rules. The following list of groups should be added as well:
Schema Admins
DOMAIN\Administrators
Account Operators
Backup Operators
Print Operators
Server Operators
Domain Controllers
Read-Only Domain Controllers
Group Policy Creators Owners
Cryptographic Operators
+ Other privileged groups created in your domain
Configure the remaining settings from the above picture with the following values:
Allow log on locally - IMPROSEC\PAW-Users, BUILTIN\Administrators
Allow log on through Terminal Services - Enabled but blank
Access this computer from the network - BUILTIN\Administrators
Debug programs - Enabled but blank
To ensure that the local privileged groups remain empty, edit the following GPO setting values:
Computer Configuration\Preferences\Control Panel Settings\Local Users and Groups
Click New and click Local Group
Select the Update action, and select "Administrators"
Select “Delete all member users” and “Delete all member groups” check boxes
Click OK
Repeat this step for the following local groups:
Cryptographic Operators
Hyper-V Administrators
Network Configuration Operators
Power Users
Remote Desktop Users
Replicators
Finally edit the “PAW – Secure Baseline” GPO once again to enable Virtualization Based Security. Find the following GPO setting and select “Turn on Virtualization Based Security”
Computer Configuration\Policies\Administrative Templates\System\Device Guard
Select the following settings:
Platform Security Level – Secure boot and DMA Protection
Virtualization Based Protection of Code Integrity – Enabled with UEFI lock
Credential Guard Configuration – Enabled with UEFI lock
Secure Launch Configuration - Enabled
Now we’re ready to join the PAW to the domain. Execute the following PowerShell command on the PAW:
Add-Computer AD.IMPROSEC.COM -Credential (Get-Credentials) -NewName “IMPRO-PAW” -OUPath “OU=PAW,OU=Tier 0,OU=IMPROSEC,DC=AD,DC=IMPROSEC,DC=COM” ; Restart-Computer
Going back to Active Directory Users and Computers, we should now see the PAW added to the correct OU:
You’re now ready to RDP to your desired Tier 0 system, using your Tier 0 account, with the required privileges.
As a final note, do not assign the user “paw.nfp” user any privileges locally on the machine or in Active Directory. LAPS should be deployed to PAW machines and the local built-in Administrator account should be configured with the LAPS installation.
For the above configuration, I recommend using strictly RDP to connect to Tier 0 systems and manage them directly. RSAT is installed, however the permissions set in the GPO’s will not allow any privileged users to login nor run these tools locally on the PAW. Edit the GPO “PAW – Secure baseline” before attempting to use RSAT tools.
Remember that the above PAW solution is not a final product. This is only the initial configuration of PAW.