Device Health Attestation assessment for compliance policies for conditional access explained and demoed

Intro

Another “Overdue” blogpost.. Mainly because I couldn’t get it working in TP1706. However with the release of TP1708 I decided to give it another try and … something got fixed, or at least, my challenge is completed now ;-)

Before diving straight into this, let’s take a step back and see what this is all about.

Device Health Attestation (DHA) is a feature that got introduced in Windows 10 - 1507.

The device’s firmware logs the boot process, and Windows 10 can send it to a trusted server that can check and assess the device’s health.

Windows 10 takes measurements of the UEFI firmware and each of the Windows and antimalware components are made as they load during the boot process. Additionally, they are taken and measured sequentially, not all at once. When these measurements are complete, their values are digitally signed and stored securely in the TPM and cannot be changed unless the system is reset.

During each subsequent boot, the same components are measured, which allows comparison of the measurements against an expected baseline. For additional security, the values measured by the TPM can be signed and transmitted to a remote server, which can then perform the comparison. This process, called remote device health attestation, allows the server to verify health status of the Windows device.

Although Secure Boot is a proactive form of protection, health attestation is a reactive form of boot protection

Unlike Secure Boot, health attestation will not stop the boot process and enter remediation when a measurement does not work. But with conditional access control, health attestation will help to prevent access to high-value assets. (Source)

So, This challenge is all about Using that DHA-report as a compliancy rule for conditional access

Setting it all up

When I started working on this challenge, I thought it was going to be a walk in the park… Turns out the park I chose was for experienced hikers (1) ;-)

Anyway, let’s keep moving forward ! First of all, let’s make sure that the windows 10 devices you already manage have their health-reports evaluated. Microsoft offers the DHA service in three ways:

• DHA cloud service : A Microsoft-managed DHA service that is free, geo-load-balanced, and optimized for access from different regions of the world.
• DHA on-premises service : A new server role introduced in Windows Server 2016 Technical Preview 5. It’s available for free to customers that have a Windows Server 2016 license.
• DHA Azure cloud service : A virtual host in Microsoft Azure. To do this, you need a virtual host and licenses for the DHA on-premises service.

Given that there is a free option, we are going for the DHA Cloud service. To enable this, navigate in your Configmgr AdminUI to Administration - Client Settings.

Edit your default client settings and select “Computer Agent”. If you scroll down a bit in that list you”ll notice an option “Enable communication with Healh Attestation Service”. Flip it to YES.

Note : This feature is already available in the normal SCCM Current branch, so you can already enable this feature in production and review those health-reports !

Getting the results from this feature can take a bit of time. Those collected reports need to be sent to Azure, get processed and get back sent down to your environment, but once all of that magic has happened you should be able to see the results in the Monitoring pane, under Security in the “Health Attestation” dashboard.

(In my tests the results came in fairly quick, but your mileage may vary)

Ok, now on the the actual challenge, navigate to Assets and Compliance and locate the compliance policies under Compliance settings.

Upon creating a new compliance policy, you are greeted with a friendly wizard. Name your rule thoughtfully and select if you want to create a rule for Configmgr managed machines or Intune/Hybrid managed devices.

I selected the Configmgr managed machines. Click Next.

For the supported platforms, there is no point selecting any other OS but Windows 10 (and/or server 2016) as the other platforms don’t deliver a health report. Click Next.

Add a new Rule and select “Reported as healthy by Health Attestation Service” as the Condition. Additionally, you can specify what “healthy” means for you :

• Bitlocker Enabled
• Secure boot Enabled
• Code Integrity Enabled
• Early Launch Anti-Malware Enabled (ELAM)

Finish the wizard as normal.

Behind the scenes

On The client-side, Compliancy-related actions are recorded in the ComplRelayAgent.Log

As you can see we are sending our data to the management point, and await feedback. So let’s see what’s going on on that side.

The logfile where we can find more detailed information is MP_Token.Log and is situated in the MP’s log folder (usually under \program files\sms_ccm\Logs).

I highlighted the communcation with the Azure HA Service. As you can see we send our health-report to : HAS.Spserv.Microsoft.com

The results

Depending if you had enabled the client setting to already have your health reports being evaluated by a cloud service, it might take a while before you see the results trickle in… but once they do :

(1) Note to product team : There is a typo in how you verify if a challenge is completed ;-) “Bitlocket” instead of “Bitlocker” . The result is that this challenge cannot be completed , even if you set it all up correctly.

As a side-note… If you are emarking on a mission to deploy windows 10 in your environment, make sure you at least cover the basics ! Don’t take any shortcuts anymore by skipping any of these features …

• Set the Bios to UEFI and enable Secure-boot
• Enable bitlocker
• Enable Credential guard
• Disable SMBv1
• Disable Powershell v2
• Patch your Systems (although this is really for ANY OS)

Those features are free to implement and don’t take a lot of effort, but the added value is that you are already much better protected against the current ongoing ransom-ware attacks.

That’s it ! Enjoy …