Data Center Security articles Data Center Security articles Tue, 26 Oct 2021 05:48:51 GMT DataCenterSecurity 2021-10-26T05:48:51Z Awareness: Update HGS policies after installing the February 2020 security update <P><FONT color="#DC381F"><STRONG>2/17/2020 update: </STRONG>KB4524244 has been removed from the Windows Update catalog and will not be re-offered (more info in the <A href="#" target="_self">release notes</A>). For customers who already installed KB4524244 or any other OEM or Windows update that changes your Secure Boot configuration, the guidance below still applies.</FONT></P> <HR /> <P>Users of the Host Guardian Service (HGS) for shielded VMs or SQL Server Always Encrypted with Secure Enclaves should be aware that the <A href="#" target="_self">February 2020 Security Update (KB4524244)</A>&nbsp;for Windows 10 and Windows Server may cause your guarded hosts or SQL Servers to fail attestation. You won't want to get caught by this in production, so read on to learn more about the update, how to prepare for the change, and best practice guidance for handling updates in production environments.</P> <P>&nbsp;</P> <H3><STRONG>What's special about the February 2020 security update?</STRONG></H3> <P>The February 2020 security update&nbsp;"<SPAN>addresses an issue in which a third-party Unified Extensible Firmware Interface (UEFI) boot manager might expose UEFI-enabled computers to a security vulnerability."&nbsp;It does this by updating your Secure Boot configuration to block the vulnerable boot manager. While updates to the Secure Boot configuration are rare, they are important to protect the integrity of the pre-OS boot process.</SPAN></P> <P>&nbsp;</P> <P>You normally wouldn't even notice that the Secure Boot configuration has been updated, but it's one of many measurements HGS analyzes when a machine attests in TPM mode. HGS compares the machine's current Secure Boot configuration (measured by the TPM) with the list of trusted baselines registered on HGS. Baselines captured before the February 2020 security update is installed will have the old Secure Boot configuration in them, so when an updated machine tries to attest, HGS will notice the discrepancy and flag the machine as unhealthy. This is the intended behavior, since a change to the Secure Boot configuration could indicate someone is trying to allow other, potentially compromised, boot managers to run on your computer. In the case of KB4524244, however, the updated Secure Boot configuration helps improve your security, so you'll want to capture a new baseline that includes the new configuration and register it as a trusted baseline with HGS.</P> <P>&nbsp;</P> <H3><STRONG>Who's affected?</STRONG></H3> <P>The changes included in KB4524244 will only affect attestation if <U>all</U> the following apply to your environment:</P> <OL> <LI>You are using HGS in TPM attestation mode.</LI> <LI>You captured and registered the TPM baseline for your host(s) before installing KB4524244.</LI> <LI>You later install KB4524244 and reboot the machine to apply the update.</LI> </OL> <P>The best indication that your attestation failure is a result of the Secure Boot configuration update is if your&nbsp;<STRONG>AttestationSubstatus = SecureBootSettings</STRONG>. You can get this information by running <FONT face="courier new,courier"><STRONG>Get-HgsClientConfiguration</STRONG></FONT> on the machine attesting with HGS. If this cmdlet returns other substatus values, check out our <A href="#" target="_self">troubleshooting guide</A> for more information.</P> <P>&nbsp;</P> <PRE>PS C:\&gt; Get-HgsClientConfiguration<BR />IsHostGuarded : False<BR />Mode : HostGuardianService<BR />KeyProtectionServerUrl :<BR />AttestationServerUrl :<BR />AttestationOperationMode : Tpm<BR />AttestationStatus : InsecureHostConfiguration<BR />AttestationSubstatus : SecureBootSettings</PRE> <P>&nbsp;</P> <H3><STRONG>Recommended update process</STRONG></H3> <P>Microsoft recommends installing the February 2020 security update on all of your machines. To ensure a smooth rollout and avoid downtime for your shielded VMs or SQL Servers, it's recommended to apply the update and configure HGS in the following order:</P> <P>&nbsp;</P> <OL> <LI>Isolate one of your machines to perform the initial update on. This machine will have temporary downtime, so make sure to move any production workloads off it first. You can also use a pre-prod environment machine if it has the same hardware configuration as your production servers.<BR /><BR /></LI> <LI>Run <STRONG><FONT face="courier new,courier">Get-HgsClientConfiguration</FONT></STRONG> to confirm it is passing attestation with HGS. You only want to capture an updated baseline on a known-good machine.<BR /><BR /></LI> <LI>Install KB4524244 on the machine and reboot it.<BR /><BR /></LI> <LI>Run <STRONG><FONT face="courier new,courier">Get-HgsClientConfiguration</FONT></STRONG> again and see if it fails with <STRONG>AttestationSubstatus = SecureBootSettings</STRONG>. If it still passes attestation, the Secure Boot configuration may not have been applied yet. Wait a few minutes then reboot the machine again. Don't proceed until the attestation starts failing.<BR /><BR /></LI> <LI>With the update applied, run the following command in an elevated PowerShell console:<BR /><STRONG><FONT face="courier new,courier">Get-HgsAttestationBaselinePolicy -Path .\Post-KB4524244.tcglog</FONT></STRONG><BR /><BR /><EM>Tip: if you're running SQL Server in a VM, you may see an error saying the IOMMU is not available. Re-run the above command with <STRONG><FONT face="courier new,courier">-SkipValidation</FONT></STRONG> at the end to bypass this check.<BR /><BR /></EM></LI> <LI>Copy the file to your HGS server, then register it with the following PowerShell command:<BR /><STRONG><FONT face="courier new,courier">Add-HgsAttestationTpmPolicy -Name Post-KB4524244 -Path .\Post-KB424244.tcglog<BR /><BR /></FONT></STRONG><EM>Tip: if you're registering a Windows Server 2016 Hyper-V host with a Windows Server 2019 HGS server, make sure to add <STRONG><FONT face="courier new,courier">-PolicyVersion v1</FONT></STRONG> to the end of the above command.<BR /><BR /></EM></LI> <LI>Back on the machine where you captured the new baseline policy, run&nbsp;<FONT face="courier new,courier"><STRONG>Get-HgsClientConfiguration</STRONG></FONT> again. It should pass attestation.<BR /><BR /></LI> <LI>The baseline policy will allow machines with the same hardware and software configuration to attest successfully. If you run a heterogeneous fleet (different hardware vendors, different generations of hardware, or different OS versions), repeat steps 1-7 for each unique hardware-software configuration. Generally, you'll need an updated baseline for each baseline you already registered with HGS. Use&nbsp;<FONT face="courier new,courier"><STRONG>Get-HgsAttestationPolicy -PolicyType SecureBootSettings</STRONG></FONT> to see all baselines registered with HGS.<BR /><BR /></LI> <LI>Once all the unique configurations have been registered with HGS, you can roll out KB4524244 to your other machines and they should experience a seamless update.<BR /><BR /></LI> <LI>Finally, once all machines have been updated and rebooted, you can disable or remove the old baseline policies from HGS so computers without the Secure Boot configuration update aren't marked as healthy. See <A href="#" target="_self">Disable-HgsAttestationPolicy</A> and <A href="#" target="_self">Remove-HgsAttestationPolicy</A> for more information.</LI> </OL> <P>&nbsp;</P> <H3><STRONG>General update guidance</STRONG></H3> <P>TPM attestation with HGS provides strong assurances about the security of your servers. It's recommended that you always test any software or hardware updates in an isolated, pre-production environment before rolling the changes out to all machines. This will help you catch any changes that cause attestation to fail and give you time to prepare new baseline or code integrity policies to trust those changes.</P> <P>&nbsp;</P> Mon, 17 Feb 2020 20:36:51 GMT RyanWillis 2020-02-17T20:36:51Z What is new in Windows 10 1803 for PAW? <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Jun 08, 2018 </STRONG> <BR /> In this blog post, I’ll walk you through the new features which are relevant to the <A href="#" target="_blank"> PAW solution </A> in the latest Windows 10 1803 release. <BR /> <H2> Offline HGS </H2> <BR /> 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 <A href="#" target="_blank"> here </A> . <BR /> <H2> Lock PAW VM to the device </H2> <BR /> 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. <BR /> New-ShieldingDataFile [-ShieldingDataFilePath] &lt;string&gt; [-Owner] &lt;Guardian&gt; [-VolumeIDQualifier]&nbsp;&lt;VolumeIDQualifier[]&gt; [-AnswerFile] &lt;NamedFileContent&gt; [[-OtherFile] &lt;NamedFileContent[]&gt;] [[-Guardian] &lt;Guardian[]&gt;] [-Policy {Shielded | EncryptionSupported}] <STRONG> [- </STRONG> <STRONG> BindToHostTpm </STRONG> <STRONG> &lt;bool&gt; </STRONG> ] [-WhatIf] [-Confirm]&nbsp; [&lt;CommonParameters&gt;] <BR /> 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. <BR /> <H2> VMConnect to shielded VM </H2> <BR /> 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. <BR /> <H2> Get VM EKpub from the device host </H2> <BR /> 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 <A href="#" target="_blank"> TPM key attestation </A> . 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. &nbsp;The event gets generated every time the shielded VM powered on. <BR /> <H2> Conclusion </H2> <BR /> 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. </BODY></HTML> Fri, 15 Mar 2019 23:17:11 GMT Jian (Jane) Yan 2019-03-15T23:17:11Z PAW deployment guide <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Apr 30, 2018 </STRONG> <BR /> After running the PAW TAP program on the solution explained in this <A href="#" target="_blank"> blogpost </A> , 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. <BR /> <BR /> 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 <A href="#" target="_blank"> whitepaper </A> which provides a much more comprehensive view. Even on the PAW topic, the <A href="#" target="_blank"> whitepaper </A> 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. <BR /> <H2> Solution overview </H2> <BR /> 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. <BR /> <BR /> 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: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> A common misconception about PAW is “the device which the admin connects to, to get to the backend server&nbsp; (PAW?)”; in fact, PAW is the device which admin uses with physical keyboard and mouse.&nbsp; Consider the following diagram, PAW is commonly considered to be the device in the middle: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> 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. <BR /> <H2> Infrastructure deployment </H2> <BR /> When we designed the solution, one criteria is to fit it into the existing deployment. If you are familiar with the <A href="#" target="_blank"> EASE </A> , this is the model we tested to with the solution. <BR /> <BR /> 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 <A href="#" target="_blank"> here </A> . <BR /> <BR /> <IMG src="" /> <BR /> <BR /> 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: <BR /> <UL> <BR /> <LI> 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; </LI> <BR /> <LI> PAW VM is dedicated to manage a certain datacenter assets, it should be placed in the same secure bastion forest as the host; </LI> <BR /> <LI> The desktop VM should be managed like all other user desktop machines, which joins to the production domain. </LI> <BR /> </UL> <BR /> A few other infrastructure services are necessary for PAW but not dedicated for PAW: <BR /> <UL> <BR /> <LI> WDS: service to image the PAW devices </LI> <BR /> <LI> SCCM: manage/configure PAW devices </LI> <BR /> <LI> Monitoring service </LI> <BR /> <LI> VPN server </LI> <BR /> <LI> WSUS for patch management </LI> <BR /> </UL> <BR /> Some services Azure offers alternative to, such as <A href="#" target="_blank"> ATP </A> which can do better security monitoring using a large database tracking many attack signatures. <BR /> <BR /> 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. <BR /> <H2> PAW device configuration </H2> <BR /> From end user perspective, the solution looks like: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> A single device with multiple VMs running on it, with the following software/hardware requirements: <BR /> <UL> <BR /> <LI> 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. </LI> <BR /> <LI> The device must have TPM2.0, running UEFI with secure boot enabled. </LI> <BR /> <LI> Recommending memory 16GB or above; hard disk is 500GB and above to support multiple VMs. </LI> <BR /> </UL> <BR /> <H2> Storage </H2> <BR /> 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 <A href="#" target="_blank"> here </A> for more options on Bitlocker management. <BR /> <BR /> The storage is partitioned as the following: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> 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. <BR /> <BR /> <BR /> <H2> Network </H2> <BR /> 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.&nbsp; 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&nbsp; can download the cmdlet module <A href="#" target="_blank"> here </A> to create additional VM INS switches. <BR /> <BR /> 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 ( <A href="#" target="_blank"> WDAG </A> ). <BR /> <BR /> You can use group policy settings to configure WDAG, in my testing, I’ve configured the following settings on the host: <BR /> <UL> <BR /> <LI> Enable WDAG (Computer configuration\Administrative Templates\Windows Components\Windows Defender Application guard) </LI> <BR /> </UL> <BR /> <IMG src="" /> <BR /> <BR /> 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. <BR /> <UL> <BR /> <LI> Configure network isolation policy (Computer configuration\Administrative Templates\Network\Network Isolation) </LI> <BR /> </UL> <BR /> <IMG src="" /> <BR /> <BR /> The highlighted policy is the setting you can whitelist Urls. You can find more reference on how to configure the policy <A href="#" target="_blank"> here </A> . On my PAW device, I configured the following value for this policy: <EM> </EM> (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. <BR /> <BR /> 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. <BR /> <UL> <BR /> <LI> Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hns\Parameters </LI> <BR /> <LI> Name: ICSFlags </LI> <BR /> <LI> Type: DWORD </LI> <BR /> <LI> Value: 1 </LI> <BR /> </UL> <BR /> Note: Reboot the machine after the change. <BR /> <BR /> Also, this VPN behavior will be improved in the future release. <BR /> <H2> VM management </H2> <BR /> 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 <A href="#" target="_blank"> GuardedFabricTools </A> our team released in the Gallery. <BR /> <H2> Host user start menu customization </H2> <BR /> 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: <BR /> <EM> &lt;LayoutModificationTemplate xmlns:defaultlayout="<A href="#" target="_blank"></A>" xmlns:start="<A href="#" target="_blank"></A>" Version="1" xmlns="<A href="#" target="_blank"></A>"&gt; </EM> <BR /> <EM> &lt;LayoutOptions StartTileGroupCellWidth="6" /&gt; </EM> <BR /> <EM> &lt;DefaultLayoutOverride&gt; </EM> <BR /> <EM> &lt;StartLayoutCollection&gt; </EM> <BR /> <EM> &lt;defaultlayout:StartLayout GroupCellWidth="6"&gt; </EM> <BR /> <EM> &lt;start:Group Name="PAW"&gt; </EM> <BR /> <EM> &lt;start:Tile </EM> <EM> AppUserModelID="Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge" </EM> <BR /> <EM> Size="2x2" </EM> <BR /> <EM> Column="0" </EM> <BR /> <EM> Row="0"/&gt; </EM> <BR /> <EM> &lt;start:DesktopApplicationTile </EM> <EM> DesktopApplicationLinkPath="D:\PawFiles\bin\StartProgram\VMManager.lnk" </EM> <BR /> <EM> Size="2x2" </EM> <BR /> <EM> Column="2" </EM> <BR /> <EM> Row="0"/&gt; </EM> <BR /> <I> &lt;start:DesktopApplicationTile </I> <EM> DesktopApplicationID="{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WindowsPowerShell\v1.0\powershell.exe" </EM> <BR /> <EM> Size="2x2" </EM> <BR /> <EM> Column="4" </EM> <BR /> <EM> Row="0"/&gt; </EM> <BR /> <I> </I> <I> &lt;/start:Group&gt; </I> <BR /> <EM> &lt;/defaultlayout:StartLayout&gt; </EM> <BR /> <EM> &lt;/StartLayoutCollection&gt; </EM> <BR /> <EM> &lt;/DefaultLayoutOverride&gt; </EM> <BR /> <EM> &lt;/LayoutModificationTemplate&gt; </EM> <BR /> You can save the content above to an xml file (startmenu.xml), and use group policy to apply it: <BR /> <BR /> <STRONG> Computer Configuration </STRONG> &gt; <STRONG> Administrative Templates </STRONG> &gt; <STRONG> Start Menu and Taskbar </STRONG> <BR /> <BR /> Enable the Start Layout policy and specify the startmenu.xml file full path. Check the <A href="#" target="_blank"> docs </A> for more details. <BR /> <BR /> 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 <A href="#" target="_blank"> here </A> . <BR /> <H2> Image rollout </H2> <BR /> Windows 10 has a number of security features which can better protect the operating system. I wrote a separate blog <A href="#" target="_blank"> post </A> 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 <A href="#" target="_blank"> clean source principle </A> : <BR /> <UL> <BR /> <LI> Windows Deployment Server (WDS): you can first build the host OS iso image using <A href="#" target="_blank"> MDT </A> (Microsoft deployment toolkit), then using the WDS to enable device to install the image; </LI> <BR /> <LI> 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. </LI> <BR /> </UL> <BR /> 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. <BR /> <BR /> 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. <BR /> <H2> VM provisioning </H2> <BR /> You will need shielded VM templates to provision the PAW VMs. Template creation is a separate topic covered <A href="#" target="_blank"> here </A> , and I also shared an <A href="#" target="_blank"> example </A> of creating PAW VMs with Kiosk experience. <BR /> <BR /> Once you have created the templates, you can store it centrally, and download it to the PAW device for PAW VM provisioning. <BR /> <BR /> 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. <BR /> <H2> Logon and Connect </H2> <BR /> 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: <BR /> <TABLE> <TBODY><TR> <TD> </TD> <TD> Physical host </TD> <TD> Desktop VM </TD> <TD> PAW VM </TD> </TR> <TR> <TD> Logon user identity </TD> <TD> ESAE domain user </TD> <TD> Production domain user </TD> <TD> Privileged account for backend management </TD> </TR> <TR> <TD> Logon method </TD> <TD> <BR /> <UL> <BR /> <LI> Windows Hello for business </LI> <BR /> <LI> Smartcard </LI> <BR /> </UL> <BR /> </TD> <TD> Smartcard </TD> <TD> Smartcard <BR /> <BR /> (Note: Hello for business is not supported for VMs today) </TD> </TR> <TR> <TD> Connect </TD> <TD> <BR /> <UL> <BR /> <LI> Interactive logon </LI> <BR /> <LI> RDP is disabled </LI> <BR /> </UL> <BR /> </TD> <TD> VMConnect or Mstsc </TD> <TD> <A href="#" target="_blank"> RDP over VMBus </A> </TD> </TR> </TBODY></TABLE> <BR /> Old fashion user name/password still works for all the connections, but they are less secure comparing to smartcard or Windows Hello for business. <BR /> <H2> Conclusion </H2> <BR /> 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 </BODY></HTML> Fri, 15 Mar 2019 23:17:02 GMT Jian (Jane) Yan 2019-03-15T23:17:02Z Apply Code Integrity Policy without reboot <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Apr 27, 2018 </STRONG> <BR /> There is a new Code Integrity policy option introduced in Windows 10, and it is available in Windows Server 2019 insider build “ <A href="#" target="_blank"> Update Policy No Reboot </A> ”. I got numerous questions around how to use this option, and here is the blogpost to answer it. <BR /> <H2> What is this option? </H2> <BR /> 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. <BR /> <BR /> 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. <BR /> <BR /> This option is not recommended on the <A href="#" target="_blank"> Guarded Fabric </A> 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. <BR /> <H2> How to apply it? </H2> <BR /> Let’s use an example to illustrate the process. <BR /> <BR /> I have s server which is governed by a CI policy (CI.old), in this policy, it has the option enabled: <BR /> &lt;Rule&gt; <BR /> &lt;Option&gt;Enabled:Update Policy No Reboot&lt;/Option&gt; <BR /> &lt;/Rule&gt; <BR /> 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: <BR /> Invoke-CimMethod -Namespace root/microsoft/Windows/CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{ FilePath = 'C:\sipolicy.p7b' } <BR /> 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. <BR /> <BR /> Note: this cmdlet for applying new CI policy may change in the new release of Windows (post 1804 release) <BR /> <BR /> </BODY></HTML> Fri, 15 Mar 2019 23:15:49 GMT Jian (Jane) Yan 2019-03-15T23:15:49Z Connect to Virtual Machines (VMs) on PAW <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Apr 12, 2018 </STRONG> <BR /> Continuing the PAW <A href="#" target="_blank"> series </A> , this blog post discusses the options to connect to the VMs running on the PAW device. <BR /> <BR /> In Windows, you can connect to a locally running VM using: <BR /> <UL> <BR /> <LI> VMConnect (basic mode or enhanced mode) </LI> <BR /> <LI> RDP using mstsc.exe (classic RDP client) </LI> <BR /> <LI> RDP using the Remote Desktop app from Store (modern RDP client) </LI> <BR /> <LI> RDP over VMBus (this is done by creating a special RDP file, shown later in the doc) </LI> <BR /> </UL> <BR /> In addition, it’s quite straightforward to develop a customized RDP app using the inbox <A href="#" target="_blank"> RDP ActiveX control </A> . 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. <BR /> <BR /> 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. <BR /> <BR /> 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. <BR /> <BR /> 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: <BR /> <TABLE> <TBODY><TR> <TD> </TD> <TD> VMConnect (enhanced mode) </TD> <TD> RDP </TD> </TR> <TR> <TD> Transport </TD> <TD> VMBus, which doesn’t require any network ports to be opened </TD> <TD> Requires open RDP firewall port to allow it </TD> </TR> <TR> <TD> User permission </TD> <TD> Hyper-V admin on the host </TD> <TD> Standard user on the host; user must be in the Remote desktop user group in the VM </TD> </TR> </TBODY></TABLE> <BR /> In addition, there are advantages of using RDP as it has more functionalities over VMConnect, to name a couple: <BR /> <OL> <BR /> <LI> Select a subset monitors for VM connection (for example, use 2 out of the 3 monitors connected to the device) </LI> <BR /> <LI> Video device pass through </LI> <BR /> </OL> <BR /> 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". <BR /> <H2> RDP over VMBus </H2> <BR /> This is done by creating an RDP file with the following configuration: <BR /> <BR /> <EM> pcb:s:11111111-1111-1111-1111-111111111111;EnhancedMode=1 </EM> <BR /> <BR /> <EM> full address:s:localhost </EM> <BR /> <BR /> <EM> server port:i:2179 </EM> <BR /> <BR /> where 11111111-1111-1111-1111-111111111111 is the VM ID on the host. <BR /> <BR /> 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. <BR /> <H2> RDP file sample </H2> <BR /> 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".&nbsp;Below is the RDP file I used for my desktop VM as an example, you can find the setting references <A href="#" target="_blank"> here </A> . <BR /> <BR /> [snippet slug=rdp-file-sample line_numbers=false lang=bsh] <BR /> <BR /> If you would like to share desired user experience or report issues using PAW, feel free to reach us <A> here </A> . </BODY></HTML> Fri, 15 Mar 2019 23:15:46 GMT Jian (Jane) Yan 2019-03-15T23:15:46Z Default Code Integrity policy for Windows Server <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Mar 10, 2018 </STRONG> <BR /> After Windows Defender Application Control (WDAC, formerly known as Code Integrity) was released in Windows Server 2016, I wrote a <A href="#" target="_blank"> blog post </A> on it, it was a very effective way to do application whitelisting, and get secure! <BR /> <BR /> 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. <BR /> <BR /> Those policies are stored under “C:\Windows\schemas\CodeIntegrity\ExamplePolicies” on any Windows OS post 1709 release. I recommend two policies for Windows Server: <BR /> <BR /> <STRONG> AllowMicrosoft </STRONG> : 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. <BR /> <BR /> <STRONG> DefaultWindows </STRONG> : 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. <BR /> <BR /> There are known applications in Windows that might be used to bypass WDAC, the full list is published on this <A href="#" target="_blank"> page </A> . 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. <BR /> <BR /> 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: <BR /> <BR /> <A href="#" target="_blank"> AllowMicrosoft_DenyBypassApps_Audit.xml </A> <BR /> <BR /> <A href="#" target="_blank"> DefaultWindows_DenyBypassApps_Audit.xml </A> <BR /> <BR /> One of the new rule options in the above policy file is “ <A href="#" target="_blank"> Update policy no reboot </A> ”. 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. <BR /> <H2> Adding additional publishers </H2> <BR /> 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: <BR /> <OL> <BR /> <LI> <STRONG> Adding publisher </STRONG> : 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: </LI> <BR /> </OL> <BR /> New-CIPolicy -FilePath &lt;appCI.xml&gt; -Level Publisher -ScanPath &lt;the path which the app is installed&gt;&nbsp; -UserPEs <BR /> <OL> <BR /> <LI> <STRONG> Adding FilePublisher </STRONG> : 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: </LI> <BR /> </OL> <BR /> New-CIPolicy -FilePath &lt;appCI.xml&gt; -Level FilePublisher -ScanPath &lt;the path which the app is installed&gt;&nbsp; -UserPEs <BR /> You can mix and match different applications (from different vendors) with the two approaches described above. <BR /> <BR /> 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. <BR /> <BR /> 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. <BR /> <H2> Merge CI policies </H2> <BR /> 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: <BR /> Merge-CIPolicy -OutputFilePath ‘Serverdefault-audit.xml’ -PolicyPaths ‘.\AllowMicrosoft_DenyByPassApps_Audit’,’additionalCI1.xml’, ‘CI2.xml’ <BR /> <H2> Deploy CI policy </H2> <BR /> CI deployment and ongoing monitoring is covered in this blog <A href="#" target="_blank"> post </A> . You can also reference this <A href="#" target="_blank"> page </A> for group policy deployment. Below is a quick reference for your convenience: <BR /> <BR /> The created CI policy is in audit mode, you can change it to enforced mode by running: <BR /> Set-RuleOptions -FilePath C:\CI\FilePublisher.xml -Option 3 -Delete <BR /> 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. <BR /> <BR /> Run the following cmdlet to convert the xml file: <BR /> ConvertFrom-CIPolicy C:\CI\FilePublisher.xml C:\CI\FilePublisher.bin <BR /> Deploy CI policy: <BR /> Copy-Item C:\CI\FilePublisher.bin C:\Windows\System32\CodeIntegrity\SiPolicy.p7b <BR /> Reboot the server to allow code integrity service to load the policy. <BR /> <BR /> <BR /> <BR /> 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 <A href="" target="_blank"> us </A> or submit and vote on requests through the <A href="#" target="_blank"> User Voice </A> . <BR /> <H2> </H2> </BODY></HTML> Fri, 15 Mar 2019 23:15:41 GMT Jian (Jane) Yan 2019-03-15T23:15:41Z Shielded VM local mode and HGS mode <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Jan 05, 2018 </STRONG> <BR /> 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. <BR /> <BR /> 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). &nbsp;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 <A href="#" target="_blank"> here </A> . <BR /> <BR /> 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. <BR /> <BR /> 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. <BR /> <BR /> 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. <BR /> <BR /> It’s quite simple to change the setting. To set the host to local mode: <BR /> Set-HGSClientConfiguration -EnableLocalMode <BR /> To change it to HGS mode: <BR /> Set-HGSClientConfiguration -AttestationServerUrl &lt;url&gt; -KeyProtectionServerUrl &lt;Url&gt; <BR /> 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: <BR /> <BR /> <EM> [snippet slug=new-shielded-vm-local-mode line_numbers=false lang=bsh] </EM> <BR /> <BR /> You can find the script to create remote mode shielded VM <A href="#" target="_blank"> here </A> . <BR /> <BR /> 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. </BODY></HTML> Fri, 15 Mar 2019 23:15:37 GMT Jian (Jane) Yan 2019-03-15T23:15:37Z Building VM template using Assigned Access <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Nov 30, 2017 </STRONG> <BR /> 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. <BR /> <BR /> 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 <A href="#" target="_blank"> Assigned Acces </A> s. There are a few ways to configure it. I chose the Windows Configuration Designer downloaded from the Windows Store. You can follow the instructions <A href="#" target="_blank"> here </A> to create the package. <BR /> <H2> Creating provisioning package for Azure portal management </H2> <BR /> 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 <EM> % </EM> <EM> P </EM> <EM> rogramfiles </EM> <EM> %\ </EM> <EM> Internet explorer\iexplorer.exe -k </EM> (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. <BR /> <H2> Creating provisioning package for RDP </H2> <BR /> 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: <BR /> <OL> <BR /> <LI> 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 <A href="#" target="_blank"> offline distribution </A> . To install the Appx package: </LI> <BR /> </OL> <BR /> <EM> Dism </EM> <EM> /add-provisionedAppxPackage /image:e:\ /PackagePath:&lt;path to .appxbundle&gt; /LicensePath:&lt;path to license xml&gt; /DependecyPackagePath:&lt;adding dependency appx if needed&gt; </EM> <BR /> <BR /> <EM> Where e:\ is the mounted VHDX drive </EM> <BR /> <OL> <BR /> <LI> 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) </LI> <BR /> <LI> 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. </LI> <BR /> </OL> <BR /> <H2> Deploy package </H2> <BR /> As I have mentioned earlier, there are two ways to apply the (.ppkg) package: <BR /> <OL> <BR /> <LI> <STRONG> Online </STRONG> : 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. </LI> <BR /> </OL> <BR /> 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. <BR /> <OL> <BR /> <LI> <STRONG> Offline </STRONG> : If you already have a syspreped image to start with, you can apply the package to the image by running </LI> <BR /> </OL> <BR /> <EM> Dism </EM> <EM> /add- </EM> <EM> provisioningpackage </EM> <EM> / </EM> <EM> packagepath </EM> <EM> : </EM> <EM> &lt;full path to </EM> <EM> ppkg </EM> <EM> file&gt; </EM> <EM> /image=e:\ </EM> <BR /> <BR /> <EM> (where e:\ is the mounted VHDX </EM> <EM> file) </EM> <BR /> <BR /> Now the VM image can be used as the template and you can follow the previous <A href="#" target="_blank"> blog post </A> to deploy it. If you are part of the TAP program, I have also made the image available for download. <BR /> <H2> Windows unattend file </H2> <BR /> To create PAW VM, you will need a Windows unattend file. I have shared a sample copy in a previous <A href="#" target="_blank"> blog post </A> . For the RDP VM template, I added the following to pin the app in the start menu: <BR /> <BR /> [snippet slug=unattend-pin-rdp-in-start-menu line_numbers=false lang=bsh] <BR /> <BR /> If you have ideas/requests for different images, you are welcome to share it with <A href="" target="_blank"> us </A> . </BODY></HTML> Fri, 15 Mar 2019 23:15:33 GMT Jian (Jane) Yan 2019-03-15T23:15:33Z Why use shielded VMs for your privileged access workstation (PAW) solution? <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Nov 29, 2017 </STRONG> <BR /> 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. <BR /> <BR /> 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. <BR /> <BR /> There are tons of documents/videos on technet about shielded VMs, <A href="#" target="_blank"> this </A> 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. <BR /> <BR /> So why shielded VMs? <BR /> <BR /> There are two aspects to this question: <BR /> <OL> <BR /> <LI> Why do we want to use VMs? (as opposed to dedicated physical PAW devices )? </LI> <BR /> </OL> <BR /> <OL> <BR /> <LI> What are the security benefits when running a shielded VM over a regular VM? </LI> <BR /> </OL> <BR /> 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. <BR /> <BR /> 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. <BR /> <BR /> 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. <BR /> <BR /> 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: <BR /> <OL> <BR /> <LI> The physical device must have TPM version 2.0. The endorsement key from the TPM is used as a strong form of device identity; </LI> <BR /> </OL> <BR /> <OL> <BR /> <LI> 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; </LI> <BR /> </OL> <BR /> <OL> <BR /> <LI> Finally, the code integrity policy is also measured and validated against the policy managed by the Host guardian service. </LI> <BR /> </OL> <BR /> 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: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> 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. <BR /> <BR /> 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 <A href="#" target="_blank"> here </A> . 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 <A href="#" target="_blank"> here </A> . <BR /> <BR /> 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 <A href="" target="_blank"> us </A> . <BR /> <BR /> </BODY></HTML> Fri, 15 Mar 2019 23:15:30 GMT Jian (Jane) Yan 2019-03-15T23:15:30Z Improved branch office support for shielded VMs in Windows Server, version 1709 <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Nov 15, 2017 </STRONG> <BR /> 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? <BR /> 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. <BR /> <BR /> 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. <BR /> <BR /> This blog post explains the recommended architecture for setting up HGS in a branch office scenario. <BR /> <H2> Recommended Architecture </H2> <BR /> <IMG src="" /> <BR /> <BR /> To set up a branch office HGS, follow these high-level steps: <BR /> <OL> <BR /> <LI> Ensure your main datacenter's HGS cluster is installed and operational. For more information, read our <A href="#" target="_blank"> HGS deployment instructions </A> . </LI> <BR /> <LI> 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 <A href="#" target="_blank"> guarded host deployment instructions </A> . 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. </LI> <BR /> <LI> <A href="#" target="_blank"> Deploy a new shielded VM </A> 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. </LI> <BR /> <LI> Configure the new shielded VM as an HGS server following our <A href="#" target="_blank"> HGS deployment instructions </A> . 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. </LI> <BR /> <LI> 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. </LI> <BR /> <LI> 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 <A href="#" target="_blank"> Set-HgsClientConfiguration </A> . Details on how to do this are included at the end of the blog post. </LI> <BR /> <LI> 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. </LI> <BR /> </OL> <BR /> You can repeat these steps for each branch office you want to configure. In general, we have three core recommendations for branch office deployments: <BR /> <OL> <BR /> <LI> 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. </LI> <BR /> <LI> 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. </LI> <BR /> <LI> 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: <BR /> <UL> <BR /> <LI> The shielded HGS server is configured with an owner guardian (central IT) and one additional guardian for the main datacenter HGS </LI> <BR /> <LI> 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. </LI> <BR /> </UL> <BR /> </LI> <BR /> </OL> <BR /> <H2> Configuring fallback URLs in Hyper-V </H2> <BR /> To use the new fallback functionality, you will need to use Hyper-V on Windows Server, version 1709. <A href="#" target="_blank"> Read more about the semi-annual channel </A> to decide if upgrading to version 1709 is right for you. <BR /> <BR /> 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: <BR /> <BR /> (Don't forget to swap "primaryhgs" and "fallbackhgs" for your own DNS names!) <BR /> Set-HgsClientConfiguration -KeyProtectionServerUrl http://primaryhgs/KeyProtection -AttestationServerUrl http://primaryhgs/Attestation -FallbackKeyProtectionServerUrl http://fallbackhgs/KeyProtection -FallbackAttestationServerUrl http://fallbackhgs/Attestation <BR /> You can check if your Hyper-V host is passing attestation by using Test-HgsClientConfiguration: <BR /> Test-HgsClientConfiguration -UsePrimary <BR /> Test-HgsClientConfiguration -UseFallback <BR /> If you are no longer using a fallback HGS server, you can remove it by using Set-HgsClientConfiguration without fallback URLs: <BR /> Set-HgsClientConfiguration -KeyProtectionServerUrl http://primaryhgs/KeyProtection -AttestationServerUrl http://primaryhgs/Attestation <BR /> <H2> When is a fallback server used? </H2> <BR /> 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 <EM> always </EM> 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 <EM> can </EM> reach the primary HGS server, but fails attestation or receives another terminating response, it will not attempt the fallback URL. <BR /> <BR /> You can monitor the <STRONG> Microsoft-Windows-HostGuardianService-Client/Operational </STRONG> event log for event ID <STRONG> 2021 </STRONG> on a Hyper-V host to see when a fallback server is in use. <BR /> <BR /> <BR /> <BR /> 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 <A href="" target="_blank"> </A> . </BODY></HTML> Fri, 15 Mar 2019 23:15:17 GMT RyanWillis 2019-03-15T23:15:17Z How to deploy a VM template for PAW <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Nov 01, 2017 </STRONG> <BR /> Continuing with the PAW series, after you followed the previous <A href="#" target="_blank"> blog </A> to build the PAW device, you can now deploy PAW VMs on it. There are two types of VMs you can create: <BR /> <UL> <BR /> <LI> 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. </LI> <BR /> <LI> 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. </LI> <BR /> </UL> <BR /> <EM> If you are part of the PAW TAP program, you can download a couple of templates I created for evaluation. </EM> <BR /> <BR /> This blog post walks you through step-by-step on how to deploy a shielded VM template on a PAW device. <BR /> <BR /> <STRONG> Important </STRONG> : 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 <A href="#" target="_blank"> here </A> , make sure you select this file: <STRONG> WindowsTH-RSAT_WS2016-x64.msu. </STRONG> (Note that WindowsTH-RSAT_WS_1709-*.msu package will not work). <BR /> <BR /> Once RSAT is installed, these features are added in the start menu: <STRONG> Template Disk Wizard </STRONG> and <STRONG> Shielding Data File Wizard </STRONG> . You can use the Template Disk Wizard to create the VM template disk, and the Shielded Data File Wizard to create the PDK file. <BR /> <H2> Pre-requisites </H2> <BR /> You need a template disk created by following this <A href="#" target="_blank"> article, </A> 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"&#157; in the article has the instructions of how to build a template disk. <BR /> <BR /> For convenience, below is a short description on how to create a template disk from a syspreped OS image. You can either use the <B> Template Disk Wizard </B> , or run the following PowerShell commands : <BR /> $cert = New-SelfSignedCertificate -DnsName '' <BR /> Protect-TemplateDisk -Path ‘C:\PAWVM.vhdx’ -TemplateName "PAWTemplate" -Version -Certificate $cert <BR /> <H2> Creating shielding data file (PDK) </H2> <BR /> 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 <A href="#" target="_blank"> here </A> . <BR /> <BR /> This section illustrates the process specific for a PAW solution. <BR /> <H2> Prepare necessary files </H2> <BR /> The PAW PDK files requires the following files: <BR /> <UL> <BR /> <LI> HGS Guardian </LI> <BR /> <LI> Windows Unattend file </LI> <BR /> <LI> Template disk volume signature </LI> <BR /> </UL> <BR /> <H3> HGS guardian </H3> <BR /> 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: <BR /> Invoke-WebRequest http://&lt;HGSServer"&gt;FQDN&gt;/KeyProtection/service/metadata/2014-07/metadata.xml -OutFile C:\HGSGuardian.xml <BR /> <EM> If you are using the TAP evaluation image, you can get the PartnerPAWPoCGuardian,xml file from the Yammer group. </EM> <BR /> <H3> Windows Unattend file </H3> <BR /> 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 " <A href="#" target="_blank"> Security level for VMs </A> "&#157;. <BR /> <BR /> 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. <BR /> <H3> Template disk volume signature </H3> <BR /> 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. <BR /> <BR /> You can run the following cmdlet to create the template disk volume signature file: <BR /> <BR /> Save-VolumeSignatureCatalog -TemplateDiskPath &lt;templatefilename.vhdx&gt; -VolumeSignatureCatalogPath &lt;templatefilename.vsc&gt; <BR /> <BR /> <EM> 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. </EM> <BR /> <H2> Create PDK </H2> <BR /> You can use the Shielding Data File Wizard to create the PDK file, or using the following cmdlet: <BR /> <BR /> [snippet slug=new-paw-pdk line_numbers=false lang=bsh] <BR /> <H2> Create PAW VM </H2> <BR /> 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: <BR /> <BR /> [video width="1620" height="1080" mp4="<A href="#" target="_blank">"][/video</A>] <BR /> <BR /> <EM> 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. </EM> <BR /> <BR /> 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. <BR /> <BR /> <BR /> <H2> Conclusion </H2> <BR /> As always, you feedback and questions will help us to make this better. Feel free to share your comment below or email <A href="" target="_blank"> us </A> . <BR /> <H2> Appendix - Sample unattend.xml </H2> <BR /> [snippet slug=sample-windows-client-1709-unattended line_numbers=false lang=xml] <BR /> <BR /> </BODY></HTML> Fri, 15 Mar 2019 23:15:06 GMT Jian (Jane) Yan 2019-03-15T23:15:06Z PAW host buildout <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Oct 17, 2017 </STRONG> <BR /> Continuing with the PAW series, in this blog post, I'd like to share the details of what we are planning to configure the host. I'd love to hear your thoughts, feedback about the design. For a recap on the PAW overall solution, you can find it in this <A href="#" target="_blank"> blog post </A> . <BR /> <BR /> The PAW host is designed to run as little workload as possible. Ideally, it would just be the hypervisor. However, in reality there will be some applications which must be running on the physical host, such as hardware management tools, a browser for handling captive WiFi authentication portals, and an application to manage the virtual machines. I'm using Windows 10, version 1709 Enterprise Edition for my prototype. <BR /> <H2> Pre-requisites: </H2> <BR /> <UL> <BR /> <LI> A machine installed with Windows 10, version 1709 Enterprise Edition </LI> <BR /> <LI> A physical device <BR /> <UL> <BR /> <LI> Has TPM2.0 (TPM reset and cleared) </LI> <BR /> <LI> UEFI running in Native Mode (not Compatibility/CSM/Legacy mode) </LI> <BR /> <LI> Second Layer Address Translation (SLAT) and Virtualization Extensions (Eg, Intel VT or AMD V) enabled </LI> <BR /> <LI> SecureBoot enabled </LI> <BR /> <LI> Recommended hard disk size 500GB or above </LI> <BR /> <LI> Device storage layout: </LI> <BR /> </UL> <BR /> </LI> <BR /> </UL> <BR /> <IMG src="" /> <BR /> <H2> Adding features </H2> <BR /> 1709 Windows release has a new feature to support Windows client to run shielded VMs. On the host, we will create shielded VMs to run the secure workload. The following features are enabled on the PAW host: <BR /> <UL> <BR /> <LI> Hyper-V </LI> <BR /> <LI> Guarded Host (a.k.a. HostGuardian) </LI> <BR /> <LI> <A href="#" target="_blank"> Windows Defender Application Guard </A> is also enabled, to allow more network protection of the host </LI> <BR /> </UL> <BR /> <H2> Enable security settings </H2> <BR /> The solution leverages a number of Windows built-in security features, some are enabled by default, some requires configuration changes. <BR /> <UL> <BR /> <LI> Windows Defender is enabled by default to monitor malware; </LI> <BR /> <LI> Control Flow Guard is also enabled by default to combat memory corruption vulnerabilities; </LI> <BR /> <LI> <A href="#" target="_blank"> Credential guard </A> protects logon credentials with VSM, you can enable it with group policy; </LI> <BR /> <LI> <A href="#" target="_blank"> Code Integrity policy </A> defines the trusted software can run on the device, you can create a Code integrity policy for the device by running this cmdlet: </LI> <BR /> </UL> <BR /> <EM> New-CIPolicy -Level Publisher -UserPEs -FilePath &lt;CIpolicypath.xml&gt; </EM> <BR /> <P> You will need to follow this <A href="#" target="_blank"> document </A> to deploy the policy on the local machine. </P> <BR /> <P> Alternatively, Windows now comes with a built-in sample Code integrity policy you can build on, under %windir%\schemas\CodeIntegrity\ExamplePolicies. We recommend you deploy a code integrity policy in enforcement mode. </P> <BR /> <BR /> <UL> <BR /> <LI> <A href="#" target="_blank"> Windows Defender Exploit guard </A> (WDEG) is designed to prevent host intrusions. There are four features in WDEG: <BR /> <UL> <BR /> <LI> Exploit protection can apply exploit mitigation techniques to apps your organization uses, both individually and to all apps; </LI> <BR /> <LI> Attack surface reduction rules can reduce the attack surface of your applications with intelligent rules that stop the vectors used by Office-, script- and mail-based malware; </LI> <BR /> <LI> Network protection extends the malware and social engineering protection offered by Windows Defender SmartScreen in Edge to cover network traffic and connectivity on your organization's devices; </LI> <BR /> <LI> Controlled folder access helps protect files in key system folders from changes made by malicious and suspicious apps, including file-encrypting ransomware malware. </LI> <BR /> </UL> <BR /> </LI> <BR /> </UL> <BR /> <P> WDEG adds more protection on Windows, you can find more details on how to configure it <A href="#" target="_blank"> here </A> . </P> <BR /> <BR /> <UL> <BR /> <LI> <A href="#" target="_blank"> Security baseline policy </A> has been drafted for the 1709 release, and it is also included as part of the PAW host customization. </LI> <BR /> </UL> <BR /> <BR /> <H2> Host guardian client configuration </H2> <BR /> To allow the PAW host to attest to the Host Guardian Server (HGS), you will need to have a HGS server deployed on-premises, or use the Cloud service we have prototyped. <BR /> <UL> <BR /> <LI> On-premises: Once you have followed this deployment <A href="#" target="_blank"> document </A> to set up the HGS server, you can configure the PAW Host using this <A href="#" target="_blank"> guide </A> . </LI> <BR /> <LI> Cloud: the service is by invitation only. You will need to get this information from <A href="" target="_blank"> us </A> . </LI> <BR /> </UL> <BR /> To verify the configuration is done correctly, you can run this cmdlet on the PAW host after you have completed the deployment: <BR /> <EM> Get-HGSClientConfiguration </EM> <BR /> <P> <IMG src="" /> </P> <BR /> <BR /> You can also use Test-HGSClientConfiguration to check for attestation result. <BR /> <H2> Deploy using a pre-built prototype image </H2> <BR /> We built a customized ISO image with all the customizations included in the document, you can enroll to our evaluation program to get a copy. I'm planning to release the evaluation copy early next week. Once you download the ISO image, you can copy it to a pre-formatted USB drive (8GB or above). To create a bootable USB: <BR /> <BR /> From an elevated command&nbsp;prompt run DISKPART, and execute the following commands: <BR /> <EM> list disk </EM> <BR /> <EM> select disk&nbsp;&lt;number&nbsp;of your USB disk... e.g 'select disk 1'&gt; </EM> <BR /> <EM> clean </EM> <BR /> <EM> create partition primary </EM> <BR /> <EM> select partition 1 </EM> <BR /> <EM> active </EM> <BR /> <EM> format quick fs=fat32 </EM> <BR /> <EM> assign </EM> <BR /> <EM> exit </EM> <BR /> USB drive is now bootable. <BR /> <BR /> Copy the image file we shared with you to the USB disk by mounting the ISO image first, then copy the files inside the mounted drive to the USB drive (don't copy the actual iso file to the USB, that will not work). <BR /> <BR /> Boot laptop using the USB drive, and follow the MDT prompts for deploying the PAW image. I recorded a short video to demo this experience: <BR /> <BR /> [video width="988" height="720" mp4="<A href="#" target="_blank">"][/video</A>] <BR /> <BR /> <BR /> <H2> Conclusion </H2> <BR /> Now your device is configured to run shielded VMs. There are a few more configurations we will add to later test builds, such as BitLocker, networking policies, create standard user for logon, lock down further on the user experience on host. Stay tuned. <BR /> <BR /> In the next blog post, I will show you how to create VMs on this device. As always, we welcome your <A href="" target="_blank"> feedback </A> . </BODY></HTML> Fri, 15 Mar 2019 23:15:03 GMT Jian (Jane) Yan 2019-03-15T23:15:03Z Privileged Access Workstation(PAW) <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Oct 13, 2017 </STRONG> <BR /> At Ignite conference last month, Dean and I presented a <A href="#" target="_blank"> session </A> on PAW. Originally we were planning to just talk about the concept of PAW and how it is deployed in Microsoft. A week before the conference, we decide to share our early design based on the Windows 10 1709 release, so that we can gauge the interest from our customers about this solution, and make decision to as to whether we should build a backend service to support the solution. <BR /> <BR /> The response was overwhelming, many customers came to visit us at the Expo during the conference, and signed up to evaluate the solution. It motivated us to speed up the development, so that we can offer a proof of concept. In the past few months, we have enrolled many customers to evaluate the solution, and gained valuable insight. <BR /> <BR /> Meanwhile, I'm planning to write a series of blog posts that explain the details of the new PAW solution, from the host configuration to the template we are building. This blog is the first one in the series, aiming at providing an overview of the PAW solution. <BR /> <H2> Solution overview </H2> <BR /> Below is a high-level topology view of the deployment: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> The PAW device is running the Windows 10 1709 release, which has a new feature "Guarded host"&#157;. This feature supports the physical device performing remote health attestation against a Host Guardian Server (HGS) and running shielded VMs. If you would like to learn about the benefit of shielded VM, you can find more details <A href="#" target="_blank"> here </A> . The shielded VM was first introduced in Windows Server 2016 to protect virtual machines running sensitive workload, and is now made available in Windows client to run the PAW VMs. <BR /> <BR /> The design of the PAW host is locked down to run the minimum set of binaries while moving all functionality into the virtual machines running on that host. Compared to the current PAW solutions that use separate physical machines running different workloads, this design is less costly and has better usability. <BR /> <UL> <BR /> <LI> the desktop VM will handle user daily productivity workload, such as email, internet access; </LI> <BR /> <LI> the PAW VM will be dedicated for secure workload, which can be locked down, such as network access; application whitelisting etc. </LI> <BR /> </UL> <BR /> One key backend service to support the PAW device is the HGS server. If you want to deploy the Host Guardian Server on-premises, you can follow this deployment <A href="#" target="_blank"> document </A> to set up the HGS server. For evaluation, you can create a single node HGS server, with self-signed certificates. <BR /> <BR /> (Note: update 2018/04, the PAW TAP program has been closed for now. I have publish guidelines on how to deploy PAW on-prem&nbsp; guide, see links below) <BR /> <BR /> I also created user voice links, if you'd like to see this offered by Microsoft, please vote here: <BR /> <BR /> <A href="#" target="_blank"> HGS as service </A> <BR /> <BR /> <A href="#" target="_blank"> Azure PAW </A> <BR /> <BR /> Our goal is to build a simple solution for customers to deploy PAW, which offers a good user experience and does not require dedicated resources for ongoing operational management. We are inviting you to join us on this development journey. <BR /> <BR /> I have purposefully stayed at a very high level in this first blog about the PAW solution. Deep dive blogs will follow. Feel free to share your questions in the comment section, so I can make sure to address in the upcoming posts. <BR /> <H2> Update </H2> <BR /> I have published a number of blog posts on the PAW solution, below is a reference list: <BR /> <UL> <BR /> <LI> <A href="#" target="_blank"> PAW deployment guide </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Why use shielded VM for PAW? </A> </LI> <BR /> <LI> <A href="#" target="_blank"> How to deploy VM template for PAW </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Building VM template for PAW </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Connect to VMs on PAW </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Shielded VM local mode vs HGS mode </A> </LI> <BR /> <LI> <A href="#" target="_blank"> How to build the PAW host </A> </LI> <BR /> </UL> </BODY></HTML> Fri, 15 Mar 2019 23:14:40 GMT Jian (Jane) Yan 2019-03-15T23:14:40Z Frequently Asked Questions About HGS Certificates <P><STRONG> First published on TECHNET on Oct 09, 2017 </STRONG> <BR />The Host Guardian Service uses public key cryptography extensively to protect shielded VMs from attackers. Any time certificates with public-private key pairs come into play, there are bound to be many questions about how to properly set up and protect those certificates. This blog hopes to clarify the most common questions our team is asked about certificate usage in HGS. <BR /><BR /><BR /><BR /><STRONG> Q: What purpose does each of the HGS certificates serve? </STRONG> <BR /><BR />A: There are 6 different types of certificates used by HGS. <BR /><BR /></P> <UL> <UL> <LI><STRONG> Encryption certificate </STRONG> : used to encrypt and decrypt the key protector, which itself contains the symmetric key that encrypts the virtual TPM of a shielded VM at rest.</LI> </UL> </UL> <P>&nbsp;</P> <UL> <UL> <LI><STRONG> Signing certificate </STRONG> : used to digitally sign the key protector to ensure its authenticity.</LI> </UL> </UL> <P>&nbsp;</P> <UL> <UL> <LI><STRONG> Communications certificate </STRONG> : used to digitally sign the metadata document provided to tenants for use in the Shielding Data File wizard.</LI> </UL> </UL> <P>&nbsp;</P> <UL> <UL> <LI><STRONG> Attestation signer certificate </STRONG> : used to sign health certificates issued by HGS to Hyper-V hosts that have successfully completed an attestation request. Hyper-V hosts will present the health certificate when they need to start up a shielded VM, allowing HGS to ensure the certificate was signed by a trusted attestation signer certificate to verify authenticity.</LI> </UL> </UL> <P>&nbsp;</P> <UL> <UL> <LI><STRONG> HTTPS (SSL/TLS) certificate </STRONG> : an optional certificate used to encrypt HTTP communications between Hyper-V hosts and the HGS server. While the key protector is always encrypted when transmitted, HTTPS may help you comply with regulatory requirements to protect all data at the transport layer.</LI> </UL> </UL> <P>&nbsp;</P> <UL> <UL> <LI><STRONG> Dump encryption certificate </STRONG> : an optional certificate used to encrypt memory dumps on Hyper-V hosts to protect sensitive information in shielded VMs. By default, HGS disallows all dumps, but if you choose to enable them, you can ensure Hyper-V hosts are encrypting the dumps with a trusted certificate known to HGS.</LI> </UL> </UL> <P><BR /><BR /><BR /><BR /><STRONG> Q: Which certificates do I need to provide? </STRONG> <BR /><BR />A: Of the above 6 certificates, the only required certificates during installation of HGS are the signing and encryption certificate. The communications certificate will re-use the signing certificate by default, and the attestation signer certificate is automatically generated and maintained by HGS (you'll see it in the local machine's certificate store with the subject name "Microsoft Remote Attestation Service"). <BR /><BR />If you choose to use HTTPS on HGS or dump encryption on Hyper-V hosts, you will need to obtain certificates for these purposes and provide that information to HGS as well. <BR /><BR /><BR /><BR /><STRONG> Q: How do I find which certificates are registered with HGS? </STRONG> <BR /><BR />A: To find the signing and encryption certificates registered with HGS, run <A href="#" target="_blank" rel="noopener"> Get-HgsKeyProtectionCertificate </A> on the HGS server. The communications certificate configuration can be retrieved with <A href="#" target="_blank" rel="noopener"> Get-HgsKeyProtectionConfiguration </A> . By default, the signing certificate is re-used as your communications certificate, so there's no need to worry if you see it twice. <BR /><BR /><BR /><BR /><STRONG> Q: Should I add my certificate to HGS using a PFX file or by thumbprint? </STRONG> <BR /><BR />A: Unless you are using a certificate with a private key stored in a hardware security module, you should add your certificate to HGS using a password protected PFX file that contains the private key. This will allow HGS to replicate the certificate to other HGS nodes and automatically manage the permissions for you. <BR /><BR />If you cannot export your certificate with its private key to a PFX file (as is the case with HSM-backed certificates, where the private key never leaves the HSM device), you will have to add the certificate to HGS using its thumbprint. This requires you to install the certificate and key storage provider on each HGS node according to your manufacturer's instructions and ensure that the HGS group managed service account has access to use the private key. <BR /><BR /><BR /><BR /><STRONG> Q: Do I have to use a hardware security module for the signing and encryption certificates? </STRONG> <BR /><BR />A: Hardware Security Modules (HSMs) can help prevent theft and misuse of certificate private keys. HSMs may help you meet compliance requirements or provide additional assurances that your certificates cannot be exported and used maliciously on other machines. HGS does not require the use of an HSM, but supports any HSM that uses a Key Storage Provider to communicate between Windows and the HSM. <BR /><BR /><BR /><BR /><STRONG> Q: Does HGS support "bring your own key"&#157; scenarios? </STRONG> <BR /><BR />A: Yes, HGS allows you to configure more than one signing and encryption certificate. This is ideal if your VM owners want to use encryption and signing keys unique to them. To add additional certificates, use <A href="#" target="_blank" rel="noopener"> Add-HgsKeyProtectionCertificate </A> on an HGS server. As you may have guessed, <A href="#" target="_blank" rel="noopener"> Remove-HgsKeyProtectionCertificate </A> will help you remove certificates if your VM owners no longer use your hosting infrastructure. <BR /><BR /><BR /><BR /><STRONG> Q: Which certificates are included in the HGS metadata document? </STRONG> <BR /><BR />A: The metadata document (obtained at <EM> http://&lt;hgs&gt;/KeyProtection/service/metadata/2014-07/metadata.xml </EM> ) contains the <EM> primary </EM> signing and encryption certificates along with their public keys, and is signed by the communications certificate. This document needs to be provided to your VM owners when they are running the shielding data file wizard to authorize your HGS to decrypt their VMs' TPMs. You can find the primary signing and encryption certificates with <STRONG> Get-HgsKeyProtectionCertificate -IsPrimary $true </STRONG> and change them with <A href="#" target="_blank" rel="noopener"> Set-HgsKeyProtectionCertificate </A> . <BR /><BR /><BR /><BR /><STRONG> Q: I want to use certificates issued by a third party or enterprise certificate authority. How should I configure the certificate template? </STRONG> <BR /><BR />A: For encryption, signing and communications certificates, refer to the <A href="#" target="_blank" rel="noopener"> table of required certificate properties </A> in our documentation. HTTPS certificates can be issued in any format supported by Internet Information Services 10, but should follow the subject name requirements explained in the <A href="#" target="_blank" rel="noopener"> HGS HTTPS documentation </A> . <BR /><BR /><BR /><BR /><STRONG> Q: What happens when my certificates expire? </STRONG> <BR /><BR />A: If your encryption or signing certificate expires, don't panic! Certificates are only validated once during the lifetime of a shielded VM: when the HGS metadata is added in the shielding data file wizard or <A href="#" target="_blank" rel="noopener"> Import-HgsGuardian </A> PowerShell cmdlet. Existing shielded VMs and new VMs created using the same encryption keys will continue to work the same after the certificate expires. Do not renew the certificates unless you are sure that doing so will not change the key pair. If the keys change, existing shielded VMs will be unable to decrypt their vTPM state and, therefore, will not start. <BR /><BR />Instead, you should create new signing and encryption certificates and add them to HGS as additional certificates, and mark them as primary certificates (see <A href="#" target="_blank" rel="noopener"> Add-HgsKeyProtectionCertificate </A> and <A href="#" target="_blank" rel="noopener"> Set-HgsKeyProtectionCertificate </A> ). Leave the expired certificates in HGS so that existing VMs can continue to boot using those certificates. New VMs created using metadata obtained after the HGS certificates were updated will use the new (valid) certificates.</P> <P>&nbsp;</P> <BLOCKQUOTE><EM> <STRONG> Sidebar </STRONG> : The recommendation to not renew your signing and encryption certificates probably makes your PKI experts' hair stand on end. To help calm their nerves, offer them a cup of tea and think about how these certificates are used. They are intended for long-term protection of the keys that encrypt the virtual TPM for a shielded VM. There's no telling how long your VMs will run. A VM could run for minutes, days, or years. The keys originally used to wrap the VM's transport key (the symmetric key that encrypts the vTPM contents) must remain available throughout the lifetime of the VM, thus you should not remove or renew the keys until you're 100% sure no shielded VMs rely on it. Also, remember that VM checkpoints and backups are bound to the encryption keys used at the time the snapshot was taken, so even if you're not using the keys today, you may want to keep them around in case a VM is restored to an earlier state. </EM></BLOCKQUOTE> <P><BR />The communications certificate provides additional assurances to advanced users that the HGS metadata document has not been modified during transit. The shielding data file wizard <EM> does not </EM> validate the communications certificate, so there is little risk if the communications certificate expires unless you are manually validating the XML document signature. You can update the communications certificate at any time without impacting existing VMs using <A href="#" target="_blank" rel="noopener"> Set-HgsKeyProtectionConfiguration </A> . <BR /><BR />The attestation signer certificate will automatically be reissued by HGS when it expires, and other HGS nodes will be updated to trust that new certificate. You do not have to worry about managing this certificate. <BR /><BR />Lastly, HTTPS certificates must be renewed before they expire. If an HTTPS certificate lapses, Hyper-V hosts communicating to HGS via HTTPS will no longer trust the connection and will be unable to attest or obtain keys for their shielded VMs. You can follow your normal HTTPS certificate renewal process for HGS HTTPS certificates. <BR /><BR /><BR /><BR /><STRONG> Q: When I go to retrieve the HGS metadata document, I get an HTTP 500 error saying that the server encountered an internal error. What should I do? </STRONG> <BR /><BR />A: In almost every case where HGS cannot serve its metadata document, it is a result of HGS not being able to use one of its certificates. The following conditions must be satisfied for each of the signing, encryption, and communications certificates: <BR /><BR /></P> <UL> <UL> <LI>Private keys for the certificate are associated with the certificate object in the cert store.</LI> </UL> </UL> <P>&nbsp;</P> <UL> <UL> <LI>The HGS group managed service account has access to use those private keys.</LI> </UL> </UL> <P>&nbsp;</P> <UL> <UL> <LI>The keys use the RSA algorithm and are 2048 bits or longer.</LI> </UL> </UL> <P>&nbsp;</P> <UL> <UL> <LI>The signing certificate allows the Digital Signature key usage</LI> </UL> </UL> <P>&nbsp;</P> <UL> <UL> <LI>The encryption certificate allows the Data Encipherment key usage</LI> </UL> </UL> <P>&nbsp;</P> <UL> <UL> <LI>The communications certificate allows both the Digital Signature and Data Encipherment key usages</LI> </UL> </UL> <P><BR /><BR />If all the above conditions are met, but you are still getting an HTTP 500 error, your certificate may be using a legacy Cryptographic Service Provider or an improperly configured Key Storage Provider (e.g. an HSM KSP that was not given access to use the private keys). Check your certificate template or HSM documentation to identify if your certificate uses a CSP. If it does, reissue the certificate using a KSP so HGS can use it. <BR /><BR />The following script can help check these conditions for the signing, encryption and communications certificates. <BR /><BR /></P> <P>&nbsp;</P> <P>&nbsp;</P> <LI-CODE lang="python">&lt;# Instructions: Run the full script below on your HGS server to analyze your certificate configuration. Output: Summary of all certificates tested. For test-by-test information, inspect the Tests property of the $results object #&gt; # Get all KPS certificates $AllKpsCertificates = Get-HgsKeyProtectionCertificate $CommunicationsCertificate = Get-HgsKeyProtectionConfiguration $AllKpsCertificates += [pscustomobject] @{ Certificate = $CommunicationsCertificate.CommunicationsCertificate CertificateData = $CommunicationsCertificate.CommunicationsCertificateData CertificateType = "Communications" } $results = @() foreach ($cert in $AllKpsCertificates) { $certResult = @{ Thumbprint = $cert.Certificate.Thumbprint CertificateType = $cert.CertificateType Tests = @{} } $errprefix = "TEST FAILURE: The {0} certificate with thumbprint {1}" -f $cert.CertificateType.ToString(), $cert.Certificate.Thumbprint # Check basic certificare requirements if ($cert.Certificate.GetKeyAlgorithm() -eq '1.2.840.113549.1.1.1') { $certResult.Tests.RsaAlgorithm = 'Passed' } else { $certResult.Tests.RsaAlgorithm = 'Failed' Write-Warning "$errprefix does use the RSA algorithm." } if ($cert.Certificate.Version -eq 3) { $certResult.Tests.CertificateVersion = 'Passed' } else { $certResult.Tests.CertificateVersion = 'Failed' Write-Warning "$errprefix is not a version 3 certificate." } if ($cert.Certificate.PublicKey.Key.KeySize -ge 2048) { $certResult.Tests.KeySize = 'Passed' } else { $certResult.Tests.KeySize = 'Failed' Write-Warning "$errprefix has a key length shorter than 2048 bits." } # Check key usage if ($cert.CertificateType -eq 'Encryption' -or $cert.CertificateType -eq 'Communications') { if ($cert.Certificate.Extensions[''].KeyUsages.HasFlag([System.Security.Cryptography.X509Certificates.X509KeyUsageFlags]::DataEncipherment)) { $certResult.Tests.KeyUsage = 'Passed' } else { $certResult.Tests.KeyUsage = 'Failed' Write-Warning "$errprefix does not allow the DataEncipherment key usage." } } else { if ($cert.Certificate.Extensions[''].KeyUsages.HasFlag([System.Security.Cryptography.X509Certificates.X509KeyUsageFlags]::DigitalSignature)) { $certResult.Tests.KeyUsage = 'Passed' } else { $certResult.Tests.KeyUsage = 'Failed' Write-Warning "$errprefix does not allow the DigitalSignature key usage." } } # Check if certificate was added by thumbprint for additional tests if ($cert.CertificateData -is [Microsoft.Windows.KpsServer.Common.CertificateManagement.CertificateReference]) { if ($cert.Certificate.HasPrivateKey) { $certResult.Tests.PrivateKeyPresent = 'Passed' # Try getting CNG info the "real" way if ((Get-TypeData -TypeName System.Security.Cryptography.X509Certificates.X509CertificateExtensionMethods)) { if ([System.Security.Cryptography.X509Certificates.X509CertificateExtensionMethods]::HasCngKey($cert.Certificate)) { $providertype = 0 $cngKeyInfo = [System.Security.Cryptography.X509Certificates.X509Certificate2ExtensionMethods]::GetCngPrivateKey($cert.Certificate) $provider = $cngKeyInfo.Provider $container = $cngKeyInfo.UniqueName } else { $providertype = 'CAPI' $provider = $null $container = $null } } else { # Try to replicate test using regex parsing $certutiloutput = certutil.exe -v -store `"$($cert.CertificateData.StoreName)`" $cert.Thumbprint $providertyperegex = [regex]'^ *ProviderType = (.*)$' $providerregex = [regex]'^ *Provider = (.*)$' $containerregex = [regex]'^ *Unique container name: (.*)$' $providertype = $provider = $container = $null foreach ($line in $certutiloutput) { if (-not $providertype -and $providertyperegex.IsMatch($line)) { $providertype = $providertyperegex.Match($line).Groups[1].Value } elseif (-not $provider -and $providerregex.IsMatch($line)) { $provider = $providerregex.Match($line).Groups[1].Value } elseif (-not $container -and $containerregex.IsMatch($line)) { $container = $containerregex.Match($line).Groups[1].Value } } } if ($providertype -eq 0) { $certResult.Tests.CngKey = 'Passed' if ($provider -eq 'Microsoft Software Key Storage Provider') { $keyFilePaths = Join-Path "$env:ALLUSERSPROFILEMicrosoftCryptoKeys", "$env:ALLUSERSPROFILEMicrosoftCryptoSystemKeys" -ChildPath $container if (Test-Path $keyFilePaths[0]) { $keyFile = $keyFilePaths[0] } elseif ((Test-Path $keyFilePaths[1])) { $keyFile = $keyFilePaths[1] } else { $certResult.Tests.PrivateKeyPermissions = 'Failed' Write-Warning "$errprefix has a private key that could not be found. Please verify the HGS gMSA has access to the private key." } if ($keyFile) { $keyAcl = Get-Acl $keyFile $gmsaAccount = (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName $accessRule = $keyAcl.Access | Where-Object IdentityReference -eq $gmsaAccount if ($accessRule -and $accessRule.AccessControlType -eq 'Allow' -and $accessRule.FileSystemRights.HasFlag([System.Security.AccessControl.FileSystemRights]::Read)) { $certResult.Tests.PrivateKeyPermissions = 'Passed' } else { $certResult.Tests.PrivateKeyPermissions = 'Failed' Write-Warning "$errprefix is not configured to allow the HGS gMSA account access to the private key." } } } else { $certResult.Tests.PrivateKeyPermissions = 'Skipped' Write-Warning ("TEST SKIPPED: The {0} certificate with thumbprint {1} uses a custom key storage provider. This script cannot check if the HGS gMSA has access to the private key." -f $cert.CertificateType, $cert.Certificate.Thumbprint) } } else { $certResult.Tests.CngKey = 'Failed' $certResult.Tests.PrivateKeyPermissions = 'Skipped' Write-Warning "$errprefix is using a legacy crypto service provider to access its private key instead of a key storage provider." } } else { $certResult.Tests.PrivateKeyPresent = 'Failed' $certResult.Tests.PrivateKeyPermissions = 'Skipped' $certResult.Tests.CngKey = 'Skipped' Write-Warning "$errprefix does not have a private key associated with it." } } else { # The certificate was added by PFX $certResult.Tests.PrivateKeyPresent = 'Passed' $certResult.Tests.PrivateKeyPermissions = 'Passed' $certResult.Tests.CngKey = 'Passed' } # Compute final result if ($certResult.Tests.Values -contains 'Failed') { $certResult.Result = 'Failed' } elseif ($certResult.Tests.Values -contains 'Skipped') { $certResult.Result = 'Passed (some tests skipped)' } else { $certResult.Result = 'Passed' } $results += [pscustomobject] $certResult } Format-Table -InputObject $results -AutoSize -Property 'Thumbprint', 'CertificateType', 'Result'</LI-CODE> <P>&nbsp;</P> <P><BR /><BR />These were the most common questions we've received on certificates, but if you've run into an issue not described above, let us know in the comments or send us an email at <A href="" target="_blank" rel="noopener"> </A> .</P> Fri, 14 Feb 2020 20:29:11 GMT RyanWillis 2020-02-14T20:29:11Z Credential Guard lab companion <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on May 15, 2017 </STRONG> <BR /> If you have heard about Credential Guard in Windows Server 2016 (and in Windows 10), but do not have an environment to try it out, <A href="#" target="_blank"> here </A> is a lab environment we built for you to play. <BR /> <H2> Lab access </H2> <BR /> The <A href="#" target="_blank"> link </A> will lead you to a sign up page, after that, you will see the following labs listed for Windows Server 2016: <BR /> <BR /> [caption id="attachment_1295" align="alignnone" width="473"] <IMG src="" /> Windows Server 2016 labs[/caption] <BR /> <BR /> There are 3 exercises in the <STRONG> Implementing Breach Resistance Security in Windows Server 2016 </STRONG> : <BR /> <UL> <BR /> <LI> Credential Guard </LI> <BR /> <LI> Remote Credential Guard </LI> <BR /> <LI> Device Guard </LI> <BR /> </UL> <BR /> This blogpost will walk you through the Credential Guard lab details. <BR /> <BR /> After click on the link of Breach Resistance lab, you be required to sign in and then you can launch the lab: <BR /> <BR /> [caption id="attachment_1305" align="alignnone" width="201"] <IMG src="" /> Sign-in[/caption] <BR /> <BR /> <IMG src="" /> <BR /> <BR /> Launch page <BR /> <BR /> It takes a few minutes to create the VMs, and once it has done, you will see the following machines prepared: <BR /> <BR /> [caption id="attachment_1315" align="alignnone" width="173"] <IMG src="" /> Initialize[/caption] <BR /> <UL> <BR /> <LI> <STRONG> DC </STRONG> : domain controller, which is not used for this exercise. </LI> <BR /> <LI> <STRONG> SRV01 </STRONG> and <STRONG> SRV02 </STRONG> : both are Windows Server 2016, and used for the lab exercise. </LI> <BR /> </UL> <BR /> <H2> Lab exercise – Explained </H2> <BR /> The steps are listed in the Content section: <BR /> <BR /> [caption id="attachment_1325" align="alignnone" width="171"] <IMG src="" /> Content[/caption] <BR /> <BR /> This lab is structured to cover the following in sequence: <BR /> <OL> <BR /> <LI> Understand how attackers can use the hash in memory to gain access to domain controllers </LI> <BR /> <LI> Configure Credential Guard </LI> <BR /> <LI> Verify the hash in memory is protected using Credential Guard </LI> <BR /> </OL> <BR /> You can follow the steps listed under the content section to complete the lab, the intent of the blog, is to break the procedures into groups, to help you understand the exercise better. <BR /> <H2> Prep the hash </H2> <BR /> Lsass.exe is the process which handles user logon, it stores the user credential information in its memory. The memory is cleared when the machine starts up. In this lab environment, all the virtual machines start at the time lab launches, when you logon to the machine, you will only have the logon user credential information in memory. In order to demonstrate an attacker gaining user access using other account’s hash, the first part of the lab is to simulate a server which has been running for a while, different users had remotely or locally connected to it, therefore, lsass memory stored many different user credential information. <BR /> <BR /> This is accomplished by step 1-8. <BR /> <H2> Retrieving credential hash </H2> <BR /> Mimikatz is a popular tool for retrieving lsass memory information. The tool has been copied to the lab machines, step 9-13 walk you through the process of dumping lsass memory using Mimikatz. <BR /> <H2> Pass the Hash </H2> <BR /> Pass the hash is a hacking technique that allows an attacker to authenticate by using the underlying NTLM, instead of specifying the user password. In step 14 to 24, you will extract LabAdmin hash from lsass using Mimikatz, and use the hash to open a PowerShell console, and perform a couple of operations using the LabAdmin privilege: <BR /> <OL> <BR /> <LI> Add a user to the domain admin group </LI> <BR /> <LI> Open remote PowerShell connection to a domain controller </LI> <BR /> </OL> <BR /> Both operations could not be performed by the logon user. But using the hash of the LabAdmin, an attacker will be able to do it using the information retrieve from Lsass memory. <BR /> <BR /> <BR /> <H2> Configure and verify Credential Guard </H2> <BR /> Step 25 to 36 illustrate the steps to configure credential guard, then verify its status using msinfo32.exe and PowerShell. <BR /> <BR /> Step 37 to 43 goes further to use Mimikatz to show the hash in Lsass is now encrypted using Credential Guard. <BR /> <H2> More info </H2> <BR /> The exercise illustrated the benefit of Credential Guard in Windows Server 2016 as well as Windows 10. For more information, you can find <A href="#" target="_blank"> here </A> . </BODY></HTML> Fri, 15 Mar 2019 23:14:25 GMT Jian (Jane) Yan 2019-03-15T23:14:25Z Leverage PowerShell Just Enough Administration for your Helpdesk <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Apr 24, 2017 </STRONG> <BR /> <EM> [Today's guest post was authored by Dan Cuomo based on a real-world application of&nbsp;JEA] </EM> <BR /> <BR /> Hi Folks -- Platforms PFE Dan Cuomo here to talk about one method to enable the use of Just Enough Administration for your helpdesk administrators. <BR /> <BR /> If you're security conscious, you're no doubt in a constant struggle to try and lower the number of administrators on a system. This is a constant battle between good and evil -- you want to enable users to perform their work while at the same time prevent them from gaining too much access where they can break something, or worse, view, delete, or modify sensitive information. One approach to solve this problem is through Just Enough Administration (JEA), a security feature included with PowerShell 5. JEA is one component in a multi-phased approach to <A href="#" target="_blank"> securing privileged access </A> . <BR /> <BR /> With JEA, you empower your users to perform specific tasks through PowerShell <STRONG> <EM> without providing them elevated rights </EM> </STRONG> . You can control the available commands and parameters, validate input for the specified parameters, and have full auditing capabilities with over-the-shoulder transcripts, module logging, and <A href="#" target="_blank"> deep script block logging </A> . For a quick visual example, please see our <A href="#" target="_blank"> earlier blog post </A> . <BR /> <BR /> This sounds fantastic but there are a couple of challenges preventing adoption: <BR /> <OL> <BR /> <LI> Heterogenous client versions </LI> <BR /> <LI> End-user skillset to initiate the connection </LI> <BR /> </OL> <BR /> <H2> Heterogeneous Client Versions </H2> <BR /> Many environments today choose to allow administrators to perform work-related tasks from their favorite device. This could be a workstation, tablet, or mobile device running Windows, Linux or macOS. This means that members on your team may each have a slightly different experience when making a connection to a server that needs to be managed. Most importantly, however, <EM> they are not PowerShell gurus </EM> and, as such, are prone to frustration. <BR /> <BR /> In addition, managing all of this can become quite cumbersome; testing different environments and documenting connection procedures is a time consuming and manual process. To avoid having a helpdesk for your helpdesk, a standardized approach is warranted. <BR /> <H2> End-user skillset to make the connection </H2> <BR /> Imagine you want to allow helpdesk administrators to create new Active Directory accounts. There are several solutions for this today, each with their own downsides. I've seen anything from group-based delegation to adding a bunch of admins to a domain admins group <STRONG> <EM> * <A href="#" target="_blank"> cringe </A> * </EM> </STRONG> ...this time around, you choose to create a JEA endpoint that only enables one scenario: creating a new user. <BR /> <BR /> To do this, User1 logs into their workstation with a non-privileged account (e.g. CONTOSO\User1) and are given an "admin" account (e.g. CONTOSO\User1-Admin) for completing their user creation-related activities. <BR /> <BR /> In the upper left corner of the screenshot below, you can see User1 has logged into the workstation. User1 then opens a PowerShell prompt and attempts to connect to the domain controller (DC01) and receives an <STRONG> </STRONG> <STRONG> Access Denied </STRONG> message. CONTOSO\User1 was only granted domain user rights and does not have access to connect to the DC. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> "Oh, right! I need to use my admin credentials -- I always do that..." User1 says. <BR /> <BR /> In the next screenshot, User1 stores the admin account credentials into the variable <STRONG> $UsrAdminCred </STRONG> and reattempts the connection, once again receiving the access denied message. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> As a Tier 1 Administrator, User1-Admin should have rights to connect to DC01 through a Tier1 group membership. Frustrated, User1 calls the helpdesk only to find out that the account is in the appropriate Tier1 group. <BR /> <BR /> After considerable delay, User1 searches through the Tier 1 Administrators help manual and realizes that he needs to specify the JEA constrained endpoint provided to all Tier 1 administrators. <BR /> <BR /> User1-Admin now specifies the connection to DC01 using the session configuration we set up for this exact scenario. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> To summarize the steps required for a successful connection, User1 must: <BR /> <OL> <BR /> <LI> Open PowerShell </LI> <BR /> <LI> Use <EM> Enter-PSSession </EM> with the <EM> -ComputerName </EM> parameter to create a session to another computer </LI> <BR /> <LI> Use the <EM> -ConfigurationName </EM> parameter to specify the name of the JEA endpoint on the remote computer that CONTOSO\User1-Admin can connect to </LI> <BR /> <LI> Use the <EM> -Credential </EM> parameter to specify the alternate credentials used to make the connection </LI> <BR /> </OL> <BR /> If successful, CONTOSO\User1-Admin is now presented with a session that is restricted to the following commands. Note that <EM> New-ADUser </EM> is the only application command allowed in this session, aside from the 8 default JEA functions. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> User1 no doubt makes a number of wrong turns along the way. Multiply this by the number of admins intended to do this work and you'll need that second helpdesk for your helpdesk staff. Let's look at a more user-friendly&nbsp;alternative. <BR /> <H2> Enter the web-based PowerShell Console </H2> <BR /> One way to solve both problems outlined above is by using <A href="#" target="_blank"> PowerShell Web Access </A> (PSWA). PSWA provides a form-based, SSL certificate secured IIS website that users can sign into and run PowerShell. <BR /> <BR /> Clients can log in from any device on the network that can reach the website using a <A href="#" target="_blank"> variety of supported browsers </A> . <BR /> <BR /> In the screenshot below, User1-Admin browsed to the PSWA login page for the helpdesk staff and specifies the necessary login credentials and computer name. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> To connect to the custom JEA endpoint, User1 only needs to click the <STRONG> Optional connection settings </STRONG> drop-down and replace the default <STRONG> configuration name </STRONG> (Microsoft.PowerShell) with the one configured for JEA. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> To reiterate, CONTOSO\User1-Admin has <STRONG> no </STRONG> administrative rights on DC01. User1-Admin is only allowed to use PSWA to connect to the JEA endpoint on domain controllers. Beyond the web portal itself, PowerShell will again enforce that only Tier 1 Admins can access the JEA endpoint and restrict them to running only the <EM> New-ADUser </EM> cmdlet. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> The screenshots below show that CONTOSO\User1-Admin only belongs to Domain Users and the Tier 1 administration group. The Tier 1 group does not belong to any other privileged groups itself. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> After clicking <STRONG> Sign In </STRONG> , CONTOSO\User1-Admin is connected to a remote PowerShell session on DC01 and can use the limited cmdlets shown previously. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> From here, JEA operates as it normally would, allowing the New-ADUser cmdlet to perform the user creation on behalf of User1-Admin. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> Now you might be asking yourself if you need to go scrolling through IIS logs to identify the connection that somehow correlates that action to... <BR /> <BR /> <EM> Let me stop you right there </EM> . Since we've enabled PowerShell Script Block and Module logging, when the command is run on DC01, a new event (with ID 4103) is added to the PowerShell operational log. Some of the interesting aspects of that event are: <BR /> <UL> <BR /> <LI> <STRONG> CommandInvocation </STRONG> - the command&nbsp;the user ran </LI> <BR /> <LI> <STRONG> ParameterBinding </STRONG> - any options that were included with that command </LI> <BR /> <LI> <STRONG> User </STRONG> - the temporary identity (virtual account) used by JEA during that session. Active Directory logs would show this user as being the one who added NewUser01. </LI> <BR /> <LI> <STRONG> ConnectedUser </STRONG> - the non-privileged account (User1-Admin) that connected to the JEA endpoint and ran the command </LI> <BR /> </UL> <BR /> <IMG src="" /> <BR /> <H2> That's awesome! How do I get started? </H2> <BR /> There are a few moving parts to set this all up, but it boils down to the following steps: <BR /> <OL> <BR /> <LI> <A href="#" target="_blank"> Create a JEA Role Capability&nbsp;file </A> <BR /> This file defines the capabilities granted to your users and is placed inside a PowerShell module on the machine(s) being managed. In our example above, the role capability file only granted access to the <EM> New-ADUser </EM> cmdlet. </LI> <BR /> <LI> <A href="#" target="_blank"> Create the JEA Session Configuration file </A> <BR /> This file defines the parameters for the PowerShell session configuration. For example, a JEA session configuration correlates the users or groups that can use the role capability file for creating new user accounts. It also instructs PowerShell to use a temporary admin account on the machine to execute the commands on behalf of the connecting users. </LI> <BR /> <LI> <A href="#" target="_blank"> Register the JEA Session Configuration </A> <BR /> The session configuration file is registered on the target node and given a friendly name (JEA_AccountGeneration in our example) which users provide to <EM> Enter-PSSession </EM> or the PSWA connection info. Session configurations must be registered on each machine that should be manageable through JEA. </LI> <BR /> <LI> <A href="#" target="_blank"> Install PowerShell Web Access </A> <BR /> Install the PowerShell Web Access feature on a gateway server. In our scenario, this was the server named </LI> <BR /> <LI> <A href="#" target="_blank"> Configure the PowerShell Web Access Gateway </A> <BR /> Configure an IIS web application on PSWA01. <BR /> <BR /> <STRONG> NOTE: </STRONG> As a best practice, it is recommended that you <EM> DO NOT </EM> make the PSWA site accessible outside your company's intranet. Under no circumstance should you expose a direct connection to your domain controllers from the Internet! </LI> <BR /> <LI> <A href="#" target="_blank"> Configure authorization rules </A> <BR /> This is the only task that changes if you're combining PSWA and JEA. In this step, you add an authorization rule to PSWA allowing a user or group to connect to a computer or group. In our scenario, we also specify the JEA session configuration name configured on the target node (DC01).To set the custom authorization rule, we use <A href="#" target="_blank"> Add-PswaAuthorizationRule </A> as shown below. Since we want the users to be able to connect using the custom session configuration, we add the <EM> -ConfigurationName </EM> parameter along with the name selected when registering the endpoint in step 3. <IMG src="" /> </LI> <BR /> <LI> Lock down&nbsp;the PowerShell Web Access Gateway <BR /> As the central entry point for management of a domain controller, it's important to make sure that the PowerShell Web Access Gateway is properly locked down to prevent malicious users from changing the authorization policies or launching attacks on other machines. Check out <A href="#" target="_blank"> our blog on securing jump servers </A> for some tips on how to lock down gateway servers in general and be sure to follow all best practices when configuring the PSWA Gateway. </LI> <BR /> </OL> <BR /> As previously noted, JEA is one in a multi-phased approach to <A href="#" target="_blank"> securing privileged access </A> . JEA does this by reducing the number of elevated rights required to administer systems. In some cases, JEA may be all that you need to enable your helpdesk or other administrators to perform their duties in a more secure manner. <BR /> <BR /> If you're attempting to implement JEA but find yourself struggling due to the hurdles associated with some of the mechanics, combining JEA with PowerShell Web Access can simplify this process for you by providing users with a less error-prone, forms-based mechanism for them to connect to their constrained sessions. <BR /> <BR /> Thanks for reading, <BR /> <BR /> Dan Cuomo </BODY></HTML> Fri, 15 Mar 2019 23:13:39 GMT RyanWillis 2019-03-15T23:13:39Z Rest easy with regulatory compliance in Windows Server 2016 <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Apr 24, 2017 </STRONG> <BR /> [This blog post was originally published at: <A href="#" target="_blank"></A>] <BR /> <BR /> Last month we learned that Windows Server 2016 has achieved Common Criteria certification for the General Purpose OS protection profile. <BR /> <BR /> This international standard is especially important for our customers in the public sector, where Common Criteria certification is highly recommended or even required. That’s why Microsoft has been participating in Common Criteria for nearly two decades, dating back to Windows 2000 Server. <BR /> <BR /> Deploying Windows Server 2016 can also help you meet a host of other compliance requirements and security objectives, such as <STRONG> ISO 27001 </STRONG> , <STRONG> PCI </STRONG> , and <STRONG> FedRamp </STRONG> . <BR /> <BR /> What does this mean? If compliance with any of these regulatory requirements is important to your organization or industry, you can rest easy. We’ve done the work for you, mapping the security features in Windows Server 2016 to these certifications. <BR /> <BR /> All you have to do is click on the appropriate link(s) below to see how Windows Server 2016 helps you get the certifications you need. <BR /> <UL> <BR /> <LI> <A href="#" target="_blank"> Common Criteria certification </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Credential Guard and ISO 27001, PCI and FedRamp </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Device Guard and ISO 27001, PCI and FedRamp </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Shielded Virtual Machines and ISO 27001, PCI and FedRamp </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Windows Defender and ISO 27001, PCI and FedRamp </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Privileged Identity Management and ISO 27001, PCI and FedRamp </A> </LI> <BR /> </UL> <BR /> For more security guidance for the Windows Server operating system in general, check out the <A href="#" target="_blank"> Datacenter and Private Cloud Security blog </A> . </BODY></HTML> Fri, 15 Mar 2019 23:11:54 GMT Vinicius Apolinario 2019-03-15T23:11:54Z Shielded VMs – additional considerations when running a guarded fabric <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Apr 21, 2017 </STRONG> <BR /> So you’ve deployed a guarded fabric and your VMs are running happily.&nbsp; Having now reached that perfect <EM> steady state, </EM> let's have a look at the operational and administrative differences relative to a regular fabric.&nbsp; The purpose of this blog isn’t to exhaustively walk you through some mundane day-to-day set of administrative or operational&nbsp;duties, rather, I want to call out: <BR /> <UL> <BR /> <LI> The aspects of a guarded fabric that differentiate it from a regular fabric </LI> <BR /> <LI> The impact of losing any of these guarded-fabric-specific artifacts </LI> <BR /> <LI> What, if anything you can do to recover from that loss </LI> <BR /> </UL> <BR /> <H2> What are the ‘new’ things we need to concern ourselves with? </H2> <BR /> Maintaining a fabric of regular virtual machines on any hypervisor platform pretty much boils down to the same set of administrative and operational tasks &amp; duties: backup the VM definitions, backup their disks, etc.&nbsp; For a guarded fabric, however, there’s a small number of artifacts that are specific to running and maintaining shielded VMs: <BR /> <OL> <BR /> <LI> Shielding data (PDK files) </LI> <BR /> <LI> Shielded template disks </LI> <BR /> <LI> Volume Signature Catalog files (VSC files) </LI> <BR /> <LI> Virtual Trusted Platform Modules (vTPMs) </LI> <BR /> <LI> Guardians </LI> <BR /> <LI> BitLocker recovery keys </LI> <BR /> </OL> <BR /> Let’s walk through each one: <BR /> <H2> 1. Shielding data (PDK) files </H2> <BR /> Shielding data (a PDK file) contains the secrets necessary for tenants (or, if you prefer, a virtual machine owner) to securely deploy shielded VMs.&nbsp; PDK files are created by VM owners using the <EM> Shielding Data File wizard ( </EM> which is included with Windows Server 2016 and the Remote Server Administration Tools (RSAT) and uploaded to the fabric where their shielded VMs will ultimately run.&nbsp; The PDK file is essentially an encrypted bag of secrets that contains, among other things, the following: <BR /> <UL> <BR /> <LI> an unattend file used to specialize the VM during provisioning </LI> <BR /> <LI> an RDP certificate to secure RDP communication with the VM once it's deployed </LI> <BR /> <LI> a setting indicating whether the PDK is used to create new shielded VMs or convert existing VMs to shielded (see the note below) </LI> <BR /> <LI> the list of guardians that define which guarded fabrics the shielded VM can run on </LI> <BR /> <LI> a setting indicating whether the&nbsp;security policy of the new VM is <EM> encryption supported </EM> (weaker) <EM> </EM> or <EM> shielded </EM> (Hyper-V 2016's strongest setting) </LI> <BR /> <LI> one or more volume ID qualifier rules and their associated&nbsp;volume signature catalog file (more on that in a moment) </LI> <BR /> </UL> <BR /> The guarded fabric uses PDK files when provisioning a new shielded VM and also when converting an existing (regular) VM to a shielded VM. <BR /> <BR /> <STRONG> Note: </STRONG> As implied, you cannot convert a regular VM to a shielded VM using shielding data that was designated for new VMs only.&nbsp; This is because shielding data designated for new VMs might contain arbitrary secrets put in there by whoever created it.&nbsp; If that same shielding data were later&nbsp;used to convert a VM owned by an attacker to a shielded VM, then the secrets inside the shielding data would have been deposited on the malicious VM's disk unencrypted which probably isn't good.&nbsp; Hence, the setting and enforcement logic to block it. <BR /> <BR /> All of that said then, what happens if you lose the PDK file?&nbsp; Well, assuming you have a copy of all the things kept inside it then losing it merely requires that you re-create the PDK using the <EM> Shielding Data File wizard. </EM> <BR /> <H2> 2. Shielded template disks </H2> <BR /> If&nbsp;you already understand the purpose&nbsp;a <EM> template disk </EM> serves in a fabric of regular VMs, then you're pretty much there with s <EM> hielded template disks. </EM> It’s a regular VHDX file with a Sysprep’d copy of Windows but it's signed at a trusted time by a trustworthy administrator. <BR /> <BR /> To create a <EM> shielded template disk </EM> , simply create a template disk in the same way you always have and then run it through the <EM> Template Disk Signing wizard, another tool in Windows Server 2016 and RSAT. </EM> This tool creates a cryptographic signature based on critical parts of the template disk (the OS partition, for example) as it exists at that precise time.&nbsp; The signature is created using a certificate of the administrator's choosing.&nbsp; This signature is then stored on the EFI (the system) partition of the now-shielded template disk. <BR /> <BR /> The certificate used for signing is sensitive and must be considered a secret since possession of it allows an attacker to sign arbitrary template disks that could contain malware .&nbsp; An administrator then extracts the signature from the shielded template disk and&nbsp;saves it&nbsp;in a volume signature catalog file (which, as you already know, is stored in shielding data files). <BR /> <BR /> Later, during shielded VM provisioning, the signature of the shielded template disk is computed once again and compared against the original signature &amp; signing certificate to determine if the shielded template disk has been tampered with.&nbsp; Assuming it hasn't, shielded VM provisioning proceeds as normal. <BR /> <BR /> What if you lose a shielded template disk?&nbsp; Just recreate it (or vow to never deploy another new shielded VM again which doesn't seem like the right approach to me).&nbsp; Stated another way, there's nothing unique about a shielded template disk except what a trusted administrator might have put on it. <BR /> <BR /> What if you lose the template disk signing certificate itself?&nbsp; If it’s&nbsp;destroyed accidentally, tenants won’t be able to use existing shielding data with any new template disks because they’ll have been signed by a different certificate (you lost the original one, remember). <BR /> <BR /> As already noted, if the signing certificate is stolen, an attacker can sign any template disk and convince the shielded VM provisioning engine that everything's just peachy because it's signed with the blessed certificate--that's really very bad indeed and all existing PDKs should be edited to remove their trust in that now-stolen certificate. <BR /> <H2> 3. Volume signature catalogs (VSC files) </H2> <BR /> As noted above, shielded template disks have a cryptographic signature stored on them that represents the disk at a trusted time.&nbsp; That signature can be extracted and stored in a VSC file which is, in turn, stored in a shielding data (PDK) file and used during provisioning to ensure that the template disk hasn't been tampered with since being signed. <BR /> <BR /> If you lose a VSC file, you can simply extract it again from the parent&nbsp;shielded template disk. <BR /> <H2> 4. vTPM </H2> <BR /> A vTPM is exactly as its name implies, a virtualized trusted platform module that behaves in the same way as normal V2 TPMs.&nbsp; The vTPM of a virtual machine is not bound to its Hyper-V host's physical TPM in any way whatsoever--it's entirely synthetic.&nbsp; Shielded VM's encrypt their OS disk and, while a bit of an over-simplification, the keys used to encrypt the OS disk are <EM> sealed </EM> inside the vTPM.&nbsp; To <EM> seal </EM> keys inside a TPM (whether it's virtual or otherwise) means that the keys are locked to a particular set of boot + OS <EM> measurements </EM> and will only be released if the measurements are the same as they were at the time the keys were last sealed there.&nbsp; The term <EM> measurements </EM> describes certain firmware variables and a set of hashes of the binaries that comprise the boot process and some of the OS itself. <BR /> <BR /> As is true of virtual machines whose configuration and state is stored as files on a disk, the same is true for a vTPM.&nbsp; It's worth noting, though, that the vTPM is encrypted on disk.&nbsp; You can deduce then if a shielded VM's vTPM is either lost or cannot be decrypted, the shielded VM's BitLockered disk also can't be decrypted.&nbsp; Hence it's important to ensure that a shielded VM (or any VM with a vTPM device added to it on a Hyper-V host running Windows Server 2016 or later) is backed up using tools that understand that the VM is more than just a VHDX and a bunch of arbitrary configuration entries&nbsp;in a text file. <BR /> <BR /> What if a shielded VM's configuration, including its vTPM state, is lost but its VHDX is preserved?&nbsp; Adding that VHDX to another VM will cause the VM to boot into BitLocker recovery and you'll need the BitLocker recovery key to complete the boot process. <BR /> <BR /> <STRONG> Note: </STRONG> Guarded fabrics do NOT automate the creation/backup of BitLocker recovery keys--this is the responsibility of the VM owner or the VM owner's IT department. <BR /> <H2> 5. Guardians </H2> <BR /> <EM> Guardian </EM> is the term we use to describe the pair of certificates--one encryption, one signing--that protect the symmetric encryption key that is used to encrypt a shielded VM's vTPM (I'd advise that you read that sentence again).&nbsp; Guardians themselves aren't secrets because they only contain public keys (make sure the certificates you use to create the guardian honor this assumption, i.e. the certificate itself doesn't contain the private keys); the private keys of a guardian should be maintained by the <EM> Host Guardian Service </EM> (HGS).&nbsp; Guardians spend most of their lives indirectly protecting a shielded VM's vTPM.&nbsp; When a new shielded VM is provisioned, the guardians&nbsp;protecting the key that actually encrypts the vTPM are copied from the shielding data file and written to the vTPM's <EM> key protector </EM> (KP).&nbsp; It's not unreasonable to think of a KP as something akin to an ACL on a file.&nbsp; In summary : <BR /> <OL> <BR /> <LI> Each HGS cluster has a default guardian for which it exclusively possesses the private keys </LI> <BR /> <LI> Each VM owner who creates a PDK file also has an <EM> owner </EM> guardian--in this one instance, the private keys are maintained outside of HGS by the VM owne </LI> <BR /> </OL> <BR /> It's logical then to say that PDKs/KPs&nbsp;typically contain at least two guardians: the VM owner’s guardian and one or more guardians that represent the guarded fabrics where the VM is permitted to run--remember, the guardians within the PDK/KP should never contain the private keys. <BR /> <BR /> With all that said then, what happens if you lose a guardian?&nbsp; Well it depends--did you lose the public key, the private key, or both?&nbsp; Or perhaps you lost the PDK in which the guardian lives.&nbsp; If you merely&nbsp;lost the PDK in which the guardian lived, then simply re-create a new PDK file&nbsp;and add your guardian to it.&nbsp; If you lost the default guardian from your Host Guardian Service, simply download the metadata and use it to re-create the guardian.&nbsp; There's a laundry list of ways you could lose a guardian but the reality is this: the only thing that really matters about a guardian is its private key because that is needed to begin the process of decrypting a vTPM--lose that and you're one step closer to losing the whole shielded VM. <BR /> <H2> 6. BitLocker recovery keys </H2> <BR /> As shielded VMs running Windows use BitLocker to encrypt their OS volume, the BitLocker key is sealed to the vTPM.&nbsp; It is therefore possible in rare cases for the shielded VM to trip BitLocker recovery.&nbsp; Since guarded fabrics do NOT automate the creation or backup of BitLocker recovery keys, it is important to understand that this requirement exists for shielded VMs and must be met through normal Windows operational procedures.&nbsp; If BitLocker recovery is tripped and you do not possess the recovery keys, then the OS volume cannot be decrypted and the VM will no longer boot. <BR /> <H2> Summary </H2> <BR /> <TABLE> <TBODY><TR> <TD> <BR /> <H3> <STRONG> Lost artifact </STRONG> </H3> <BR /> </TD> <TD> <BR /> <H3> <STRONG> Can it be recreated? </STRONG> </H3> <BR /> </TD> <TD> <BR /> <H3> <STRONG> Details </STRONG> </H3> <BR /> </TD> <TD> <BR /> <H3> <STRONG> Impact&nbsp;if <BR /> irrecoverable </STRONG> </H3> <BR /> </TD> </TR> <TR> <TD> Shielding Data File &nbsp;(PDK file) </TD> <TD> Yes </TD> <TD> Assuming you still have <BR /> everything that went inside it </TD> <TD> Annoyance </TD> </TR> <TR> <TD> </TD> <TD> </TD> <TD> </TD> <TD> </TD> </TR> <TR> <TD> Shielded Template Disk </TD> <TD> Yes </TD> <TD> Rebuild the template disk and <BR /> run the Template Disk Signing <BR /> wizard against it </TD> <TD> Annoyance </TD> </TR> <TR> <TD> </TD> <TD> </TD> <TD> </TD> <TD> </TD> </TR> <TR> <TD> Volume Signature Catalog <BR /> (VSC file) </TD> <TD> Yes </TD> <TD> Re-export it from its parent <BR /> shielded template disk </TD> <TD> Annoyance </TD> </TR> <TR> <TD> </TD> <TD> </TD> <TD> </TD> <TD> </TD> </TR> <TR> <TD> vTPM </TD> <TD> No </TD> <TD> Each VM's vTPM is unique and <BR /> changes frequently over its <BR /> entire lifetime </TD> <TD> Possible data loss </TD> </TR> <TR> <TD> </TD> <TD> </TD> <TD> </TD> <TD> </TD> </TR> <TR> <TD> Guardian </TD> <TD> Yes </TD> <TD> Obtain the encryption and <BR /> signing certificates used to create <BR /> the guardian and recreate it </TD> <TD> Annoyance </TD> </TR> <TR> <TD> </TD> <TD> </TD> <TD> </TD> <TD> </TD> </TR> <TR> <TD> BitLocker Recovery Key </TD> <TD> No </TD> <TD> If a shielded VM has tripped into <BR /> BitLocker recovery and you do not <BR /> have the recovery key, all encrypted <BR /> volumes are lost </TD> <TD> Visit <A href="#" target="_blank"></A> <BR /> and update your resume </TD> </TR> </TBODY></TABLE> </BODY></HTML> Fri, 15 Mar 2019 23:11:50 GMT Dean Wells 2019-03-15T23:11:50Z Shielded VMs: A conceptual review of the components and steps necessary to deploy a guarded fabric <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Mar 14, 2017 </STRONG> <BR /> <EM> [This post was authored by Dean Wells, Principal Program Manager on the Windows Server team] </EM> <BR /> <BR /> If you're anything like me, you probably find it immensely helpful having an end-to-end conceptual view of what you're doing before actually doing it--that's the purpose of this blog. <BR /> <BR /> Deploying a guarded fabric involves several new concepts so, in this blog, we'll describe each of the pieces including what it does, any specific requirements, their relative sequence, and point you to the cmdlet used to complete each step. <BR /> <BR /> For simplicity, let's start with something we already understand: an existing Hyper-V fabric running on Windows Server 2012 R2. We'll walk through the process of converting (upgrading and augmenting) this into a Windows Server 2016 guarded fabric (note that <EM> guarded fabric </EM> is the term we use to describe a fabric that can run shielded VMs). <BR /> <H2> Step 1: Upgrade Hyper-V hosts to Windows Server 2016 </H2> <BR /> At minimum, shielded VMs require that the Hyper-V hosts run Windows Server Datacenter edition. We recommend using Server Core, but you can also use the full desktop experience if you like. If you are upgrading hosts, it's also worth noting that you can upgrade from Standard edition to Datacenter edition. <BR /> <BR /> <IMG src="" /> <BR /> <H2> Step 2: Deploy and set up the Host Guardian Service (HGS) </H2> <BR /> The Host Guardian Service is a new role in Windows Server 2016 (both Standard and Datacenter editions). HGS remotely measures Hyper-V host health via a process known as attestation and releases keys based on that health assessment. HGS is typically deployed as a 3-node bare-metal cluster for high availability and scale purposes. <BR /> <BR /> The keys needed by Hyper-V to work with shielded VMs are stored on HGS. Since the Hyper-V hosts don't persistently store these keys, they must ask HGS for them whenever a shielded VM is powered on or when receiving a shielded VM through live migration. For HGS to release a key to Hyper-V, the request must be accompanied by a trustworthy, non-expired certificate of health. Hyper-V obtains the health certificate upon successful completion of attestation. The health certificate lasts for up to 8 hours. The method used by HGS to determine a Hyper-V host's health is dependent upon HGS' attestation mode. There are exactly two mutually-exclusive modes which we'll discuss in the next section. <BR /> <BR /> <BR /> <BR /> <IMG src="" /> <BR /> <BR /> <BR /> <BR /> We begin by adding the HGS role and providing initial configuration information. <BR /> <TABLE> <TBODY><TR> StepCmdlet </TR> <TR> <TD> Add the HGS role </TD> <TD> <CODE> Install-WindowsFeature </CODE> (or use Server Manager) </TD> </TR> <TR> <TD> Install and configure HGS </TD> <TD> <CODE> Install-HgsServer </CODE> </TD> </TR> </TBODY></TABLE> <BR /> <H2> </H2> <BR /> <H2> Step 3: Prepare and initialize HGS </H2> <BR /> The HGS role is now installed but it's not yet initialized. Initializing HGS is really all about two things: selecting the certificates used to protect shielded VMs and configuring HGS' attestation mode. As noted earlier, HGS supports precisely two attestation modes: <BR /> <UL> <BR /> <LI> TPM-based attestation </LI> <BR /> <LI> AD-based attestation </LI> <BR /> </UL> <BR /> <EM> TPM-based attestation </EM> is the preferred choice because it imposes stringent cryptographically-enforced health requirements on hosts before releasing the keys they need to work with shielded VMs. Specifically, we leverage a TPM-backed identity, UEFI secure &amp; measured boot as well as&nbsp;our latest and greatest hypervisor-enforced code integrity policies. This mode of attestation requires that each Hyper-V host support UEFI 2.3.1 revision C or later and TPM v2. This hardware is readily available from most major OEMs. If you do not yet have hardware that supports UEFI 2.3.1c and TPM 2.0, you can still deploy shielded VMs using AD-based attestation. <BR /> <BR /> <EM> AD-based attestation </EM> uses Active Directory security groups to assess health. A fabric admin creates or designates a group in the fabric Active Directory domain and adds each of the trusted Hyper-V hosts (the computer accounts) to that group. Finally, they tell HGS which security groups are deemed trustworthy. With this mode of attestation, HGS does not check for Secure Boot or code integrity policies on the host, instead, it simply examines the host's group membership. This mode provides encryption at rest and on the wire but offers no protection from malware or malicious administrators on the Hyper-V hosts. <BR /> <BR /> Deploying a guarded fabric using AD-based attestation still offers a significant value in terms of security and compliance. In some cases, deploying sensitive workloads that are subject to regulatory controls in shielded VMs will allow you to meet compliance requirements with your existing server hardware. <BR /> <BR /> <STRONG> Note: </STRONG> once suitable server hardware has been obtained, HGS permits you to switch from AD mode to TPM mode using a single command. <BR /> <TABLE> <TBODY><TR> StepCmdlet </TR> <TR> <TD> Initialize the HGS server </TD> <TD> <CODE> Initialize-HgsServer </CODE> </TD> </TR> <TR> <TD> Switch from AD-based attestation to TPM-based attestation </TD> <TD> <CODE> Set-HgsServer -TrustTpm </CODE> </TD> </TR> </TBODY></TABLE> <BR /> <BR /> <BR /> For the purposes of this blog, we'll continue to walk through a TPM-based attestation deployment. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> <BR /> <BR /> As we noted earlier, for TPM-based attestation, three things must be collected from Hyper-V hosts: <BR /> <OL> <BR /> <LI> <EM> TPM identity </EM> . The public endorsement key (or EKpub) from the TPM 2.0 module on each Hyper-V host is used to uniquely identify each legitimate host. <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <TABLE> <TBODY><TR> StepCmdlet </TR> <TR> <TD> Capture the EKpub </TD> <TD> <CODE> Get-PlatformIdentifier </CODE> </TD> </TR> <TR> <TD> Add the captured EKpub to HGS </TD> <TD> <CODE> Add-HgsAttestationTpmHost </CODE> </TD> </TR> </TBODY></TABLE> <BR /> . </LI> <BR /> <LI> <EM> Hardware baseline. </EM> A baseline is recorded in the form of a Trusted Computing Group log file, or TCGlog. The TCGlog contains measurements representing anything security-sensitive that the host did or executed beginning with booting up from the UEFI firmare, on and up through drivers and the kernel until the host is all but ready to go. If each of your Hyper-V hosts are identical, then a single baseline is all you need. If they are not, then you'll need one for each class of hardware. To create the baseline, simply configure a Hyper-V host to your satisfaction (think golden image or a clean room setup) and extract the baseline from it. Ensure the <EM> Host Guardian Hyper-V Support </EM> feature is installed on your Hyper-V host before continuing. <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <TABLE> <TBODY><TR> StepCmdlet </TR> <TR> <TD> Capture the hardware baseline </TD> <TD> <CODE> Get-HgsAttestationBaselinePolicy </CODE> </TD> </TR> <TR> <TD> Add the baseline to HGS </TD> <TD> <CODE> Add-HgsAttestationTpmPolicy </CODE> </TD> </TR> </TBODY></TABLE> <BR /> . </LI> <BR /> <LI> <EM> Code integrity policy </EM> . Windows Server 2016 and Windows 10 both have a new form of enforcement for CI policies, called <EM> hypervisor-enforced code integrity (HVCI) </EM> . HVCI provides stronger enforcement and ensures that a host is only allowed to run binaries (including drivers and other kernel-mode components) that a trusted admin has allowed it to run. If each of your Hyper-V hosts are identical, then a single CI policy is all you need. If they are not, then you'll need one for each unique software configuration. To create the policy, configure the <EM> golden image </EM> host used in step 2 with all the software, agents, and updates you will use in production and extract a CI policy. You'll need to copy this file to a special folder and reboot each host in order for the policy to take effect. <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <BR /> <TABLE> <TBODY><TR> StepCmdlet </TR> <TR> <TD> Capture a CI policy from a <EM> golden image </EM> </TD> <TD> <CODE> New-CIPolicy </CODE> </TD> </TR> <TR> <TD> Convert the policy to a binary form consumed by HGS and Windows </TD> <TD> <CODE> ConvertFrom-CIPolicy </CODE> </TD> </TR> <TR> <TD> Add the CI policy to HGS </TD> <TD> <CODE> Add-HgsAttestationCIPolicy </CODE> </TD> </TR> </TBODY></TABLE> <BR /> </LI> <BR /> </OL> <BR /> In terms of the infrastructure required to run shielded VMs, you're done! HGS is now able to validate that each host's EKpub, TCGlog and CI policy match with its whitelisted inventory before issuing a health certificate. <BR /> <BR /> Now let's briefly walk through creating a shielded VM template disk and a shielding data file so that we can provision shielded VMs simply and securely on the fabric we just built. <BR /> <H2> Step 4: Create a template for shielded VMs </H2> <BR /> A shielded VM template protects template disks by creating a signature of the OS volume at a known trustworthy point in time. If the template disk is later infected by malware, its signature will differ and cause the shielded VM provisioning process to abort creation. Shielded template disks are created by running the <EM> Shielded Template Disk Creation Wizard </EM> against a regular template disk. <BR /> <BR /> The wizard is included with the <EM> Shielded VM Tools </EM> feature in Windows Server 2016 Remote Server Administration Tools, and the <A href="#" target="_blank"> Windows 10 Remote Server Administration Tools </A> package. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> <BR /> <BR /> A trustworthy administrator, such as the fabric administrator or VM owner, will need a signing certificate to create the disk signature. The disk signature is computed by hashing every sector of the OS volume on the template disk. If anything changes on the OS partition, the hash of the volume will also change. This process allows users creating shielded VMs on the fabric to place high levels of trust in the template disks and the shielded VMs that are born from them. <BR /> <H2> Step 5: Create a shielding data file </H2> <BR /> A shielding data file, sometimes called a PDK file after its file extension, stores and encrypts sensitive information used during shielded VM creation such as&nbsp;a collection of template disk signing certificates that the VM owner trusts, the administrator password of the new shielded VM, RDP certificates, and so on. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> The shielding data file also includes the security policy setting for the shielded VM. You must choose one of two security policies when you create a shielding data file: <BR /> <UL> <BR /> <LI> <STRONG> Shielded </STRONG> : the most secure option, which eliminates many administrative attack vectors </LI> <BR /> <LI> <STRONG> Encryption supported </STRONG> : a lesser level of protection that still provides the compliance benefits of being able to encrypt a VM, but allows Hyper-V admins to do things like using the VM console connection and PowerShell Direct. </LI> <BR /> </UL> <BR /> <IMG src="" /> <BR /> <BR /> At this stage, you can add optional management components like VMM or Windows Azure Pack. If you'd prefer not to, you can also create a shielded VM using PowerShell alone, as demonstrated in the <A href="#" target="_blank"> Step by step - Creating shielded VMs without VMM </A> blog. You're now ready to deploy your first shielded VM. <BR /> <H2> Step 6: Creating a shielded VM </H2> <BR /> Creating shielded virtual machines differs very little from regular virtual machines. In Windows Azure Pack, the experience is even easier than creating a regular VM because you only need to supply a name, shielding data file (containing the rest of the specialization information), and the VM network. <BR /> <BR /> <IMG src="" /> <BR /> <H2> Learn more </H2> <BR /> The steps discussed in this blog are also covered in a video that shows the required syntax of each step and concludes with deploying a shielded VM. You can find the video here: <A href="#" target="_blank"> Deploying shielded VMs and a guarded fabric with Windows Server 2016 </A> . <BR /> <BR /> To get started deploying shielded VMs in your own environment, check out our <A href="#" target="_blank"> planning and deployment guides </A> . </BODY></HTML> Fri, 15 Mar 2019 23:11:46 GMT RyanWillis 2019-03-15T23:11:46Z Step by Step: Creating a JEA endpoint for DNS management <P><STRONG> First published on TECHNET on Mar 07, 2017 </STRONG></P> <P><BR />Just Enough Administration (JEA) provides a way for administrators to delegate certain admin tasks to non-administrators using PowerShell. Unlike some of the other built-in delegation solutions in Windows, JEA is not tied to a particular product or service. You can create custom roles in JEA that allow users to manage any software on the system. In this blog post, we'll&nbsp;show you&nbsp;how to create a JEA endpoint for managing a DNS server that is co-located on an Active Directory Domain Controller. <BR /><BR />For a quick refresher on JEA and the scenario we're solving for, check out the 6 minute video below.</P> <P><BR /><LI-VIDEO vid="" align="center" size="small" width="200" height="113" uploading="false" thumbnail="" external="url"></LI-VIDEO></P> <DIV>&nbsp;</DIV> <H2>Prerequisites</H2> <P><BR />Before you get started, ensure you have an instance of Windows Server running the Microsoft DNS Server&nbsp;role available to you. We recommend Windows Server 2016, but the same steps apply if you're using Windows Server 2012 or 2012 R2 and have <A href="#" target="_blank" rel="noopener"> Windows Management Framework 5.1 </A> installed. You will also need a domain administrator account to register the JEA endpoint on the server. <BR /><BR /><EM> Note: JEA supports Windows Server 2008 R2 as well, but the DNS Server PowerShell module is&nbsp;not available for 2008 R2. </EM> </P> <P>&nbsp;</P> <H2>Planning for JEA</H2> <P><BR />Before you can create a JEA endpoint, you need to know two things: </P> <UL> <LI>Which commands do users need to run on this system?</LI> <LI>Who are the users that should be able to run those commands?</LI> </UL> <P>To determine this information, you should meet with your operations team (DNS admins) and security team to figure out the right balance of convenience and security for your particular organization. The following DNS-related tasks probably come to mind when&nbsp;figuring out what DNS admins need to do:</P> <P>&nbsp;</P> <UL> <LI>Checking the DNS server state and configuration</LI> <LI>Creating, Reading, Updating, and Deleting DNS records and forwarders</LI> <LI>Clearing the DNS server cache</LI> <LI>Restarting the DNS service</LI> <LI>Viewing DNS events in the event log</LI> </UL> <P>&nbsp;</P> <P>With those tasks clearly defined, you&nbsp;then need to find the PowerShell modules, functions, scripts, and command line executables admins need to use to accomplish the tasks. For the DNS server, these are usually handled by: <BR /><BR /></P> <UL> <LI>dnscmd.exe</LI> <LI>Add/Get/Set/Remove-DnsServerForwarderDnsServer PowerShell module </LI> </UL> <UL> <UL> <LI>Get/Set-DnsServer</LI> </UL> <UL> <LI>Add/Get/Set/Remove-DnsServerResourceRecord</LI> </UL> <LI>net.exe or the&nbsp;Restart-Service PowerShell cmdlet</LI> <LI>Get-WinEvent</LI> </UL> <P><BR />Next, we need to filter the list of commands to remove any potentially dangerous commands. This includes any commands which could give a DNS admin the ability to control things outside of the DNS server on the system and special invocations of seemingly-good commands which could have unintended side effects. <BR /><BR /></P> <UL> <LI>net.exe should not be allowed in a JEA session, because it could allow a DNS admin to add themselves to a privileged security group, open up a file share, and more</LI> <LI>Restart-Service should only allow the DNS admin to restart the DNS Server, not any other services on the machine</LI> <LI>dnscmd.exe is appropriate for DNS admins, but allows users to both read and change the DNS server configuration. When you allow non-PowerShell programs in a JEA session, users can use any parameters they want, potentially&nbsp;allowing those in a "viewer" role to make changes.</LI> <LI>Get-WinEvent should only let DNS admins review DNS logs, not arbitrary application event logs. Sensitive information can sometimes be logged, especially on a domain controller, so it is best to limit the DNS admins to only viewing relevant logs to them.</LI> </UL> <P><BR />Lastly, we need to consider the various roles a DNS admin may need. Should all users with access to the DNS server be treated as admins, or are there also people who just need to view the configuration or make small changes? For this example, we'll assume there are two types of DNS admins: those who just need read access to the data, and those who can make changes to the DNS server. We'll group the commands under each role, and use those in the next step to create 2 role capability files. <BR /><BR /><STRONG> DNS Viewers </STRONG> - need access to the&nbsp;"Get" commands from the DnsServer PowerShell module. They also should be able to review the DNS events in the event log. <BR /><BR /><STRONG> DNS Admins </STRONG> - need access to all DnsServer commands, including Add/Set/Remove. Additionally, they should be able to restart the DNS service. </P> <P>&nbsp;</P> <H2>Creating&nbsp;role capability files</H2> <P><BR />Now that we have the list of commands defined, it's time to create JEA roles that represent the set of allowable commands. This is trivial to do using the <A href="#" target="_blank" rel="noopener"> New-PSRoleCapabilityFile </A> cmdlet. The below lines should be run in an elevated PowerShell prompt on the DNS server. You can also create the role capability files on another computer and copy them to a PowerShell module folder on the DNS server when you are ready to deploy JEA. <BR /><BR /></P> <PRE class="prettyprint linenums lang-bsh" title="JEA Step by Step: Creating Role Capabilities"># Create a module in Program Files for the JEA roles $modulePath = "$env:ProgramFiles\WindowsPowerShell\Modules\JEARoles" New-Item $modulePath -ItemType Directory -Force New-ModuleManifest -Path (Join-Path $modulePath "JEARoles.psd1") -Description "Contains custom JEA Role Capabilities" # Create a folder for the role capabilities $roleCapabilityPath = Join-Path $modulePath "RoleCapabilities" New-Item $roleCapabilityPath -ItemType Directory # Define the function for getting only DNS Server events $dnsEventFnDef = @{ Name = 'Get-DnsServerLog' ScriptBlock = { param([long]$MaxEvents = 100) Get-WinEvent -ProviderName "Microsoft-Windows-Dns-Server-Service" -MaxEvents $MaxEvents } } # Create the DNS Viewer role capability New-PSRoleCapabilityFile -Path (Join-Path $roleCapabilityPath "DnsViewer.psrc") -VisibleCmdlets "DnsServer\Get-*" -VisibleFunctions "Get-DnsServerLog" -FunctionDefinitions $dnsEventFnDef # Create the DNS admin role capability New-PSRoleCapabilityFile -Path (Join-Path $roleCapabilityPath "DnsAdmin.psrc") -VisibleCmdlets "DnsServer\*", @{ Name = "Restart-Service"; Parameters = @{ Name = "Name"; ValidateSet = "Dns" } }</PRE> <P><BR />These commands will perform the following changes: <BR /><BR /></P> <OL> <LI>Create a new PowerShell module named "JEARoles" in the Program Files directory. You can change this name if you'd like.</LI> <LI>Create a RoleCapabilities subdirectory, where Role Capabilities can be found by JEA.</LI> <LI>Define a new custom function, called Get-DnsServerLog, which gets the DNS events from the event log.</LI> <LI>Create the DnsViewer role capability file, which allows any "Get" command from the DnsServer module as well as the custom Get-DnsServerLog function we defined.</LI> <LI>Create the DnsAdmin role capability file, which allows all commands from the DnsServer module as well as Restart-Service (but only for the DNS service).</LI> </OL> <P>You can add, remove, or change role capabilities at any time. They just need to be uniquely named and located in a subfolder named "RoleCapabilities" inside a valid PowerShell module. </P> <P>&nbsp;</P> <H2>Creating a session configuration file</H2> <P><BR />After creating your roles, you're ready to define the mapping between users and roles. To complete this step, you'll need to create two security groups: one holding users who should have view-only rights and one for users who should be full DNS admins. We'll also set up transcripts in the session configuration file so that users' actions are logged on the system for review during security audits. <BR /><BR />Lastly, we'll register the session configuration on the computer. This will create a new PowerShell endpoint that users can connect to and manage the DNS server. This process will restart WinRM and disconnect any users currently managing the system, so be sure to do this during a scheduled maintenance window. <BR /><BR /></P> <PRE class="prettyprint linenums lang-bsh" title="JEA Step by Step: Creating session configuration"># Pick location for file and security groups $jeaConfigPath = "$env:ProgramData\JEAConfiguration" $viewerGroup = "CONTOSO\JEA-DNS-Viewers" $adminGroup = "CONTOSO\JEA-DNS-Admins" # Create the session configuration file New-Item $jeaConfigPath -ItemType Directory -Force New-PSSessionConfigurationFile -Path (Join-Path $jeaConfigPath "JeaDnsConfig.pssc") -SessionType RestrictedRemoteServer -TranscriptDirectory (Join-Path $jeaConfigPath "Transcripts") -RunAsVirtualAccount -RoleDefinitions @{ $viewerGroup = @{ RoleCapabilities = 'DnsViewer' }; $adminGroup = @{ RoleCapabilities = 'DnsViewer', 'DnsAdmin' } } # Register the session configuration file Register-PSSessionConfiguration -Name DnsAdministration -Path (Join-Path $jeaConfigPath "JeaDnsConfig.pssc") -Force</PRE> <P>The session configuration file has a few important settings:</P> <UL> <LI><STRONG>SessionType </STRONG> determines whether PowerShell should provide all or none of its regular features to users. Since JEA operates under a whitelist model, we use RestrictedRemoteServer to instruct PowerShell to take away all commands except those explicitly permitted by role capabilities. Additionally, the file system, registry, certificate store, and other providers are removed and the PowerShell language is turned off to prevent users from pasting in their own code to bypass JEA restrictions.</LI> <LI><STRONG> TranscriptDirectory </STRONG> instructs PowerShell to save a full log of every command a user enters when managing the server with this JEA endpoint to a file in the specified folder. This is particularly useful when you need to audit what users did on a server.</LI> <LI><STRONG> RunAsVirtualAccount </STRONG> is what tells JEA to use a temporary, privileged account (virtual account) to execute the commands on the user's behalf. This is how a non-admin is able to run elevated commands.</LI> <LI><STRONG> RoleDefinitions </STRONG> specifies the mapping between users/groups and JEA roles. JEA roles are specified by their file name, without the .psrc file extension ( <EM> DnsViewer </EM> and <EM> DnsAdmin </EM> , in our case). You should ensure role capabilities are named uniquely on your system to avoid conflicts.</LI> </UL> <P>&nbsp;</P> <H2>Use JEA</H2> <P><BR />Once JEA is registered on the server, you're ready to use it! On another machine, substitute in your server's name and run the following command to enter an interactive PowerShell session using the DnsAdministration endpoint created in the last step. </P> <P>&nbsp;</P> <PRE><CODE>Enter-PSSession -ConfigurationName DnsAdministration</CODE></PRE> <P><BR />You will only be able to connect successfully if your user account belongs to the <STRONG> JEA-DNS-Viewers </STRONG> or <STRONG> JEA-DNS-Admins </STRONG> security group. You can then run <STRONG> Get-Command </STRONG> to see the limited set of commands available to you.</P> <P>&nbsp;</P> <H2>Learn more</H2> <P><BR />That's it! Once you figure out&nbsp;who your admins are and what commands they need access to, setting up JEA is straightforward. To learn more about JEA and start creating endpoints for your own environment, check out the <A href="#" target="_blank" rel="noopener"> JEA documentation </A> and <A href="#" target="_blank" rel="noopener"> GitHub samples </A> for further inspiration. You can also download the DnsViewer and DnsAdmin role capabilities created in this blog from the GitHub repository.</P> Wed, 08 Jan 2020 21:08:51 GMT RyanWillis 2020-01-08T21:08:51Z Join Host Guardian Servers to an existing bastion forest <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Mar 07, 2017 </STRONG> <BR /> Shielded VM prevents unauthorized access from the host. To achieve this security assurance, there must be a role separation between the fabric admins (who manage the Guarded Hosts) and the HGS admins (who manage the Host Guardian Servers). By default, when you install the first HGS server, it will create its own forest, this will prevent a single user account (i.e. domain admin account) having full control of both the guarded hosts and the host guardian servers. <BR /> <BR /> If you already have an existing bastion forest, and want to join the Host Guardian servers to it, you need to consider how you can separate the roles between fabric admins and HGS admins. In a simple analogy, fabric admins have access to the door of a container where shielded VMs live, and HGS admins have access to the key opens that door. If one single account can access to both the key and the door, he can access the shielded VM, this breaks the shielded VM security assurance goal. <BR /> <BR /> In working with some customers who have deployed <A href="#" target="_blank"> ESAE (Enhanced Security Administrative Environment) forest </A> , I learnt the steps on how you can deploy HGS in the ESAE forest, and like to share the details in this blog post. <BR /> <BR /> A few things to consider before deployment: <BR /> <OL> <BR /> <LI> In this blog post, I will use ESAE forest as an example. The steps are applicable to join HGS to any existing bastion forest. The security risks need to be evaluated, especially around fabric admin and HGS admin role separation. </LI> <BR /> <LI> Specific to ESAE forest, because the RedCard admin (domain admin of the ESAE forest) will have full control over the production domain, the usage of RedCard admin privilege should be highly restricted and protected as this account holds both the key and has access to the door. </LI> <BR /> <LI> There are three deployment options. Thanks to Andrej Budja who has created the following nice table to put the options into comparison. If you choose option #1, you can follow the <A href="#" target="_blank"> deployment guide </A> , published TechNet to deploy HGS. The guide provides detailed instructions from planning to the actual steps of <A href="#" target="_blank"> setting HGS servers </A> , which will create its own forest. If you choose option #2 or #3, the guide has a reference to <A href="#" target="_blank"> Initialize HGS in an existing bastion forest </A> , and lists the requirements before adding HGS to the existing forest. This blogpost provides the details on what and how to create those objects to deploy HGS in ESAE environment; I did not cover the host deployment in ESAE forest, because it should follow the ESAE guide to deploy servers in ESAE. </LI> <BR /> </OL> <BR /> <TABLE> <TBODY><TR> <STRONG> Deployment options: </STRONG> <STRONG> #1: Guarded hosts in the production domain, HGS in a dedicated bastion forest (not in ESAE forest) </STRONG> <STRONG> #2: Guarded hosts in the production domain; HGS in the ESAE forest </STRONG> <STRONG> #3: Guarded hosts and HGS are in the ESAE forest </STRONG> </TR> <TR> <TD> <STRONG> Infrastructure </STRONG> </TD> <TD> <BR /> <UL> <BR /> <LI> Guarded Hyper-V Servers joined to the production domain; </LI> <BR /> <LI> HGS Servers deployed in a separate forest (default HGS deployment configuration per <A href="#" target="_blank"> deployment guide </A> ) </LI> <BR /> <LI> HGS forest has a one-way trust with the production domain (covered in the deployment guide) </LI> <BR /> <LI> HGS Servers use a certificate from public CA or certificate from a CA <STRONG> independent </STRONG> from the production domainHGS PAWs in the HGS forest. </LI> <BR /> </UL> <BR /> </TD> <TD> <BR /> <UL> <BR /> <LI> Guarded Hyper-V Servers joined to the production domain; </LI> <BR /> <LI> HGS Servers deployed in the ESAE forest </LI> <BR /> <LI> ESAE forest has a one-way trust with the production domain [In addition to the trust, ESAE forest fully managed the production forest] This is ESAE deployment guideline, orthogonal to HGS deployment </LI> <BR /> <LI> HGS Servers use a certificate from ESAE CA </LI> <BR /> </UL> <BR /> </TD> <TD> <BR /> <UL> <BR /> <LI> Hyper-V Servers joined to the ESAE forest </LI> <BR /> <LI> HGS Servers deployed in the ESAE forest </LI> <BR /> <LI> HGS Servers use a certificate from ESAE CA </LI> <BR /> </UL> <BR /> </TD> </TR> <TR> <TD> <STRONG> Admin model </STRONG> </TD> <TD> <BR /> <UL> <BR /> <LI> Tier1Operators are local admins on the Hyper-V hosts </LI> <BR /> <LI> Tier1Operators use Tier 1 PAW to manage Hyper-V hosts </LI> <BR /> <LI> Tier1Operators do NOT have access to the VM workload </LI> <BR /> <LI> HGS servers managed by HGS DAs </LI> <BR /> <LI> HGS Admins are local admins on the HGS Servers </LI> <BR /> <LI> HGS Admins use dedicated HGS PAWs to manage HGS forest </LI> <BR /> <LI> HGS PAWs are joined to the HGS forest </LI> <BR /> </UL> <BR /> </TD> <TD> <BR /> <UL> <BR /> <LI> Tier1Operators are local admins on the Hyper-V host </LI> <BR /> <LI> Tier1Operators use a Tier 1 PAW to manage Hyper-V Servers </LI> <BR /> <LI> Tier1Operators do NOT have access to the VM workload </LI> <BR /> <LI> HGS Admins are local admins on HGS Servers </LI> <BR /> <LI> HGS Admins use ESAE admin workstations to manage HGS Servers </LI> <BR /> <LI> HGS Admins use a smartcard to logon to the ESAE forest </LI> <BR /> <LI> ESAE GoldCard Admins manage the production DCs </LI> <BR /> <LI> ESAE GoldCard Admins use ESAE admin workstation. </LI> <BR /> <LI> ESAE forest is managed by &nbsp;ESAE RedCard Admins </LI> <BR /> </UL> <BR /> </TD> <TD> <BR /> <UL> <BR /> <LI> RedCard Admins are local admins on the Hyper-V host </LI> <BR /> <LI> Hyper-V Admins are local admins on the Hyper-V hosts </LI> <BR /> <LI> Hyper-V admins use ESAE admin workstation to manage Hyper-V Servers. </LI> <BR /> <LI> Hyper-V Admins do NOT have access to the VM workload </LI> <BR /> <LI> HGS Admins are local admins on HGS Servers </LI> <BR /> <LI> HGS Admins use ESAE admin workstations to manage HGS Servers </LI> <BR /> <LI> ESAE GoldCard Admins manage the production DCs. </LI> <BR /> <LI> ESAE GoldCard Admins use ESAE admin workstation. </LI> <BR /> <LI> ESAE forest is managed by &nbsp;ESAE RedCard Admins </LI> <BR /> </UL> <BR /> </TD> </TR> <TR> <TD> <STRONG> Residual Risk </STRONG> </TD> <TD> <BR /> <UL> <BR /> <LI> Secure deployment of the bastion forest (default HGS deployment) </LI> <BR /> <LI> Secure operations (PAWs) of the bastion forest </LI> <BR /> </UL> <BR /> </TD> <TD> <BR /> <UL> <BR /> <LI> RedCard Admins control HGS Admins AND Tier1Operators (allowing them access to the doors and keys) </LI> <BR /> <LI> HGS Admins have local administrator permissions on HGS Servers inside ESAE (can attack ESAE from within ESAE) </LI> <BR /> <LI> More users in ESAE </LI> <BR /> <LI> Increased attack surface for ESAE </LI> <BR /> </UL> <BR /> </TD> <TD> <BR /> <UL> <BR /> <LI> RedCard Admins control HGS Admins AND Hyper-V Servers (allowing them access to the doors and keys) </LI> <BR /> <LI> Hyper-V Admins have local administrator permissions on Hyper-V Servers inside ESAE (can attack ESAE from within ESAE) </LI> <BR /> <LI> HGS Admins have local administrator permissions on HGS Servers inside ESAE (can attack ESAE from within ESAE) </LI> <BR /> <LI> Even more users in ESAE </LI> <BR /> <LI> Increased attack surface for ESAE </LI> <BR /> </UL> <BR /> </TD> </TR> <TR> <TD> <STRONG> Recommendation order </STRONG> </TD> <TD> 1 </TD> <TD> 2 </TD> <TD> 2 </TD> </TR> </TBODY></TABLE> <BR /> <H2> Prepare the ESAE environment </H2> <BR /> The example used in this blogpost is based on the default ESAE environment offered by Microsoft. Here is a screenshot of the OU structure: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> These objects must be created before you configure the Host Guardian service: <BR /> <TABLE> <TBODY><TR> <TD> Account type </TD> <TD> Account name </TD> <TD> Placed in OU </TD> <TD> Description </TD> </TR> <TR> <TD> User </TD> <TD> HGSAdmin </TD> <TD> Red Card Admin </TD> <TD> The account to manage HGS servers. </TD> </TR> <TR> <TD> Security Group – Global </TD> <TD> HGSAdmins </TD> <TD> Groups </TD> <TD> Members of this group are full admins of the Host Guardian (HGS) servers and services. Ensure HGSAdmin is a member of this group. </TD> </TR> <TR> <TD> Security Group – Global </TD> <TD> HGSViewAdmins </TD> <TD> Groups </TD> <TD> Members of this group can view all the configurations of Host Guardian (HGS) services, but do not have permission to change any configurations. HGSAdmin should be a member of this group. </TD> </TR> <TR> <TD> Security Group – Domain Local </TD> <TD> HGSgMSAUsers </TD> <TD> Groups </TD> <TD> Members of this group are HGS server cluster nodes which are part of the same HGS cluster, so they can use the same gMSA account to access the KPS service. </TD> </TR> <TR> <TD> Organizational Unit </TD> <TD> HGS Servers </TD> <TD> Servers </TD> <TD> This will contain all the HGS related computer objects. Ensure to add the HGSAdmins to have full control of the OU, and HGSViewAdmins to have read access to the OU. </TD> </TR> <TR> <TD> Computer </TD> <TD> HGSSvr </TD> <TD> HGS Servers </TD> <TD> HGS server computer object account, must be a member of HGSgMSAUsers group. The object name must match the HGS server name in order to allow the HGS server joining to the domain. <BR /> Ensures the HGSAdmins has full control on the object. </TD> </TR> <TR> <TD> Computer </TD> <TD> HGSCluster </TD> <TD> HGS Servers </TD> <TD> HGS ClusterEnsures the HGSAdmins has full control on the object. </TD> </TR> <TR> <TD> Computer </TD> <TD> HGSSvcs </TD> <TD> HGS Servers </TD> <TD> HGS VCO (Both HGSCluster and HGSSvcs are pre-stage per this article: <A href="#" target="_blank"> </A> Ensures the HGSAdmins has full control on the object. </TD> </TR> <TR> <TD> msDS-Group ManagedServiceAccount </TD> <TD> HGSgMSA </TD> <TD> Service Accounts </TD> <TD> HGS servers use this account to access the KPS service across HGS nodes.You can use the script below to create this account </TD> </TR> </TBODY></TABLE> <BR /> [snippet slug=creategmsa line_numbers=false lang=bsh] <BR /> <BR /> In addition, you should not use domain admin account for HGS server management. You should use the account in the HGSAdmins security group, and create a group policy to add HGSAdmins to each of the HGS server local administrator group: <BR /> <BR /> <IMG src="" /> <BR /> <H2> Setting up HGS </H2> <BR /> <OL> <BR /> <LI> <STRONG> Joining the ESAE domain </STRONG> : </LI> <BR /> </OL> <BR /> Logon the HGS server using a local administrator first and join the HGS server to ESAE domain: <BR /> <EM> Add-Computer -DomainName -Credential (Get-Credential) </EM> <BR /> Restart the computer; <BR /> <OL> <BR /> <LI> <STRONG> Configure HGS </STRONG> : </LI> <BR /> </OL> <BR /> Logon the HGS server using the HGSAdmin account (which should be a member of the machine local administrator group) <BR /> <UL> <BR /> <LI> Install HGS feature: </LI> <BR /> </UL> <BR /> <EM> Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart </EM> <BR /> <UL> <BR /> <LI> Specify the signing and encryption certificates that HGS will use (you can find more details <A href="#" target="_blank"> here </A> ) </LI> <BR /> </UL> <BR /> For testing, I used self-signed certs: <BR /> <EM> $certificatePassword = ConvertTo-SecureString -AsPlainText '&lt;password&gt;' –Force </EM> <BR /> <BR /> <EM> $signingCert = New-SelfSignedCertificate -DnsName "" </EM> <BR /> <BR /> <EM> Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath 'C:\signingCert.pfx' </EM> <BR /> <BR /> <EM> $encryptionCert = New-SelfSignedCertificate -DnsName "" </EM> <BR /> <BR /> <EM> Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath 'C:\encryptionCert.pfx' </EM> <BR /> <UL> Add Service account </UL> <BR /> <EM> Install-ADServiceAccount 'HgsGMSA' </EM> <BR /> <UL> <BR /> <LI> <STRONG> Initialize HGS </STRONG> : </LI> <BR /> </UL> <BR /> <EM> Initialize-HgsServer -UseExistingDomain -ClusterName HGSCluster -HgsServiceName HgsSvcs -JeaAdministratorsGroup HGSAdmin -JeaReviewersGroup HGSViewAdmin -ServiceAccount HGSgMSA @certParameters &nbsp;-TrustTPM </EM> <BR /> After initialization, you can follow the <A href="#" target="_blank"> deployment guide </A> for further configuration of the guarded hosts. </BODY></HTML> Fri, 15 Mar 2019 23:10:37 GMT Jian (Jane) Yan 2019-03-15T23:10:37Z Why you should not enable Credential Guard on Domain Controllers? <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Feb 21, 2017 </STRONG> <BR /> Credential guard protects the credential derivatives like NTLM hash and Kerberos tickets; this TechNet <A href="#" target="_blank"> article </A> has a very detailed explanation as well as deployment guidelines. There was a recent change in this article to call out the following: <BR /> <BR /> <BR /> <EM> Warning </EM> <BR /> <EM> Enabling Credential Guard on domain controllers is not supported. The domain controller hosts authentication services which integrate with processes isolated when Credential Guard is enabled, causing crashes. </EM> <BR /> <BR /> <BR /> I would like to share my learnings on why you should not enable Credential Guard on Domain Controllers. <BR /> <BR /> Credential guard protects credentials in LSASS memory; it does not protect credentials stored on disks. On domain controllers, it does not protect credentials that are stored in the active directory SAM database. <BR /> <BR /> In a production environment, you should restrict user access to a domain controller in order to protect the assets on that domain controller. If someone manages to get (unauthorized) access to it, and able to retrieve information in LSASS memory, that means the person already acquired domain admin privilege, and Credential Guard adds no value in that case. <BR /> <BR /> Given that there is no added security benefit, we decided not to support Credential Guard on domain controllers. </BODY></HTML> Fri, 15 Mar 2019 23:10:14 GMT Jian (Jane) Yan 2019-03-15T23:10:14Z Use Windows Server 2016 to secure a jump server <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Feb 02, 2017 </STRONG> <BR /> When talking to customers about the security features in Windows Server 2016, a common question keeps coming up, how do I secure my jump server? Recently, I worked with a Microsoft internal team to deploy Windows Server 2016 on their jump server; I thought it is a good use case to share. <BR /> <H2> Why is it important to secure a jump server? </H2> <BR /> A jump server typically does not store any sensitive data; you may wonder do I really need to secure it? Although it does not have sensitive data on disk, it does have sensitive data in memory. Jump servers enable users to connect and manage servers/services in separate security zones. When establishing the connections, user credentials are stored in memory, and these credentials are attractive targets for credential theft attacks. In addition, if a malicious actor takes over your jump server, they can act on behalf of connected users to take control over the assets that are managed through that jump server. <BR /> <BR /> There are additional protections by ensuring jump server access from a Privileged Access Workstation, you can find more details <A href="#" target="_blank"> here </A> .&nbsp;In this blog post, I would like to focus on leveraging the security features in Windows Server 2016 to better protect against attacks on this server. <BR /> <H2> Hardware requirement </H2> <BR /> Windows Server 2016 (along with Windows 10) introduced a number of security features which require hardware support. If you are considering purchasing new hardware, check the <A href="#" target="_blank"> following </A> : <BR /> <UL> <BR /> <LI> UEFI Secure Boot (optionally with non-Microsoft UEFI CAs removed from the UEFI database&nbsp;) </LI> <BR /> <LI> Virtualization support enabled by default in the system firmware: <BR /> <UL> <BR /> <LI> Virtualization extensions (for example, Intel VT-x, AMD RVI) </LI> <BR /> <LI> SLAT (for example, Intel EPT, AMD RVI) </LI> <BR /> <LI> IOMMU (for example, Intel VT-d, AMD-Vi) </LI> <BR /> <LI> UEFI configured to prevent an unauthorized user from disabling Device Guard–dependent hardware security features (for example, Secure Boot) </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> Kernel mode drivers signed and compatible with hypervisor-enforced code integrity </LI> <BR /> </UL> <BR /> In order to take advantage of the full set of security protections, the server hardware must support all of the above. However, there are some security features which do not require special hardware support, and you should enable these features on your existing hardware when you upgrade to Windows Server 2016: <BR /> <TABLE> <TBODY><TR> <TD> <STRONG> Features </STRONG> </TD> <TD> <STRONG> Can be enabled on existing hardware without hardware support? </STRONG> </TD> </TR> <TR> <TD> Credential Guard </TD> <TD> No </TD> </TR> <TR> <TD> Remote Credential Guard </TD> <TD> Yes </TD> </TR> <TR> <TD> Device Guard-&nbsp; HVCI </TD> <TD> No </TD> </TR> <TR> <TD> Device Guard- Config Code Integrity </TD> <TD> Yes </TD> </TR> <TR> <TD> Security baseline </TD> <TD> Yes </TD> </TR> </TBODY></TABLE> <BR /> <BR /> <H2> Secure configuration </H2> <BR /> A jump server typically runs on dedicated hardware within a physically secure perimeter, running a specific workload. Once deployed, the workload does not change very much. This characteristic makes jump servers a good candidate to lock down the software it trusts. <BR /> <BR /> In the Microsoft internal deployment example, the jump server is designed to enable users to manage services using JEA, and is protected by the following features in Windows Server 2016: <BR /> <UL> <BR /> <LI> <STRONG> Credential guard </STRONG> : Credential guard encrypts the domain credentials (i.e. Kerberos tickets and NTLM hashes) in memory and stores the encryption key in an isolated space which is secured by the&nbsp;hypervisor. By enabling it on the jump server, it can protect users’ domain credentials which are otherwise unencrypted and susceptible to pass the hash attack. For more details about this feature, see <A href="#" target="_blank"> here </A> . </LI> <BR /> </UL> <BR /> Additional considerations: <BR /> <BR /> Credential guard protects only Kerberos and NTLM credentials. If a user logs onto the jump server using a local account, those credentials will not be protected. <BR /> <UL> <BR /> <LI> <STRONG> Remote Credential Guard </STRONG> : In the past, when users RDP to a server, the client would send their credentials (username/password) to the RDP server in order to log them on. Since jump servers are a central point for many different users to logon, the jump server exposes a high risk if an attacker is able to compromise it.&nbsp; With Remote Credential Guard, credentials aren’t actually sent to the jump server.&nbsp; Instead, Remote Credential Guard protects the user credentials by logging on using Kerberos single-sign-on tickets greatly reducing the risk of credential theft. You can find more information <A href="#" target="_blank"> here </A> . </LI> <BR /> </UL> <BR /> Additional considerations: <BR /> <BR /> Remote Credential Guard only works with Kerberos. This means that if the jump server is in a workgroup, or if there is no trust relationship between the user’s logon domain and the jump server&nbsp;’s domain, the connection will use NTLM and Remote Credential Guard will not protect those credentials. In addition, Remote Credential Guard is not supported when using an RDP gateway. <BR /> <BR /> <BR /> <UL> <BR /> <LI> <STRONG> Device guard </STRONG> : Device guard enables administrators to define what software is trusted to run on the system. There are two types of protections: <BR /> <UL> <BR /> <LI> <STRONG> HVCI </STRONG> (Hypervisor Enforced Code Integrity) leverages Virtualization Based Security (VBS) to enforce kernel mode components to comply with the code integrity policy, and is protected against malicious intervention by admins on the OS. </LI> <BR /> <LI> <STRONG> Config code integrity </STRONG> allows admins to create a custom code integrity policy, and specify trusted software (both kernel mode and user mode). </LI> <BR /> </UL> <BR /> </LI> <BR /> </UL> <BR /> Additional considerations: <BR /> <BR /> If the jump server runs Windows Server Core edition, the <EM> FilePublisher </EM> policy is recommended. <EM> FilePublisher </EM> white lists all the files allowed to run on the server. If the jump server runs Windows Server full desktop edition, the <EM> Publisher </EM> policy is recommended which uses only the signer certificates in the policy (i.e. the server will allow files to run as long as they are signed by the certificates in the CI policy). <BR /> <BR /> <A href="#" target="_blank"> Server Core </A> has fewer files in the OS, which reduces the number of files that need servicing and, in turn, the likelihood of a required update to a CI policy that uses the <EM> FilePublisher </EM> rule. &nbsp;The use of the <EM> Publisher </EM> policy rule is intended to reduce the policy update need. However, if your requirement is to do file level white listing on the jump server, you should use the <EM> FilePublisher </EM> rule. <BR /> <BR /> You should always start with the code integrity (CI) policy in audit mode so you can evaluate the effectiveness of the CI policy without impacting the server’s ability to boot or the user experience. Once you are confident in the policy, you can change it to enforcement mode. Microsoft’s internal jump servers use full server with desktop experience and, therefore, use the <EM> Publisher </EM> CI policy&nbsp;&nbsp; in audit mode.&nbsp; Once we complete internal testing, it will be moved to enforcement mode. <BR /> <BR /> I have written a separate <A href="#" target="_blank"> blog </A> on device guard in Windows Server 2016, which covers how to create, deploy and monitor CI policies. <BR /> <UL> <BR /> <LI> <STRONG> Security baseline: </STRONG> Aaron Margosis wrote a blog post on the new <A href="#" target="_blank"> security baseline template </A> for Windows Server 2016 and Windows 10. The download package includes GPOs, scripts and documentation on the settings it configures. The baseline template enables Credential Guard, Remote Credential Guard and Device Guard with HVCI. </LI> <BR /> </UL> <BR /> Additional considerations: <BR /> <OL> <BR /> <LI> If you are configuring JEA on the jump server, ensure it has the latest update of Windows Server 2016 first. </LI> <BR /> <LI> You should also configure JEA first before apply CI policy in enforcement mode. </LI> <BR /> <LI> If you need to configure trusted sites in Internet Explorer on the jump server, you must do so before applying the baseline. Once locked down, it will be hard to change the configuration. </LI> <BR /> <LI> Join the jump server to a trusted domain, so the RDP client can use Remote Credential Guard to RDP to the jump server. </LI> <BR /> <LI> The security baseline has a policy setting to prevent computers from connecting to both domain-based networks and non-domain-based networks at the same time. If the jump server is not joined to a domain, you may need to change this policy </LI> <BR /> </OL> <BR /> <UL> <BR /> <LI> <STRONG> Network firewall ports </STRONG> : This configuration highly depends on the connection you want to allow. In our case, we configured the firewall ports to only allow inbound RDP and WinRM, which allows user to RDP to the jump server use JEA to remotely manage services, etc. </LI> <BR /> </UL> <BR /> <BR /> <H2> Conclusion </H2> <BR /> I hope by sharing the Microsoft internal jump server configuration, it gives you a good starting point on how you can leverage Windows Server 2016 to protect the jump servers in your environment. If you have any security tips to share, you can reach us by email at </BODY></HTML> Fri, 15 Mar 2019 23:10:09 GMT Jian (Jane) Yan 2019-03-15T23:10:09Z Windows Server 2016 security auditing for enhanced threat detection <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Jan 30, 2017 </STRONG> <BR /> Windows Server 2016 includes new audit events to help with early detection of malicious activity in your datacenter. You can find the complete list of the events from this <A href="#" target="_blank"> reference paper </A> , and new events in Windows Server 2016 <A href="#" target="_blank"> here </A> under the Security auditing section. <BR /> <BR /> In this blog post, I would like to highlight a few of these events, which are easy to configure and provide a good starting point to improve detection capabilities in your environment. <BR /> <H2> Detecting malicious reconnaissance attempts to access SAM </H2> <BR /> The Security Account Manager (SAM) is a database file, which stores users’ passwords. A common attack is to access SAM remotely to enumerate user groups, such as finding all the users in the local admin group on a server. On Windows Server 2016, when an attacker with insufficient privilege runs a query on the network to identify highly privileged accounts, you will see the following events on the server: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> <IMG src="" /> <IMG src="" /> <BR /> <BR /> Event 16962 and 16969 are generated by default, and 16965 is generated if you set this registry key on the server: <BR /> <BR /> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ <BR /> <BR /> REG_DWORD RestrictRemoteSamEventThrottlingWindow = 0 <BR /> <BR /> You can find these events under Windows Logs\System, with event source Directory-Services-SAM. <BR /> <H2> Alerting on suspicious activities that should not occur on server machines: Security Audit logs </H2> <BR /> You can enable granular security audit logs by enabling individual group polices, under Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit polices. The <A href="#" target="_blank"> reference paper </A> has the complete list of the events you can monitor. I went through all of them, and like to recommend the following as they are particularly important on server: <BR /> <UL> <BR /> <LI> Detailed Tracking\Audit PNP Activity: <BR /> <UL> <BR /> <LI> Event 6416 can be used to detect when new devices are attached to the server </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> Account Management\Audit User Account Management: <BR /> <UL> <BR /> <LI> Event 4724 can be used to detect when an account password is reset by another account </LI> <BR /> <LI> Event 4798: A user’s local group membership was enumerated </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> Account Management\Audit Security Group Management: <BR /> <UL> <BR /> <LI> Event 4799: A security-enabled local group membership (BUILTIN\Administrators) was enumerated </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> Logon and Logoff\Audit Account Lockout <BR /> <UL> <BR /> <LI> Event 4625: Account failed to log on when the account was already locked out. </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> Audit system integrity: <BR /> <UL> <BR /> <LI> Event 4816: RPC detected an integrity violation while decrypting an incoming message (We recommend monitoring this event especially on High Value Asset [HVA] computers, because it can be a sign of malicious activity.) </LI> <BR /> <LI> Event 5038: Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error. </LI> <BR /> <LI> Event 6281: Code Integrity determined that the page hashes of an image file are not valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could also indicate a disk device error. </LI> <BR /> <LI> Event 6410: Code integrity determined that a file does not meet the security requirements to load into a process. <A href="#" target="_blank"> Code Integrity </A> is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it is loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. For example, when a driver tries to modify memory pages, the system will log this event. </LI> <BR /> </UL> <BR /> </LI> <BR /> </UL> <BR /> Conclusion <BR /> <BR /> Security monitoring is not easy. The new addition of the security events in Windows Server 2016 builds the foundation for better threats detection. I’m going to share more detection logic as I learn more, and I’d love to hear your feedback or monitoring experiences. You can reach us by email at </BODY></HTML> Fri, 15 Mar 2019 23:10:03 GMT Jian (Jane) Yan 2019-03-15T23:10:03Z Windows Server 2016 security sessions at Microsoft Ignite 2016 <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Sep 22, 2016 </STRONG> <BR /> If you're going to Ignite next week, you don't want to miss the Windows Server 2016 security sessions we prepared for you! Check out this blog post on the Hybrid Cloud blog that also feature some great videos created by our Program Managers! <BR /> <BR /> In addition, check out <A href="#" target="_blank"> this webpage </A> on which you can list all Windows Server 2016 related sessions. <BR /> <BR /> Finally, we'll have two Windows Server Security booths at the show floor - one at the Windows Server area and the other at the Microsoft Security area. Stop by and come say hello to the team! <BR /> <BR /> See you all in Atlanta! </BODY></HTML> Fri, 15 Mar 2019 23:09:29 GMT Vinicius Apolinario 2019-03-15T23:09:29Z Overview of Device Guard in Windows Server 2016 <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Sep 20, 2016 </STRONG> <BR /> With <A href="#" target="_blank"> thousands of new malware released </A> every day, it may not be sufficient to only use signature-based detection to fight against malware. Device Guard on Windows Server 2016 changes from a mode where apps are trusted unless blocked by an antivirus or other security solution, to a mode where the operating system trusts only apps authorized by your enterprise. <BR /> <BR /> In my mind, antivirus software is like the police which catch bad apps if they made their name on the list; whereas Device Guard is like a vault, which allows you to create a secure environment which allows only the apps you trust to enter. We need both mechanisms, depending on how sensitive the information is to be protected. <BR /> <H2> What is Device Guard </H2> <BR /> Device Guard can protect software running in Kernel mode and User mode. Under Kernel mode protection, Device Guard ensures the drivers are, at the very least, signed by a known signature (WHQL signed) or you can further restrict the drivers by whitelisting them in the policy. Device Guard will block drivers from loading dynamic code and block any driver that is not on the whitelist. If there is a comprised driver which tries to modify code in memory, it cannot be executed on the machine. Device Guard also provides user mode protection (UMCI), where you can create Code Integrity (CI) policies which defines what’s trusted and authorized to run on individual servers. <BR /> <BR /> For details on Device Guard, here are some good references (not a complete list): <BR /> <UL> <BR /> <LI> <A href="#" target="_blank"> Introduction to Device Guard </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Requirements for deployment planning for Device Guard </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Code integrity policies </A> </LI> <BR /> </UL> <BR /> <H2> Enhanced Kernel Mode protection using Hypervisor Code Integrity (HVCI) </H2> <BR /> The core functionality and protection of Device Guard starts at the hardware level. Devices that have processors equipped with SLAT technologies and virtualization extensions, such as Intel VT x and AMD V, will be able to take advantage of a Virtualization Based Security (VBS) environment that dramatically enhances Windows security by isolating critical Windows services from the operating system itself. <BR /> <BR /> Device Guard leverages VBS to isolate its Hypervisor Code Integrity (HVCI) service, which enables Device Guard to help protect kernel mode processes and drivers from vulnerability exploits and zero days. HVCI uses the processor’s functionality to force all software running in kernel mode to safely allocate memory. This means that after memory has been allocated, its state must be changed from writable to read only or execute only. By forcing memory into these states, it helps ensure that attacks are unable to inject malicious code into kernel mode processes and drivers through techniques such as buffer overruns or heap spraying. <BR /> <BR /> To deliver this level of security, Device Guard has the following hardware and software requirements: <BR /> <UL> <BR /> <LI> UEFI Secure Boot (optionally with non-Microsoft UEFI CAs removed from the UEFI database) </LI> <BR /> <LI> Virtualization support enabled by default in the system firmware: <BR /> <UL> <BR /> <LI> Virtualization extensions (for example, Intel VT-x, AMD RVI) </LI> <BR /> <LI> SLAT (for example, Intel EPT, AMD RVI) </LI> <BR /> <LI> IOMMU (for example, Intel VT-d, AMD-Vi) </LI> <BR /> <LI> UEFI configured to prevent an unauthorized user from disabling Device Guard–dependent hardware security features (for example, Secure Boot) </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> Kernel mode drivers signed and compatible with hypervisor-enforced code integrity </LI> <BR /> </UL> <BR /> HVCI (a.k.a Virtualization Based Security of Code Integrity) can be deployed using Group Policy. It is recommended to enable HVCI on all the servers running Windows Server 2016. For more details of Group Policy configuration, see <A href="#" target="_blank"> here </A> . <BR /> <H2> Deploy configurable code integrity policy </H2> <BR /> Historically, most malware has been unsigned. Simply by deploying code integrity policies, organizations can get immediately protection against unsigned malware, which is estimated to be responsible for the majority of current attacks. By using code integrity policies, an enterprise can also select exactly which binaries can run in both user mode and kernel mode. When completely enforced, it will only load specific applications or software with specific signatures. This feature alone fundamentally changes security in an enterprise. <BR /> <BR /> You can run configurable code integrity independent of HVCI, thus making it available to devices that don’t meet the HVCI hardware requirements. There is a downside of not meeting the hardware requirement though, the security enforcement will not be as strong. <BR /> <BR /> Configurable code integrity policy offers a wide range of options which define the level of granularity governing what software to trust on a server, ranging from allowing software signed by reputable publishers (e.g.: Microsoft) to matching the hash of each file. <BR /> <BR /> It is recommended that you always first deploy code integrity policies in audit mode, as it allows you to review the binaries fail to load under the policy. You can then adjust the policy before changing the code integrity policy to enforcement mode. <BR /> <BR /> In this blog, I’d like to illustrate 2 common types of code integrity policies, one for general server usage and another one for locked down servers: <BR /> <OL> <BR /> <LI> General server usage: Servers which run a variety of workloads, expected to have new software installed from time to time, flexible in what they are used for. </LI> <BR /> <LI> Locked down servers: Servers which run a specific, often highly secure and critically in their reliability, such as a Hyper-V host or Domain Controller. </LI> <BR /> </OL> <BR /> <H2> Create code Integrity policy for general server usage </H2> <BR /> To create the code integrity policy, you can start by building a reference server on their standard hardware, and install all of the software that their servers are known to run. Then, run the following cmdlet: <BR /> <BR /> <A href="#" target="_blank"> <EM> New-CIPolicy </EM> </A> <EM> -Level Publisher -Fallback Hash -UserPEs -FilePath C:\CI\Publisher.xml </EM> <BR /> <BR /> For details of the level parameter, see <A href="#" target="_blank"> here </A> . <BR /> <BR /> This cmdlet creates the policy by scanning the files on the server, and extracts the publisher information from the files and adds it to the policy. The policy is created in auditing mode. Under audit mode, files which is not covered by the CI policy will be able to load, however, they will be logged in the Microsoft\Windows\CodeIntegrity event log channel. Administrators can audit the logs to detect any potential security attacks. <BR /> <BR /> As part of normal operations, they will get software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, there is no need to update the code integrity policy. <BR /> <BR /> Same code integrity policy can be deployed to servers in the same category and running the same hardware. <BR /> <H2> Create code Integrity policy for lockdown server </H2> <BR /> It is a similar process to create the code integrity policy on this category of servers, but with different level of control on the software you trust. For this type of server, we recommend using FilePublisher, to ensure only whitelisted files can be loaded on the server. To create the Code Integrity policy, run the following cmdlet: <BR /> <BR /> <A href="#" target="_blank"> <EM> New-CIPolicy </EM> </A> <EM> -Level FilePublisher -Fallback Hash -UserPEs -FilePath C:\CI\FilePublisher.xml </EM> <BR /> <BR /> This cmdlet creates the policy by scanning the files on the server, and whitelist the files by their name, version and publisher info in the policy. Only the files are on the whitelist with matching name, publisher, and version equal or greater is considered as trusted. In the case of software update, the update to the files covered by the policy will have a higher version number, therefore you won’t need to regenerate CI policy. If there are new files added to the server, you will need to scan the new files, and merge it to the existing CI policy. <BR /> <BR /> The cmdlet creates the policy in audit mode, you can validate the policy in the audit mode first, ensure all the files you trust are covered by the CI policy. Once you are comfortable with it, you can run the following cmdlet to change it to enforcement mode: <BR /> <BR /> <EM> Set-RuleOptions -FilePath C:\CI\FilePublisher.xml -Option 3 -delete </EM> <BR /> <H2> Deploy code integrity policy </H2> <BR /> The xml file created by the 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. <BR /> <BR /> Run the following cmdlet to convert the xml file: <BR /> <BR /> <EM> ConvertFrom-CIPolicy C:\CI\FilePublisher.xml C:\CI\FilePublisher.bin </EM> <BR /> <BR /> Deploy CI policy: <BR /> <BR /> <EM> Copy-Item C:\CI\FilePublisher.bin C:\Windows\System32\CodeIntegrity\SiPolicy.p7b </EM> <BR /> <BR /> Reboot the server to allow code integrity service to load the policy. <BR /> <H2> Monitoring </H2> <BR /> When the code integrity policy is deployed in audit mode, software which is not authorized by the policy can still be loaded, but will leave a trace behind in the event log. Here is an example of the eventlog showing: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> If you have multiple servers to be monitored, you can use the Security information and event management (SIEM) software, to channel the events from each server and build a single pane of glass view of the files executed but not yet authorized in the environment. I have used Microsoft Operations Management Suite (OMS) to monitor the events, here is a sample view for my test servers: <BR /> <BR /> <IMG src="" /> <BR /> <H2> Conclusion </H2> <BR /> This blogpost illustrated a powerful mechanism to protect Windows Servers in your environment, by giving you the control to define what software is trusted, and block all non-trusted software to execute in the environment. As always, we’d love to hear your feedback. You can reach us by email at or submit and vote on requests through the <A href="#" target="_blank"> User Voice web site </A> . </BODY></HTML> Fri, 15 Mar 2019 23:09:20 GMT Jian (Jane) Yan 2019-03-15T23:09:20Z Step by Step: Shielding existing VMs without VMM <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Sep 01, 2016 </STRONG> <BR /> Continuing on the topic of Shielded VMs from my last <A href="#" target="_blank"> blog </A> on creating shielded VMs, this blogpost will share my learnings from validating the scenario. This blogpost doesn't&nbsp;dive deep in terminologies&nbsp;which are fully explained in the <A href="#" target="_blank"> Shielded VM deployment guide </A> . <BR /> <BR /> A side note, System Center VMM has built-in&nbsp;functionality to support shielding existing VMs to make the process simpler, and it is recommended to use SCVMM to manage shielded VMs in production. <BR /> <H2> Process outline </H2> <BR /> <UL> <BR /> <LI> Tenant admin creates the shielding data file, which defines the VM&nbsp;shielding policy and includes the certificates which restricts the VMs to run on allowed guarded fabrics </LI> <BR /> <LI> Tenant admin creates a helper VHDX&nbsp;that is used to shield the VMs </LI> <BR /> <LI> Fabric admin takes the shielding data file and helper VHDX, and shield an existing VM on a guarded host </LI> <BR /> </UL> <BR /> <H2> Create Shielding Data (PDK) File for shielding existing VMs </H2> <BR /> The shielding data specifies the shielding policy and key material that identifies which fabrics can run shielded VMs. The tenant administrator creates the shielding data using the Shielding Data File Wizard (which is part of the Remote Server Administration Tools – Shielded VM Tools), on a machine which is not part of the guarded fabric. When running this tool, ensure to select the option for shielding existing VMs: <BR /> <BR /> You can also use the following cmdlet to create the shielding data file: <BR /> New-ShieldingDataFile -ShieldingDataFilePath &lt;PDK file path&gt; -Owner $owner -Guardian $guardian -Policy &lt;Shielded or EncryptionSupported&gt; <BR /> Where $owner and $guardian are explained in this <A href="#" target="_blank"> blogpost </A> . <BR /> <P> <I> Tip: In testing, make sure you don’t run this tool/cmdlet on a guarded host. </I> </P> <BR /> <BR /> <H2> Create a Helper VHDX </H2> <BR /> As part of the shielding process for existing VMs, a “helper VM” is created that is responsible for preparing and encrypting the existing VM’s VHDX. To make the Helper VHDX, you will need to create a fully functional Gen 2 VM (HelperVM) running Windows Server 2016 with either the desktop experience or Server Core installation option (Nano server is not supported for helper VHDXs). Make sure a user can log on to this VM before shutting it down. Once the VM is in the OFF state, make a copy of its VHDX file. This copy of VHDX file is referred to as a Helper VHDX. You can delete HelperVM and its configuration files if you want – they are not needed anymore. <BR /> <P> <I> Tips: </I> </P> <BR /> <BR /> <UL> <BR /> <LI> <I> The Helper VHDX and VM to be shielded can’t come from the same VHDX file. This&nbsp;happens often&nbsp;in test labs, where the same VHDX files is copied multiple times to build HelperVM and other testing VMs. If the Helper VHDX and the VM to be&nbsp;shielded are originated from the same VHDX file, there will be disk signature conflicts which result in failure in the&nbsp;shielding process. </I> </LI> <BR /> <LI> <I> Do not use a differencing VHDX for the helper VHDX. </I> </LI> <BR /> </UL> <BR /> Run the following cmdlet to&nbsp;enable shielding feature&nbsp;in&nbsp;the Helper VHDX: <BR /> Initialize-VMShieldingHelperVHD -Path &lt;Helper.vhdx&gt; <BR /> <P> <I> Tips: </I> </P> <BR /> <BR /> <UL> <BR /> <LI> <I> The cmdlet is part of the RSAT-&gt; Feature Administration Tools -&gt; Shielded VM tools. Make sure the Helper VHDX is on a Hyper-V host which is not the guarded host. </I> </LI> <BR /> <LI> <I> The VHDX file will be modified in place. If you want to keep a copy of the original VHDX, make sure you make a copy of the&nbsp;VHDX before running the cmdlet. </I> </LI> <BR /> <LI> <I> After the Helper VHDX is initialized, do not attach it to any VM. </I> </LI> <BR /> <LI> <I> Each Helper VHDX can only be used once after it has been initialized. If you are planning to shield multiple existing VMs, make a copy of the initialized Helper VHDX first. The script in the next section will make a copy for you if you run it in its entirety. </I> </LI> <BR /> </UL> <BR /> <H2> Shield an existing VM </H2> <BR /> The VMs to be shielded (let’s call them TargetVMs) are running on guarded hosts. Before running the script below, make sure you first copy the PDK files and the initialized Helper VHDX file to the guarded host where the TargetVMs are running. <BR /> <BR /> There are two steps to shield the VM: <BR /> <UL> <BR /> <LI> Prepare VM: Using the Helper VHDX to configures the TargetVM and&nbsp;encrypt its disk. </LI> <BR /> <LI> Enable shielding: Shield the VM based on the policy defined in the Shielding Data File. </LI> <BR /> </UL> <BR /> The script below will perform the shielding process described above. The script takes 3 parameters: <BR /> <UL> <BR /> <LI> PDKFile: the path to the shielding data file created above. </LI> <BR /> <LI> HelperVHDX: the path to the Helper VHDX file created and initialized, and copied to the guarded host. </LI> <BR /> <LI> VMName: the name of the TargetVM </LI> <BR /> </UL> <BR /> You can copy and save the script, and run it on the guarded host to shield the VM. <BR /> <BR /> [snippet slug=shieldexistingvm line_numbers=false lang=bsh] <BR /> <P> <I> Tips: </I> </P> <BR /> <BR /> <UL> <BR /> <LI> <I> The TargetVM must not use a differencing VHDX. The provisioning job will fail immediately if it determines the TargetVM is running with differencing VHDX. </I> </LI> <BR /> <LI> <I> If an error occurred, you can also enable the “ShieldedVM-ProvionsioningService” debug event log channel to get more details on the error. </I> </LI> <BR /> <LI> <I> After the TargetVM is been prepared, the HelperVHDX file will be deleted. This is because the HelperVHDX can no longer be used to shield another VM. Make sure you make a copy of the HelperVHDX if you want to shield another VM. </I> </LI> <BR /> </UL> <BR /> <H2> Conclusion </H2> <BR /> This blogpost illustrated the steps to shield an existing VM without System Center Virtual Machine Manager(VMM). If you are using VMM to manage the fabric and it is recommended to use VMM in production, you can follow the <A href="#" target="_blank"> deployment guide </A> to learn the procedure. <BR /> <BR /> I hope the script helps to simplify the process. As always, we’d love to hear your feedback. You can reach us by email at or submit and vote on requests through the <A href="#" target="_blank"> User Voice web site </A> </BODY></HTML> Fri, 15 Mar 2019 23:09:00 GMT Jian (Jane) Yan 2019-03-15T23:09:00Z Reduce the number of admins on your servers with Just Enough Administration <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Aug 29, 2016 </STRONG> <BR /> <H2> Least Privilege </H2> <BR /> As part of your information&nbsp;security strategy, you are probably familiar with the principle&nbsp;of <EM> least privilege </EM> . The concept itself is simple&nbsp;-- give your IT staff and end-users as few permissions as necessary to get their jobs done. This helps shrink your attack surface and limit exposure when attackers compromise&nbsp;user credentials through phishing, key logging, or <A href="#" target="_blank"> pass the hash </A> attacks. Anyone who has tried removing all of their&nbsp;privileged accounts, however, knows that it is impossible to do in an average computing&nbsp;environment. Too many applications require administrator privileges in order to be run, including many components in the operating system&nbsp;itself. This can lead to frustrating situations, where in order to restart a service, install a security update or view event logs to troubleshoot a problem, you need full administrator privileges on that machine. Being a local admin (or, worse yet, a domain admin on an Active Directory Domain Controller) gives you&nbsp;permissions to do anything you want. For an attacker wielding your credentials, that can mean installing malware,&nbsp;stealing files, or finding ways to get access to even more privileged credentials. <BR /> <BR /> Some applications use role based access controls (RBAC) to get around these issues. By implementing authorization logic within the application, the requirement for administrator privileges can often be relieved.&nbsp;For example, Active Directory Domain Services has&nbsp;a delegated administration model that enables help desk staff to reset passwords for users without having the ability to manage the rest of the directory. While powerful, these RBAC tools are often limited to the scope of the application for which they were written. The AD RBAC tools cannot be used to manage DNS servers, for example. <BR /> <H2> Just Enough Administration </H2> <BR /> Just Enough Administration (JEA) was created to solve this exact problem. JEA is a PowerShell security feature that&nbsp;helps you create constrained management endpoints using role based access controls for <EM> anything </EM> that can be managed with PowerShell. With JEA, a non-administrator is able to run specific commands, scripts, and executables as if they were an administrator on the machine and all their actions are fully logged. A single JEA role may allow users to manage a few pieces of multiple applications, enabling scenarios not possible with built-in RBAC solutions. <BR /> <BR /> <BR /> <BR /> <IMG src="" /> <BR /> <BR /> <BR /> <BR /> Let's examine the typical JEA workflow, as shown in the diagram above. First, a highly trusted security admin has to configure a JEA endpoint on each server. This involves creating or downloading one or more Role Capability files, which define <EM> what </EM> a user is able to do when they belong to a role (including which cmdlets, providers, and executables they may use), and a Session Configuration file which maps users and groups to those roles. These users and groups do not need to be assigned administrative rights on the system; they can just be domain users or local users. Behind the scenes, JEA uses temporary, per-session local admin accounts to execute commands on their behalf. (Detailed information about these configuration&nbsp;files will be covered in a future blog.) Next, a user connects to the JEA endpoint using PowerShell remoting and their unprivileged user credentials. The JEA endpoint will examine the connecting user's group membership and grant the user access to all the appropriate commands for their role(s). The user can then run their PowerShell commands to get their job done without ever actually being an admin on the machine. <BR /> <BR /> JEA configurations are designed to support complex environments.&nbsp;The endpoints themselves are&nbsp;local to each machine, allowing you&nbsp;to customize them for that machine's particular needs. For more general endpoints, you can use our DSC resource to quickly and consistently deploy JEA configurations across many machines -- even your whole datacenter! <BR /> <H2> How to&nbsp;Get Started </H2> <BR /> Just Enough Administration is built into Windows PowerShell 5.0+. If you're running Windows Server 2016 or Windows 10, you likely already have it installed on your machine. It is also available on Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 when you install <A href="#" target="_blank"> Windows Management Framework 5.0 </A> or higher. <BR /> <BR /> Check out the <A href="#" target="_blank"> MSDN documentation </A> to learn more about setting up JEA and the <A href="#" target="_blank"> JEA GitHub repository </A> to download sample roles and the JEA DSC resource. <BR /> <BR /> Finally, keep checking back here for more blogs on JEA and our other technologies&nbsp;that can help you secure your privileged access. </BODY></HTML> Fri, 15 Mar 2019 23:08:56 GMT RyanWillis 2019-03-15T23:08:56Z Host Guardian Service - AD-based vs. TPM-based attestation <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Aug 16, 2016 </STRONG> <BR /> [This post is authored by Dean Wells, Principal Program Manager for the Windows Server Security Product Team] <BR /> <H2> Overview </H2> <BR /> The Host Guardian Service (HGS) is a new role in Windows Server 2016 that provides health attestation and key protection/release services for Hyper-V hosts running Shielded VMs. This blog describes the differences between HGS’ two mutually-exclusive attestation modes. For more information about the HGS role and how it’s configured, see the blog post <A href="#" target="_blank"> here </A> . <BR /> <H2> What is HGS attestation? </H2> <BR /> Generally speaking, attestation is a process in which the health of a given computer is measured in some way—typically by an external, trusted authority. In the case of Shielded VMs, HGS serves as the external, trusted authority and is used to measure specific health characteristics of Hyper-V hosts in order to determine if they’re authorized (authorized because they’re healthy) to run Shielded VMs. The process used to determine whether a Hyper-V host is healthy or not and the specifics of what we <STRONG> <EM> measure </EM> </STRONG> are dictated by HGS’ attestation mode. <BR /> <BR /> <STRONG> NOTE: </STRONG> HGS’ attestation mode is configured during installation (by using the <EM> <STRONG> Initialize-HgsServer </STRONG> </EM> cmdlet) but can also be changed after the fact using the <EM> <STRONG> Set-HgsServer </STRONG> </EM> cmdlet. <BR /> <BR /> HGS supports two mutually-exclusive attestation modes: <BR /> <OL> <BR /> <LI> AD-based attestation (sometimes written as Windows Server Active Directory based attestation) </LI> <BR /> <LI> TPM-based attestation (Trusted Platform Module) </LI> <BR /> </OL> <BR /> Let’s go through the requirements and basic setup process for each of the two modes and wrap things up with the assurance (security promise) differences between them. <BR /> <H2> 1. AD-based attestation </H2> <BR /> With AD-based attestation, HGS measures only the group membership of the Hyper-V host that is attesting against it. Note that we’re measuring the <STRONG> <EM> computer account’s </EM> </STRONG> membership, not a user’s. Let’s talk a bit more about how&nbsp;that looks and how it’s setup. In most scenarios, AD-based attestation will use two forests/domains: one forest to which the Hyper-V hosts are joined (the <STRONG> <EM> fabricAD </EM> </STRONG> ) and a second forest that is automatically created when HGS is first installed ( <STRONG> <EM> HGS-AD </EM> </STRONG> ). <BR /> <BR /> This is probably a good time to point out that HGS can also use existing AD forests, i.e. not create its own forest during install. If this sounds like an appealing deployment option, ensure you’ve carefully considered that the HGS forest contains all of the servers running the HGS service and, therefore, it also contains the keys that can be used to compromise a shielded VM—in short, it’s contains the keys than can unravel a guarded fabric. For this reason, HGS typically resides in its own AD forest where the role is co-located with the domain controllers themselves. There are no particular technical requirements in order for an existing forest to be compatible with HGS’ needs but there are operational requirements and security-related best practices. Suitable forests are likely purpose-built serving one sensitive function, e.g. the forest used by Microsoft’s Privileged Identity Management solution. These sort of forests are suitable and usually exhibit the following characteristics: they have very few admins, they are not general-purpose in nature and the frequency of logons are low. General purpose forests such as CORP AD forests are not suitable for use by HGS. Since HGS needs to be isolated from fabric administrators, fabric AD forests fall very much into the unsuitable bucket. <BR /> <BR /> OK, back to the AD-based attestation setup steps: next, a one-way cross-forest trust needs to be created from <STRONG> <EM> HGS-AD </EM> </STRONG> to <STRONG> <EM> fabricAD </EM> </STRONG> (i.e. <STRONG> <EM> HGS-AD </EM> </STRONG> trusts <STRONG> <EM> fabricAD </EM> </STRONG> ). Next, an Active Directory global group ( <STRONG> <EM> TrustedHostGroup) </EM> </STRONG> is created in the <STRONG> <EM> fabricAD </EM> </STRONG> domain and the computer accounts of the Hyper-V hosts that need to run Shielded VMs are added as members. Finally, the security identifier (SID) of the <STRONG> <EM> fabricAD\TrustedHostGroup </EM> </STRONG> is added to HGS by a trusted admin using the <EM> <STRONG> Add-HgsAttestationHostGroup </STRONG> </EM> cmdlet. At this stage, you’ve now enlightened HGS as to what a <EM> healthy host </EM> looks like when using AD-based attestation. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> When a Hyper-V host attests with HGS, the host’s identity and group membership are sent to HGS’ attestation service in the form of a Kerberos service ticket (hence the need for the trust). The service ticket contains the computer account SID of the Hyper-V host as well as the SIDs of any groups that the computer account is a member of (which includes the <STRONG> <EM> TrustedHostGroup </EM> </STRONG> ). HGS compares this list of SIDs against its own list of trusted attestation host groups and if a match is found, the host is issued a certificate of health entitling it to request keys from HGS’ key protection service. <BR /> <H2> 2. TPM-based attestation </H2> <BR /> With TPM-based attestation, HGS enforces far more rigorous attestation requirements than those used in AD-based attestation. As before, let’s walk through how we set this up and call out some of the setup differences as we go along. <BR /> <BR /> When using TPM-based attestation, one of the more obvious differences is that no Active Directory trust relationship is required, or even recommended. Instead, the identity of a Hyper-V host is expressed to HGS by using a unique key found within each Hyper-V host’s TPM (the TPM must be a version 2 TPM)—the key is referred to as an EKpub or public endorsement key. You can extract the key from the Hyper-V host using the <EM> <STRONG> Get-PlatformIdentifier </STRONG> </EM> cmdlet. You must then add that key to the HGS service using the <EM> <STRONG> Add-HgsAttestationTpmHost </STRONG> </EM> cmdlet—HGS will now at least permit this host to attempt attestation but we’re not done yet. <BR /> <BR /> Next, we need to teach HGS how to measure whether a Hyper-V host is healthy or not—there are two distinct parts to the measurement process: <BR /> <UL> <BR /> <LI> a baseline policy </LI> <BR /> <LI> a code-integrity (CI) policy </LI> <BR /> </UL> <BR /> The baseline policy contains measurements that describe the binaries loaded by the Operating System during the boot process. These measurements are extended into specific platform configuration registers (or PCRs) in the host’s TPM. <BR /> <BR /> The CI policy contains a whitelist of binaries (drivers, tools, etc.) that are allowed to run on the Hyper-V host. <BR /> <BR /> To create the baseline and CI policies, a trusted admin nominates an existing host (or builds a new Hyper-V host) that represents their definition of health. The baseline and CI policies are then extracted from this trusted and healthy host. Here’s the basic process and cmdlets needed (the exact syntax can be found in the Shielded VM deployment guide or via each cmdlet’s online help): <BR /> <OL> <BR /> <LI> Identify an existing healthy host or build a new one <BR /> <UL> <BR /> <LI> if all hosts run on identical hardware and are installed and configured with identical software, then only a single baseline and CI policy is needed </LI> <BR /> <LI> if, however, some hosts are from a different hardware vendor or are a significantly different model from the same vendor, then generating a second baseline and CI policy is almost certainly required </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> to extract the baseline policy from an appropriate Hyper-V host: <BR /> <UL> <BR /> <LI> use the <EM> <STRONG> Get-HgsAttestationBaselinePolicy </STRONG> </EM> cmdlet </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> to add the baseline policy to HGS: <BR /> <UL> <BR /> <LI> use the <EM> <STRONG> Add-HgsAttestationTpmPolicy </STRONG> </EM> </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> to extract the code integrity policy from an appropriate Hyper-V host: <BR /> <UL> <BR /> <LI> use the <EM> <STRONG> New-CIPolicy </STRONG> </EM> cmdlet to generate the policy (this takes a while, e.g. 30+ mins) </LI> <BR /> <LI> then use the <EM> <STRONG> ConvertFrom-CIPolicy </STRONG> </EM> to convert it to the format that HGS needs </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> to add the code integrity policy to HGS: <BR /> <UL> <BR /> <LI> use the <EM> <STRONG> Add-HgsAttestationCiPolicy </STRONG> </EM> cmdlet </LI> <BR /> </UL> <BR /> </LI> <BR /> </OL> <BR /> When a Hyper-V host attests with HGS, the host first sends its EKpub in order to prove that it is authorized to participate in the guarded fabric—HGS compares the EKpub to its known list and if it finds a match, the attestation process continues. <BR /> <BR /> Next, the Hyper-V host must send over its baseline measurements contained in something called the tcglog. The tcglog (or trustworthy computing group log) can be thought of as a list of individually-measured binaries and the order in which they loaded—this is used to ensure unauthorized software (such as rootkits) are not loaded prior to the OS. During attestation, HGS compares the tcglog to its database of known-healthy baselines and if it finds a match, the attestation process continues. <BR /> <BR /> Next, HGS uses the series of measurements contained in the tcglog to compute what the values in the host’s TPM should be. HGS then reaches back into the host’s TPM over a secure channel and verifies that the PCR-values match what it just computed. If they do, the attestation process continues. <BR /> <BR /> Finally, the host sends over a hash of its CI policy which HGS then compares to its database of known-good CI policies and if it finds a match, the attestation process is affirmatively completed and a certificate of health sent back to the Hyper-V host which entitles it to request keys from HGS’ key protection service. <BR /> <BR /> At this point, HGS now has the following: <BR /> <UL> <BR /> <LI> <I> a key that identifies who the host is (EKpub) indicating it’s potentially trustworthy </I> <BR /> <UL> <BR /> <LI> <I> <EM> (where ‘potentially’ will be determined by the baseline and CI policy measurements) </EM> </I> </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> a cryptographically verified list of the binaries that the host loaded </LI> <BR /> <LI> the host’s CI policy </LI> <BR /> </UL> <BR /> <H2> Contrasting the respective requirements and vulnerabilities of the two attestation modes </H2> <BR /> <UL> <BR /> </UL> <OL> </OL> <BR /> <BR /> We now understand the requirements, configuration differences and the specific measurements that are taken in each of the two modes in order to determine whether a Hyper-V host is healthy or not. The table below outlines some of the resulting differences relative to each attestation mode: <BR /> <TABLE> <TBODY><TR> <TD> <STRONG> </STRONG> </TD> <TD> <STRONG> AD-based attestation </STRONG> </TD> <TD> <STRONG> TPM-based attestation </STRONG> </TD> </TR> <TR> <TD> <STRONG> 1. Hyper-V host hardware and software requirements? </STRONG> </TD> <TD> ·&nbsp;&nbsp; Windows Server 2016 Datacenter Edition <BR /> <BR /> ·&nbsp;&nbsp; No specific hardware requirements beyond what Hyper-V itself needs (SLAT, etc.) </TD> <TD> ·&nbsp;&nbsp; Windows Server 2016 Datacenter Edition <BR /> <BR /> ·&nbsp;&nbsp; Hyper-V host hardware must provide: <BR /> <UL> <BR /> <LI> UEFI 2.3.1 rev. C or later </LI> <BR /> <LI> Secure Boot / Measured Boot </LI> <BR /> <LI> TPM v2 </LI> <BR /> </UL> <BR /> </TD> </TR> <TR> <TD> <STRONG> 2. Host Guardian Service (HGS) hardware and software requirements </STRONG> </TD> <TD> <STRONG> <EM> --------------- no differences ---------------&gt; </EM> </STRONG> </TD> <TD> ·&nbsp;&nbsp; Windows Server 2016 Server Core and up <BR /> <BR /> ·&nbsp;&nbsp; The hardware need only be able to run Windows Server 2016 Server Core and up </TD> </TR> <TR> <TD> <STRONG> 3. What do we measure &amp; attest to in order to permit Shielded VMs to powered-on or to be live migrated to a new host? </STRONG> </TD> <TD> ·&nbsp;&nbsp; The Hyper-V host must be a member of a designated/trusted AD group whose SID (security identifier) has been configured on HGS </TD> <TD> ·&nbsp;&nbsp; The Hyper-V host computer’s boot process including that it’s using secure, measured boot <BR /> <BR /> ·&nbsp;&nbsp; The host’s Operating System and drivers <BR /> <BR /> ·&nbsp;&nbsp; The host’s code-integrity policy <BR /> <BR /> ·&nbsp;&nbsp; Various other aspects such as is a debuggers attached -to the host --&gt; NOT permitted </TD> </TR> <TR> <TD> <STRONG> 4. What protections does the Shielded VM receive? </STRONG> </TD> <TD> <STRONG> <EM> --------------- no differences ---------------&gt; </EM> </STRONG> </TD> <TD> ·&nbsp;&nbsp; A version 2 compatible TPM <BR /> <BR /> ·&nbsp;&nbsp; UEFI firmware with secure, measured boot support <BR /> <BR /> ·&nbsp;&nbsp; Encrypted disks with secure, TPM-backed key-release <BR /> <BR /> ·&nbsp;&nbsp; Encrypted Live Migration traffic </TD> </TR> <TR> <TD> <STRONG> 5. Which guest Operating Systems can be shielded? </STRONG> </TD> <TD> <STRONG> <EM> --------------- no differences ---------------&gt; </EM> </STRONG> </TD> <TD> ·&nbsp;&nbsp; Windows 8 and later <BR /> <BR /> ·&nbsp;&nbsp; Windows Server 2012 and later </TD> </TR> <TR> <TD> <STRONG> 6. Supports both ‘Shielded’ mode and ‘Encryption supported’ mode? </STRONG> </TD> <TD> Yes </TD> <TD> Yes </TD> </TR> <TR> <TD> <STRONG> 7. Provide some examples of how a guarded host or a shielded VM might be attacked </STRONG> </TD> <TD> ·&nbsp;&nbsp; The AD admin is bribed or blackmailed and adds a compromised Hyper-V host to the trusted group in AD <BR /> <BR /> ·&nbsp;&nbsp; The Hyper-V admin installs malware on a Hyper-V host <BR /> <BR /> ·&nbsp;&nbsp; The HGS admin is bribed or blackmailed and weakens the attestation requirements <BR /> <BR /> ·&nbsp;&nbsp; An attacker compromises the identity of a legitimate HGS admin <BR /> <BR /> ·&nbsp;&nbsp; Hyper-V host firmware or platform attacks that enable the attacker to obtain keying material </TD> <TD> ·&nbsp;&nbsp; The HGS admin is bribed or blackmailed and weakens the attestation requirements <BR /> <BR /> ·&nbsp;&nbsp; An attacker compromises the identity of a legitimate HGS admin and weakens the attestation requirements <BR /> <BR /> ·&nbsp;&nbsp; An attacker abuses administrative privileges and manages to obtain guardian (private) keys or transport keys for specific shielded VMs <BR /> <BR /> ·&nbsp;&nbsp; Hyper-V host firmware or platform exploits that enable the attacker to obtain keying material </TD> </TR> </TBODY></TABLE> </BODY></HTML> Fri, 15 Mar 2019 23:08:43 GMT Vinicius Apolinario 2019-03-15T23:08:43Z Step-by-step: Quick reference guide to deploying guarded hosts <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Jun 08, 2016 </STRONG> <BR /> My original blog post on the topic of deploying Shielded VMs without VMM included the instructions to deploy guarded hosts. &nbsp;Based on feedback around keeping the blog posts short and scenario-focused, I split the content into 2. This blog serves as a quick reference to deploy guarded hosts. <BR /> <BR /> Once again, I highly recommend you read through the <A href="#" target="_blank"> deployment guide </A> first to understand the building blocks that enable the shielded VM scenario. I assume you understand the terminology, as well as the difference between Admin-trusted and TPM-trusted attestation mode. They are all well explained in the <A href="#" target="_blank"> deployment guide </A> . <BR /> <H2> Prerequisites </H2> <BR /> At a minimum, you will need 2 machines running the <A href="#" target="_blank"> TP5 release of the Windows Server 2016 </A> . One machine will be configured as a guarded host (a Hyper-V host that can run shielded VMs), and the other machine will be configured as a Host Guardian Service (HGS) Server. <BR /> <BR /> If you are testing the TPM-trusted attestation mode, the Hyper-V guarded host must provide/support the following: <BR /> <UL> <BR /> <LI> IOMMU and SLAT must be supported and enabled </LI> <BR /> <LI> TPM v2.0 </LI> <BR /> <LI> UEFI 2.3.1 or later </LI> <BR /> <LI> Configured to boot using UEFI (not BIOS or “legacy” mode), </LI> <BR /> <LI> Secure Boot enabled </LI> <BR /> </UL> <BR /> If you are testing Admin-trusted attestation, there will be no additional hardware requirements, other than being able to run Hyper-V in Windows Server 2016 TP5. <BR /> <BR /> TPM-trusted attestation and Admin-trusted attestation configuration requirements are very different for each Hyper-V host. They will be illustrated individually in the sections below. <BR /> <H2> Role/feature installation on the guarded host </H2> <BR /> You must install the following on the guarded host: <BR /> <UL> <BR /> <LI> Hyper-V (role) </LI> <BR /> <LI> Host Guardian Hyper-V Support (feature) </LI> <BR /> </UL> <BR /> You may use Server Manager or run the following cmdlet to install the roles/features: <BR /> Install-WindowsFeature Hyper-V, HostGuardian –IncludeManagementTools -Restart <BR /> <H2> 1. Deploy and configure guarded hosts using TPM-trusted attestation </H2> <BR /> The process involves the following steps which generate files on the guarded host. The files are later copied to the HGS server to complete the configuration. <BR /> <OL> <BR /> <LI> Retrieve the TPM identifier: this is used to register the specific host with the HGS server. </LI> <BR /> <LI> Create code integrity (CI) policy: this is used to ensure the software running on the host is trusted </LI> <BR /> <LI> Capture the TPM baseline: this is used to measures the pre-OS UEFI firmware loaded on the host, to ensure only those are trusted and authorized can be loaded on each guarded host </LI> <BR /> <LI> Configure the Hyper-V guarded host’s HGS server </LI> <BR /> </OL> <BR /> Note: if you are testing with more than one Hyper-V host, you will get the TPM identifier from each host.&nbsp; If the hardware and software configuration of the second host is the same, you can use the same CI policy and TPM baseline measurement as long. <BR /> <H2> Retrieve TPM identifier </H2> <BR /> Run the following cmdlet to get the TPM identifier on the host: <BR /> (Get-PlatformIdentifier –Name 'HostName').InnerXml | Out-file HostName.xml <BR /> <H2> Create and apply CI policy </H2> <BR /> It is recommended that you first create the CI policy in audit mode to see if it’s missing anything, then enforce the policy when using the system to host production workloads. For more information about generating CI policies and the enforcement mode, consult the <A href="#" target="_blank"> Device Guard Deployment Guide </A> . <BR /> Run the following cmdlets to create the CI policy on the host: <BR /> New-CIPolicy –Level FilePublisher –Fallback Hash –FilePath 'CodeIntegrity.xml' <BR /> Next, we convert the XML file to the format used by HGS: <BR /> ConvertFrom-CIPolicy –XmlFilePath 'CodeIntegrity.xml' –BinaryFilePath 'CodeIntegrity.p7b' <BR /> You can create one CI policy for all the hosts as long as they have the same hardware and software configuration, but you must apply the CI policy on each host. To do so, copy the binary CI policy file (CodeIntegrity.p7b) to the following location on each host (the name must match exactly): <BR /> C:\Windows\System32\CodeIntegrity\SIPolicy.p7b <BR /> Restart the host to activate the CI policy in audit mode. <BR /> <H2> Capture TPM baseline </H2> <BR /> Run the following cmdlet to capture the TPM baseline: <BR /> Get-HgsAttestationBaselinePolicy –Path 'c:\host.tcglog' <BR /> <H2> Configure the host to be managed by a specific HGS server </H2> <BR /> Run the following cmdlet to configure the host to attest against an HGS server: <BR /> Set-HgsClientConfiguration -AttestationServerURL 'http://&lt;HGS Server FQDN&gt;/Attestation' -KeyProtectionServerURL 'http://&lt;HGS Server FQDN&gt;/KeyProtection' <BR /> Note: you can get the FQDN and entire URL values by running Get-HGSServer on the HGS server. <BR /> The output of the cmdlet will show the host is not guarded, this is expected as HGS server has not yet been configured to trust this host. <BR /> <H2> TP5 specific step </H2> <BR /> If you are running Windows Server Technical Preview 5 on your guarded host(s), you must download and run this script from each host in order to configure certain security settings necessary for TPM attestation. Restart the host after running the script to apply the changes. <BR /> <H2> Configuration on the HGS server </H2> <BR /> Configure the following on the HGS server to complete the host deployment: <BR /> <OL> <BR /> <LI> Add each guarded host on the HGS server </LI> <BR /> <LI> Add one CI policy for each set of hosts that use the same hardware and software configuration </LI> <BR /> <LI> Add one TPM baseline policy for each set of hosts that use the same hardware and software configuration </LI> <BR /> </OL> <BR /> The following configuration steps requires the files you created in the previous section (e.g. host.xml, CodeIntegrity.p7b and host.tcglog). For simplicity’s sake, copy them manually to the HGS server or to a file share that both the Hyper-V host and the HGS server can access. Once you’ve copied all 3 files, proceed with the following commands. <BR /> <H3> Adding a guarded host </H3> <BR /> Run the following cmdlet to add a guarded host: <BR /> Add-HgsAttestationTpmHost –Path 'c:\host.xml' –Name 'Host1' -Force <BR /> Note: the file specified here was created in the section Retrieving TPM identifier. <BR /> <H3> Add CI policy </H3> <BR /> Run the following cmdlet to add a CI policy: <BR /> Add-HgsAttestationCIPolicy -Path 'c:\CodeIntegrity.p7b' -Name 'HostCIPolicy' <BR /> Note: the file specified here was created in the section Creating and apply CI policy. <BR /> <H3> Add TPM baseline policy </H3> <BR /> Run the following cmdlet to add a TPM baseline policy: <BR /> Add-HgsAttestationTpmPolicy –Path 'c:\host.tcglog' –Name 'HostTPMPolicy' <BR /> Note: the file specified here was created in the section Capture TPM baseline. <BR /> <H3> Verification </H3> <BR /> Run the following cmdlet on each host to validate attestation status: <BR /> Get-HgsClientConfiguration <BR /> Check the output, to ensure the AttestationStatus equals passed and IsHostGuarded is True. Now the hosts are guarded and ready to deploy the shielded VMs. <BR /> <BR /> If the AttestationStatus is failed, check the AttestationSubstatus for details, and consult the <A href="#" target="_blank"> deployment guide </A> to fix the errors. You can also use the HGS Diagnostic cmdlets to check your topology setup, for details running the HGSDiag tool, see the <A href="#" target="_blank"> diag blog post </A> . <BR /> <H2> 2. Deploy and configure guarded hosts using Admin-trusted attestation </H2> <BR /> With admin-trusted attestation, hosts will leverage Active Directory to provide proof of identity. You will create a new GLOBAL security group in the fabric domain and add the trusted hosts to this security group. <BR /> On the HGS server, you will create a guarded host group using this cmdlet: <BR /> Add-HgsAttestationHostGroup -Name 'GuardedHostGroup' –Identitifier '&lt;SID&gt;' <BR /> To obtain the SID, use the following PowerShell cmdlet against the fabric AD and copy the SID as formatted in the output (don’t forget to wrap it in quotes). <BR /> Get-ADGroup 'GuardedHost' <BR /> To verify that the guarded host group was successfully added, run <BR /> Get-HgsAttestationHostGroup <BR /> The friendly name of your group should appear. <BR /> <BR /> On the guarded host, run the following cmdlet to complete the HGS configuration: <BR /> Set-HgsClientConfiguration -AttestationServerURL 'http://&lt;HGS Server FQDN&gt;/Attestation' -KeyProtectionServerURL 'http://&lt;HGS Server FQDN&gt;/KeyProtection' <BR /> Note: you can get the URL values by running the following cmdlet on the HGS server: <BR /> Get-HGSServer <BR /> The output of the cmdlet shows the attestation status. Check it to ensure the AttestationStatus is passed and IsHostGuarded is True. Now the hosts are guarded and ready to deploy the shielded VMs. <BR /> <BR /> If the AttestationStatus is failed, check the AttestationSubstatus for details, and consult the <A href="#" target="_blank"> deployment guide </A> to fix the errors. You can also use the HGS Diagnostic cmdlets to check your topology setup, for details running the HGSDiag tool, see the <A href="#" target="_blank"> diag blog post </A> . <BR /> <H2> Conclusion </H2> <BR /> Now you have the guarded hosts ready and can proceed to deploy the shielded VMs. <BR /> As always, we value your comments and feedback, and you can share with <A href="" target="_blank"> us </A> , or submit and vote on request through the <A href="#" target="_blank"> User Voice website </A> . </BODY></HTML> Fri, 15 Mar 2019 23:08:30 GMT Jian (Jane) Yan 2019-03-15T23:08:30Z Step by Step - Shielded VM Recovery <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Jun 07, 2016 </STRONG> <BR /> Shielded VMs protect the data and state of a Virtual Machine against inspection, theft and tampering from malware and datacenter administrators and they do so both at rest and in-flight. One of the ways we achieve is to block the features in Hyper-V that are there for an administrator’s convenience, e.g. we block console access and PowerShell Direct (among others) to ensure that no one but the tenant (or VM owner) has access. <BR /> <BR /> This works great until there is a problem with the remote connection to a shielded VM. Troubleshooting these problems often requires a console connection. The question is how can we limit shielded VM access to tenant admins exclusively?&nbsp; One way to solve this problem is to use <STRONG> Encryption Supported </STRONG> instead of <STRONG> Shielded </STRONG> .&nbsp; The <STRONG> Encryption Supported </STRONG> mode is useful here because it does permit console connections but using it directly on a hoster's fabric exposes the VM to attack vectors that shielding prevents.&nbsp; As a result, you might argue that the <STRONG> Shielded </STRONG> mode is effectively rendered useless for anyone who wants to enable the strongest possible protections on their VMs but also have a supportability story should the guest OS break in some way—a supportability story that typically requires a console connection. There is a detailed comparison of <STRONG> Shielded </STRONG> vs <STRONG> Encryption Supported </STRONG> in the <A href="#" target="_blank"> Shielded VM deployment guide </A> . <BR /> <BR /> So if you want to have your cake and eat it, too, read on.&nbsp; The&nbsp; solution came with the advent of the <A href="#" target="_blank"> Hyper-V nested virtualization&nbsp;feature </A> in Windows Server 2016. This feature enables a Virtual Machine to run Hyper-V and function just like it would on a physical machine (Note that, this feature is currently supported only on Intel processors). Using nested virtualization, we can simply put the damaged VM inside a shielded recovery VM (a.k.a. a repair garage), and lower the security policy of the damaged VM to Encryption Supported, where console connection to the damaged VM is permitted and access to the repair garage is limited to only the tenant admins. With all these building blocks in place, this blog post will show you the step-by-step instructions to establish console access to shielded VMs. <BR /> <BR /> The diagram below illustrates how a repair garage is used to enable a console connection to a damaged shielded VM: <BR /> <BR /> [caption id="attachment_615" align="alignnone" width="300"] <IMG src="" /> Damaged VM inside a repair garage, offer console access to tenant admin[/caption] <BR /> <H2> Terminology </H2> <BR /> <STRONG> Damaged VM </STRONG> (i.e. DVM): the shielded VM which needs to be enabled for console access. <BR /> <STRONG> Repair Garage VM </STRONG> (i.e. VMRE): a shielded VM which is configured with nested virtualization. It acts like a repair garage, inside which, the damaged VM can be accessed through the console. <BR /> <STRONG> Tenant host </STRONG> : a host machine that stores the owner guardian (including its private key) of the DVM. If you want to learn more about the owner concept, you can refer to the deployment guide. <BR /> <H2> Process outline </H2> <BR /> If a VM is shielded, we assume the VM owner or tenant wants to ensure that fabric admins CANNOT access their VM so it is important to maintain shielding protections throughout the recovery process. <BR /> <BR /> The recovery process starts with the tenant admin (TA) who wants to establish console access to a shielded VM (i.e. DVM). <BR /> <OL> <BR /> <LI> TA first provisions a shielded VM (i.e. VMRE), </LI> <BR /> <LI> TA then notifies the fabric admin (FA) that he wants to move the DVM inside the RVM. </LI> <BR /> <LI> To do this, FA will first create a new VHDX for the repair garage (RG VHDX) </LI> <BR /> <LI> FA then export the DVM to the data VHDX file </LI> <BR /> <LI> FA dismounts RG VHDX file and attaches the RG VHDX to the VMRE </LI> <BR /> <LI> FA configures VMRE to enable nested virtualization </LI> <BR /> <LI> TA then RDPs to VMRE(remember, VMREis shielded and only accessible to the tenant) </LI> <BR /> <LI> TA imports the DVM from the RG VHDX </LI> <BR /> <LI> TA changes the security policy on DVM to 'Encryption Supported' in order to gain console access to DVM from within VMRE </LI> <BR /> <LI> TA completes the troubleshooting on DVM and exports it back to RG VHDX </LI> <BR /> <LI> Fabric admin puts it back on the fabric </LI> <BR /> </OL> <BR /> <H2> Step by step instructions </H2> <BR /> <H2> Pre-requisites: </H2> <BR /> <UL> <BR /> <LI> TA wants to connect to a shielded VM, for simplicity, name it DVM </LI> <BR /> <LI> TA provisions another shielded VM with the name VMRE </LI> <BR /> <LI> VMRE and DVM connect to the same Virtual Switch on the same host </LI> <BR /> <LI> VMRE memory size must be large enough to allow DVM to start as a VM inside it </LI> <BR /> </UL> <BR /> <H2> Prepare for recovery </H2> <BR /> To make this process easier, I have written PowerShell scripts, which is now published to the <A href="#" target="_blank"> PowerShell Gallery </A> , you can follow the instructions on the page to deploy the model, and run the module functions to accomplish the tasks in the recovery process. <BR /> <H3> Fabric admin (FA): </H3> <BR /> FA runs the Export-ShieldedVMToVMRE on the guarded host which has both the RVM and the DVM running: <BR /> <OL> <BR /> <LI> FA configures&nbsp;VMRE to run nested virtualization </LI> <BR /> <LI> FA creates a repair garage VHDX (RG VHDX), mounts it, formats it and exports DVM onto it </LI> <BR /> <LI> FA attaches the RG VHDX to VMRE </LI> <BR /> </OL> <BR /> <H3> Tenant admin (TA): </H3> <BR /> TA connects &nbsp;to the RVM, and runs the&nbsp;Import-ShieldedVMInVMRE which performs the following prerequisite tasks: <BR /> <OL> <BR /> <LI> Install Hyper-V role on VMRE, this requires reboot. TA will rerun Import-ShieldedVMInVMRE after reboot. </LI> <BR /> <LI> Import DVM within VMRE </LI> <BR /> <LI> Retrieve the current Key Protector of DVM </LI> <BR /> <LI> Create a temporary recovery guardian certificate </LI> <BR /> <LI> Copy the files created in step #3 and #4 to tenant host where the owner private key of DVM is stored. Run the Grant-VMREAccess to create a new Key Protector on the tenant host. </LI> <BR /> <LI> Copy the new Key Protector to VMRE, continue with the Import-ShieldedVMInVMRE function, which attaches the new&nbsp;Key Protector&nbsp;to DVM, then changes DVM security policy to encryption supported. </LI> <BR /> </OL> <BR /> Now, tenant admin can access DVM console inside VMREremote connection. <BR /> <H2> Cleanup </H2> <BR /> <H3> Tenant admin: </H3> <BR /> Once the troubleshooting process completes, tenant admin runs the Export-RecoveredVMToFabric in VMRE to: <BR /> <OL> <BR /> <LI> Change the DVM security policy back to be shielded; </LI> <BR /> <LI> Export DVM to the data VHDX; </LI> <BR /> <LI> Remove files created&nbsp;during the recovery process </LI> <BR /> </OL> <BR /> <H3> Fabric admin: </H3> <BR /> Runs the Import-RecoveredVMtoFabric on the same guarded host (where DVM and VMREruns) to bring the (now fixed) DVM back on the fabric. <BR /> <H2> Conclusion </H2> <BR /> There is plenty of room for improvement to make this recovery process simpler and that’s something we’re hoping to do going forward. &nbsp;I hope the scripts are helpful in reducing the complexity in the meantime. As always, your comments and feedback will tell us where to focus our energy and resources. You can share them to <A href="" target="_blank"> us </A> , or submit and vote on a request through the <A href="#" target="_blank"> User Voice </A> website. </BODY></HTML> Fri, 15 Mar 2019 23:08:25 GMT Jian (Jane) Yan 2019-03-15T23:08:25Z Step by step - Creating Shielded VMs without VMM <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Jun 06, 2016 </STRONG> <BR /> Hi, I’m Jane, one of the newest members of the Windows Server Security Product Team. My very first hands-on experience is to deploy Shielded VMs with the minimum amount of hardware. It was fun and a great learning experience. I followed the comprehensive <A href="#" target="_blank"> TP5 deployment guide on Shielded VM and Guarded Fabric </A> guide with one deviation: I deployed it&nbsp;without VMM. If you are just like me, trying out the scenario end to end, this blog post will provide you the step by step instructions to use just the PowerShell cmdlets to create shielded VMs. <BR /> <BR /> This blog post doesn’t cover any of the gory details or the building blocks for this scenario, etc.&nbsp; For that, I highly recommend that you first read through the <A href="#" target="_blank"> deployment guide </A> which also covers terminology descriptions, scenario overview and architectural designs. <BR /> <H2> Prerequisites </H2> <BR /> Before you start, you should have completed the deployment of both the guarded host and the Host Guardian Service (HGS) server. &nbsp;For your reference, you can follow the <A href="#" target="_blank"> deploying HGS server </A> blog to setup the HGS server as well as deploying guarded host guide to configure the guarded hosts. <BR /> <BR /> As a way to quickly check and verify your deployment, run the following cmdlet on each guarded host: <BR /> Get-HGSClientConfiguration <BR /> The output of the cmdlet should display that IsHostGuarded is True, and AttestationStatus is Passed. <BR /> <BR /> There are 2 ways to create shielded VMs: <BR /> <UL> <BR /> <LI> Shielding an existing VM (a.k.a grandfathering) </LI> <BR /> <LI> Provisioning a shielded VM from a template </LI> <BR /> </UL> <BR /> I’ll illustrate both approaches in this blog post. <BR /> <H2> Shielding an existing VM </H2> <BR /> Let’s start with the simpler approach. This requires you to have a running VM on a host which is not the guarded host. This is important to distinguish, because you are simulating the scenario where a tenant wants to take an existing, unprotected VM and shield it before moving it to a guarded host. For clarity, the host machine which is not the guarded host will be referred as the tenant host below. A shielded VM can only run on a trusted guarded host. The trust is established by the&nbsp;adding the HGS guardian (retrieved from the HGS server) to the Key Protector which is used to shield the VM. That way, the shielded VM can only be started after the guarded host successfully attest against the HGS server. <BR /> <BR /> In this example, the running VM is named <EM> SVM </EM> . This VM must be generation 2 and have a supported OS installed with remote desktop enabled. You should verify the VM can be connected through RDP first, as it will almost certainly be the primary way to access the VM once it is shielded (unless you have installed other remoting capabilities). <BR /> <H2> Retrieve the HGS guardian </H2> <BR /> As explained above, the first step is to get the HGS guardian metadata from the HGS server, and use it to create the Key protector. To do this, run the following PowerShell command on a guarded host or any machine that can reach the HGS server: <BR /> Invoke-WebRequest http://&lt;HGSServer"&gt;FQDN&gt;/KeyProtection/service/metadata/2014-07/metadata.xml -OutFile C:\HGSGuardian.xml <BR /> Copy the file C:\HGSGuardian.xml to the tenant host. <BR /> <H2> Shield the VM </H2> <BR /> Each shielded VM has a Key Protector which contains&nbsp;one owner guardian, and one or more HGS guardians. The&nbsp;steps below illustrate the process of&nbsp;getting the guardians, create the Key Protector in order to shield the VM. <BR /> <BR /> Run the following cmdlets on a tenant host: <BR /> <BR /> [snippet slug=shield-a-vm-by-tenant-admin line_numbers=false lang=bsh] <BR /> <BR /> Typically, you would logon to the VM and enable BitLocker before moving it to the guarded host. Since this is only for testing purposes, we’ll skip this step here. <BR /> <BR /> To complete the process, perform the following steps: <BR /> <UL> <BR /> <LI> shut down the shielded VM </LI> <BR /> <LI> export the VM from the tenant host </LI> <BR /> <LI> copy the exported file to the guarded host and import them </LI> <BR /> <LI> start the VM on the guarded host </LI> <BR /> </UL> <BR /> As shown above, this approach is quite manual and easy to make mistakes (such as not running BitLocker to encrypt data). Therefore, it is not recommended in production. For that, you should use the second approach illustrated in the following section: <A href="" target="_blank"> Provisioning Shielded VMs using the template disk. </A> <BR /> <H2> <A> </A> Provisioning Shielded VMs using shielded templates </H2> <BR /> In production, you would typically use a fabric manager (e.g. VMM) to deploy shielded VMs. However, the steps illustrated below allow you to deploy and validate the entire scenario without a fabric manager. <BR /> <BR /> In a nutshell, you will create a template disk, a shielding data file, a Windows unattend.xml file and other security artifacts on the tenant host, then copy these files to a guarded host and provision shielded VMs. <BR /> <H2> Prerequisites </H2> <BR /> In order to create the template disk and the shielding data file, you will need to install the “Shielded VM Tools” feature under the Remote Server Administration Tools -&gt; Feature Administration Tools on the tenant host machine. You can do this either in Server Manager or by running the following cmdlet: <BR /> Install-WindowsFeature RSAT-Shielded-VM-Tools <BR /> Next, you will also need a VHDX file with a fully installed and sysprepped OS—we’ll call it ServerOS.vhdx. <BR /> <H2> Create a signed template disk </H2> <BR /> In order to create the signed template disk, you will need to have a certificate to sign it. For simplicity, let’s create a self-signed certificate for this purpose. &nbsp;Run the following PowerShell commands on the tenant host: <BR /> $cert = New-SelfSignedCertificate -DnsName '' <BR /> Now, we sign the disk: <BR /> Protect-TemplateDisk -Path ‘C:\ServerOS.vhdx’ -TemplateName "ServerOSTemplate" -Version -Certificate $cert <BR /> <H2> Create Shielding Data (PDK) file </H2> <BR /> Shielding Data is created/owned by tenants/VM owners and contains secrets that must be protected from the fabric admin and that is needed to create shielded VMs, e.g. the shielded VM’s administrator password.&nbsp; Shielding Data is contained in a PDK file which is also encrypted.&nbsp; Once created by the tenant/VM owner, the resulting PDK file must be copied to the guarded fabric. The <A href="#" target="_blank"> deployment guide </A> has much more detailed explanation of shielding data and why it is necessary. <BR /> <BR /> In addition, you will also need a Windows unattend.xml file; a working sample is also included in the <A href="#" target="_blank"> deployment guide </A> . <BR /> <BR /> During deployment, you will need to import the HGS guardian, you can follow the steps described in the section above titled Retrieve the HGS guardian—it will be referenced as ‘C:\HGSGuardian.xml’ below. <BR /> <BR /> Run the following cmdlets on the tenant host to create the PDK: <BR /> <BR /> [snippet slug=create-pdk lang=bsh] <BR /> <H2> Provision shielded VM on a guarded host </H2> <BR /> Copy the template disk file (ServerOS.vhdx) and the PDK file (contoso.pdk) to the guarded host, to get ready for deployment. <BR /> <BR /> The Windows unattend.xml file has some placeholder settings that need to be substituted during deployment to ensure the resulting VM is unique and fully configured, e.g. it contains a computer name and a timezone. These unique values are specified in a FSK (Fabric Specialization Key) file. To create one, run the following cmdlet on the guarded host to create the FSK file, and provision a shielded VM using the signed template disk: <BR /> [snippet slug=creating-shielded-vm-using-template-disk lang=bsh] <BR /> <BR /> While the shielded VM is being provisioned, you can use the following cmdlet to check the progress: <BR /> Get-ShieldedVMProvisioningStatus -VMName $vmname <BR /> Once it’s completed, make sure the shielded VM has the correct Network Adapter configured so it can be accessed through RDP. <BR /> <H2> Running Shielded VMs on a Hyper-V cluster </H2> <BR /> If you are trying to deploy shielded VMs on clustered guarded hosts (using a Windows Failover Cluster), you can configure the shielded VM to be highly available using the following cmdlet: <BR /> Add-ClusterVirtualMachineRole -VMName 'contososvm1' -Cluster &lt;guarded host cluster name&gt; <BR /> The shielded VM can now be live migrated within the cluster. <BR /> <H2> Conclusion </H2> <BR /> In summary, this blog post walked you through the steps to create shielded VMs without a fabric manager such as VMM. This enables you to deploy and validate the scenario with a simpler topology (at the expense of a more complex administration experience). <BR /> <BR /> This scenario is new in Windows Server 2016—we’d love to hear your feedback. You can reach <A href="" target="_blank"> us </A> , or submit and vote on request through the <A href="#" target="_blank"> User Voice web site </A> . </BODY></HTML> Fri, 15 Mar 2019 23:08:13 GMT Jian (Jane) Yan 2019-03-15T23:08:13Z A closer look at shielded VMs in Windows Server 2016 <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on May 10, 2016 </STRONG> <BR /> [This blog post was originally published in the <A href="#" target="_blank"> Windows Server Blog </A> ] <BR /> <BR /> <EM> This post was authored by Jeff Woolsey, Principal Program Manager, Windows Server. </EM> <BR /> <BR /> On this week’s Microsoft Mechanics show, we bring you Dean Wells and Matt McSpirit to demonstrate Shielded VMs – another reason why you should be evaluating Windows Server 2016. <BR /> <BR /> <IFRAME frameborder="0" height="315" src="" width="560"> </IFRAME> <BR /> <H3> A little backstory … </H3> <BR /> As someone who has spent a lot of time with hypervisors and virtualization, I’m the first one to tell you that virtual machines are fantastic. If you look at any datacenter today, virtualization is a key element. With virtual machines we’ve made it easier to deploy, manage, service and automate the infrastructure. The benefits are many; however, as much as I love virtualization, I’m almost the first person to tell you that virtualization also requires us to think differently about the security of our virtualized infrastructure and applications. <BR /> <BR /> Take a deep breath and read that last sentence again. It’s ok. <BR /> <BR /> Let’s discuss. <BR /> <H3> Security, what security? </H3> <BR /> With virtual machines, we’ve taken an operating system, an application and its dependencies which used to run on hardware and encapsulated those into a few files for a virtual machine so we can run multiple virtual machines (if not dozens) on a single system concurrently. They’re easier to live migrate, backup, replicate, but it also means that we’ve made it easier to modify or even copy entire workloads off the network or onto a USB stick and walk out the door with your crown jewels. A perfect example is your domain controller. Imagine if your domain controller somehow got out of your organization. The DC is literally the keys to your kingdom. <BR /> <BR /> Now, imagine that someone manages to walk out the door with dozens of virtual machines because they’re all centrally located. Worse, they can take those virtual machines home and run them on their personal desktop or laptop and you still have no idea they left the premises. <BR /> <BR /> Let me be very clear: Every hypervisor, every virtualization platform has this issue. VMware, Hyper-V, Xen, KVM, etc. <BR /> <H3> Encryption and TPMs </H3> <BR /> It’s usually at this point where someone interjects with: “Yes, but the answer to this problem is encryption. All we need to do is add a virtual Trusted Platform Module (TPM) to the virtual machine so that the tenant can encrypt the VM.” <BR /> <BR /> Great idea, except that doesn’t work. <BR /> <BR /> We need to protect against rogue administrators and, by definition, an administrator can do anything they want on the system. Thus, anything you do to encrypt or protect a VM, the admin can undo. For example, suppose we just provided a virtual TPM inside the virtual machine. With a virtual TPM, the host admin could still find those keys in memory and decrypt the VM. <BR /> Again, this applies to all platforms: VMware, Hyper-V, Xen, KVM, etc. <BR /> <BR /> Do I have your attention yet? <BR /> <H3> Shielded VMs and guarded fabric </H3> <BR /> At the end of the day what you want is to be able to: <BR /> <UL> <BR /> <LI> Safeguard VMs so that VMs can only run on infrastructure you designate as your organization’s fabric and are </LI> <BR /> <LI> Protected VMs even from compromised administrators </LI> <BR /> </UL> <BR /> To do this, we are introducing Shielded VMs in Windows Server 2016. Shielded VMs protect virtual machines from compromised or malicious administrators in the fabric, such as storage admins, backup admins, etc. by encrypting disk and state of virtual machines so only VM or tenant admins can access it. <BR /> <BR /> In addition, we are also protecting the fabric with a new Windows Server feature: the Host Guardian Service. When a shielded virtual machine is turned on, the Host Guardian Service (HGS) checks to see if the hosts are allowed to run the Shielded VM. This is accomplished through attestation and hardware based boot measurements along with a new feature: Code integrity to determine whether a host meets the criteria as a healthy host and may run the Shielded VM. <BR /> <BR /> If you’re looking for more information on Shielded VMs, please check out the <A href="#" target="_blank"> Shielded VMs documentation </A> and the <A href="#" target="_blank"> Shielded VMs infographic </A> . <BR /> <BR /> Finally, a huge thanks to all of you for your feedback on Windows Server 2016. We’ve been listening closely and tuning it based on your input. </BODY></HTML> Fri, 15 Mar 2019 23:08:10 GMT Vinicius Apolinario 2019-03-15T23:08:10Z Overview of Host Guardian Service (HGS) Diagnostics <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on May 04, 2016 </STRONG> <BR /> [This post is authored by Jim Hughes,&nbsp;Software Engineer&nbsp;for the&nbsp;Windows Server&nbsp;Team] <BR /> <BR /> The Host Guardian Service (HGS) is a principal component in enabling Hyper-V to host <A href="#" title="Shielded VM Overview Blog" target="_blank"> Shielded VMs in Windows Server 2016 </A> . Shielded VMs are your typical Hyper-V virtual machines, but protected from tampering and inspection by platform administrators and malicious actors. <BR /> <BR /> The initial <A href="#" title="HGS Deployment Blog" target="_blank"> deployment of HGS </A> is a complex task that encompasses the management of multiple roles and features (Active Directory, DNS, Failover Clustering, IIS, and Hyper-V) in addition to infrastructure management tools (Group Policy and System Center). That was a lot for me to remember to write down in this post—putting all of these pieces together in a production deployment is even more difficult. The problem only compounds when something goes wrong and your HGS deployment stops functioning—where does one start with an environment so complex? <BR /> <BR /> To solve this problem, we designed a set of PowerShell cmdlets for diagnosing HGS and its supporting infrastructure. These cmdlets let you spend less time guessing and checking, reducing the time it takes to deliver shielded VM’s to your customers. If things go wrong later on, you can minimize the impact by quickly triaging various configuration points, checking for frequent missteps we’ve noted during the past four technical previews. <BR /> <H2> What’s in the Box </H2> <BR /> HGS Diagnostics are available in <A href="#" target="_blank"> Windows Server 2016 Technical Preview </A> in both the Host Guardian Service role and the Host Guardian Hyper-V Support feature. This means that all diagnostic tools are available on both your guarded hosts and HGS cluster. To learn more about deploying HGS, read the <A href="#" target="_blank"> deployment guide </A> . <BR /> <H2> HGS Diagnostics 101 </H2> <BR /> Diagnostics are accessed using the <EM> Get-HgsTrace </EM> cmdlet. This can be executed remotely using PowerShell remoting or locally from a PowerShell prompt. To audit the local machine, run <EM> Get-HgsTrace </EM> with the <EM> -RunDiagnostics </EM> switch (without the <EM> -RunDiagnostics </EM> switch, trace data is collected from the host but not analyzed; this is useful for those who are willing to get their hands dirty to manually diagnose a tricky issue). <BR /> <BR /> <IMG src="" /> <BR /> <BR /> A report is generated that details any issues identified on the local system. To see everything that was tested and not just noteworthy results, provide the <EM> -Detailed </EM> switch. Each failure message specifies what went wrong and how to remediate the issue. In this case it looks like I forgot to restart after installing a new code integrity policy. <BR /> <BR /> If the test detects no issues but a problem is still occurring, you can immediately narrow the scope of your investigation to items not verified by the diagnostics. <BR /> <H2> HGS Diagnostics 202 </H2> <BR /> We’ve just scratched the surface of what this tool can do. You can even diagnose multiple hosts at once with the <EM> New-HgsTraceTarget </EM> cmdlet—diagnostics can use the increased knowledge of your deployment to find issues that could not be identified by looking at each host in isolation. To learn more, read the <A href="#" target="_blank"> documentation available on TechNet </A> . <BR /> <BR /> <STRONG> Disclaimer: </STRONG> This is still pre-release software and as we continue to iterate, there may be changes to the syntax and functionality of the diagnostic cmdlets. <BR /> <BR /> Happy triaging! </BODY></HTML> Fri, 15 Mar 2019 23:08:07 GMT Vinicius Apolinario 2019-03-15T23:08:07Z Step by Step - Configuring Key Protection for the Host Guardian Service in Windows Server 2016 <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Mar 28, 2016 </STRONG> <BR /> [This post is authored by Sumesh Kumar, Program Manager for the Enterprise and Security Product Team] <BR /> <BR /> The “Key Protection Service” (KPS) is one of the two services that run as part of a Windows Server role called the Host Guardian Service (or HGS). The second of those two services is called Attestation and will be covered in a separate blog. KPS provides the keys (known as Transport Keys or TKs) needed to unlock &amp; run Shielded VMs on affirmatively attested (or healthy) Hyper-V hosts. In this Blog post we will cover the installation and configuration of KPS in Windows Server 2016. <BR /> <H2> 1 Installation/Configuration </H2> <BR /> KPS is automatically installed when you install the HGS server role. Check out how to install the HGS role <A href="#" title="Host Guardian Service" target="_blank"> here </A> . <BR /> <H2> 1.1 Initializing with HSM Backed Keys </H2> <BR /> If you followed the instructions to install the HGS role, then you now have a HGS initialized with a pair of software keys. You also have the option to use <A href="#" target="_blank"> Hardware Security Module </A> (HSM) backed keys. HSMs provide strong physical protection of secure assets, including keys, and should be considered a best practice when deploying HGS. <BR /> <BR /> To initialize the HGS server using signing and encryption keys that are backed by an HSM, use the following PowerShell syntax: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> The signing and encryption keys used to initialize HGS will be the default keys used for protecting Shielded VMs. <BR /> <H2> 1.2 Adding HSM Backed Keys </H2> <BR /> If you initialized HGS using keys other than those in an HSM or you simply want to replace the default keys that HGS uses, you can add the new encryption and signing keys using the Add-HgsKeyProtectionCertificate PowerShell cmdlet. <BR /> <BR /> To view HGS’s current certificates, use Get-HgsKeyProtectionCertificate. <BR /> <H2> 1.3 Marking HSM Backed Keys as Primary </H2> <BR /> You can set newly added HSM backed keys as the primary set of encryption and signing keys with Set-HgsKeyProtectionCertificate. <BR /> <BR /> <IMG src="" /> <BR /> <H2> 1.4 KPS and Key Management Tips </H2> <BR /> 1. When importing a new set of signing and encryption keys, ensure you add them to the Certificate Store under “Local Computer” (referred to as “Local Machine” in PowerShell). <BR /> <BR /> <IMG src="" /> <BR /> <BR /> 2. Ensure the user account under which the KPS service executes (KeyProtection app pool), has “read” access rights to the private keys of the HSM backed keys. This requires two steps: <BR /> <BR /> Step #1. Launch IIS Manager and select “Application Pools” and note the account (as shown below) under which the KeyProtection app pool is running. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> Step #2. Run the Local Machine Certificate Management Console (certlm.msc). Locate the encryption and signing certificates under the “Personal” folder, right click each of them in turn and verify (or add the permission if necessary to) the user account from Step #1 to the list of Groups and Users permitted to manage the private keys. Allow “Read” is the only needed permission. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> 3. To confirm KPS has access to the private keys of your encryption and signing certificates, run the HGS diagnostics using Get-HgsTrace. If any tests fail, be sure to remediate the identified problem(s) before continuing to configure any additional nodes. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> 4. The signing and encryption keys must be available on every node in the HGS cluster. On each of these nodes, you will need to install the same encryption and signing certificates according to your HSM manufacturer’s directions. Once the certificates are installed, grant the KPS App Pool identity read access to the private keys, as before. <BR /> <H2> 2 Bring Your Own Key scenario (BYOK) </H2> <BR /> Security-sensitive tenants may prefer to use their own HSM-backed keys for signing and encryption instead of the default keys configured and owned by the hoster. To support this, the hoster and tenant need to agree on a process to copy the tenant’s keys into the hoster’s HSM. This is a sensitive process and is subject to far greater scrutiny than other key management methods—it can even take place via in-person, offline methods. The actual process of either migrating keys from the tenant HSM to the hoster HSM or having the hoster’s HSM create the keys (so they’re “born” in the HSM) should be done according to the HSM manufacturer’s guidance. <BR /> <BR /> Once the tenant’s encryption and signing keys are known to the hoster’s HSM, the hoster must install the certificates on each HGS node and grant the KPS App Pool access to the private keys, as shown in sections 1.2 and 1.4. Note that the certificates you install onto each HGS node only hold the public key, the private key never leaves the HSM. Finally, the hoster must <STRONG> not </STRONG> assign the tenant’s keys as the primary KPS keys because KPS’ primary key is assumed to be appropriate for all tenants, not an individual tenant. When the hoster has finished configuring all HGS nodes with the tenant’s keys, tenant may now deploy new Shielded VMs based upon them. <BR /> <BR /> </BODY></HTML> Fri, 15 Mar 2019 23:04:26 GMT Vinicius Apolinario 2019-03-15T23:04:26Z Step by Step - Creating Shielded VMs <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Mar 23, 2016 </STRONG> <BR /> [This post is authored by Dean Wells, Principal Program Manager for the Windows Server Security Product Team] <BR /> <BR /> In this blog, we’ll walk through the steps necessary to create a shielded VM and briefly discuss each of the prerequisite pieces. For the purposes of the blog, we’ll walk through the end-to-end experience from the perspective of a tenant as it appears in Azure Pack (formerly Windows Azure Pack). <BR /> <H2> Step 1 – Connect to and logon to the tenant portal </H2> <BR /> Let’s start with the easy part: We’ll need to browse to the tenant portal and log on—enough said about that step. <BR /> <H2> Step 2 – Kick off the process of creating a new Shielded VM </H2> <BR /> Creating a new shielded VM begins with the same steps as creating a regular VM: <STRONG> New -&gt; Standalone Virtual Machine -&gt; From Gallery </STRONG> <BR /> <BR /> <IMG src="" /> <BR /> <H2> Step 3 – Select the appropriate template </H2> <BR /> In the same way that regular (non-shielded) VMs are created from regular templates, shielded VMs are created from <STRONG> Shielded Templates </STRONG> . A Shielded Template is similar in nature to a regular template but there are important differences. To illustrate, when you create a regular VM using a regular template, you will be prompted to enter the new VM’s <STRONG> administrator credentials </STRONG> . In the case of a Shielded Template, all of these kind of secrets live inside something called <STRONG> shielding data </STRONG> which you, as the tenant, create and encrypt on-premises and upload to the hoster. We’ll come back to how create <STRONG> shielding data </STRONG> in a little while. <BR /> <BR /> Back to the creation process—we’re at the point in the process where things start to differ a little compared to creating regular VMs. In order to create a <STRONG> shielded VM, </STRONG> we need to choose a <STRONG> Shielded Template </STRONG> . They’re rather cleverly distinguished from regular templates with an icon that depicts a <STRONG> shield </STRONG> as highlighted below—so we select an appropriate <STRONG> Shielded Template </STRONG> and continue on. <BR /> <BR /> <BR /> <BR /> <IMG src="" /> <BR /> <H2> Sidebar </H2> <BR /> At this point, it makes sense for us to segue into two related topics both of which are prerequisite to deploying shielded VMs in a hosted environment. The two topics are: <BR /> <OL> <BR /> <LI> What is a <STRONG> Volume Signature Catalog? </STRONG> </LI> <BR /> <LI> What is <STRONG> Shielding Data? </STRONG> </LI> <BR /> </OL> <BR /> <H2> 1. What is a Volume Signature Catalog? </H2> <BR /> When deploying a new VM from template, whether it be shielded or not, a template disk is used as the basis for the VM’s operating system disk. Template disks for Windows operating systems are typically prepared using a tool called sysprep—sysprep (de)configures the OS to a generalized (unnamed, unconfigured, etc.) state. At deployment time, the generalized template disk is copied, then specialized and a new VM is born. These template disks are stored in a configurable location on the fabric. Fabric and/or storage admins are likely to have administrative permissions to the template disks. Given this, consider which of the following two attack vectors represents the least path of resistance when attempting to maliciously gain access to a shielded VM: <BR /> <BR /> 1) attack existing shielded VMs and attempt to subvert the array of protections that shielding affords <BR /> <BR /> 2) add malware to a template disk that will be used to deploy future (not-yet-created) shielded VMs <BR /> <BR /> Clearly, #2 is by far the simpler of the two and a vulnerability that we needed to eliminate. Here’s how we handle that: template disks that will used as the basis of new shielded VMs ( <STRONG> shielded template disks </STRONG> ) require one additional preparation step—they must be signed. To sign a shielded template disk, a trusted admin performs the following steps: <BR /> <OL> <BR /> <LI> Build and prepare a new template disk in the normal manner (or copy an existing one) </LI> <BR /> <LI> Run a new tool called the “ <STRONG> Template Disk Signing Wizard </STRONG> ” </LI> <BR /> </OL> <BR /> <IMG src="" /> <BR /> <BR /> As you can see, the wizard requires the following inputs: <BR /> <UL> <BR /> <LI> A certificate used to sign the disk <BR /> <UL> <BR /> <LI> Needs to support RSA encryption and 2048 bit keys </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> The path to the template disk you want to sign <BR /> <UL> <BR /> <LI> Note that this disk will be modified in-place, so you may wish to make a copy first </LI> <BR /> </UL> <BR /> </LI> <BR /> <LI> A friendly name and a 4-part version number, e.g. <BR /> <UL> <BR /> <LI> Shielded WS 2016 Server Core </LI> <BR /> <LI> </LI> <BR /> </UL> <BR /> </LI> <BR /> </UL> <BR /> … once you click <EM> Generate, </EM> the wizard will work on the disk for some time and save the <STRONG> volume signature catalog </STRONG> (.VSC file) to the VHDX. <BR /> <BR /> One final step remains—you need to extract the <STRONG> volume signature catalog </STRONG> from the now-prepped VHDX and save it as a .VSC file which you will later add to <STRONG> Shielding Data </STRONG> . To do that, run the following cmdlet: <BR /> <BR /> <IMG src="" /> <BR /> <H2> 2. What is Shielding Data? </H2> <BR /> Shielding Data (stored as PDK files) can be thought of as a bunch of encrypted secrets. You’ll use <STRONG> Shielding Data </STRONG> both when provisioning new shielded VMs as well as when converting regular VMs to shielded VMs. Remember, the hoster can’t read the contents of the <STRONG> Shielding Data </STRONG> because its encrypted using keys that are not available to the hoster’s administrators. <STRONG> Shielding Data </STRONG> is securely decrypted at provisioning time by a trusted provisioning component that is also isolated from administrators. <BR /> <BR /> Among others, <STRONG> Shielding Data </STRONG> contains secrets such as: <BR /> <UL> <BR /> <LI> Administrator credentials </LI> <BR /> <LI> An RDP certificate to secure remote desktop communication with your newly provisioned VM </LI> <BR /> <LI> A Key Protector (or KP) that defines which guarded fabrics a shielded VM is authorized to run on </LI> <BR /> <LI> A volume signature catalog (.VSC files) that contains a list of trusted, signed template-disks that a new VM is allowed to be created from </LI> <BR /> </UL> <BR /> <STRONG> NB: </STRONG> All new VMs created from the same <STRONG> Shielding Data </STRONG> will share all of the secrets contained therein. Stated another way, if two or more VMs are deployed using the same <STRONG> Shielding Data </STRONG> , their initial administrator credentials will be the same and they will use the same RDP certificate to secure communication, etc. <BR /> <BR /> <STRONG> Shielding Data </STRONG> is created using the Shielding Data Wizard as shown below, and the resulting PDK file is then uploaded by you/the tenant to the hoster’s guarded fabric. <BR /> <H3> The Shielding Data File Wizard <BR /> <IMG src="" /> </H3> <BR /> For a step-by-step description of exactly how to create <STRONG> Shielding Data </STRONG> , please see the <A href="#" target="_blank"> Shielded VMs and Guarded Fabric deployment guide </A> . <BR /> <H2> Step 4 – Selecting your Shielding Data </H2> <BR /> Next, we need to name the VM as usual and then select the <B> Shielding Data </B> that we mentioned briefly earlier on. Here’s how you do that: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> Step 5 – Connect the new Shielded VM to a network <BR /> <BR /> In the final step, select the Network to which the Shielded VM should be connected to. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> That’s all there is to it. Simple, huh! </BODY></HTML> Fri, 15 Mar 2019 23:03:31 GMT Vinicius Apolinario 2019-03-15T23:03:31Z Step by Step - Configuring Guarded Hosts with Virtual Machine Manager 2016 <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Mar 21, 2016 </STRONG> <BR /> <BR /> <BR /> [This post is authored by John Patterson, Program Manager for the&nbsp;System Center&nbsp;Product Team] <BR /> <BR /> In this blog I want to talk about setting up guarded hosts using Virtual Machine Manager (VMM). A guarded host is just a host that can run shielded VMs. Once your Host Guardian Service has been set up and configured, configuring hosts to run shielded VMs is pretty easy. <BR /> <BR /> All you need to do in VMM to set up a guarded host is to configure the host you want to be guarded with three (sometimes four) properties: <BR /> <UL> <BR /> <LI> <STRONG> Attestation Service URL </STRONG> – The URL of the attestation service (part of the HGS). The attestation service basically confirms that the host is authorized to run shielded VMs. </LI> <BR /> <LI> <STRONG> Key Protection Service URL </STRONG> – The URL of the key protection service (also part of the HGS). Once a host passes attestation, it retrieves the key required to decrypt VMs from this service. </LI> <BR /> <LI> <STRONG> Code Integrity Policy File Share Path (Only Required for TPM Attestation Mode) </STRONG> – When using TPM attestation mode (bare minimum requirement is that your host must have a TPM 2.0 chip in it), a code integrity policy is used to restrict the software that can run in kernel mode to ONLY what is specified in the code integrity file (a .p7b file). In order to get this file on the host, you must set the path to it. </LI> <BR /> <LI> <STRONG> Shielding Helper VHD </STRONG> – Includes tools to convert existing non-Shielded VMs to Shielded VMs </LI> <BR /> </UL> <BR /> So… while there is a LOT behind shielded VMs, guarded hosts, and encrypted workloads, actually configuring a guarded host is easy (remember at most you only need to set these three properties). Let’s do this in VMM. <BR /> <H2> Step 1 – Configuring the Global HGS Settings </H2> <BR /> In the VMM console navigate to <STRONG> Settings &gt; Host Guardian Service Settings </STRONG> <BR /> <BR /> <IMG src="" /> <BR /> <BR /> Here you need to do three things: <BR /> <UL> <BR /> <LI> Tell VMM what attestation and key protection URLs hosts in VMM will use (Note: all hosts in VMM must use the same ATT and KPS URLs) </LI> <BR /> <LI> Add any CI policies to VMM (really you don’t add the CI policy itself, you add a friendly name and the location where the host themselves can fetch the CI policy from). Note above I’m pointing to a file share the hosts can access (via their host account) to get the CI policy from. </LI> <BR /> <LI> Specify the location of the Shielding Helper VHD in the VMM Library </LI> <BR /> </UL> <BR /> <STRONG> Here is a potential gotcha: The Code Integrity Policy File Share Path entered in VMM is the EXACT same path set on the hosts. </STRONG> So ALL the hosts using a particular CI policy need to have access to the file share path that is set in VMM. <BR /> <BR /> <IMG src="" /> <BR /> <H2> Step 2 – Configure Your Guarded Host </H2> <BR /> <EM> <STRONG> Note: For applying Code Integrity Policy on a TPM based host, the host needs to move into Maintenance Mode <BR /> </STRONG> <STRONG> Right Click Host &gt; Start Maintenance Mode </STRONG> </EM> <BR /> <BR /> <STRONG> Right Click Host &gt; Host Guardian Service &gt; Check the Checkboxes </STRONG> <BR /> <BR /> <IMG src="" /> <BR /> <UL> <BR /> <LI> The first checkbox essentially sets the attestation and key protection URLs on the host. If you are <STRONG> not using </STRONG> TPM based attestation, this is the only box you need to check. </LI> <BR /> <LI> The second check box sets the file path of the CI policy on the host it doesn’t ACTUALLY put the CI policy on the host. The host fetches its CI policy on its own from the given location. In my case I’m using TPM based attestation, so I specify the CI policy designated for my Dell hosts (if you didn’t guess it, this happens to be a Dell server) </LI> <BR /> </UL> <BR /> After successfully Applying ‘Host Guardian Service’ settings, need to move the host out of the Maintenance Mode. <BR /> <BR /> <STRONG> Right Click Host &gt; Stop Maintenance Mode </STRONG> <BR /> <BR /> <BR /> <H2> That’s It </H2> <BR /> That’s all it takes to configure hosts to run shielded VMs in VMM. At this point, shielded VMs will be automatically placed on any guarded hosts under VMM’s management. </BODY></HTML> Fri, 15 Mar 2019 23:02:26 GMT Vinicius Apolinario 2019-03-15T23:02:26Z Step by Step - Configuring the Host Guardian Service in Windows Server 2016 <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Mar 16, 2016 </STRONG> <BR /> <STRONG> For the most up-to-date installation instructions, check out our official documentation at <A href="#" target="_blank"> </A> </STRONG> <BR /> <BR /> [This post is authored by Amitabh Tamhane, Senior Program Manager and Ryan Puffer, Program Manager for the Windows Server Product Team] <BR /> <BR /> The “Host Guardian Service” (HGS) is a new server role introduced in Windows Server 2016. HGS provides Attestation and Key Protection services that enable Hyper-V to run <A href="#" target="_blank"> Shielded virtual machines </A> . A Hyper-V host is known as a “guarded host” once the Attestation service affirmatively validates its identity &amp; configuration. Once affirmatively attested, the Key Protection service provides the transport key (TK) needed to unlock &amp; run Shielded VMs. <BR /> <BR /> Shielded VMs protect VM data and state by supporting a virtual TPM (vTPM) device which allows BitLocker encryption of the VM’s disks. This vTPM device is encrypted with a transport key. HGS is a security critical component that protects the TK. In addition, there are significant security enhancements made across multiple components (including Hyper-V) that raise the security assurance levels for Shielded VMs. For more details on terms like Shielded VMs, guarded fabric, guarded hosts, etc. click <A href="#" target="_blank"> here </A> . <BR /> <BR /> The purpose of this blog is to walk-through the default configuration steps for the Host Guardian Service role and the corresponding Hyper-V support components. For advanced scenarios and more information on the guarded fabric topology, consult the <A href="#" target="_blank"> guarded fabric deployment guide </A> . <BR /> <H2> 1. Installing Host Guardian Service (HGS) Role </H2> <BR /> On a machine running Windows Server 2016, install the Host Guardian Service role using Server Manager or Windows PowerShell. As a security best practice, it is recommended that you use a dedicated physical machine running the Server Core installation option for HGS. <BR /> <STRONG> Using Server Manager: </STRONG> <BR /> <BR /> <IMG src="" /> <BR /> <BR /> <STRONG> Using PowerShell: </STRONG> <BR /> <BR /> <IMG src="" /> <BR /> <H2> 2. Configuring HGS Server </H2> <BR /> After installing the HGS role, you still need to configure the role to make it a fully functional HGS server. All management of HGS is done through Windows PowerShell. <BR /> <BR /> <EM> Note: This blog assumes the default installation mode for HGS where a new Active Directory forest will be created specifically for the Host Guardian Service. If you wish to instead join HGS to an existing, highly trusted Active Directory domain, please consult the <A href="#" target="_blank"> guarded fabric deployment guide </A> for the extra configuration steps you must take. </EM> <BR /> <H2> 2.1. Install-HgsServer </H2> <BR /> The first step is set up the dedicated Active Directory forest for the HGS servers. Each node in the HGS cluster is a domain controller for this private domain. Ensure the HGS server is not already joined to a domain before running this command. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> After the machine restarts, it will be the primary domain controller for the newly created domain. Log into the server with your administrator account to continue the HGS setup process. <BR /> <BR /> 2.2. Initialize-HgsServer <BR /> <BR /> With the domain set up, it is now time to configure the HGS cluster and web services for Key Protection and Attestation. You will need 2 certificates (1 for signing, 1 for encryption) in order to complete this step. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> “HgsServiceName” will be used to register the cluster service name with the local DNS server. In the above example, the service name is “HGS”, so the FQDN of the service will be “” (refer to the domain name specified in the Install-HgsServer). <BR /> <BR /> The “TrustTpm” parameter specifies the Attestation service operation mode. For TPM-trusted fabrics, use “-TrustTpm”. If your host machines do not meet the hardware requirements for TPM attestation, you can configure HGS to use AD attestation with the “-TrustActiveDirectory” parameter. <BR /> <BR /> The last 4 parameters are for specifying the signing and encryption certificates, where the certificates are provided as references to password-protected PFX files that contain the public and private keys of each certificate. These certificates are used by the Key Protection Service in HGS to decrypt keys of shielded VMs. Owners of shielded VMs use the public keys to authorize a fabric to run their VMs. <BR /> <BR /> If you are setting up HGS in your test lab, you can use self-signed certificates to get started quickly. To generate self-signed certificates and export them to PFX files, use the New-SelfSignedCertificate and Export-PfxCertificate cmdlets. <BR /> <BR /> When using HSM backed certificates or non-exportable certificates from your PKI, you will specify the thumbprint of the certificate instead of a PFX file and password when running Initialize-HgsServer. The <A href="#" target="_blank"> guarded fabric deployment guide </A> explains the extra steps you need to take when using PKI-issued or HSM-backed certificates. <BR /> <H2> 2.3. Validate your configuration </H2> <BR /> Once the primary HGS Server is configured, you can run the HGS diagnostics to ensure everything is set up correctly. In PowerShell, run the following command to check if there are any additional steps you need to take. <BR /> <BR /> <IMG src="" /> <BR /> <H2> 3. Authorizing guarded hosts </H2> <BR /> Before a Hyper-V host can run shielded VMs, HGS must be configured with attestation policies which are used to determine if the host is “healthy” and allowed to request keys for shielded VMs. <BR /> <BR /> 3.1. TPM-trusted attestation <BR /> <BR /> For TPM-trusted attestation, a guarded host’s TPM 2.0’s Endorsement Key (EK) needs to be retrieved and added to the list of authorized hosts in HGS. <BR /> <BR /> On each host, use the Get-PlatformIdentifier cmdlet to generate an XML file containing the EKpub and EKcert. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> Copy this file to your HGS server and use the Add-HgsAttestationTpmHost cmdlet to authorize the guarded host with the attestation service: <BR /> <BR /> <IMG src="" /> <BR /> <H2> 3.2 AD-trusted attestation </H2> <BR /> For Admin-trusted attestation, the guarded host is expected to be part of an Active Directory security group. Use the Add-HgsAttestationHostGroup to authorize the Active Directory group’s SID with the Attestation service: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> <EM> Note: For AD-trusted attestation, you also need to establish one-way trust between the fabric Active Directory domain and the HGS domain. Consult the deployment guide for instructions on how to set up this trust. </EM> <BR /> <BR /> 4. Configuring Policies (TPM-trusted attestation only) <BR /> <BR /> For TPM-trusted attestation, the guarded host’s software integrity is also verified. You need to configure baseline policies with the attestation service to establish one or more authorized (known good) host configurations. <BR /> <BR /> <EM> Note: For AD-trusted attestation, the guarded host’s configuration is not verified. Hence, the steps below are not required for AD-trusted attestation. </EM> <BR /> <H2> 4.1. Add-HgsAttestationCIPolicy </H2> <BR /> On a reference host (sometimes called a golden image) that is completely configured with all software agents and features installed, run the New-CIPolicy cmdlet to generate a code integrity policy. This policy will be applied to every machine with the same configuration, and is used to prevent unauthorized software from running on the host. You will need to create a CI policy once for each unique hardware/software configuration in your datacenter. Consult the <A href="#" target="_blank"> deployment guide </A> for detailed instructions on the CI policy cmdlets. <BR /> <BR /> Once generated, you’ll have a code integrity policy stored in a binary file with a .p7b extension. Copy this file to your HGS server and add it to the attestation service: <BR /> <BR /> <IMG src="" /> <BR /> <H2> 4.2. Get-HgsAttestationBaselinePolicy </H2> <BR /> Next, for each unique hardware configuration in your datacenter you need to collect a TPM baseline policy. This file will contain information about the UEFI boot sequence up to the point where control of the system is handed off to the Windows boot loader. It is validated by HGS to ensure the system did not try to load unauthorized code such as a rootkit before Windows was loaded. <BR /> <BR /> To capture a TPM baseline policy, run the following command on a reference host: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> Copy the file to your HGS server and register it with the attestation service: <BR /> <H2> <IMG src="" /> </H2> <BR /> <H2> 5. Configure HGS Client </H2> <BR /> The final step is to configure each guarded host to attest with and request keys from your HGS servers. You can find the two URLs to use here by running Get-HgsServer on the HGS server. Run the following command on each guarded host: <BR /> <BR /> <IMG src="" /> <BR /> <BR /> This command will trigger an attestation attempt with the server and show you its result. If “IsHostGuarded” is not true, check the attestation status and substatus for indications as to why your host did not pass attestation with HGS. <BR /> <H2> 6. Conclusion </H2> <BR /> Now that the HGS attestation service has been configured with information about the trusted hosts and their trusted configurations in your datacenter, you are ready to create your first shielded VM. Check out this <A href="#" target="_blank"> blog post </A> or the <A href="#" target="_blank"> deployment guide </A> for information about creating a shielded VM. <BR /> <BR /> </BODY></HTML> Fri, 15 Mar 2019 23:01:50 GMT Vinicius Apolinario 2019-03-15T23:01:50Z What are Shielded VMs in Windows Server 2016 Hyper-V? <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Mar 14, 2016 </STRONG> <BR /> As Information Technology became the norm, companies have been forced to invest tremendous amounts of money and manpower in protecting sensitive business information. These protections include building physically secured datacenters as well as implementing complex &amp; time-consuming processes to ensure access to both physical and logical resources is strictly controlled. <BR /> <BR /> With the introduction of virtualization, the story was yet further complicated. In a virtualized fabric, we can’t simply use the same techniques that we use to secure physical machines. Simply stated, the meat and potatoes of a VM are merely files on a disk and server admins and storage admins, etc. will have access to these files; access that can be abused and go undetected. For example, a malicious admin can copy the files of 10, 20 or more VMs to a USB stick taking their secrets home with them. If any one of the VMs was an Active Directory domain controller, the malicious admin can use readily available brute force techniques to crack the passwords in the Active Directory database ultimately giving them access to everything else. Attack vectors like these are true of all virtualization platforms. <BR /> <H2> Introducing Shielded Virtual Machines (VMs) </H2> <BR /> Windows Server 2016 Shielded VMs remedy this disconcerting situation by extending virtual machines the same security capabilities that physical machines have enjoyed for years, e.g. secure boot, TPMs and disk encryption. As a result, the data and state of a Shielded VM are protected against inspection, theft and tampering from malware running on a Hyper-V host as well as the fabric admins administering it. But, of course, these protections are provided in software—software that is subject to the same sort of attacks. A new Windows Server 2016 service known as the Host Guardian Service (HGS) helps address this problem. Without HGS, a Hyper-V host cannot power a Shielded VM on because it can’t decrypt it. Why? Because Hyper-V doesn’t have the keys—only HGS does. HGS won’t hand out the keys to a Hyper-V host until that host has been measured and is considered “healthy”—a process known as “attestation”. See the picture below for an overview of this process. <BR /> <BR /> <IMG src="" /> <BR /> <BR /> There are many possible attack vectors that we are able to protect against with Shielded VMs, here are a few examples along with how Shielded VMs protect against the attack: <BR /> <BR /> <BR /> <TABLE> <TBODY><TR> <TD> <STRONG> Attack vector </STRONG> </TD> <TD> <STRONG> Shielded VM defense </STRONG> </TD> </TR> <TR> <TD> A malicious admin steals VHDs </TD> <TD> Shielded VMs’ VHDs are encrypted </TD> </TR> <TR> <TD> Attach a debugger to the Hyper-V host </TD> <TD> HGS won’t release keys to hosts with debuggers attached—this is something we measure in HGS </TD> </TR> <TR> <TD> Inject malware on a Hyper-V host </TD> <TD> All software (kernel mode, user mode and drivers) running on a host is measured </TD> </TR> <TR> <TD> Inject malware into a VM template disk </TD> <TD> Shielded VMs are only deployed from template disks that match known healthy ones </TD> </TR> <TR> <TD> A malicious admin attempts to move a Shielded VM to an untrusted host </TD> <TD> Trusted hosts are added to HGS using an identifier unique to their TPM; the new host will not be recognized because it wasn’t added </TD> </TR> </TBODY></TABLE> <BR /> <BR /> <BR /> For more information, please take a look at any or all of the following resources: <BR /> <UL> <BR /> <LI> <A href="#" target="_blank"> YouTube video showing Shielded VMs in action </A> </LI> <BR /> <LI> <A href="#" target="_blank"> Shielded VM deployment documentation </A> </LI> <BR /> </UL> <BR /> In the next posts, we will go through the technical details of the Shielded VMs components and its configurations. </BODY></HTML> Fri, 15 Mar 2019 23:00:04 GMT Vinicius Apolinario 2019-03-15T23:00:04Z Securing Privileged Access - A practical approach <HTML> <HEAD></HEAD><BODY> <STRONG> First published on TECHNET on Feb 23, 2016 </STRONG> <BR /> Securing privileged access is a critical first step to establishing security assurances for business assets in a modern organization. The security of most or all business assets in an organization depends on the integrity of the privileged accounts that administer and manage IT systems. Cyber-attackers are targeting these accounts and other elements of privileged access to rapidly gain access to targeted data and systems using credential theft attacks like Pass-the-Hash and Pass-the-Ticket. Protecting administrative access against determined adversaries require you to take a complete and thoughtful approach to isolate these systems from risks. <BR /> <BR /> With that in mind, the team worked hard in the last few months in bringing together a&nbsp;roadmap that is designed to maximize the use of technologies that you may have already&nbsp;deployed, take advantage of key current and upcoming security technologies, and integrate any 3rd party security tools you may already have deployed. <BR /> <BR /> The roadmap of Microsoft recommendations is broken into 3 stages: <BR /> <UL> <BR /> <LI> Phase 1: 2-4 week plan – Quickly mitigate the most frequently used attack techniques </LI> <BR /> <LI> Phase 2: 1-3 month plan – Build visibility and control of admin activity </LI> <BR /> <LI> Phase 3: 6+ month plan – Continue building defenses to a more proactive security posture </LI> <BR /> </UL> <BR /> <IMG src="" /> <BR /> <BR /> To&nbsp;read the official article on the Roadmap to Secure Privileged Access, check out the TechNet article <A href="#" title="Secure Privileged Access" target="_blank"> here </A> . </BODY></HTML> Fri, 15 Mar 2019 22:59:51 GMT Vinicius Apolinario 2019-03-15T22:59:51Z