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
- The Issue
- How did they enroll the device
- MDM Enrollment Options
- Something not working with MDM-only?
- Performing a sync on an MDM-only enrollment
- Performing an MDM-Only Enrollment
- Performing an MDM enrollment with PowerShell
- Comparing Enrollments with Enrollments
- What about AADR and the Certificate?
- Fixing the missing Certificate
- Certificate Location Overview
- Microsoft their Opinion
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..
Of course, I did write a blog about the Intune Certificate in the past and how to deal with the expired Intune MDM certificate
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
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!
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”
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”
I am explaining that flow in this blog below
If you have read the blog, you could have stumbled upon this picture, describing the ms-organization-access-flow.
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?
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.
It worked perfectly and I didn’t receive any notification that their devices stopped syncing, so pretty much a flawless victory.
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.
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.
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
After asking for your credentials the device becomes MDM enrolled
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!
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
In that specific blog, I was deploying Bitlocker to my device with a scheduled task and an attached PowerShell script/command.
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
As shown above, it’s missing stuff like my PowerShell script and other important PowerShell scripts!
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?
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
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?
When looking at the key it tries to find, we are noticing it is looking specifically at the SslClientCertReference key
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!
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
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
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:
Sounds familiar right, the UserId: S-1-5-18. I closed the event logs and switched to Procmon.
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
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!
9. Performing an MDM enrollment with PowerShell
Of course, I was curious about what would happen when choosing the unsupported GPO enrollment option.
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
The second one is an AADJ enrolled device but this time I enrolled it with the PowerShell/GPO option
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
After pressing export, you have the option to export the needed private key.
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
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!
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!
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!
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 | Autopilot||Existing AADJ + Intune enrolled with GPO||Existing AADJ + Intune Enrolled with MDM-Only||Existing AADJ + Intune Enrolled with Company Portal|
|AAD identity cert||Current User personal Store||Local machine Personal certificate store||Local machine Personal certificate store||Local machine Personal certificate store||Local machine Personal certificate store|
|MDM cert||System User Personal certificate store||Local 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
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! 🙂
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.