Last Updated on April 29, 2023 by rudyooms

This blog will be about me looking at the MMP-C Enrollment and the EPMAgent again but this time I am going to look at how it gets its latest Endpoint Privilege Management elevation rules from Intune MMP-C AKA Intune V2

I will divide this blog into multiple parts

1. Introduction
2. How it starts
3. The Schedule Flow
4. How it proceeds
5. The MMP-C Sync Flow
6. The Declared Configuration Service
7. The Message Signature
8. The forgotten Schedule?

1. Introduction

After you have activated and configured the required Endpoint Privilege Management policies in Intune, the EPM Agent would be installed on your device

Besides this policy, I guess you also configured an additional elevation rule policy to elevate some fine ass executables

So far so good, as mentioned in the previous blog the device would enroll into MMP-C and would get the EPM agent pushed. If you didn’t read that blog before, please do as it describes the whole enrollment flow in detail!

MMPC | Dual Enrollment | Linkedenrollment | EPMAgent (call4cloud.nl)

But what if you want to change an existing Elevation policy because you added something that didn’t mean to be elevated? How does the EPM agent fetch the latest elevation policies out there? How long could it take?

2. How it starts

As mentioned in my previous blog, the device would have a dual enrollment. One enrollment dedicated to your good old Intune neighbor and one new enrollment “linked” to the new enrollment aka EPMAgent

With the new enrollment we got, we also have the same kind of schedules we have with the Intune enrollment. These schedules were brought to life to sync some “stuff”

The main difference here Is the fact that schedule #3 is repeated every 4 hours instead of the 8 hours we will notice with the default Intune enrollment

These schedules will make sure your device will be synced with the latest policies, so I assume the MMP-C schedule #3 would do the same for the EPMagent? When using the PowerShell module EpmCmdlets.dll from the EPMtools folder we will notice that the LastWrite time is exactly the same as the last time schedule #3 was executed successfully!

When taking a closer look at schedule #3 from the Intune and MMP-C enrollment, those tasks would both trigger the deviceenroller.exe (Which we don’t talk about)

This deviceenroller.exe would eventually kick off the “Schedule to run OMADMCLIENT” but to do so it needs to perform some small steps first

3. The Schedule Flow

Let’s start by looking at what happens when we execute “Schedule #3 created by enrollment client” I have created a simple flow explaining how Schedule #3 finally calls up on the schedule to run OMADMCLIENT by client

4. How it proceeds

Every 4 hours schedule #3 would kick off the OMADMClient.exe with some parameters. By comparing all the logs/traces I got with the deviceenroller.exe and the OMADMCLIENT, I noticed it calls up a DLL called: dcsvc.dll

At first, it didn’t ring any bell but taking a closer look, I noticed a nice Declared Configuration (DC) service (dcsvc.dll)

Besides the DLL files, we will also notice the same when the device performs a WCOS check-in at the MMP-C service. In this body of the post, we will notice an XML

This XML contains something called the DeclaredConfiguration schema

When looking at the corresponding response we got in Fiddler, we will also notice the same declaredconfiguration being mentioned with some nice WinDC Documents

At first, I was expecting some Intune NodeCache stuff in It as shown below

I guess it uses some nice “Declared Configuration Documents” with the settings (Epm Elevated MSFTPolicies) in it instead.

5. The MMP-C Sync Flow

Schedule #3 is being executed every 4 hours and would make sure any additional EPM elevation policies will be delivered or removed from the device. So I added an additional rule to the already existing PowerShell.exe policy I have

I turned all logging on (Procmon/Fiddler/Syncml/WPR trace/Event log Debug logging) and this is what I got! It should explain the dependencies of the whole process and should give you an insight into what is happening when your EPMAgent needs some adjustments

As shown above, at the end and after waiting a couple of hours schedule #3 kicks in and would deliver the elevation policy test.exe (DC Document) to the device with the use of the Declared Configuration Service! We will also notice the DocumentID being mentioned in the EPM ElevationRules

Looking back at an overview I created in my last EPM blog, I guess I need to change some stuff. At first, I thought the Epmagent was the “core” component in the MMP-C Enrollment but it isn’t!!!. It certainly looks like its the DCSVC!!!

6. The Declared Configuration Service

When looking at the top of the flow, we will notice the Declared Configuration (DC) service itself on top of the food chain. I was pretty flabbergasted that I never noticed this service so I decided to take a look at my other VMs that I got enrolled in Intune. When looking at the first one, I noticed that with the Windows 10 21h2 2022-05 update, the Declared Configuration Service corresponding DLL and the registry keys were not on the device

So I decided to upgrade the device update by update (preview included) until I installed the 2022-10 update

Guess what suddenly arrived on the device? A nice file called dcsvc.dll

I guess the “Declared Configuration” was left out of the “highlights”? I guess when they mentioned the declared configuration part, I definitely would have looked at it because the DCCSVC seems to be the core component of the MMPC enrollment

7. The Signature

Inside the EPMagent sync flow, I showed you, we will notice the DC part being mentioned a lot! Raw vs Cooked! I guess when the RAW data (document) is processed by the MMP-C service, the raw document data will be Cooked and ready for delivery!

Inside this WinDC document data, we will notice some important information such as the DocumentID and the EPMPayload

When taking a closer look at the Data from the picture above and having experienced the issue with the SSL inspection myself I noticed the “Signatures” part in it

When comparing the MMPC, SyncML output with the Intune sync, we will notice that this Syncml doesn’t mention a signature in it

When decoding this Base64 Value we will notice that it contains some certificates and other important stuff

Looking at the picture above, we will first spot the Azure TLS issuing CA and a revocation list

Besides the revocation list and the Azure TLS certificate, we will also spot a link to the PKI repository

So by the looks of it, each “Message” that gets delivered by the Declared Configuration Service will be signed by this certificate. Sounds way…way…way safer than the good old SyncML messages!!

The moment you put TLS inspection in it, it will break!

8. The Forgotten refresh schedule?

Even when we have looked at Schedule #3, we also have the same kind of schedule that could kick off a similar process. This schedule would “refresh” any setting changed on the device…

This schedule would kick off the deviceenroller.exe (always that damn executable!!!) with the /DeclaredConfigurationRefresh parameter.

For now, I still need to learn more about this task. By the looks of it, manually triggering this task, doesn’t trigger any communication with the MMP-C service itself to compare stuff. I will add more information to this part once I know the exact details.

Conclusion

Each day we get closer to understanding how something works. Hopefully, this blog showed you the importance of the declared configuration and how the EPM agent fetches the latest Endpoint Privilege Management elevation policies.