Datacenter and Private Cloud Security Blog

What is new in Windows 10 1803 for PAW?

Jian (Jane) Yan[MSFT] — Fri, 08 Jun 2018 02:20:50 GMT

In this blog post, I’ll walk you through the new features which are relevant to the PAW solution in the latest Windows 10 1803 release.

Offline HGS

Prior to 1803 release, to start a shielded VM, the host must connect to the HGS server in order to perform health attestation. One of the top customer feedback is that, PAW devices are sometimes in an offline mode, which means it does not have access to any network, or unable to connect to the HGS server, yet it is important to support the user to access the shielded VM at any time. We introduced the Offline HGS feature in the 1803 release to support this scenario. At high level, if the host health has not changed, shielded VM can start without connecting to the HGS server. That is, when the PAW device is unable to connect to the HGS server, as long as the device health matches previously attested state, it can used a copy of the cached key protector to unlock the shielded VM. The device must connect to the HGS server first to attest its health state before it can function at offline state. You can find the details on how to configure it here.

Lock PAW VM to the device

A shielded VM can start on a host device after the device can attest its health to the correct HGS server. To further secure the VM, ensure only the owner of the VM can start it, we added a policy to lock the shielded VM on the device where it is created. This is a policy controlled by the administrator, the setting is stored in the shielding data file, and it will be enforced at the shielded VM creation time.

New-ShieldingDataFile [-ShieldingDataFilePath]  [-Owner]  [-VolumeIDQualifier]  [-AnswerFile]  [[-OtherFile] ] [[-Guardian] ] [-Policy {Shielded | EncryptionSupported}]  [-BindToHostTpm ] [-WhatIf] [-Confirm]  []

By setting the BindToHostTpm to true, the shielded VM will only start on the device where it is created. This is to prevent a case where an insider tries to steal a shielded VM and attempts to get it started on a different PAW device. This feature will also prevent shielded VM to migrate to another device. For the PAW scenario, you would want to ensure the data is not only stored locally, but also backed up or synced to the backend servers. In case of a hardware device failure, a new shielded VM can be provisioned and data can be restored.

VMConnect to shielded VM

VMConnect was previously blocked to connect to the shielded VM. In the PAW scenario, the user owns both device and the shielded VM, using VMConnect is another top request. After extensive security review, we enabled the support of VMConnect to shielded VM without lower the security assurance.

Get VM EKpub from the device host

Shielded VM has vTPM, which has the same characteristics of a physical TPM including the presence of EKpub. EKpub is used by in various attestation methods such as TPM key attestation. In the physical TPM scenario, the TPM EKpub is retrieved through a different channel and compared with the value from the device, this is to ensure the device TPM has not been tampered with and used as an immutable ID. For the shielded VM case, we added a channel to retrieve its EKPub from the host, the value can be compared with the EKPub retrieved from inside the VM to ensure its integrity and identity. The VM EKpub information is stored in the eventlog channel “Microsoft-Windows-Hyper-V-Worker-Analytic”, with Event ID 1500. The event gets generated every time the shielded VM powered on.

Conclusion

As we continue to make the solution better, we welcome your feedback. In my next blog post, I’ll share the new networking capabilities in the insider release.

PAW deployment guide

Jian (Jane) Yan[MSFT] — Mon, 30 Apr 2018 15:32:05 GMT

After running the PAW TAP program on the solution explained in this blogpost, I received tons of interests and great feedback. While the team is investigating on a plan, a lot of customers are asking how they can deploy PAW in their datacenter. This blogpost is dedicated on this topic. To put the solution into perspective, PAW is just one piece to the privileged account protection puzzle, important but there are a lot more to consider. Microsoft has published a whitepaper which provides a much more comprehensive view. Even on the PAW topic, the whitepaper covers more aspects than this blogpost, such as creating different management tiers for your assets to reduce risk. This blogpost only focusses on one aspect, which is the PAW deployment, including the backend servers. I highly recommend you get familiar with the strategy explained in the whitepaper first before planning for PAW deployment.

Solution overview

There a few different options to deploy PAW, in this blogpost, I’ll focus on the solution which was evaluated in the PAW TAP program. The general feedback was positive, and customer liked the singled device configuration. The solution leverages the shielded VM built in Windows 10 1709 to run secure workload, it includes the client configuration (end user device) and server backend. Here is a simplified topology overview: A common misconception about PAW is “the device which the admin connects to, to get to the backend server (PAW?)”; in fact, PAW is the device which admin uses with physical keyboard and mouse. Consider the following diagram, PAW is commonly considered to be the device in the middle: In this example, PAW refers to the User device , because you are using the keyboard/mouse on this device. If this device is compromised, attacker can get easily get the information to breach the datacenter.

Infrastructure deployment

When we designed the solution, one criteria is to fit it into the existing deployment. If you are familiar with the EASE, this is the model we tested to with the solution. At a high-level, you will deploy a Host Guardian Server (HGS) in the environment. HGS is designed to run in its own forest, you can find details of the HGS deployment here. In addition to HGS, PAW devices need to be managed. There are two common choices: leverage Azure (AAD and Intune) ; or using domain management. Furthermore, with on-prem deployment, a common question is about which domain should the PAW device joining to? Let’s start with identify the computer entities: physical PAW device, a desktop VM and one or more PAW VMs. The example here again using ESAE model as the example:

PAW physical device should be joined to the bastion forest. The risk for placing PAW in the production domain is the exposure to attack. I’ve seen breach to the SCCM server in production environment which leads to compromise of all the PAW devices when PAWs are managed by it. To reduce this risk, consider creating a separate PAW domain or if your company is open to cloud, PAW physical devices can also be AAD managed. We might create ESAE/PAW offering leverage AAD in the future;
PAW VM is dedicated to manage a certain datacenter assets, it should be placed in the same secure bastion forest as the host;
The desktop VM should be managed like all other user desktop machines, which joins to the production domain.

A few other infrastructure services are necessary for PAW but not dedicated for PAW:

WDS: service to image the PAW devices
SCCM: manage/configure PAW devices
Monitoring service
VPN server
WSUS for patch management

Some services Azure offers alternative to, such as ATP which can do better security monitoring using a large database tracking many attack signatures. Another important aspect to consider is the “Break glass” scenario. This is not particular to the PAW deployment. As with any process, if you require all the admins to use PAW, if the PAW device breaks, how would the admin work? Can they physically access the backend servers? Or are there backup devices? This should be considered as part of PAW deployment plan.

PAW device configuration

From end user perspective, the solution looks like: A single device with multiple VMs running on it, with the following software/hardware requirements:

License: To create shielded VMs, you need to enable “Guarded host” feature in Windows optional components. It is available on Windows client Enterprise edition and an E5 license.
The device must have TPM2.0, running UEFI with secure boot enabled.
Recommending memory 16GB or above; hard disk is 500GB and above to support multiple VMs.

Storage

For the PAW device, I separated the partitions for the host OS and the VM VHDs. This way, if the host needs to be rebuilt, the VM information stays. In the past, you need to remember suspend BitLocker of the data drive if it’s host OS is being re-installed, and re-enable it afterwards; the latest release has better Bitlocker support where you don’t need to suspend. But of course, you should ensure there is a Bitlocker recovery plan in place. See here for more options on Bitlocker management. The storage is partitioned as the following: In my testing, I assigned 60GB to the host OS volume, and use the rest of the disk for the data volume. You can adjust the size depending on if you need to store certain data on the host OS. Given the workloads are moved to the VMs, ideally there is little workload and data to be stored on the host OS, so the volume size should be configured for just running the OS. In general, you will need to reserve some space for Windows update on the host OS.

Network

In the Windows 10 1709 release, there is a new type of VM switch “default switch” when Hyper-V is enabled. It allows virtual machines to share the host’s network connection. Without getting too deep into networking, this switch enables the VMs access to the host’s network whether you’re connected to WIFI, or Ethernet. It’s not manageable through the Hyper-V manager app. You can download the cmdlet module here to create additional VM INS switches. To lockdown the network access through Edge, 1709 release also introduced Application Guard, you can take advantage of it to control the access. There is another option to do network-whitelisting through a proxy server, that’s how we do it in Microsoft. I think each has its own advantages. Proxy server network whitelisting is more mature, and there are several software vendors offering the solution, so I’m not going to go into the details here. I’ll focus on the configuration leveraging the Windows Defender Application Guard (WDAG). You can use group policy settings to configure WDAG, in my testing, I’ve configured the following settings on the host:

Enable WDAG (Computer configuration\Administrative Templates\Windows Components\Windows Defender Application guard)

The configuration for these settings are straightforward, you can simply enable the policies. This will configure the policy on the default switch, to allow/block traffic appropriately.

Configure network isolation policy (Computer configuration\Administrative Templates\Network\Network Isolation)

The highlighted policy is the setting you can whitelist Urls. You can find more reference on how to configure the policy here. On my PAW device, I configured the following value for this policy: pawhgs.xxx.microsoft.com (this is the Url for the HGS server which the PAW devices attest to). If user tries to connect to any other Urls, it will be launched through WDAG. Another common question is on VPN. When the host is required to connect through VPN, how can the desktop VM be configured to not use the host VPN? You can configure the host with a registry key to prevent the VM using the host VPN.

Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hns\Parameters
Name: ICSFlags
Type: DWORD
Value: 1

Note: Reboot the machine after the change. Also, this VPN behavior will be improved in the future release.

VM management

In general, there should be little VM management which the end user needs to do. Majority of the work is for the IT admins who provisions the PAW devices, which includes creating the VMs. Currently, the VM management is supported through PowerShell. Inbox Hyper-V module can do almost all the VM management, shielded VM provisioning scenario is supported by the GuardedFabricTools our team released in the Gallery.

Host user start menu customization

You can use group policy to change the start menu layout on the PAW device. Here is an example I created to show only Edge in the start menu:


  
  
    
      
        
          AppUserModelID="Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge" 
           Size="2x2" 
           Column="0" 
           Row="0"/>
          DesktopApplicationLinkPath="D:\PawFiles\bin\StartProgram\VMManager.lnk"
           Size="2x2" 
           Column="2" 
           Row="0"/>
          DesktopApplicationID="{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WindowsPowerShell\v1.0\powershell.exe"
           Size="2x2" 
           Column="4" 
           Row="0"/>

You can save the content above to an xml file (startmenu.xml), and use group policy to apply it: Computer Configuration > Administrative Templates >Start Menu and Taskbar Enable the Start Layout policy and specify the startmenu.xml file full path. Check the docs for more details. After VMs provisioned, you can also add additional RDP connection to the start menu, so user can easily launch them. For details on how to create more short cuts in the start menu, see here.
Image rollout
Windows 10 has a number of security features which can better protect the operating system. I wrote a separate blog post on how to enable them. The question I often get is “how should I deploy the device?” Again, there are a couple of options, both approach should follow the clean source principle:

Windows Deployment Server (WDS): you can first build the host OS iso image using MDT (Microsoft deployment toolkit), then using the WDS to enable device to install the image;

USB boot: if the deployment is small, in my test environment, I created USB boot key with the ISO image created by MDT, and manually installed the PAW devices.

Note that, to comply with the clean source principle, you should ensure using the separate deployment infrastructure from the existing one used for production. This is to ensure a higher trust level for PAW. I think it’s also possible to do all the configuration through Intune, but I’m not the expert on Intune, I’m still looking for help to get all the CSPs created to customize the host. It will be a more scalable approach for future.
VM provisioning
You will need shielded VM templates to provision the PAW VMs. Template creation is a separate topic covered here, and I also shared an example of creating PAW VMs with Kiosk experience. Once you have created the templates, you can store it centrally, and download it to the PAW device for PAW VM provisioning. Desktop VM images are regular VHDs, you can simply download it locally to the device and create the VM from it. A common question is whether the desktop VM should be shielded; in my view, it should be managed in a similar secure level as other desktops in the environment. Host device has Bitlocker enabled, which also protects the desktop VM as a regular desktop. Shielding desktop VM will provide another layer of protection to prevent physical access to the device, and copying the desktop VM to another machine. If you do want to shield the desktop VM, one key scenario is to allow user to start the desktop VM while the device is offline. This is a new feature added in the 0418 release.
Logon and Connect
In the previous Infrastructure deployment section, we looked at how each machine entity is managed by the backend, let’s take a look how user will connect to them here:

Physical host Desktop VM PAW VM

Logon user identity ESAE domain user Production domain user Privileged account for backend management

Logon method

Windows Hello for business

Smartcard

Smartcard Smartcard (Note: Hello for business is not supported for VMs today)

Connect

Interactive logon

RDP is disabled

VMConnect or Mstsc RDP over VMBus

Old fashion user name/password still works for all the connections, but they are less secure comparing to smartcard or Windows Hello for business.
Conclusion
Usually with deployment guide, I’d provide detailed step-by-step instructions. I’m trying a different approach to cover more on planning considerations and referencing to other docs for the detailed instructions. It is such a large topic, I’m sure there are aspects which didn’t get covered, as always, feel free to post your questions/comments below or to us

Apply Code Integrity Policy without reboot

Jian (Jane) Yan[MSFT] — Fri, 27 Apr 2018 13:29:47 GMT
There is a new Code Integrity policy option introduced in Windows 10, and it is available in Windows Server 2019 insider build “Update Policy No Reboot”. I got numerous questions around how to use this option, and here is the blogpost to answer it.
What is this option?
After the Windows Server 2016 release, we talked to many customers about using Code Integrity (CI) policy to secure the servers. One main feedback from server customers is, it requires a reboot when I need to make a change in the policy. This option allows you apply a new CI policy without reboot. This option can used for both signed and unsigned CI policy. For unsigned CI policy, any running executables; already loaded dlls or running PowerShell session will not be stopped, new policy will be applied to new PowerShell sessions, reloading dlls or executables. For signed CI policy, one additional check is in the pre-boot environment with UEFI validation, and this check won’t take effect till the machine reboot. This option is not recommended on the Guarded Fabric deployment. As part of the host attestation, measured boot log and CI policy are checked against the HGS server, it ensures the guarded host is running the same copy of the CI policy as admin defined on the HGS server. If the guarded host is running the CI policy allow “no reboot”, it breaks the guarded host security promise.
How to apply it?
Let’s use an example to illustrate the process. I have s server which is governed by a CI policy (CI.old), in this policy, it has the option enabled:

Now I have a new policy I’d like to apply, I convert it to the binary format using Convertfrom-CIpolicy, and run the following cmd to apply the new policy:
Invoke-CimMethod -Namespace root/microsoft/Windows/CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{ FilePath = 'C:\sipolicy.p7b' }
In short, to apply CI policy without reboot, you need to ensure the existing policy has the option enabled, and run the cmdlet to apply the new policy. Note: this cmdlet for applying new CI policy may change in the new release of Windows (post 1804 release)

Connect to Virtual Machines (VMs) on PAW

Jian (Jane) Yan[MSFT] — Thu, 12 Apr 2018 16:26:47 GMT
Continuing the PAW series, this blog post discusses the options to connect to the VMs running on the PAW device. In Windows, you can connect to a locally running VM using:

VMConnect (basic mode or enhanced mode)

RDP using mstsc.exe (classic RDP client)

RDP using the Remote Desktop app from Store (modern RDP client)

RDP over VMBus (this is done by creating a special RDP file, shown later in the doc)

In addition, it’s quite straightforward to develop a customized RDP app using the inbox RDP ActiveX control. Elena (our intern) wrote a RDP app for VM connection last summer, which is part of the PAW management app she developed. Hence, if none of the inbox apps meets your requirement, this might be a good approach. Modern RDP client has a very nice clean UI, but it is still being actively developed. As of the latest release, it does not support pass through devices yet, so I don’t recommend it for VM connection on PAW. It is however a good choice for RDP to servers (i.e. server management) from the PAW VM. VMConnect (basic mode) allows you to see OS boot phase, i.e. you can see the screen outputs even before the VM starts, whereas RDP (and VMConnect enhanced mode) can only display after the Remote Desktop service starts in the VM. If you need to enter BitLocker key for example, you can only do so using VMConnect basic mode. VMConnect (enhanced mode) and RDP are built on top of the same RDP protocol, so they share similar features. For example, you can pass through smart card to the VM using either VMConnect (enhanced mode) or RDP (note, ensure the right card reader driver is installed in the VM). However, there are two main differences between VMConnect (enhanced mode) and RDP:

VMConnect (enhanced mode) RDP

Transport VMBus, which doesn’t require any network ports to be opened Requires open RDP firewall port to allow it

User permission Hyper-V admin on the host Standard user on the host; user must be in the Remote desktop user group in the VM

In addition, there are advantages of using RDP as it has more functionalities over VMConnect, to name a couple:

Select a subset monitors for VM connection (for example, use 2 out of the 3 monitors connected to the device)

Video device pass through

Using RDP client or VMConnect are pretty straightforward, I won’t go into details on those. There is another approach which allows to get the benefit of RDP, as well as using the VMBus, so you don’t need to open RDP ports on the VM, we call it "RDP over VMBus".
RDP over VMBus
This is done by creating an RDP file with the following configuration: pcb:s:11111111-1111-1111-1111-111111111111;EnhancedMode=1 full address:s:localhost server port:i:2179 where 11111111-1111-1111-1111-111111111111 is the VM ID on the host. The downside of using this connection is that user will need to log on the VM twice; the first time is for the user to logon the local host, and second logon is the VM itself. I’m trying to figure out if there is a way to skip the first logon, welcome your ideas.
RDP file sample
You can create RDP files by running mstsc, and click on "Show Options", after specify the configuration, click on "Save As" on the General page. To use RDP over VMBus, simply replace the setting for "Full address" and "Server port". Below is the RDP file I used for my desktop VM as an example, you can find the setting references here. [snippet slug=rdp-file-sample line_numbers=false lang=bsh] If you would like to share desired user experience or report issues using PAW, feel free to reach us here.

Default Code Integrity policy for Windows Server

Jian (Jane) Yan[MSFT] — Sat, 10 Mar 2018 14:33:21 GMT
After Windows Defender Application Control (WDAC, formerly known as Code Integrity) was released in Windows Server 2016, I wrote a blog post on it, it was a very effective way to do application whitelisting, and get secure! When engaging with customers to get their feedback and help deploy WDAC, the consistent feedback has been “it’s great, but it’s too hard to deploy it.” We listened, and created a few default policies, which balance the security and operational management effort. Those policies are stored under “C:\Windows\schemas\CodeIntegrity\ExamplePolicies” on any Windows OS post 1709 release. I recommend two policies for Windows Server: AllowMicrosoft: this CI policy allows all the files signed by Microsoft. If you are running Server applications such as SQL, Exchange, or the server is monitored by agents published by Microsoft, you should start with this policy. DefaultWindows: this policy only allows the files which are shipped in Windows and doesn’t permit other applications released by Microsoft (such as Office). This is a good policy to use if the Server is dedicated for inbox server roles/features, such as Hyper-V. There are known applications in Windows that might be used to bypass WDAC, the full list is published on this page. I recommend adding them to the deny list in the Code Integrity policy. Please note, the list is updated periodically with newly identified applications, you should review the list and add them to your CI policy if determined fit. To make it easy for you, I created two copies of the default CI policies that you can download (the follow CI policy is designed for the next release of Windows Server, you can also modify it to remove the new policy rule options for Windows Server 2016: AllowMicrosoft_DenyBypassApps_Audit.xml DefaultWindows_DenyBypassApps_Audit.xml One of the new rule options in the above policy file is “Update policy no reboot”. On generic servers, it’s often user needs to be add software, when do so, the CI policy might require a change to cover the application, this rule option allows the CI policy to be updated without machine reboot. This option is added post Windows Server 2016. If you want to use the policies on Windows server 2016, you will need to remove them.
Adding additional publishers
Most of the customers have their own applications developed internally or acquired externally to manage the servers, i.e. the above default policies are not enough. To allow these apps (or even drivers) to load, you will need to modify the CI policy to cover them. There are a couple of approaches:

Adding publisher: If you want to trust all the applications created by the vendor, you can add their publisher to the CI policy. Run the following cmdlet to extract the publishers to an xml file:

New-CIPolicy -FilePath -Level Publisher -ScanPath -UserPEs

Adding FilePublisher: If you want to only trust the installed application (not all the applications from this vendor), you can add FilePublisher to the CI policy to the CI policy. Run the following cmdlet to extract the file list and its publisher to an xml file:

New-CIPolicy -FilePath -Level FilePublisher -ScanPath -UserPEs
You can mix and match different applications (from different vendors) with the two approaches described above. For example, you have an active development team internally, you want to add your enterprise signer/publisher in the CI, so that all the enterprise signed applications can run in the environment; you can also enable a device driver by adding the FilePublisher rule for that driver. For the same publisher, you need to choose between to trust the publisher or trust the FilePublisher. For example, if you contracted a vendor company to develop an application, and you decide to trust the vendor company by adding their publisher to the CI, later if you want to change to trust only that application, you should remove the vendor publisher from the CI first, then add the application FilePublisher rule.
Merge CI policies
With all the CI files generated to cover the additional file/publisher information, you will then merge them with the default CI policies by running:
Merge-CIPolicy -OutputFilePath ‘Serverdefault-audit.xml’ -PolicyPaths ‘.\AllowMicrosoft_DenyByPassApps_Audit’,’additionalCI1.xml’, ‘CI2.xml’

Deploy CI policy
CI deployment and ongoing monitoring is covered in this blog post. You can also reference this page for group policy deployment. Below is a quick reference for your convenience: The created CI policy is in audit mode, you can change it to enforced mode by running:
Set-RuleOptions -FilePath C:\CI\FilePublisher.xml -Option 3 -Delete
The XML file created by New-CIPolicy can’t be consumed by the system yet. To deploy the policy, it needs to be converted to binary format and copied to the CodeIntegrity folder under System32. Run the following cmdlet to convert the xml file:
ConvertFrom-CIPolicy C:\CI\FilePublisher.xml C:\CI\FilePublisher.bin
Deploy CI policy:
Copy-Item C:\CI\FilePublisher.bin C:\Windows\System32\CodeIntegrity\SiPolicy.p7b
Reboot the server to allow code integrity service to load the policy. I hope the default server CI policies can help you to speed up the deployment, and as always, you can share your feedback by email with us or submit and vote on requests through the User Voice.

Shielded VM local mode and HGS mode

Jian (Jane) Yan[MSFT] — Fri, 05 Jan 2018 15:24:30 GMT
With the new capability in Windows 10, version 1709, Windows Client can host shielded VMs while using remote Host Guardian Service (HGS) attestation. This caused some confusion as people stated they have already been running shielded VMs on client. This blog post is intended to clarify things and explain how to run them side by side. In Windows 10, when you create a VM, you can optionally attach a virtual TPM (vTPM) to it. It offers similar protection to the VM as a physical TPM does for the physical device. vTPM state is encrypted and the encryption key can be either stored locally (a.k.a. local mode) or stored remotely on a HGS server (a.k.a HGS mode). There are several strong security measures in HGS mode such as validating boot measurements and code integrity policies. For more information on what HGS mode measures, check out my previous blog post on Privileged Access Workstations here. The mode--local mode vs. HGS mode--is a configuration setting on the physical host so it knows where to get the key to unlock the vTPM. When the host is running in HGS mode, it will get the key from HGS server (assuming it qualifies as healthy); when the host is running in local mode, it will look for the key locally. Previously, Windows Client only supported local mode; HGS mode support was added in the Windows 10, version 1709 release. When you start the shielded VM in HGS mode, the host must get the key from HGS. If the host is not connected to the network, the shielded VM won’t start. In local mode, the key is held locally so the VM can start anytime. Using the example of a PAW’s configuration, it typically hosts one desktop VM and one PAW VM. The Desktop VM needs to run anytime, while the PAW VM should be protected by HGS. This can be done by setting the host to local mode when create and start the desktop VM and setting the host to HGS mode when create and start the PAW VM. It’s quite simple to change the setting. To set the host to local mode:
Set-HGSClientConfiguration -EnableLocalMode
To change it to HGS mode:
Set-HGSClientConfiguration -AttestationServerUrl -KeyProtectionServerUrl
If you are writing scripts, be sure to configure the host to the correct mode before creating or starting the shielded VM. Below is a sample script to create a shielded VM local mode: [snippet slug=new-shielded-vm-local-mode line_numbers=false lang=bsh] You can find the script to create remote mode shielded VM here. If you have VMs in both modes running side by side, be sure to set the host in the correct mode before create or start them. If the host is running in the wrong mode for the VM, the VM will not be able to start. You can easily correct it by setting the security policy again on the VM after you change the host mode.

Building VM template using Assigned Access

Jian (Jane) Yan[MSFT] — Thu, 30 Nov 2017 10:03:47 GMT
Since it took me a couple of attempts to create VM templates for Azure portal management and Remote Desktop (in order to make them available for the TAP evaluation), I thought it best to share the process, so you can build your own customized image. My goal is to create a PAW VM that offers user a kiosk experience which is dedicated to one application. When user connects to the VM, it only shows the Azure portal page or the RDP application, nothing else. To create a kiosk experience, I used Assigned Access. There are a few ways to configure it. I chose the Windows Configuration Designer downloaded from the Windows Store. You can follow the instructions here to create the package.
Creating provisioning package for Azure portal management
To build the Azure portal package, on the wizard page that defines the Kiosk account and app, select the App type: Classic Windows App, and the full path as %Programfiles%\Internet explorer\iexplorer.exe -k portal.azure.com (note: don’t use quotes around the string, it doesn’t work). To apply the package, simply copied the package inside the VM, which is the online approach below.
Creating provisioning package for RDP
There are two RDP apps for Windows: classic app (mstsc.exe) and Remote Desktop from store. I like the store version for its simple user experience, and choose it for the template. It turns out that I learnt quite a bit from building the package for it:

Store RDP app is not built-in, so I need to find the appx package to install it in the image. To save time, I used an internal copy. You can do this for any applications if it supports offline distribution. To install the Appx package:

Dism /add-provisionedAppxPackage /image:e:\ /PackagePath: /LicensePath: /DependecyPackagePath: Where e:\ is the mounted VHDX drive

However, when testing the image above by logon, the app is not there. Apparently, if the app is not pinned to the Start menu, it gets removed during the first user logon, so I added the app to the start menu in the unattend xml file. (For details, see the unattend file section)

Trying the same approach by applying the package online led me nowhere, that's how I learnt the offline approach, and it turns out to be a much simpler process. Because I simply modify the syspreped image without user logon, and I can skip sysprep later to make it a template.

Deploy package
As I have mentioned earlier, there are two ways to apply the (.ppkg) package:

Online: copies the package file to the VM while it’s running and applied it by simply double-clicking the .ppkg file which applied automatically. After the VM reboots, you will see the kiosk mode experience which shows IE and only connects to the Azure portal page.

To turn this into a template, you can just sysprep the image. I did this by switching to a different user (local admin) where I ran sysprep.

Offline: If you already have a syspreped image to start with, you can apply the package to the image by running

Dism /add-provisioningpackage /packagepath:ppkg file> /image=e:\ (where e:\ is the mounted VHDX file) Now the VM image can be used as the template and you can follow the previous blog post to deploy it. If you are part of the TAP program, I have also made the image available for download.
Windows unattend file
To create PAW VM, you will need a Windows unattend file. I have shared a sample copy in a previous blog post. For the RDP VM template, I added the following to pin the app in the start menu: [snippet slug=unattend-pin-rdp-in-start-menu line_numbers=false lang=bsh] If you have ideas/requests for different images, you are welcome to share it with us.

Why use shielded VMs for your privileged access workstation (PAW) solution?

Jian (Jane) Yan[MSFT] — Wed, 29 Nov 2017 09:39:54 GMT
It’s great to see customers trying out PAWs and it’s generating a lot of great questions. Many questions are related to shielded VMs so I’d like to focus this blog post on sharing our reasoning for building the PAW solution on shielded VMs. Running virtual machines (VMs) on Windows client is not new, but running a shielded VM on Windows client is. The ability to run shielded VMs on client was introduced in the Windows 10 1709 release. There are many security considerations built in to shielded VMs, from secure provisioning to protecting data at rest. As part of the PAW solution, the privileged access workload gains additional security protections by running inside a shielded VM.    There are tons of documents/videos on technet about shielded VMs, this is a good starting point. Note that this blog post is not intended to repeat the content, but rather focus on its usage from the PAW perspective.   So why shielded VMs? There are two aspects to this question:

Why do we want to use VMs? (as opposed to dedicated physical PAW devices )?

What are the security benefits when running a shielded VM over a regular VM?

The use of VMs reduces the number of devices per user. In most environments where PAW is deployed, its user must carry at least 2 devices; in some cases, 5 or more (based on customer feedback). By using VMs, a user can carry just one device with all their workloads and the PAW itself running in different isolated VMs.   Admins also have an easier time managing the VM images as the images can be more tailored to a specific role. For example, the PAW VM used by Domain Admins to manage Active Directory will differ from the VM image that SQL admins use allowing each to be locked down in ways specific to its role. If there is a need for new applications, admins can easily create new VM images.   Furthermore, you can harden the OS on the physical machine when all the workloads are moved to VMs. Using application whitelisting (such as a code integrity policy), the physical machine can be further locked down allowing it to run only authorized VMs.   Let’s dive into the second question about the security benefits of using shielded VMs. It starts with enforcing higher security requirements on the physical PAW itself through remote health attestation:

The physical device must have TPM version 2.0. The endorsement key from the TPM is used as a strong form of device identity;

The TPM is also used in measured boot to ensure that the security configuration and the binaries loaded in the boot process match the approved (healthy) baseline configuration;

Finally, the code integrity policy is also measured and validated against the policy managed by the Host guardian service.

If the device itself is compromised, any changes to operating system binaries or the code integrity policy will cause it to fail attestation and prevent VMs from running. In short, shielded VM security starts with a clean, trustworthy host as illustrated below: In addition to the host remote health attestation, shielded VMs use a virtual TPM to encrypt data through Bitlocker. If the physical device is compromised, the virtual disks are encrypted and the attacker will either have to find a way to break BitLocker encryption or compromise the Host guardian service in the datacenter; neither is trivial. A typical process to create a VM is to simply attach a copy of a VHDX which contains the appropriate operating system. In a production deployment, admins usually create syspreped images and distribute the images through file shares. At deployment time, however, there is no guarantee that the VHDX file the admin created hasn’t been tampered with. Shielded VMs add security measures to detect images that have been tampered with and prevent deployment. Admins create a signature (.vsc files) for each trustworthy VHDX. The signature is included in the encrypted shielding data files (.pdk files) and used to check the VHDX during provisioning. If the VHDX’s current signature doesn’t match, VM provisioning will fail. Shielding data files are unique to shielded VM provisioning and you can find more information here. Therefore, to create a PAW VM, you will need to have a shielding data file and a VM template disk with a matching or trusted signature. You can find the steps to create shielding data files here. In my next blog post, I will share how I built a couple of PAW VM template. If you have ideas/requests, you are welcome to share it with us.

Improved branch office support for shielded VMs in Windows Server, version 1709

Ryan Puffer — Wed, 15 Nov 2017 09:00:02 GMT
Companies with large branch offices often must make a tradeoff between user experience and security. To increase employee productivity, it may make sense to deploy replicas of certain applications like Active Directory Domain Controllers or file servers in a branch office. But with limited — if any — IT resources at the remote location, how can you ensure your data is secure? This is where shielded virtual machines come to the rescue! Shielded VMs allow you to encrypt the data of virtual machines to prevent someone with access to the Hyper-V server from accessing your sensitive data. To ensure the Hyper-V host is trusted to run your VM, it needs to prove to the Host Guardian Service (HGS) that it is configured as-expected and retrieve the keys needed to start up your shielded VM. Typically, HGS would reside in your primary datacenter where it can be better protected and managed by your security team. With Windows Server, version 1709, we’ve made it easier to support branch offices with poor WAN links back to the main datacenter. This is done by installing a virtualized HGS server in the branch office. To run a local copy of HGS in a branch office, you would want to shield it to protect the key material from being stolen. But how do you bootstrap the first shielded HGS server? It needs another HGS to release its keys. That’s why we’ve introduced fallback URLs in Hyper-V to allow your Hyper-V server to prefer a local HGS server and fall back to your main datacenter’s HGS in case the local server is offline. This blog post explains the recommended architecture for setting up HGS in a branch office scenario.
Recommended Architecture
To set up a branch office HGS, follow these high-level steps:

Ensure your main datacenter's HGS cluster is installed and operational. For more information, read our HGS deployment instructions.

Ensure your branch office has at least one Hyper-V host running Windows Server, version 1709 or higher and network connectivity to your main datacenter. Register your branch office Hyper-V host with your main datacenter's HGS cluster by following our guarded host deployment instructions. At this point, since you only have one HGS cluster, the Hyper-V host should use the datacenter's HGS server as the primary HGS server.

Deploy a new shielded VM running Windows Server 2016 on your branch office Hyper-V server. This will become your branch office HGS server. Note that while the Hyper-V host must run Windows Server, version 1709, we recommend using Windows Server 2016 for the HGS servers.

Configure the new shielded VM as an HGS server following our HGS deployment instructions. This HGS server should not join the existing HGS cluster, nor should it use the same certificates as the main datacenter's HGS servers. You can, however, join the new HGS server to the same Active Directory domain, if desired. You can optionally add more HGS servers in the branch office for resiliency, but since you have the main datacenter as a fallback option, you may only need one HGS server running in the remote office.

Register the Hyper-V host (and any others in your branch office) with your new HGS server. Be sure to keep both the branch office HGS and main datacenter HGS servers updated with your latest Hyper-V host attestation information. Your operations team should ensure both servers get updated whenever a Hyper-V host configuration changes in the branch office.

Reconfigure the Hyper-V host to use the new branch office HGS server as its primary HGS server and the main datacenter's HGS server as a fallback with Set-HgsClientConfiguration. Details on how to do this are included at the end of the blog post.

Finally, deploy the rest of your shielded VMs in the branch office. It is recommended that you configure those VMs with the guardians of both the branch office and main datacenter HGS servers so that either HGS can start them up.

You can repeat these steps for each branch office you want to configure. In general, we have three core recommendations for branch office deployments:

Every branch should use a different HGS cluster with unique certificates. Don't join the branch office HGS nodes to the primary datacenter's HGS cluster.

Keep the attestation policies in sync between the primary datacenter and branch office HGS nodes. If the branch office HGS goes down, your Hyper-V host will need to pass attestation with your main datacenter's HGS.

For the best resiliency, configure every shielded VM at the branch office to authorize both the branch office and main datacenter HGS guardians to decrypt the VM. The branch office HGS servers must always allow the main datacenter HGS to start them up. For example, the VMs in your branch office may be configured such that:

The shielded HGS server is configured with an owner guardian (central IT) and one additional guardian for the main datacenter HGS

An application server shielded VM is configured with an owner guardian (business group IT) and two additional guardians, one for the shielded HGS server running in the branch office and one for the main datacenter in case the branch office HGS is offline.

Configuring fallback URLs in Hyper-V
To use the new fallback functionality, you will need to use Hyper-V on Windows Server, version 1709. Read more about the semi-annual channel to decide if upgrading to version 1709 is right for you. You will need the URLs for both your primary (typically, the branch office HGS) and fallback (main datacenter) servers to continue. Once you have them, run the following command in PowerShell on the Hyper-V host to configure the URLs: (Don't forget to swap "primaryhgs" and "fallbackhgs" for your own DNS names!)
Set-HgsClientConfiguration -KeyProtectionServerUrl https://primaryhgs/KeyProtection -AttestationServerUrl https://primaryhgs/Attestation -FallbackKeyProtectionServerUrl https://fallbackhgs/KeyProtection -FallbackAttestationServerUrl https://fallbackhgs/Attestation
You can check if your Hyper-V host is passing attestation by using Test-HgsClientConfiguration:
Test-HgsClientConfiguration -UsePrimary Test-HgsClientConfiguration -UseFallback
If you are no longer using a fallback HGS server, you can remove it by using Set-HgsClientConfiguration without fallback URLs:
Set-HgsClientConfiguration -KeyProtectionServerUrl https://primaryhgs/KeyProtection -AttestationServerUrl https://primaryhgs/Attestation

When is a fallback server used?
Hyper-V will only use a fallback HGS server if it is configured with fallback URLs and the primary HGS server is unreachable or returns another non-transient error. A common example of this would be if the primary HGS servers were offline, resulting in the host being unable to establish a connection. The Hyper-V host will try to contact the primary HGS server a second time before moving to the fallback URL after a maximum of 120 seconds without a response. It will always try to use the primary URL first, even if it just used the fallback URL for its last attestation attempt or key unwrapping. If Hyper-V can reach the primary HGS server, but fails attestation or receives another terminating response, it will not attempt the fallback URL. You can monitor the Microsoft-Windows-HostGuardianService-Client/Operational event log for event ID 2021 on a Hyper-V host to see when a fallback server is in use. We hope you'll find this fallback feature helpful when you're trying to secure your branch office IT. As always, if you have any questions, reach out to us at shieldedvmfeedback@microsoft.com.

How to deploy a VM template for PAW

Jian (Jane) Yan[MSFT] — Wed, 01 Nov 2017 12:54:59 GMT
Continuing with the PAW series, after you followed the previous blog to build the PAW device, you can now deploy PAW VMs on it. There are two types of VMs you can create:

Desktop VM: this is a standard VM, dedicated for user productivity workload. It is typically joined to your org production domain. You can use the same image for deploying the user desktop for this VM.

PAW VM: this is a shielded VM, used for secure workload, such as server administration. This image needs to be prepared, such that, any tampering to the image will render the image invalid, and fail to deploy new VMs. The image should contain all the applications, and the OS can be locked down to run only those applications.

If you are part of the PAW TAP program, you can download a couple of templates I created for evaluation. This blog post walks you through step-by-step on how to deploy a shielded VM template on a PAW device. Important: you will need a different machine (physical or virtual) to create the template disk and other necessary files. The machine should run Windows 10 1709 client. You can download and installed the RSAT package from here, make sure you select this file: WindowsTH-RSAT_WS2016-x64.msu. (Note that WindowsTH-RSAT_WS_1709-*.msu package will not work). Once RSAT is installed, these features are added in the start menu: Template Disk Wizard and Shielding Data File Wizard. You can use the Template Disk Wizard to create the VM template disk, and the Shielded Data File Wizard to create the PDK file.
Pre-requisites
You need a template disk created by following this article, which provides the details of how the template disk works to prevent any tampering. The section "Sign and protect the VHDX with the template disk wizard" in the article has the instructions of how to build a template disk. For convenience, below is a short description on how to create a template disk from a syspreped OS image. You can either use the Template Disk Wizard, or run the following PowerShell commands :
$cert = New-SelfSignedCertificate -DnsName 'signing.contoso.com'

Protect-TemplateDisk -Path ‘C:\PAWVM.vhdx’ -TemplateName "PAWTemplate" -Version 1.0.0.1 -Certificate $cert

Creating shielding data file (PDK)
The shielding data file is an encrypted file that the admin creates to protect sensitive information used during deployment, such as user passwords. When provisioning a shielded VM, it requires this file. If you are not familiar with the concept of shielding data file, you can find more details here. This section illustrates the process specific for a PAW solution.
Prepare necessary files
The PAW PDK files requires the following files:

HGS Guardian

Windows Unattend file

Template disk volume signature

HGS guardian
HGS guardian contains the public key used to encrypt the data on the PAW device. You will need to retrieve the information from the HGS server which the PAW device is attested to. You can run the following PowerShell command on any machine that can connect to the HGS server:
Invoke-WebRequest https://FQDN>/KeyProtection/service/metadata/2014-07/metadata.xml -OutFile C:\HGSGuardian.xml
If you are using the TAP evaluation image, you can get the PartnerPAWPoCGuardian,xml file from the Yammer group.
Windows Unattend file
Unattend file is critical for provisioning a Shielded VMs, where the VM can only be connected through RDP. In testing, I recommend using Encryption supported policy. You can find the differences between Encryption supported and shielded on "Security level for VMs". Unattend file varies slightly from different Windows released versions, to make it easy, we created a base unattend file and a cmdlet which can modify it based on the Windows version you want to run. You can get the module from the Powershell Gallery. I attached a copy of sample unattend for Windows client 1709 Enterprise at the end of the blog post, make sure you modify it before use it.
Template disk volume signature
At deployment time, the template disk will be checked against the signature to validate its integrity. If the template has been tampered with, PAW VM creation will fail. The template disk volume signature file captures the disk signature and package it into the PDK file. You can run the following cmdlet to create the template disk volume signature file: Save-VolumeSignatureCatalog -TemplateDiskPath -VolumeSignatureCatalogPath As part of TAP, you can download the vsc files through the Yammer group. Be sure the include the right VSC file for the matching template VHDX file, otherwise, VM creation will fail.
Create PDK
You can use the Shielding Data File Wizard to create the PDK file, or using the following cmdlet: [snippet slug=new-paw-pdk line_numbers=false lang=bsh]
Create PAW VM
Copy the template disk VHDX and the PDK file on the PAW device in the same folder, and run the PAWClientApp to create the VM. You can see the video on how its done here: [video width="1620" height="1080" mp4="https://msdnshared.blob.core.windows.net/media/2017/11/CreateVM.mp4"][/video] If you are using the TAP images, you should place the template disk on the D drive, and make sure you open the Storage setting page of the PAWClientApp, and change the default a location on D. If you don't have the PAWClientApp, we are releasing a cmdlet module in a couple of weeks to make the shielded VM creation easy.
Conclusion
As always, you feedback and questions will help us to make this better. Feel free to share your comment below or email us.
Appendix - Sample unattend.xml
[snippet slug=sample-windows-client-1709-unattended line_numbers=false lang=xml]

	Physical host	Desktop VM	PAW VM
Logon user identity	ESAE domain user	Production domain user	Privileged account for backend management
Logon method	Windows Hello for business Smartcard	Smartcard	Smartcard (Note: Hello for business is not supported for VMs today)
Connect	Interactive logon RDP is disabled	VMConnect or Mstsc	RDP over VMBus

	VMConnect (enhanced mode)	RDP
Transport	VMBus, which doesn’t require any network ports to be opened	Requires open RDP firewall port to allow it
User permission	Hyper-V admin on the host	Standard user on the host; user must be in the Remote desktop user group in the VM