Intune SCEP Deep Dive – Intune PKI Made Easy With Joy – Part 3

Welcome to today’s article, Intune SCEP Deep Dive. This is the third article of the Intune PKI Made Easy With Joy series.

In Part 1, we learned the basic Public Key Infrastructure (PKI) concepts. In Part 2, we covered the general workflow of SCEP cert enrolment request based on the Enterprise deployment model using automated authorization – how an end entity makes a cert enrolment request to the Certificate Authority (CA) to obtain a PKI certificate (x.509).

Today, we will learn how Microsoft has implemented SCEP with Microsoft Intune to deliver PKI certificates to managed endpoints. This article aims to help everyone understand the overall workflow in detail, including the components involved, their roles, and the flow between them. 

If you know the workflow correctly, it will help to not only get the deployment done right on the first go but also when a break-fix situation arises (which will for sure), will help you to know

• what to look for
• where to look for
• how to quickly resolve the issue

Disclaimer: This article is not a “How-To-Setup” guide to configure Intune SCEP deployment infrastructure, but instead aims to show “How It Works“

Index
Quick Recap – General SCEP workflow
Intune SCEP workflow – [High-Level Overview]
Intune SCEP Workflow – Compare and Contrast with General SCEP Workflow Establishing PKI Trust
Device Initialization
Enrollment Authorization -Vulnerability of General SCEP workflow
How does Intune overcome this SCEP inherent vulnerability of enrolment authorization?
Insights into the Intune SCEP Certificate Connector
Intune SCEP workflow – GetCACert to obtain CA cert (and RA cert), and GetCACaps is Redundant!
To be contd. (Part 4 coming soon)
Resources

So let’s get started.

Quick Recap – General SCEP workflow

The below snap summarizes the general SCEP cert enrolment workflow we covered in Part 2 of this article series.

The table below summarizes the general SCEP cert enrolment workflow for your reference.

So.No.	General SCEP workflow	Description
1	Device Initialization	The device Admin configures the device with the information required to create the cert enrolment request.
2	Device retrieves CA Cert	Device Admin navigates to CGI path /certs/mscep_admin to retrieve the challengePas
3	Admin retrieves challenge	Device Admin triggers the device to make a GetCACert and GetCACaps call to SCEP to retrieve the CA cert and CA-supported capabilities.
4	Admin configures Device	The device creates the CSR with the information as configured by the Device Admin.
5	Device creates CSR	With the CSR, the device creates cert the enrolment request message, protected using the RA encryption cert and signed by the device, and sends it to the SCEP endpoint
6	Device Sends Enrolment Request to SCEP	Upon receiving the enrolment request, SCEP verifies the signature of the message and decrypt package to retrieve challengePassword to verify authorization
7	SCEP validates enrolment authorization	The template is determined by the KeyUsage as specified in CSR Based on this SCEP chooses the template configured in HKLM\SOFTWARE\ Microsoft\Cryptography\MSCEP
8	SCEP inspects CSR to determine template	The template is determined by the KeyUsage as specified in CSR Based on this, SCEP chooses the template configured in HKLM\SOFTWARE\ Microsoft\Cryptography\MSCEP
9	SCEP makes cert request to CA	CA generates RSA key pair and corresponding x 509 cert. The cert package is protected using the Device public key sent along with CSR and signed by CA. The protected package is returned to SCEP
10	SCEP makes the cert request to CA on behalf of using the service account. This is facilitated by the RA Exchange Online Agent cert	Device Admin triggers the device to generate an RSA key pair and Transaction Identifier
11	SCEP delivers cert package to Device	CA generates a Cert package and sends it back to SCEP

Intune SCEP workflow – [High-Level Overview]

The below image summarizes the communication flow of the Intune SCEP workflow from a very high-level perspective.

1. The public key cert of the Enterprise CA needs to be exported with which a Trusted Certificate profile is created in Intune.
2. The Trusted Certificate profile is deployed to the managed device to establish PKI trust.
3. The SCEP profile is configured in Intune and deployed to the managed device.
4. The managed device prepares a Certificate Signing Request (CSR) according to the information in the received SCEP profile and sends the certificate request to the SCEP URL (the proxy URL configured in the SCEP profile).
5. Azure App Proxy forwards the request to the actual SCEP endpoint – NDES server
6. Upon receiving the request, NDES leverages the Intune Certificate Connector to check the request validity
7. For a valid request, NDES goes ahead and makes an on-behalf request to the CA for the certificate with the information as retrieved from the Certificate Signing Request (CSR)
8. CA generates the certificate key package and sends it back to NDES. NDES notifies Intune via the Intune Certificate Connector of the successful cert enrolment status.
9. NDES sends the certificate key package to the requestor (managed device).

The above workflow is simplified and high-level at its best, giving an overview of the entire communication. However, there are complex details involved.

To understand the complexities in detail, we need to correlate the Intune SCEP workflow against the general SCEP workflow.

Intune SCEP Workflow – Compare and Contrast with General SCEP Workflow Establishing PKI Trust

In General SCEP Workflow, establishing PKI trust is part of the workflow, but with Intune, this is a separate process that needs to be carried out initially.

In general SCEP workflow, the device Admin configures the device to explicitly trust the internal CA.

This is essentially via the http(s) REQUEST where pkiOperation=GetCACert, the RESPONSE to which is a degenerate PKCS#7 message containing both the CA and RA public key certificates as binary-encoded x.509 in the Content-Type. 

Device Admin validates the cert thumbprint via an out-of-band method.

You will also see a http(s) REQUEST where pkiOperation=GetCACaps, the RESPONSE to which contains the CA capabilities as returned. This is used by the Device Admin to configure the device to create the appropriate cert enrolment request.

In the Intune SCEP workflow, how does Intune configure the managed device to trust your internal CA?

For domain-joined devices, the trust with CA is automatically established when the device becomes a member of the domain. But what about the mobile devices (Android/iOS) and cloud-managed Windows devices that are not local domain joined?

Intune achieves the same via the Trusted Certificate profiles. You need to export the public key of your Root CA as an (x.509) certificate (.cer), create a trusted certificate profile with it, and deploy it to the endpoints. This is how Intune sets the device to trust your internal CA.

Since the internal CA is never exposed to the open Internet, without this, the cloud-managed devices will never be able to exchange public keys with your internal PKI infrastructure required for trust establishment and secure communication.

If you have a multi-tier PKI infrastructure, meaning there is an Enterprise Root CA (usually restricted for inbound connections) and then multiple levels of Enterprise Sub CA, the public key cert of each CA, which forms the chain of hierarchy to Root, needs to be exported and deployed to the managed endpoints as Trusted Certificate profiles.

Device Initialization

In general SCEP workflow, we see it’s the device Admin responsible for configuring the device with the information required to trigger the device to create a cert enrolment request.

With Intune managing the device, the Intune MDM service can be compared to the device Admin responsible for configuring the device with the information required to trigger a certificate enrolment request. Intune achieves this via the deployment of the SCEP certificate profile.

 The information, as configured in a SCEP profile, are

• Key Storage Provider – Define the KSP to be used to store and protect the key package that will be received.
• Root Certificate – Define the public cert of the issuing CA (explained below later)
• Certificate type – Define the cert type – User or Device?
• SCEP endpoint URL – Define the app proxy published public URL
• Renewal Threshold – Define the threshold when the device should start making renewal calls for the cert.

The following settings must match the SCEP certificate template configured in the issuing CA, which you configure while creating the SCEP profile in Intune.

• Subject Name and Subject Alternative Name – To identify the entity for which the certificate is being requested.
• Certificate validation period – Specify the timeframe the certificate will remain valid. (unless revoked)
• Key Usage – To define the certificate use case.
• Key size – To define the size of keys to be used while creating the certificate.
• Hash algorithm – To define the algorithm to be used for generating the keys.
• Extended Key Usage – To define the additional use-case of the certificate.

For multi-tier PKI, while configuring the SCEP profile in Intune, you need to select the Trusted Certificate profile of your Issuing CA as the Root Certificate within the SCEP profile instead of the actual Root CA.

Sounds confusing? Well, the UI team could have gone for a more descriptive name, but the same information is shown when you click the information icon beside the settings, so you can’t really blame it.

Why? You might have noticed I skipped the enrollment authorization step, which brings me to the most important topic…

Enrollment Authorization –Vulnerability of General SCEP workflow

SCEP, in its original implementation, has an inherent vulnerability – enrolment authorization.

In the General SCEP workflow, for automated authorization of an enrolment request, SCEP pre-shares a secret (challengePassword) with the entity with which it makes the cert request.

Essentially the device Admin navigates to <NDESFQDN>\certsrv\mscep_admin to retrieve challengePassword.

However, NDES (SCEP) upon receiving the request, the check only matches the challengePassword and not the request!

As such, it is possible that an entity may legitimately acquire SCEP challengePassword but

• use it to obtain a certificate for another entity – a security risk of Impersonation
• Use it to obtain a certificate for a different purpose than intended – security risk of elevation of Privilege

Thus, an attacker can elevate their permissions by requesting a certificate from a different, possibly higher-privileged user, which would allow them to access resources that they would not otherwise be able to access.

SCEP in general, can even be configured to

• not require challengePassword, or 
• share a static password across many entities.

This vulnerability of SCEP is addressed with enhancements made in Windows Server 2012 ADCS NDES role by including support for a Policy Module. However, Windows Server 2012 (or higher) does not ship with a Policy Module out-of-box.

Traditional management solutions, like SCCM or any MDM solution, must build and provide their own policy module to secure and harden SCEP/NDES implementation.

How does Intune overcome this SCEP inherent vulnerability of enrolment authorization?

The Intune SCEP workflow essentially uses a Policy Module to authorize cert requests, which brings us to the main component of the Intune SCEP cert deployment architecture: the Intune Certificate Connector for SCEP.

Basically, the challenge generation for Enrollment Authorization is delegated to the Policy Module, which requires the requestor to include the following information along with the challengePassword when making the cert request

• specific entity for which the cert is being requested (user or device),
• the specific purpose of the cert

A brief insight into the Intune SCEP Certificate Connector – compare-and-contrast to find more differences in the Microsoft implementation of SCEP with Intune and the general SCEP workflow.

Insights into the Intune SCEP Certificate Connector

The Intune Certificate Connector is what Intune uses to communicate with the underlying PKI infrastructure and control the certificate requests. This connector essentially brings to the table two things –

• NDESPlugin module
• Certificate Registration Point (CRP)

For SCCM folks reading this, you already know that CRP is a separate role that needs to be configured in one of the Site Servers before you install the Policy Module that ships with Config Manager on the NDES server.

Intune combines both – The plugin module and CRP in the form of a connector.

In the Intune SCEP workflow, Intune leverages this connector to generate the SCEP challenge, which is complete behind the scenes and is not exposed via any user-facing logs. Still, we may consider the mechanism to be fairly similar to the NDES SCEP cert deployment with Config Manager, with the exception being.

With Intune, the CRP and Plugin Module sit in the same server configured with the NDES role.

When the device makes the certificate request, the request is also delegated to the NDESPlugin module for verification. This is explained in the next part of this article – Part 4 (coming soon!)

But there is one more major difference between the Microsoft implementation of SCEP with Microsoft Intune and the general SCEP workflow…

Intune SCEP workflow – GetCACert to obtain CA cert (and RA cert), and GetCACaps is Redundant!

In the general SCEP workflow, we have seen that the GetCACert call to the SCEP service retrieves the CA cert. This call also returns the RA Encryption cert, with which the device protects the enrolment request message before sending it to the SCEP service.

In the Intune SCEP workflow, this is not required.

We have already seen that the Trusted Certificate profile establishes the PKI trust.

But if the device does not retrieve the RA certificate, how does it protect the cert enrolment request message before sending it to the SCEP service?

On the NDES server, after installing the Intune NDES Certificate connector, you sign in successfully with a Global Admin or Intune Admin account and get a message prompt stating, “Successfully enrolled.” The NDES server does not enrol in Intune as Intune doesn’t support Server OS.

The enrollment here points to a certificate. Other than the RA and IIS SSL binding cert, you will now have another certificate in your NDES box local machine personal cert store issued by Microsoft Intune Certificate Connector CA. (This is a Microsoft-managed CA in the cloud)

This certificate is used to secure

• The messages exchanged between Intune and the NDES (SCEP service) via the connector, as well as
• The cert enrolment request message (CSR package) that the device sends out to NDES (SCEP service)

NOTE: The RA certs (both the CEP Encryption and Exchange Enrollment Agent) are still required for the NDES service to be functional.

Post-installation and successful sign-in to the Intune SCEP Certificate Connector when you navigate the SCEP URL <NDES FQDN>/certsrv/mscep/mscep.dll You will no longer get the generic NDES webpage. This is because the NDESPugin module has started intercepting the incoming requests to the SCEP endpoint.

Provided that the configuration is good, you can expect an HTTP 403 Forbidden Error.

Intune SCEP Deep Dive—After a successful sign-in to the certificate connector, the NDESPlugin module, a component of the certificate connector, starts intercepting the requests coming to the SCEP URLs. For good configuration, it displays the HTTP Error 403.

If you get any other HTTP error code, a configuration issue requires troubleshooting. Microsoft documentation provides probable causes and remediation.

Recollecting Intune SCEP workflow covered till now…

• Intune deploys the Trusted Certificate profile to the managed endpoints to establish PKI trust.

• A unique challenge string is generated per the SCEP profile created in Intune.

Intune leverages the Intune Certificate Connector (for SCEP) for the challenge generation, handled by the NDESPlugin module on the NDES box. The challenge string is added to the SCEP payload that gets delivered to the device.

Remember that the certsrv/mscep_admin also provides the Issuing CA certificate thumbprint along with the challengePassword. The thumbprint is used by Intune for profile validation - the reason why, for multi-tier PKI, you need to select the Trusted Certificate profile of the Issuing CA instead of the actual Root CA while configuring the SCEP profile in Intune.

• Intune deploys the SCEP profile to the managed device.

To be contd. (Part 4 coming soon)

As Intune deploys the SCEP profile, the device makes the certificate request to the SCEP endpoint upon receiving the profile. But today, we will keep it until here.

In the next part of this article, we will examine the details of how the Intune Certificate Connector validates the cert request—the low-level flow of the Intune SCEP workflow. Until then, keep reading, keep learning, and last but not least, stay Safe!

Resources

• https://techcommunity.microsoft.com/t5/enterprise-mobility-security/whitepaper-securing-and-hardening-ndes-for-microsoft-intune-and/ba-p/249035
• https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-to-write-an-ndes-policy-module/ba-p/1129075
• https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn473016(v%3Dws.11)

We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.

Author

Joymalya Basu Roy is an experienced IT service professional with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He was awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site MDM Tech Space at https://joymalya.com