Intune: The Legend of the Certificate

Last Updated on September 23, 2022 by rudyooms

Do you have devices that are missing the Intune Device Certificate or have sync issues? This blog will show you a possible root cause and how to solve it! Nothing is worse than having sync issues on your devices. But it’s way worse when your devices are dropping out of Intune because of some missing Intune Certificates.

I will divide this blog into multiple parts

  1. Introduction
  2. The Issue
  3. How did they enroll the device
  4. MDM Enrollment Options
  5. Something not working with MDM-only?
  6. Troubleshooting
  7. Performing a sync on an MDM-only enrollment
  8. Performing an MDM-Only Enrollment
  9. Performing an MDM enrollment with PowerShell
  10. Comparing Enrollments with Enrollments
  11. What about AADR and the Certificate?
  12. Fixing the missing Certificate
  13. Certificate Location Overview
  14. Microsoft their Opinion
  15. Conclusion

1. Introduction

I guess you may be wondering why I am writing this blog. The last couple of months I have been noticing a lot of questions asking why devices stopped syncing with Intune.

When trying to answer some of those questions, I also got asked if there could be an explanation for why the MDM Intune certificate is missing in action! Here are some examples..

Computers dropping out of Intune : Intune (reddit.com)

Devices Disappear in Intune but still in Azure (18 Months?) : Intune (reddit.com)

MDM Certificate missing on some devices : Intune (reddit.com)

didn’t find cert in both store – in IntuneManagementExtension – Microsoft Tech Community

Of course, I did write a blog about the Intune Certificate in the past and how to deal with the expired Intune MDM certificate

Sync issues 0x80190190 and the Intune MDM device Certificate (call4cloud.nl)

Okay Okay… that blog is indeed only about expired certificates, not about the missing certificate! For your information, I also wrote an additional troubleshooting blog which is explaining how to deal with duplicate Intune Certificates or when the Intune certificate is missing its private key

Troubleshooting the Intune Device Sync error 0x80072f99 (call4cloud.nl)

But still, that doesn’t solve the issue in which the Intune Device Certificate is gone and seems to be missing.

So I had the feeling I needed to write an additional blog to show you what happened with those devices that are missing the Intune MDM device certificate…. NO! for everyone blaming the Device Cleanup Rules, you are wrong!

Terminator Wrong GIF - Terminator Wrong - Discover & Share GIFs

2. The Issue

So no expired certificates, no duplicate certificates, and no certificate with its private key missing… What else do we have left? Nothing… and I literally mean nothing

Let us take a look at the “nothing”

Graphical user interface, text, application

Description automatically generated

As shown above, the problem device is missing its Microsoft Intune MDM Device CA certificate! When you have enrolled your device with Autopilot, the Ms-Organization-Access certificate and the Intune certificate are both delivered to the “Local Computer Personal Store”

Graphical user interface, application

Description automatically generated

I am explaining that flow in this blog below

TenantID and the Azure Device and Intune MDM Certificate (call4cloud.nl)

If you have read the blog, you could have stumbled upon this picture, describing the ms-organization-access-flow.

Timeline

Description automatically generated

Please note: If you have read the above blog, we will also know how the device knows to which tenant it belongs by looking at the Certificate Properties

I guess we all know how important that Intune Device cert is right? Without it, there should be absolutely no communication possible with Intune. Even the Intune Management Extension log is telling us it didn’t find any certificates. That can’t be good right?

A picture containing timeline

Description automatically generated

Shall we go further and take a look at how this started happening?

3. How did they enroll the device?

After asking around a bit, I noticed that those problem devices were manually enrolled to Intune AFTER being Azure Ad Joined in the first place.

Microsoft their official supported method would be to wipe the device and let it enroll with Autopilot to make sure the device becomes Azure Ad Joined and Intune Enrolled

But I get it, sometimes wiping all the already azure ad joined devices to let them enroll into Intune isn’t fun.

The last time “I” needed to do this was 2 years ago, I used my own blog to do so.

Enroll existing Azure Ad joined Devices into MDM | Intune (call4cloud.nl)

It worked perfectly and I didn’t receive any notification that their devices stopped syncing, so pretty much a flawless victory.

The Unipiper on Twitter: "SCORPION WINS Flawless Victory  #ExplainThe90sIn4Words #MortalKombat http://t.co/HZ2mNxZd5H" / Twitter

But I was still wondering how my fellow it persons enrolled their devices into Intune

4. MDM Enrollment Options

Before I am going to show you some other options, we need to check what Microsoft has to tell us about the options we got.

MDM enrollment of Windows 10-based devices – Windows Client Management | Microsoft Docs

In the above MS-Doc, Microsoft is telling us: “ALL Windows 10-based devices can be connected to MDM. You can connect to an MDM through the Settings app.”

We can do so by pressing the “Enroll only in device management” button in the Access work or school settings on an already AzureAdJoined device.

Graphical user interface, application, Teams

Description automatically generated

Of course, we could also use the company portal to enroll the device into MDM. The only thing we need to do is, press the “This device hasn’t been set up for corporate use yet. Select this message to begin setup” button

Graphical user interface, application

Description automatically generated
Text

Description automatically generated

After asking for your credentials the device becomes MDM enrolled

Graphical user interface, text, application

Description automatically generated

5. Something not working with MDM-only?

So we have 3 options to our disposal, 2 supported Microsoft options and 1 NOT Microsoft supported solution. That sounds quite fun, right?

I decided to take a deep dive into all of the options. When taking a closer look at the supported Microsoft options and implementing them I noticed that all of my PowerShell scripts weren’t applying.

When thinking about it, that’s odd, right? Because when you have an AADR device that got enrolled into Intune, the PowerShell scripts do work!

Azure Ad joined vs Azure Ad Registered | AADR vs AADJ | PRT (call4cloud.nl)

But let me get back to the story, I will show you how I noticed it. Some time ago I wrote down my “bonkers” idea to make sure the device was compliant at first login

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

In that specific blog, I was deploying Bitlocker to my device with a scheduled task and an attached PowerShell script/command.

Graphical user interface, text

Description automatically generated

So I was expecting that when the AADJ device was being enrolled into MDM, that scheduled task would kick in but it wasn’t deployed and my hard drive wasn’t encrypted with Bitlocker! Luckily something in the IME log was showing me that the Scheduler failed to get the device id, which will affect script status…

Another error that I spotted was: Failed to get device id, abort PowerShell check-in

Okay… that doesn’t sound good. When taking a look at the agentexecutor.log (which should mention the PowerShell scripts I deployed) it is ONLY mentioning this couple of lines and nothing more

WinHttpGetProxyForUrl call failed because of error 12180]LOG]…. Which corresponds with (ERROR_WINHTTP_AUTODETECTION_FAILED) AKA Proxy Auto-Configuration File was not discovered

Text

Description automatically generated

As shown above, it’s missing stuff like my PowerShell script and other important PowerShell scripts!

A picture containing icon

Description automatically generated

That’s odd, right? PowerShell not working and we are also still missing our important Device cert which I was also showing you in 2 second part of this blog!

6. Troubleshooting part 1

So our existing AADJ device becomes Azure Ad Joined but PowerShell scripts aren’t working and the Intune device certificate doesn’t show up in the local machine store.

As mentioned in almost all of my Intune device cert blogs, without that certificate your device can’t sync! So why not test it?

Text

Description automatically generated

As shown above, the device could sync and the sync also was successful. Okay, that’s something I wasn’t expecting. The ability to sync your device without having the MDM certificate in the local machine store.

If you have read my troubleshooting blogs, you would know that the Certificate that is being used by Intune/MDM is listed in the software\microsoft\enrollments\guidoftheenrollment section in the registry

Graphical user interface, application

Description automatically generated

As shown above, it looks like we got ourselves the Intune Certificate Thumbprint. So I decided to do 2 things.

  • Performing A sync to determine where it looks
  • Performing a new enrollment and watching Procmon and the event logs

7. Performing a sync

So I made sure I run Procmon with system privileges and watched the omadmclient.exe process while performing a sync with Intune

As shown above, while syncing the device I noticed that omadmclient.exe was querying the SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\guid folder. It does sound like it’s trying to find the right EnrollmentCertStore doesn’t it?

Graphical user interface, application

Description automatically generated

When looking at the key it tries to find, we are noticing it is looking specifically at the SslClientCertReference key

Graphical user interface, text, application

Description automatically generated

Did you spot the MY;User part in that key? Not Machine but User! After fetching that key, it starts looking for the profile path of the S-1-5-18 user. Guess what that SID stands for

As shown above, it found the “profilepath” of the System User and after a couple of nanoseconds it performed a file query on the c:\windows\system32\config\systemprofile\appdata\roaming\microsoft\systemcertificates\my\certificates folder

As shown above, the query was a success! Guess again who that folder belongs to!

You Got It Dude Meme Template - Piñata Farms - The best meme generator and  meme maker for video & image memes

To find out if that was really the case, I opened Psexec to elevate myself to SYSTEM and opened the local cert store of the system account. You may take one wild guess about what we will find in this store

Graphical user interface, text, application, chat or text message

Description automatically generated

As shown above, it shows us the “missing” Intune MDM device certificate!

8. Performing an MDM-Only Enrollment

Let’s track down what will happen when we are performing a new Intune enrollment on an already AADJ device! I made sure I again had Procmon open and while watching Procmon run, I also opened the Crypto-Ncrypt event log

Graphical user interface, text, application, email

Description automatically generated

As shown above, I noticed event 9, mentioning a Key write with the name ConfigMgrEnrollment0. Sounds like a certificate being deployed to me. Just before closing that screen, I scrolled down to notice the Userid:

Graphical user interface, text, application

Description automatically generated

Sounds familiar right, the UserId: S-1-5-18. I closed the event logs and switched to Procmon.

Graphical user interface, text, application

Description automatically generated

As shown above, it is almost the same behavior as we noticed when we started a “sync” but the only difference is that it creates files instead of querying them. Of course, it will also set the “SslclientCertReference” key instead of opening it

A picture containing application

Description automatically generated

When watching Fiddler when the device is being enrolled we will also stumble upon some information

The device will request the enrollment of the device and will get back an encoded response. When decoding this response we will notice that the response contains the Intune MDM certificate and some additional information.

As shown below, the response also holds the information in which Certificate Store the Intune device certificate belongs!

To zoom in a little bit closer after doing some proper formatting, we will notice SSLCLIENTCERTSEACRHCRITERIA is being mentioned with the My;User Store

If you are interested in how I noticed this information, please read this blog below. This blog is version 2 of the Willy White glove blog!

Autopilot Pre-Provisioning | Technical Flow V2 | Intune (call4cloud.nl)

9. Performing an MDM enrollment with PowerShell

Of course, I was curious about what would happen when choosing the unsupported GPO enrollment option.

Enroll existing Azure Ad joined Devices into MDM | Intune (call4cloud.nl)

While writing this blog, I also updated the above blog to make sure the AADJ device will enroll into Intune within seconds. I changed a couple of lines so go check it out first!

After putting down those PowerShell commands in a PowerShell session in the System context I noticed that it was also setting the SslClientCertReference key but this time not with MY;User but with the MY;System settings

Guess where I could find that Intune cert? Yeah again, you guessed it! In the Local Machine Cert Store. Also good to know is that the PowerShell scripts that weren’t working with the first 2 options, were kicked off immediately.

10. Comparing the Enrollments with Enrollments

But I am not done yet, as something else caught my eye. When looking at the enrollments registry key I mentioned earlier. I noticed some differences

As shown above, the left picture is showing us the settings with an MDM-only enrollment (Company Portal and Settings) and the right one is showing us the settings when you performed the Intune enrollment with the PowerShell script.

Both of the devices are AADJ and Intune Enrolled but the MDM-only device is showing us the “EnrollmentType = 0” while the PowerShell script Intune enrolled device is showing the “EnrollmentType = 6”. Sounds like a different kind of enrollment right?

When taking a look at what MS Graph has to tell us, we will notice the same difference. The first screenshot is from an AADJ MDM-only enrolled device

Graphical user interface, application, table

Description automatically generated

The second one is an AADJ enrolled device but this time I enrolled it with the PowerShell/GPO option

Graphical user interface, text, application, Word

Description automatically generated

So I simply guess that 0, means “UserEnrollment” based and 6, means “AzureDomainJoined”? I am not sure, but it looks pretty much like it.

When doing the same on an Azure Ad Registered device that’s enrolled in Intune, we will notice that the enrollment type is “AutoEnrollment”. And this value corresponds to Enrollmentype = 13.

11. What about AADR and the Certificate?

As mentioned in the previous part of this blog, I also decided to take a look at what would happen with an AADR device. So I enrolled a new device but this time I did not perform an Azure Ad Join but made sure the device would only be Azure Ad Registered AND Intune Enrolled.

I was curious about the location of the Intune MDM device CA certificate! As shown below, the Intune Device CA certificate is also in the System Personal Certificate Store. So no differences here right?

Guess again… while waiting and waiting some more, something caught my attention on the Azure Ad Registered Device! I did not notice this behavior on an Azure Ad Joined device that I enrolled into Intune with the MDM-Only option.

As shown above, the IME log on the AADR and Intune enrolled device is mentioning that it will add the MdmDeviceCert (with the matching thumbprint) into WebRequest. Okay, it also is mentioning the same error we noticed on the Azure Ad Joined device: Find 0 MDM certificate but it also shows us some more information.

When looking at the total flow from above, it looks way better! Let me show you why.

  • First sets the MdmDeviceCertificate
  • Then it tries to find the Mdm Certificate in the Local Machine store
  • It will fallback to the user store and will check if it exists in that one
  • It finds the right one and will add it to the WebRequest

So I guess that’s why stuff does work on an AADR device and NOT on an AADJ device that is enrolled into Intune with the MDM-Only option!

12. Fixing the Missing Certificate

If you have a previously AADJ device and enrolled it to Intune with the supported MDM-only options, you are up for a challenge… Luckily it’s very easy to fix the missing certificate and the not working PowerShell scripts. When you have system permissions, you can do almost everything you want even exporting the Microsoft Intune MDM device CA with its private key!!

Isn’t that just beautiful? Just right-click on the certificate and select export

Graphical user interface, application

Description automatically generated

After pressing export, you have the option to export the needed private key.

Text, letter

Description automatically generated

After the export with a nice password attached, you can import it back again… but this time in the Local Machine instead of the System User Certificate Store

Graphical user interface, text, application

Description automatically generated

When you want to automate it, you could use this PowerShell script (Of course you need SYSTEM privileges to access the System Personal certificate store)

$certificate = Get-ChildItem -Path Cert:\Currentuser\My\
$password= "secret" | ConvertTo-SecureString -AsPlainText -Force

Export-PfxCertificate -Cert $certificate -FilePath c:\intune.pfx -Password $password
Import-PfxCertificate -Exportable -Password $password -CertStoreLocation Cert:\LocalMachine\My -FilePath c:\intune.pfx
net stop IntuneManagementExtension 
Net start IntuneManagementExtension

As shown below, it will export the key to a pfx and will import it back again!

Text

Description automatically generated

After restarting the IME, within a few seconds, your PowerShell scripts will start to appear on your device and the IME log will mention it found 1 MDM certificate!

Text

Description automatically generated

For the people with some “funny” ideas… NO, you can’t export the MS-Organization-Access certificate with the private key attached when you have a TPM!

Graphical user interface, text, application, email

Description automatically generated

13. Certificate Location Overview

I will finish this blog by giving you a nice simple overview of the location of where the MDM and AAD certificates will be stored.

AADR + Intune Enrolled Intune enrolled during AADJ | AutopilotExisting AADJ + Intune enrolled with GPOExisting AADJ + Intune Enrolled with MDM-OnlyExisting AADJ + Intune Enrolled with Company Portal
AAD identity certCurrent User personal StoreLocal machine Personal certificate storeLocal machine Personal certificate store Local machine Personal certificate store Local machine Personal certificate store
MDM cert System User Personal certificate storeLocal machine Personal certificate store Local machine Personal certificate store System User Personal certificate store System User Personal certificate store

I still need to add Hybrid… but then again……

14. Microsoft their Script/opinion

At the start of this blog, I was mentioning this blog. It showed us how to recover from an expired certificate

Sync issues 0x80190190 and the Intune MDM device Certificate (call4cloud.nl)

When looking back at the script I mentioned in that blog something catches my eye and something made me laugh a bit. Let’s start with the part that catches my eyes

As shown above, even Microsoft their script to fix it is looking for the “SslClientCertReference”. That can’t be a coincidence, right? Let’s move on to the funny part

It looks like Microsoft doesn’t care about our device when the Intune Device Cert is not in the MY;SYSTEM certificate store. So for everyone who has a lot of devices without the cert in the Local Machine Certificate store, screw you! 🙂

Conclusion

In my opinion, AzureDomainJoined sounds way better than UserEnrollment, and if you ask me…. I guess the UserEnrollment option could give you a lot of issues.

What happens when the certificate has expired? Is the device capable of renewing it? As I have seen many devices with duplicate or no certificates and sync errors in the last few months

What happens when the device switches to another user without wiping it?

I know for sure that the GPO/PowerShell option works perfectly (even when it’s not supported) and looking at all the topics that are mentioning that the device stopped syncing and how they enrolled the device is can only have 1 conclusion….. it’s because of the enrollment and the certificate being placed in the wrong store.

YARN | Never mind. Wrong store. | White Chicks (2004) | Video gifs by  quotes | b15e0929 | 紗

14 thoughts on “Intune: The Legend of the Certificate

  1. Hello Rudy, great article. Sadly we are affected by this problem. Wondering why it worked for years as it seems.
    Seems as the script you published for automation is missing a “$” in the first line, assuming it should be a variable.
    It works only if SYSTEM has only one certificate in the personal store, if there are more present some logic has to be added to identify the correct certificate to export I think.
    Had also a case open with Microsoft, but they focus on the fix you mentioned, remove the clients and re eroll them, which is not suitable for larger environments.

    1. Ow… oops.. it was indeed missing a $, just changed it… also added the system privileges requirement…

      That fix is indeed not fun when you need to do so on large scale… hopefully (i guess not) Microsoft will come up with a proper way to fix it

      1. To be honest, it seems Microsoft is not interested at all to do something. At least I have been told that there will be no RCA and also no support to build the script or whatever. I will not blame the engineer I have been working with, since those actions are out of his support boundaries. He did what he could do. But there was no escalation, transfer to higher support level. Do not know what is going on behind the scenes, maybe a fix will be presented in some time.

        Also wondering if if might be possible to have the deviceenroller to look in the “wrong” store for the certificate? Have to do some investigation 🙂

        Thanks again for all your work on this issue and this blog at all – highly appreciated!

        1. Hi.. Thanx! also added some more information about how the device knows in which store the certs belongs to… will digg some more if you could “alter” the request

    2. I noticed the image with Groku hiding from the MDM cert. So, uh, I how do I do this for Hybrid? I only experience this on hybrid devices. None of our AADJ devices have this issue, just HAAJD. Any updates?

  2. Hi,
    Thank you for your article,

    i have a question please ? we have a co-managed environment and affected with the same issue

    so, when i export and import the certificat, the probleme persist

    could you please help ?

  3. Hi Rudy, we had this issue on a lot of devices and i was already trying to fix this following this article. But somehow in the last two weeks this issue has been resolved automatically on all the devices but i can’t find any article from Microsoft where they explain anything about this.
    In the logs i also see that it sets the MDM Certificate ‘Set MdmDeviceCertificate : ……..’

  4. Where can we find the MDM certificate on linux(Ubuntu)/macOS devices when these devices are enrolled with Microsft Intune?

  5. So I’m just starting to see this on my own environment, and I’ve come across a variation of this where the cert was in the correct local machine store, but the Provisioning\OMADM registry value for SslClientCertReference value was missing entirely. I was able to populate it manually using the correct thumbprint ID and after restarting IME service, it immediately started syncing and is back up to date.

    But here’s the kicker… all of these systems were provisioned by Autopilot as pure AADJ+Intune, so I have no idea how this could have happened.

    Regardless, I’m actually gonna put together a little detect-remediate script for this, because this sort of stuff, so I’m gonna bookmark this blog post and come back to share it when I’m done. This is nuts though… especially the part in the MSFT script suggesting they “don’t care.”

    1. Hi… Mmm… I am interested!.. what kinda sync errors are you getting? could you share some screenshots ? was the whole key missing or only the contents of that key? (info@call4cloud.nl)

      That reference should be configured once the certificate arrives at the device (part of the security token)…. so that’s weird its gone…

  6. looks like the device cert is now enrolled as non-exportable and in the TPM, at least for my Autopiloted Win11 devices. have you managed to export it for Fiddler decryption?

    1. Hi… When i open the local cert store as admin, i can still export it (latest windows 11 build) not with a private key but dont need that for fiddler

Leave a Reply

Your email address will not be published. Required fields are marked *

8  +  2  =