Dual Enrollment / MMP-C Light for Workplace Joined Devices?

Introduction:

While scrolling through dmenrollengine.dll, I stumbled across something that caught my eye: a function related to Dual enrollment. This got me thinking: Could this be the key to fixing some known limitations? Specifically, Endpoint Privilege Management (EPM) does not work on Workplace Join devices.

We know that EPM requires dual enrollment (Linked Enrollment / MMP-C Enrollment), but Workplace Join devices traditionally don’t support it. Could this newly discovered function be the missing piece?

In this deep dive, I’ll explain how WorkplaceJoin_DualEnrollment works, the steps the DeviceEnroller takes, and why dual enrollment is possible on Workplace Joined devices. One thing is for sure: Something seems to be going on behind the scenes that may point to bigger changes coming.

Discovering WorkplaceJoin_DualEnrollment

While analyzing the DeviceEnroller executable, I discovered a hidden feature called: WorkplaceJoin_DualEnrollment.

If this WorkplaceJoin_Dualenrollment feature is enabled, this feature allows devices to use MDM client certificates for authentication, effectively enabling dual enrollment. What’s interesting is how this differs from the regular dual enrollment (also known as linked enrollment), where devices typically rely on Azure AD/Entra ID tokens for authentication when they are Entra ID joined.

In the regular dual enrollment flow, devices are authenticated via Azure AD tokens, which establish the link between the device and the MDM service, allowing both Azure AD and MDM policies to be applied. However, with WorkplaceJoin_DualEnrollment, the device isn’t Entra joined, meaning it can’t use Azure AD tokens. Instead, the device uses the MDM client certificate for authentication, bypassing the need for Azure AD and enabling a form of dual enrollment that’s more appropriate for Workplace Join devices.

This discovery opens up new possibilities for Workplace Join devices that typically wouldn’t be able to support features like Endpoint Privilege Management (EPM), which requires dual enrollment.

Intrigued, I dug deeper to see how this feature interacts with the MDM client certificate and whether enabling it could unlock dual management advanced scenarios like EPM.

The Dual Enrollment Flow: It All Starts Here

Once WorkplaceJoin_DualEnrollment is enabled, the DeviceEnroller initiates the dual enrollment process using RegisterDeviceDualEnrollMmpcUsingCertificateCredentials.

Here’s how the process unfolds:

• Enrollment Flag Set: The function sets an internal flag using SetMmpcEnrollmentFlagto indicate that dual enrollment is starting.

• Dual Enrollment Process: The core function, DualEnrollMmpcUsingCertificateCredential, handles the enrollment using the MDM client certificate. (subdeep dive below)

• Locate the MDM Client Certificate: The function retrieves the MDM client certificate by calling getenrollmentclientcertthumbprint

• Determining if the Discovery Endpoint is configured.

If the discovery endpoint is not configured, enrollment will fail. Luckily, I already spent some time on this Discovery Endpoint issue some time ago… so there are no issues here!

• Flag Reset: After the process completes (whether successful or not), the flag is cleared using SetMmpcEnrollmentFlag(0LL).

Looking back at the dual enrollment steps I documented in an older blog, the Dual Enrollment flow itself is almost the same, except for the Certificate Credential part. So far, I know (at least that’s what I thought) you always needed the Entra token to perform a second/dual enrollment, and with this functionality popping up, things change!! It reminds me a bit about how Defender was using the Leviathan token to do the same. Shall we do a sub deep dive into this topic as welll

Register Device Using Certificate Credentials Sub-Deep dive.

And the corresponding documentation of this nice new functionality!

Description of Nodes:

• Start: Entry point of the function.
• Check Active Enrollment: Verifies if the device is already enrolled.
• Generate GUID from Input: Creates a GUID from provided credentials.
• Retrieve Tenant ID: Gets AAD Tenant information from the Enrollment registry.
• Check Enrollment Client Certificate: Validates the client certificate and thumbprint for enrollment.
• Activate MDM Enrollment Instance: Prepares the MDM instance for further steps.
• Perform Enrollment: Executes the enrollment process.
• Finalize Enrollment and Log Success: Completes the enrollment and logs a success message.
• Log Errors and Exit: Handles error scenarios and releases resources.

With the Certificate Credential function also documented, shall we take a look at the total flow?

The Total WorkPlace Join Dual Enrollment Flow

Now, all the steps combined in a simple flow

If everything is successful, dual enrollment is complete, and the device is seemingly prepared for EPM or Device Inventory?

Manually Enabling WorkplaceJoin_DualEnrollment

After staring at the deviceenroller.exe and figuring out what was happening just by looking at the code, it was time to test it myself. It was obvious that I needed to ensure that my device was workplace joined instead of Entra Joined. After enrolling my workplace device in Intune, I checked if the device indeed had a work account configured.

To test this feature, I manually enabled WorkplaceJoin_DualEnrollment. Here’s how you can do it:

1. Download ViVeTool: Grab ViVeTool from GitHub and extract it.
2. Enable the Feature: Use the following command to enable WorkplaceJoin_DualEnrollment: vivetool /enable /id:38375658

1. Reboot the Device: A quick reboot applies the changes.
2. Verify the Feature: Use vivetool /query to confirm the feature is active.

Manually Triggering Dual Enrollment with send-localmdmrequest

After enabling the feature and enrolling the device in Intune, I noticed that dual enrollment didn’t kick off automatically, so I manually triggered it using send-localmdmrequest.

• SyncML Request: I structured the SyncML request to target the Linked Enrollment CSP.
• Send the Request: Run it from an elevated PowerShell session. The key path is:

./Vendor/MSFT/DMClient/Provider/MS%20DM%20Server/LinkedEnrollment/Enroll

After running the command, I received a 200 status, indicating that the request succeeded.

The Results: Where Are the Policies?

After successfully enrolling the device, I expected the Configuration Service Provider (CSP) for EPM to appear, but it didn’t. No CSP, no configuration documents, no EPM settings, nothing.

This was puzzling. Despite successfully triggering the dual enrollment, the device wasn’t receiving the EPM or device Inventory policies. I soon realized that Workplace Join devices weren’t getting the full MMP-C treatment, which explains the absence of those EPM/Device Inventory policies. But there’s more to this story.

The Funny Discovery: MMP-C Light Isn’t for EPM

While watching the event log during the enrollment process, I discovered something that might explain the issue: MicrosoftManagementPlatformLight AKA MMP-C Light.

You should ask Joost how enthusiastic I was when noticing this on a Sunday morning but with this discovery I continued exploring another dll called dmenrollengine.dll. Which was also mentioning the MmpcLightEnrollstate

It turns out that Workplace Join devices don’t get the full MMP-C enrollment, which is likely why the EPM policies aren’t being delivered.

This raises an interesting question: if MMP-C Light isn’t there to enable EPM, then what is it for? It seems like MMP-C Light is handling a different set of tasks, perhaps paving the way for something else entirely. Could this be the beginning of a shift where policies and configurations start moving from the Intune/MDM channel to the MMP-C channel?

If you have read the blog above, it is all starting to make sense! All the MDM policies will be moved over to MMP-C eventually. With workplace-joined devices also needing to receive those Intune policies, Microsoft needed to come up with a solution to ensure those workplace-joined devices could also become dual-enrolled and start receiving those policies! Ey voila!

Conclusion: MMP-C Light – Not for EPM but for Something Else?

So, is WorkplaceJoin_DualEnrollment the key to unlocking EPM for Workplace Join devices? Unfortunately, it doesn’t seem like it. While dual enrollment is required for EPM to arrive on the device, without full MMP-C enrollment, the policies that make EPM functional simply aren’t delivered.

What’s clear, though, is that MMP-C Light is doing something else entirely. It doesn’t seem to be the fix for EPM, but it’s intended for another purpose: shifting the Intune policies on Workplace Join devices to MMP-C. Could we see the transition start where MMP-C takes on a bigger role, even for lightweight devices?