Are You There Intune? It’s Me, Health Attestation Certificate

A Compliant device, I want myself to have a working Intune enrolled compliant device!!!! Nothing more! Just a compliant device!

In this blog, I will dig into the -2016345708 AKA 0x87d10194 AKA 404 Syncml(404): the requested target was not found error when your device isn’t compliant!

1. Introduction

On the 18^th of January 2023, I stumbled upon a post on the Microsoft TechCommunity

Microsoft Intune – Microsoft Community Hub

I was intrigued by the issue but unfortunately, I couldn’t reproduce the error. This post was describing an issue when you configured a compliance policy to require Bitlocker and Secure Boot on a fairly new device (HP 450 g9)

These Compliance rules are in fact based upon Windows Health Attestation Service Evaluation Rules and they are way different than I showed you in my last blog about the NodeCache and the corresponding compliance flow. These fine rules are making use of something weird called Device Health Attestation. (DHA)

As shown below, this is an example of a Device Health Attestation report (DHA-Report) and we will notice that it includes the Bitlocker and Secure Boot.

Luckily if you are interested in DHA, I already wrote a blog about that specific topic. I will advise you to read it if you have some additional free time.

Device Health Attestation Flow | DHA | TPM | PCR | AIK (call4cloud.nl)

When taking a closer look at the error the OP was mentioning in the tech community we will notice that the device isn’t compliant anymore and is giving us the error: -2016345708 (SyncMl(404): The requested target was not found)

Back in the day, this issue could occur when there was an issue being caused by a PCR7 configuration mentioning the fact that “Binding Not possible”.

The only solution we had was to update the BIOS/TPM. This time it’s something different! Let’s get our shovels and let’s dig in!

2. -2016345708

I was curious about the error message and what could be causing it…. And of a sudden (more on that, later on), I was glazing at the same error in Intune when my device started complaining it wasn’t compliant and couldn’t access the Cloud apps anymore.

As shown below, the same 0x87d10194 error was shown in the Intune portal when investigating why my device had issues accessing Onedrive

Of course, Bitlocker and Secure Boot were definitely enabled, and my device had already been rebooted multiple times. Manage-Bde also shows the hard disk as fully encrypted and with protection on.

Bitlocker wasn’t showing any issues! The same goes for Secure Boot because the command: confirm-securebootUEFI is showing us the True status

I just couldn’t comprehend why it was suddenly giving me compliancy issues. Let’s perform some basic troubleshooting steps and try to get to the bottom of this weird issue, shall we?

3. Troubleshooting part 1

So first off I opened Fiddler, exported the MDM certificate, and started watching what was happening. With my “Check Access” blog still in the back of my mind I really hoped that it showed me something more but the only thing it could tell me was the fact that: “Conditional access requires a compliant device and the error code 53000.

Mmmm, that was a pretty worthless first attempt, let’s move on. I decided to fetch my own documentation and start looking at the details again.

As shown above, the device would forward the DHA data to the DHA-Service. I guess it’s wise to start at the beginning, so I decided to first determine if the DHA-Data (TCG log, WBCL) was available on the device. Again… I wrote a lot of blogs about this topic so I opened my blog about dealing with Autopilot and the “ready for attestation” requirement

Ready For Attestation False and the 0x81039001 TPM time-out (call4cloud.nl)

I checked everything I mentioned in that blog! let me give you a small summary of what I checked

• No errors when executing the tpmtool! The Device was ready for attestation so that should mean it got the required EkCert
• The Measuredboot logs are on the device.
• The integrityservices registry key (System\CurrentControlSet\Control\IntegrityServices) showed me the WBCL reg binary value. Mmmmm okay, that’s odd.

Wait wait… waiiiiiiit!!!! I must be blind

I forgot to read the most important part!!!

Let me rephrase: “The DHA data will be forwarded to the DHA-Service”. The task responsible for this “forward” is the TPM-HASCertRTR task. This TPM task is located inside the same folder as the TPM-Maintenance task I showed you in the “ready for attestation” blog: Microsoft\Windows\TPM scheduled tasks folder. I opened the scheduled task MMC and opened the TPM subfolder.

Huhhhh… Empty… that’s odd? What happened with that task? Do you know?

4. My oopsie

As mentioned in the beginning, I wasn’t getting this -2016345708 error anywhere so trying to reproduce could be hard. Luckily everything happens for a reason (at least that’s what I want to believe sometimes)

I was picked out to present at MMS MOA, a great, great honor. I started looking at some topics I could talk about. One of the topics could very much be the Intune MDM device Certificate. I decided to check out the stuff I already wrote about it. When I was scrolling down the PowerShell script I mention in this blog

Intune Sync Debug PowerShell Tool to fix Intune Sync Issues (call4cloud.nl)

I noticed that I needed to improve some parts. I enrolled a new VM in my test tenant and after it was compliant and ready to go I started changing and testing stuff but it was becoming pretty late so I called it a day. The next day I woke up and noticed that somehow the device wasn’t compliant anymore

Okay, I did something and with it, I wrecked something else. After the Fiddler trace, I decided to use the WPR tool as I recently added some nice new nifty providers to it. One of them was Microsoft.TPM.HealthAttestationCSP provider.

After using the WPR tool and saving the trace with the Microsoft.TPM.HealthAttestationCSP included as a provider I stumbled upon one sentence.

“A SKU that is expected to have TPMTasks” rings a bell or 2 when looking back at older blogs.

At that point, it all came back to me… I f.cked up! I really f.cked up by executing parts of this script below…

I didn’t define the $enrollmentid. You can take a wild guess about what happened… All the build scheduled tasks were instantly removed… and with it the TPM-HasCertretr task.

Luckily, I have enough working and enrolled virtual machines. So, I used schtasks.exe to export and import the same task on my broken device. (Manually importing it isn’t working!) After importing the task and executing it, my device became compliant again.

Was the blog done right? No No sir… Because I now know where to start digging! I need to dig out the TPM-HasCertRetr task!

5. TPM-HasCertRetr

Let’s start with a basic explanation of this TPM-HasCertRetr scheduled task. This TPM scheduled task has an important task to perform

1. It needs to retrieve the Health Attestation Certificate (HAC). Proof of the device’s secure state (Bitlocker, Secureboot, etc). To do so it will perform a Health Certificate Request. This request contains Claims (information about Bitlocker,SecureBoot etc) the Ek Certificate, and the AIK Certificate

I decided to reach out to the person in the Microsoft Techcommunity to simply ask if that TPM-HASCertRetr was on the device and if it could be executed successfully.

As shown above, the TPM-HasCertRetr task was still on the device but after 30/40 seconds of executing the task, it failed with the error: The System cannot find the file specified (0x8007002)

I guess it’s pretty obvious that the 0x87d10194 is indeed caused by this task. Just like I did with the TPM-Maintenance task I exported it to an XML

As shown above, the same thing we noticed with the TPM-Maintenance task (responsible for TPM attestation during Autopilot Preprovisioning) it calls upon the TpmTasks.dll

Besides this information, we could also spot the WNF trigger I was talking about in a previous blog

While learning my way through this DLL file, I started searching for some keywords. One of the few that got me a response was the keyword: HASCertRetr

That keyword pointed me to another imported function (IMP) that was imported from the TpmCoreProvisioning.dll

A small side note to add: Besides the scheduled task we could also use rundll32.exe to execute this function ourselves.

rundll32 tpmcoreprovisioning.dll,TpmVerifyDeviceHealth

So I moved on and opened the tpmcoreprovisioning.dll and started looking at it. As mentioned before we will notice that the TPM task is responsible for fetching, aka retrieving the required Health Attestation Certificate (HAC)

This function is also visible and mentioned in the ETL trace we got. ActivityTpmRetrieveHealthCertificate

With the knowledge I have of all the TPM attestation troubleshooting I did, I knew this health certificate is also stored in the registry. We will notice that this health certificate is stored inside the HKLM:\ SYSTEM\CurrentControlSet\Services\TPM\WMI\HealthCert\Store\has.spserv.microsoft.com\HealthCertificate registry key as a Signed Health Certificate

Please note: To execute this task, you obviously NEED to have internet access to fetch the Health Certificate, otherwise we will run into the same error

If this registry key doesn’t exist it will be created when the Tpm-HasCertRertr was executed successfully. After it got its certificate it will start forwarding the DHA-Data (which it of course also needs to fetch by using the DHA-CSP/ HASCSP.Dll)

Inside this “HealthCertificateRequestData” function we will notice the same stuff I started looking for:

1. TCGLogs

1. Windows Boot Configuration Logs

I guess we can all agree that this “Health Certificate” is essential to have right and should be the first place to start.

6. Troubleshooting part 2

Now we have some background information about this task I again reached out to the guy in the Tech community and asked him if it was possible to fetch me some more information.

1. If the registry key has.spserv.microsoft.com\HealthCertificate was recreated after executing that task
2. If the measuredboot files were on the device
3. A Procmon Trace
4. A WPR trace with the same config I used.

When looking at all of the information I got I quickly noticed that the previously available health certificate wasn’t in the reg output he sent me.

With that information and the information I got from the Procmon trace, you could say “something is missing”

We can be pretty sure that it indeed fails at one of the first steps… fetching the HealthCertificate. To be sure I also opened the ETL trace and started looking. Besides the HealthAttestationCSP provider, I mentioned I also made sure I included the HealthAttestationCertificateTask Provider

As shown above, getting an activity error with the activity: RetrieveHealthCertificate can’t be good! It also mentions some specific functions in the tpmcoreprovisioning.dll file with the error codes “2147024894” and “2145844848”

Those error codes don’t sound familiar right? Well, let me translate them a bit

“2147024894” –> (0x80070002) —The specified file cannot be found. Now it does sound familiar!

“2145844848” –> (0x80190190) —HTTP_E_STATUS_BAD_REQUEST (Do you remember my TPM blogs?)

I guess we are right on track here. I moved on to the TPM.Provisioning.Task provider

Okay… okay… it’s mentioning the same HASCertRetr task… If you combine that error from above we have a perfect match! I added some more fields and by doing so I noticed that field 4 contained some information and the error message I was looking for

As shown above, the HealtCertResponse mentions the fact that “The X509 certificate cannot be validated. Intermediate CA cannot be trusted as it’s not present in the TrustedTpm_IntermediateCA store”

When comparing that additional field with a working device we will notice that it shouldn’t give you that error! It should remove the “response”

Which should be the “good” outcome when looking at the PostHealthXmlData function inside the tpmcoreprovisioning.dll. This one also mentions the (response removed)

With all this information we gathered I also started reading some Microsoft Documentation and hoping it would contain some useful info. If you are reading the official Microsoft documentation you could stumble upon this part. It mentions this part: x.509 SSL certificate that Chains to an enterprise-trusted root!…

I guess I don’t have to explain what would happen. Even CHATGpt knows what will happen when the intermediate certificate is not trusted

I have the feeling I am getting a Deja Vu because when we had TPM attestation issues with Intel or AMD, we also encountered an issue with the Certificate chain!

7. TPM-HASCertretr Flow

Every time I start troubleshooting stuff, I try to create a diagram with the flow in it with the corresponding Procmon/Fiddler traces in it. Why? Because it gives me a good understanding of what is happening and where it could possibly break

8. What could be causing it

When Looking at the corresponding flow I created by just looking at IDA and Procmon and doing a lot of reading, I guess it breaks between the GetCertFromWeb and the ParseHealthData steps. The error we got was mentioning the Intermediate Cert, in my assumption, some things break when checking the intermediate certificate of the Ek Certificate (GetEkAttestation) or fetching the AIK Certificate (GetWindowsAIK).

These 2 certificates are of course the only ones mentioned in the HealthXMLData but looking back at the ETL log file I guess we can rule out the EKCert as that one hasn’t had the 400 Response Code, that the HealthCertResponse got

400: the server cannot or will not process the request due to something that is perceived to be a client error 

So it must be the process that checks the AIK certificate that is giving us issues? As there aren’t any other choices left. Details! Details, it’s again always in the details!!!

By the looks of it, it’s all about the AIK certificate! The intermediate CA isn’t present in the intermediate store! Type AIK!!!!!

This error message was shown by the task name: TpmGetHealthCertResponse

I was curious if this task could also be a function inside tpmcoreprovisioning.dll. As shown below when looking at the function, it also mentions the WindowsAIK

AIK and Intermediate Certificates are definitely the keywords here… guess where I heard them before. It had something to do with Intel and TPM

TPM Attestation flow Explained | Intel 11th Gen Tiger Lake (call4cloud.nl)

Let’s dive into the Intermediate part a bit more! When looking at the TrustedTpm.Cab file we could download from Microsoft their website, we will notice some TPM vendors. And only 1 is giving us issues?

Every TPM vendor that is inside that cab file has an Intermediate CA… Except for Nuvoton

If we look at the Nuvoton_TPM_EK_Certificate_Chain.pdf, we will notice that they also mention that the EK certificate is signed by the Root CA and not the intermediate one.

Of course, I could be wrong here, but it doesn’t sound like a coincidence to me. There is no mention of an intermediate certificate. So I decided to dig deeper.

I installed the wonderful tpmdiagnostic tool to determine if I could spot some more funny details

As we need to start at the beginning of the trust I decided to start with trying to fetch the EkCert. As We noticed earlier, Nuvoton pre-installs the EK certificate in the TPM so we need to use the EkCertFromNVR command to fetch it.

After opening the “cer” file we will notice the message that the certificate’s issuer couldn’t be found.

Okay, we could successfully fetch the EKCert but could we do the same with the AIK Certificate? We could try again using the tpmdiagnostics.exe tool but this time with the GetWindowsAIKCert parameter

It looks fine to me. There are no issues here, as it seems. What’s next? Luckily, one of the other many commands that fantastic tool has to offer is the : EkChain command. This command will check if it could successfully perform a certificate chain walk

Trust dwErrorStatus:0x10000 ... Translating that error would give us: ‘Certificate or associated chain is invalid (Code: 0x10000)’.

9. Walking the Chain

When we looked at the Ekcert we got, it was indeed missing its Intermediate certificate. From the looks of it, when collecting the DHA-Data, it needs to also fetch the EKCert. That EkCert needs to be valid! The Certificate Chain walk needs to be successful!

I guess the DHA-Service somehow checks if the Certificate Chain could be successfully walked. If the walk isn’t successful the DHA-Service would respond with the message

10. The Fix?

As I don’t work at Microsoft, I can’t/couldn’t fix it. After writing this blog and publishing it online (private), I contacted multiple people at Microsoft and asked for help.

They asked me a few questions, and I responded with everything I stumbled upon and sent them the link to this private blog. After 3 weeks of waiting and not getting any response, I asked them multiple times for a response but unfortunately, nothing but silence

So I decided to ask the same people who were experiencing the same issue if they were still experiencing issues. I even bought myself a brand new HP 450 G9 with that TPM. But guess what? Suddenly, it was all fixed.

Conclusion?

Troubleshooting Device Health Attestation can be very difficult. I hope this blog provided you with some brand new information you can use when you need to troubleshoot some nasty DHA issues!