Intune

Understanding the detailed Background flow and the Logs behind a SCEP certificate deployment via Intune.

My name is Saurabh Sarkar and I am an Intune engineer in Microsoft. I have a YouTube channel ‘EverythingAboutIntune’ and you can subscribe to the same to learn more about Microsoft Intune.

Background:

For any user to access any application, he must go through 2 phases-
Authentication phase and Authorization phase.
• Authentication phase- User’s authenticity is checked (if the user is, who he claims to be)
• Authorization Phase- User is subjected to some conditions and depending on the output we determine whether the user should be given access or not.

The end goal is-
Delivering a certificate usually from an on-premises CA in the intranet to a device present anywhere in the world over the internet. The device can then leverage this certificate for any purpose

Please refer to the below Blog which explains all the steps needed to setup a SCEP/NDES infrastructure.

NDES and SCEP setup for Intune- A Complete Guide!

In this article I wanted to explain all the processing that happens under the hood, during the delivery of a SCEP certificate via Intune and correlate the flow with the relevant logs.
The detailed demonstration of the flow can be found in my below YouTube channel-

Flow (Part 1):

1- Admin creates and assigns the SCEP profile.

• Admin creates and assigns the SCEP profile
• This is the very first step in the flow which needs to be carried out by the Admin
• Once the SCEP profile has been assigned, Intune reaches out to Azure and identifies the effective applicable users.
• It then fetches the CN of the members.
• It also evaluates the Group association, making sure that the SCEP and the Trusted Profile linked are both deployed to the exact same group(and not nested groups)

2- SCEP Challenge Generation

• Intune service reaches out to the NDES server via the Intune connector and requests for the challenge password.
• A unique challenge string is generated per user per SCEP profile configured in Intune.
• The request for generating a challenge is handled by the NDES plugin module.
• The NDES plugin module utilizes the CRP to generate an enrollment challenge for the device.
• The challenge password is generated by referencing the virtual app- ‘certsrv/mscep_admin’ running in the NDES server.
• Referencing the above returns the challenge, the Thumbprint of the issuing CA and the time stamp.
• This is equivalent to manually generating a challenge from the NDES server by browsing to the “mscep_admin” url in the NDES

• If we take a wireshark trace from the NDES server while the server generates the challenge, the challenge passwords can be seen (as shown below)

The communication between the Intune service and the NDES server via the Intune connector is encrypted using the ‘Microsoft Intune NDES Connector CA’ certificate.

This certificate was generated and issued when the admin did the setup of the Intune connector in the NDES server and signed into the same.

3- Challenge response

• The NDES server sends the challenge password, the thumbprint of the issuing CA and the timestamp back to the Intune service
• As above, this communication between the NDES server via the Intune connector and the Intune service is encrypted using the ‘Microsoft Intune NDES Connector CA’ certificate.

4- SCEP payload + Challenge delivered to the device

• The challenge information is now injected into the SCEP profile (payload) and is deployed to the device.
• The SCEP payload contains all the information configured by the admin in the SCEP profile, including the Proxy URL
• The device receives the SCEP payload and the challenge password.
• We can track the same via a SyncML trace at the device end which shows the SCEP payload and the challenge received by the device.

• We can see that the other attributes as per the SCEP payload like the SAN, Key usage, Key size, EKU, Validity is also deployed to the device as a part of this MDM session

All the above attributes deployed by the Intune service as a part of the SyncMl session is derived from and is in accordance with the settings of the SCEP profile configured by the admin

5- Device generates and sends the GetCACert and GetCACaps request

• Now the device sends a GET request to the App proxy URL it received from the SCEP payload
• This can be seen in the CP logs of the device/Xcode logs of the device

#Company Portal logs from device:

#Xcode logs from an iOS device

6- The GetCACaps and GetCACert request is received by NDES and it responds

• The App proxy forwards that request to the NDES server
• The NDES server receives the above requests which is logged in its IIS.
• The logs in the IIS are in UTC so we might have to convert it to local time if we are tracking the same.
• Depending on the OS from which the request was originated we would see a different kind of log in the IIS.
• Since the deviceid of the device which generated the request is not logged in IIS, we are limited to determine only the originating OS from which the request was generated.
• We can use the below for reference-

Origin of request (OS)	Keyword to look for in the  IIS log
iOS/macOS	Darwin
Windows	Win32
Android	Android, Dalvik
Normal Browser	Mozilla, Chrome, Safari, Windows+NT

#IIS Logs in NDES: (Request originating from iOS)

Now we see that the NDES server checks the RA certificate present in the device. This can be tracked in the CapI2 logs.

• There are basically 2 kinds of checks made at this point in CapI2 viz- Build Chain and Verify chain
• The certificate chain for the RA certs are checked as well as a check is made for the CRL(to ensure that the certs are not revoked)

#CAPI2 Logs from the NDES server:

Below are the relevant 2 certificates for which the check is made-

• Once the check is done in the CapI2 logs, the server responds to the client and provides it the below
• List of all the supported operations by the CA (CACapabilities)
• The RA encryption certificate (Issued by CEP encryption template)(CACertificates)—This would be used by the client later.

Note- All certificate requests to the NDES server comes from the device over the Internet and therefore, the communication needs to be encrypted.
This communication is encrypted using the SSL certificate which we bind to the IIS of the NDES server

7- Device receives the response to the ‘GET’ request.

• The device receives the response to the ‘GET’ request.
• The same is logged in the CP logs as shown below-

#CP logs from Android device:

• The response to the GetCACert are the 2 RA certificates which are binary-encoded
• These are the CA certificates which will be later used by the device.
• SCEP uses the CA certificate in order to secure the message exchange for the CSR

• The response for a GetCACaps message is a list of CA capabilities, in plain text which is usually as below.

8- Device creates a CSR (Certificate Enrollment request)

• Now the device has everything it needs, so now it generates the CSR(Certificate Enrollment Request)
• In Windows device this can be tracked in Eventviewer with EventId 306

• The CSR generation can be tracked as below in XCode logs from an iOS device.

Now for the steps that follow, we will reference the below diagram-

FLOW: (Part 2)

9- Device sending the CSR to the Proxy

• Now the device prepares the CSR which is in accordance with the SCEP payload it received from the Intune service, thereby making a certificate enrollment request.
• The device sends this CSR to the Azure App Proxy URL which forwards it to the NDES
• This is logged in the Eventvwr with EventId 36

#Eventlogs from the Client device

10- The request is sent to the NDES server

• The CSR request is forwarded by the App Proxy to the NDES server
• This communication is encrypted using the RA certificate (issued by CEP encryption Template)
• This request lands in /certsrv/mscep which is a virtual app running in SCEP application pool of IIS in the NDES server

#IIS in the NDES server

11- The Plugin initializes and forwards the request to CRP

• The CSR request is handled by the NDES Plugin which first initializes to handle this request.

• For the NDES plugin to initialize, it references the NDES Policy Module node in the registry.
• Path-         HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP\Modules\NDESPolicy

#Registry from the NDES server

• The NDES Policy module forwards this request to the CRP to verify the challenge from the device
• This action is logged in the NDES Plugin log as well as the IIS log

#NDES Plugin Log:

Before 2021, we had to setup the ‘NDESConnector’ for deploying SCEP certificates via Intune.On 29th July 2021, Microsoft announced the launch of the ‘Unified Certificate Connector for Intune which is documented- https://learn.microsoft.com/en-us/mem/intune/fundamentals/whats-new (in Intune new release).

This was a major announcement which changed a lot of things!
Step 11 and 12 from this blog no longer happen with the new Unified Connector.
Please refer to the detailed blog below which explains the changes that have taken place with the advent of new connector.

The ‘Unified’ Certificate Connector and changes in SCEP configuration/logging via Intune

12- The CRP now validates the CSR from the device

• The CRP decrypts the CSR and now validates and verifies the challenge originating from the device in 3 steps..
• The CRP primarily checks the below
• Whether the time stamp of the challenge has expired or is it still valid(validity is 60 min)
• Whether the challenge password is correct(it matches it with the list of passwords generated by the NDES server)
• It checks the attributes for which the challenge was originally generated with the CSR to ensure the same matches.
• We can see the results of these validation in the CRP Logs

#CRP Logs:

#Phase 1

#Phase 2

#Phase 3

#Verify Complete

• Once CRP validates the challenge, the same is recorded in the NDES Plugin logs as a success.

#Logs in NDES Plugin-

• There has been a major change in the functionality of the NDES server’s challenge validation with the new connector. With the older version, the challenge validation was performed at the NDES server as shown above.
• In the Unified certificate connector the challenge validation is done by the Intune service and the result in turn (Success\Failure) is notified to the NDES server. Now there are no NDESConnectorSvc logs and we cannot see the outcome of each phase of challenge validation from the on-prem server side logs.This can only be tracked in the Intune service side logs.
• With the new connector, to achieve the above step of challenge validation, the Unified connector will send a request to the Intune service to perform the CSR validation. The Intune service will perform the same and send the response back (Success/Failure) back to the Connector.

13- CRP reaches out to the CA requesting for a client certificate

• The NDES Plugin now tells(‘Notifies’) the CRP to get a certificate from the CA as the validation was successful.
• This step is logged in the NDES plugin logs, the CRP logs as well as the IIS

#Logs in NDES Plugin-

#Logs in the IIS

#Logs in the CRP

• CRP now requests the CA for a client certificate (using the service\system account) configured in the Intune connector.
• This request is stamped using the RA certificate present in the NDES issued from the Template ‘Exchange Enrollment Agent’
• The CRP however must specify to the CA, the name of the template against which the client cert has to be issued.
• For this it references the registry ‘HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP’ and grabs the name of the Certificate Template against which the client cert has to be requested (this registry location was pre-populated by the admin in the server)
• The CSR contains the key usage information based on which the CRP decides which registry value from the below 3 it would pick as the Template name.
• The CSR got the key usage information from the SCEP profile wherein we specify the same.

14- CA issues the certificate and sends it back.

• CA makes a check for the template and validates the below.
• Ensuring that the requesting service\system account has the privileges to request for a certificate.
• Ensuring that the template for which the certificate must be issued is published.
• Ensuring that the validity of the template is more than or equal to the validity for which the client certificate is being requested.
• CA now issues the certificate to the SN and SAN as per the request.
• CA protects the certificate package by using the device’s public key (it received in the CSR)
• The CRP now receives this package and this successful reception is logged in the NDES plugin and the CRP logs.

#CRP Logs

#NDES Plugin Logs

15- Plugin uploads the certificate details back to the Intune service

• CRP upon receiving the certificate package stores it in the ‘Processing folder’ as shown below.

• We can see the content of the .CRS by opening it in a notepad

• NDESPlugin uploads the Certificate Request Status data [.CRS] to Intune via connector communication.
• The thumbprint of this client certificate can be seen in the NDES Policy Module logs

(C:\Program Files\Microsoft Intune\NDESConnectorSvc\Logs\Logs\.svclog)

• The .CRS file is now moved from ‘Processing’ folder to ‘Succeed’ folder.
• The Eventviewer logs in the NDES show that the certificate was successfully uploaded to the Intune service via the Intune connector,with EventId 0

#Eventviewer logs from the NDES server(Application and Services Logs>Microsoft Intune Connector)

• This is accompanied by a POST operation in the IIS logs

#Logged in IIS

#Screenshot from the portal:

16- The Certificate is deployed to the device.

• The certificate is delivered back to the device by the NDES server
• Certificate is sent back to the same PKIOperation session started by the device via the app proxy
• The PKIOperation session is now closed as the certificate is now delivered to the device.

17- Device receives the certificate.

• The device gets the certificate and the same is logged with EventId 309

• The device installs the certificate and the same is logged with EventId 39

• In case of an iOS device, the certificate installation can be viewed in the XCode logs as well, as shown below.

• The certificate is also visible in the ‘Issued Certificates’ tab in the CA

Viewing the SCEP certificate at the device end

Operating System	Location
Windows	MMC>Current User>Personal Store>Certificates
iOS	Settings>Device Management>Management Profile>More Details>’Under ‘Certificates’ header, ‘SHA-1’ signifies the Thumbprint
macOS	Keychains>System>My Certificates, ‘SHA-1’ signifies the Thumbprint
Android	My Certificates application >User Credentials

To confirm that we are looking at the correct certificate, we can cross reference with the thumbprint of the cert generated by the CA and viewed in the logs with the thumbprint visible in the device in the above respective locations.

Android:

iOS:

Windows

Below is a view of a procmon trace from the NDES server which shows its working folders and few ongoing background activities.

Block diagram for the flow

• Below are the different stages during the issuance of a certificate via NDES and Intune

Block diagram for the Logs

• As already substantiated in the flow above, below are the various logs that we have discussed with respect to a cert deployment via NDES.

Tracking a successful Certificate Deployment

In case of a successful SCEP certificate deployment, we can track the same in the below sequence

Conclusion:

• In case of any failures with certificate deployment, we can correlate with the above flow and then look for the mentioned logs.
• I hope that this article has been helpful in understanding the background flow during a SCEP certificate delivery via Intune and the relevant logs at each step.

Additional Information:

• As mentioned in the blog before, the flow of CSR validation has changed significantly with the introduction of the new Unified Certificate Connector.
• Please refer to the below flow diagram which provides insights into the same.
• As we can see, in Step 11 the NDES is reaching out to the Intune service for CSR validation and in Step 12 the Intune service is responding back to the NDES with the outcome of validation.(Success/Failure)

The flow for SCEP certificate delivery via the Unified Connector has been explained in the video below-