A major component of Australia Cyber Security Centre’s (ACSC) Essential Eight is the mitigation strategy Restrict Privileged Access and to reach maturity level 2 of 3 you need to consider adopting the following
Essential Eight +
- Privileged accounts (excluding privileged service accounts) are prevented from accessing the internet, email and web services.
- Privileged users use separate privileged and unprivileged operating environments.
- Privileged operating environments are not virtualised within unprivileged operating environments.
- Unprivileged accounts cannot logon to privileged operating environments.
- Privileged accounts (excluding local administrator accounts) cannot logon to unprivileged operating environments.
As of this month, or maybe last, we can now build a robust Privileged Access Workstation (PAW) using Azure Virtual Desktop (AVD) that is both Azure AD joined + MEM enrolled, without any other cumbersome dependencies necessary.
This post will not be an exhaustive guide but will build on the thoroughly excellent work of Joe Stocker who wrote the go-to guide regarding Windows Virtual Desktop (now known as Azure Virtual Desktop).
However, if you wish to AAD join and MEM enroll a device and build a Privileged Access Workstation the following guide will hopefully help in combination with his blog.
The objectives are as follows;
- Build an AVD that is Azure AD joined and MEM enrolled
- Ensure this device can only be accessed by your privileged users
- Enforce your privileged users to provide GPS-based geo-location before accessing PAW (this will prevent VPN bypasses of your traditional “named locations”)
- Ensure PAW can only be accessed from compliant devices
- Import PAW into Autopilot with a specific tag and apply PAW MEM configuration hardening policies
Azure Virtual Desktop
So, let us begin. Please remember I’m simplifying this and you will get a lot more detail from aforementioned Joe Stocker’s guide – in red are the parts which are not included in Joe’s blog and will add additional value.
- Log into Azure portal and search for Azure Virtual Desktop
- Select host pools and ‘create new host pool’
- Create a new resource group name-avd-prod-location (good to keep this separate as RBAC permission required on RG later)
- Give the host pool a name i.e name-avd-host-prod-location
- Validation environment = yes
- Host pool type = personal – assignment type = automatic > click next
- If you don’t already have a virtual network in one of your RG’s then select no to the question “add virtual machines” (otherwise see create VM section below)- * please be aware if you use an existing virtual network i.e one that references your AAD domain services or AD server then your VM creation will fail unless this has an internet route to the net.
- Register desktop app group select ‘create new’ and name name-avd-app-group
- Finally, tag with something (for this example) avd | paw > then click create
- If at number 7 you didn’t already have a virtual network now is the time to create one within your RG
- Once deployed head back to Azure Virtual Desktop and you will now see a Host pool
- Switch to Application Groups blade and you’ll also see the one you made earlier > select that group and then click assignments > in here we need to add our privileged users before assigning them to a virtual machine in the next section
Azure Virtual Desktop
- Now head back to Host pools and select the one we created earlier
- Click into Virtual machines “Total machines”
- From here we can add a new virtual machine
- The first page will be populated based on our host pool settings > click next
- From here we can select a name prefix and various other preferences
- Make sure to select a virtual network that can connect to the internet otherwise VM deployment will fail
- The most important part here for our exercise is “select which directory you would like to join = Azure Active Directory and Enroll VM with Intune = Yes
- Add tags then click review + create
- If all went well – we should now see a device in both AAD and MEM
- Finally, add your PAW users to the host pool RG with the following role “Virtual Machine User Login”
Conditional Access
If you have added the DNS (see Joe’s blog) then you should now be able to access your virtual machine using the new Remote Desktop client from https://www.microsoft.com/en-us/p/microsoft-remote-desktop/9wzdncrfj3ps#activetab=pivot:overviewtab
……not quite! You actually want to make sure your security architecture is good (which of course it already is, right?). Let’s just first make sure we have some CA policies in place
- All users require MFA
- All devices must be compliant (yes, including the device that will connect to your PAW)
- Require GPS location for app “Windows Virtual Desktop”
Once number 3 is in place you will see the following prompt – the PAW user will be required to prove their GPS-location using Microsoft Authenticator. This is a huge milestone as it means we can now prevent VPN-based attacks that can easily bypass your current “trusted locations”
Microsoft Endpoint Manager
From here the world really is your oyster- I’d make a few suggestions though;
- Follow Microsoft’s advice around deploying a PAW workstation Deploying a privileged access solution | Microsoft Docs
- If you followed their advice around creating a PAW dynamic group then ingest your new PAW devices into autopilot using the -online command (See Matt Soseman’s instructions)
- Once you have the devices populated in a dynamic group use MEM to harden devices in various ways i.e Windows Defender Application Control | Windows Defender Application Guard | Baseline Policies | MDE etc etc
Install-Script -Name get-windowsautopilotinfo -force
Get-WindowsAutoPilotInfo.ps1 -Online -GroupTag paw
References:
Deploy Azure AD joined VMs in Azure Virtual Desktop – Azure | Microsoft Docs