What’s Microsoft up to now? If you’re managing devices with Intune, keep an eye on the Intune Management Extension (IME) Cert Checker. It’s already making its way into certain tenants, ensuring devices have the right certificates for secure communication. But here’s where it gets interesting—there’s a function called IsTenantFlighted that could be part of something bigger.
Could it have a role in preventing uninstallation? You’ll need to read the blog to uncover what’s really going on!
Introduction
Certificates are a key part of device management, keeping communication with Intune secure and making sure everything works as expected. Usually, IT admins don’t have to worry about the Intune certificate since it’s handled automatically. But when managing a large number of devices, things can sometimes go wrong. Certificate issues can lead to failed enrollments or cause devices to lose connection with Intune. In some cases, it might even cause the Intune Management Extension (IME) to get uninstalled unexpectedly.
That’s where the Intune Management Extension (IME) Client Cert Checker task comes in. This task quietly checks if the correct certificate is in place to ensure everything keeps working as it should. During a recent investigation, I found some interesting details about how this process works behind the scenes and helps maintain smooth communication.
The Importance of the MDM Certificate:
Let’s start this deep dive by explaining why the Intune MDM certificate is essential to communication with the Intune service. When a device is enrolled in Intune, it receives a client certificate, which acts as its digital identity. This certificate is “what authenticates” the device with Intune, ensuring that it’s trusted (more on that later on). With this certificate in place, the device can securely communicate with Intune services, allowing it to receive policies and updates and perform other management tasks.
Without a valid MDM certificate, a device would be cut off from Intune and unable to receive application updates. This could lead to significant security risks, especially in environments where device compliance is critical to the overall security posture.
Given the stakes, ensuring that the correct MDM client certificate is in place and valid at all times is paramount. This is where the Intune Management Extension comes into play, working behind the scenes to pick and validate these certificates.
IME Client Cert Checker:
The new shiny Intune Management Extension Client Cert Checker scheduled task is a key component in this process. This new scheduled task runs regularly to check whether the device has a valid MDM client certificate. When first looking at this new task, it seems designed to prevent scenarios in which a device might lose its ability to communicate with Intune due to an invalid or missing certificate.
Let’s start with a simple overview of how this Intune Management Extension Client Cert Checker scheduled task works in 6 steps. From there on, we will zoom in on each step of this process to learn more.
- Client Cert Checker Initiation
- Certificate Search
- Tenant Flight Check
- Certificate Validation
- Metadata Storage
- Leveraging CertMetadata
Let’s break down the core steps the Client Cert Checker follows to ensure certificates remain valid.
1. Client Cert Checker Initiation
- Registry Check: The process begins by checking the registry for the last time the certificate metadata was updated. If a valid certificate is found and stored within the last 24 hours, the task is skipped.
2. Certificate Search:
- Store Scanning: The Client Cert Checker searches the device’s LocalMachineMy and CurrentUserMy certificate stores for any certificates that match the OID 1.2.840.113556.5.6.
This OID specifically identifies MDM client certificates, making it easier to narrow down the search. We can do the same with PowerShell and trying to find the certificates that have that specific OID set
Filtering: During the search, the task also filters out certificates that do not have a private key or are expired.
After these checks are done, and if only one or no certificates are found, the task stops, and the certificate metadata in the registry is deleted.
This means that the Client Cert Checker /Picker task has found either no certificates or only one valid certificate in the device’s certificate store, and as a result, it is not proceeding with further certificate validation or selection. Suppose more than one valid certificate is found. In that case, the Client Cert Checker will proceed to further validation steps, such as Intune Tenant flighting, to determine the most appropriate certificate to use.
3. Tenant Flighting Check
- Flighted Tenants: If multiple certificates are found, the task identifies the certificate by searching for the OID we noticed in Step 2
From there on, it checks whether the tenant is “flighted.” Tenant flighting ensures that only certificates from authorized tenants are allowed to proceed.
Non-Flighted Tenants: If the “tenant” is NOT flighted, the process is halted, the certificates are not used, and any existing certificate metadata in the registry is deleted.
TenantID is not flighted. That’s interesting! Let’s take a quick detour to discover what this tenant ID is. To do so, we need to spend some time on the account ID.
The AccountID
While writing this blog, I started asking myself the same question over and over: What is this Account ID corresponding with the OID 1.2.840.113556.5.6 value of the Intune MDM Device CA Certificate?
Please Note: If you want to know more about the other OIDs, please check out this blog: Unpacking the Microsoft Intune MDM Certificate – MSEndpointMgr
With the account ID decrypted, it became much easier to determine its function…Well, that may be because I was also looking at some code from the Endpoint Privilege Management client.
As shown below, IntuneInfo RetrieveIntuneInformation. I’m just thinking out loud here, but… we got the AAD/Entra Tenant ID and this Account ID / OID, which is the Intune Information.
Could this Account ID be the MSFT Internal Intune Tenant ID? I think it is!! Let me explain a bit more. Inside the WindowsAgent code, we could spot the clientcertpickerflighting method and how this method determines if the tenant is “flighted”.
It does so by taking a look at a hardcoded list of GUIDS.
For everyone who is wondering.. Yes I tried to find out to which tenants these GUIDs belong. When using AADInternals OSINT tool to obtain the tenant information, this is what we got!
No Information was found. Entering my own test tenant Entra ID showed me all the information. One thing is for sure: those GUIDS are not ENTRA tenants but belong to some specific Intune Tenants. Let’s abandon this Account ID side quest and proceed to the certificate validation.
4. Certificate Validation via SideCarGatewaySession
Remote Validation: For certificates from flighted tenants, the Client Cert Checker task initiates a SideCarGatewaySession with the Intune service to validate the certificates. This session sends certificate details to the service, which checks their validity and ensures they are correctly issued.
Handling Results: If a valid client certificate is found during this session, it is selected for use. The certificate’s metadata, including its subject name, thumbprint, and validation time, is then stored in the registry under CertMetadata. This allows for quick future validation.
5. Metadata Storage and Future Efficiency
- Registry Storage: The validated certificate’s details are stored in the registry. This enables the IME to quickly validate the certificate in future operations without needing to redo the entire validation process.
- Fallback Mechanism: If no valid client certificate is found during the SideCarGatewaySession, or if the tenant is not flighted, the task deletes any existing certificate metadata, ensuring that only valid and current certificates are used.
6. Leveraging CertMetadata:
Now that a valid certificate and its metadata are stored in the registry, the IME can use this information for future operations. When the IME needs to re-establish communication with Intune (such as during policy refreshes or device check-ins), it doesn’t need to start from scratch.
Instead, it checks the CertMetadata first:
Quick Validation: If the stored metadata matches a certificate found in the certificate store, the IME can quickly validate the certificate without contacting the Intune service again. This significantly reduces the time needed to validate the certificate, allowing the device to re-establish communication more efficiently.
Fallback Mechanism: However, if the metadata is outdated or the certificate is no longer valid, the IME has a fallback mechanism in place. It will search the certificate stores again using the OID and select the most appropriate certificate based on criteria like expiration date and the presence of a private key.
This approach ensures that the device can always find and use a valid certificate, even if the cert metadata is missing.
The Graphical Flow
Text can be text. Let me show the flow so it makes sense for those who didn’t want to read the full story above.
Under the hood of the Client Cert Checker: GetMDMCert, and GetDeviceCertificate
Let’s dive in a bit more into some of the Client Cert Checker methods and functions. The first one is the GetMDMCert Method. The GetMDMCert method within the AgentInfoRetriever class handles the heavy lifting of certificate retrieval. This method plays a crucial role in the IME’s ability to communicate securely with Intune services.
Using Metadata for Efficiency: The GetMDMCert method first checks the registry’s CertMetadata to find a matching certificate. If a valid certificate is found using the metadata, this certificate is selected for use, ensuring an efficient process.
Fallback Search: If no valid certificate is found using metadata, or if the tenant is not flighted, the method falls back to searching the LocalMachineMy and CurrentUserMy stores directly. It looks for certificates with the correct OID and selects the most appropriate one, ensuring that the device is never left without a valid MDM certificate.
This method is then called by the GetDeviceCertificate function in the DiscoveryService class. This function ensures that the device has a valid certificate before attempting to communicate with Intune services.
Ensuring Communication Readiness: The GetDeviceCertificate method checks if the device already has a valid certificate cached. If not, or if the certificate is older than a day, it retrieves a new one using GetMDMCert. This ensures that the device is always ready to securely communicate with Intune.
Configuring Service Endpoints: Once a valid certificate is obtained, the DiscoveryService uses it to discover service endpoints and configure the environment for communication with Intune. This includes setting up the SideCarGatewayService, which is crucial for ongoing interactions with Intune.
Key Takeaways:
- Certificate validation is crucial: Without a valid MDM client certificate, a device could lose its ability to communicate with Intune, impacting policy delivery, updates, and overall security.
- Client Cert Checker in action: This scheduled task makes sure that the right certificates are always in place, verifying certs regularly to keep the device connected and compliant with Intune.
- Automation at its best: The Client Cert Checker automates the entire certificate validation process—from searching for certificates to checking tenant flighting—so IT admins don’t have to worry about manual oversight or unexpected issues.
What’s Next?
While spending time on the Client Cert Check, I seem to also have stumbled upon something else as well.
The ClientCertPickingFlighting.IsCurrentTenantFlighted function is also being used in a different function as well. Did you read what it says above? SKipping the uninstallation as the tenant is flighted to NOT uninstall”
That really sounds like some additional protection in some rare cases when the IME gets uninstalled out of a sudden. Stay tuned for a deep dive on that topic as well!
Conclusion
The IME ClientCertPicker task ensures your device always has the right cert for secure communication with Intune. It checks for valid certs, logs the results, and updates the registry if everything’s good. If not, it clears out any stale entries. In short: it’s a safety net, making sure your device is always packing the right cert for secure Intune communication. If it’s got one, awesome, if not, it makes sure there’s nothing hanging around that shouldn’t be.
Just like Patch My PC, which ensures your apps are always up to date and secure, the Client Cert Checker ensures the right certificates are in place, ensuring the IME can’t be uninstalled without proper authorization.