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

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

In Part 1, we learned the basic concepts of Public Key Infrastructure (PKI). In Part 2, we covered the general workflow of SCEP cert enrolment request based on 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 for delivering PKI certificates to the managed endpoints.

The purpose of this article is to help all to understand the overall workflow in detail, the components involved and the roles they play, the flow between the components. 

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“

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.

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. SCEP profile is configured in Intune and deployed to the managed device.
4. Managed device prepares a Certificate Signing Request (CSR) as per the information in the received SCEP profile and makes the certificate request to the specified SCEP URL. (This is 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 successful cert enrolment status to Intune via the Intune Certificate Connector.
9. NDES sends the certificate key package to the requestor (managed device).

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

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, it is the device Admin responsible to configure 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 configures 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) and with it, create a Trusted Certificate profile, and deploy to the endpoints. This is how Intune sets the device to trust your internal CA.

Since the internal CA is never exposed to 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 are having multi-tier PKI infrastructure, meaning there is an Enterprise Root CA (usually restricted for inbound connection) 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, 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 the same 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 that you configure while creating the SCEP profile in Intune must match with the SCEP certificate template configured in the Issuing CA.

• 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? Well, you might have noticed I skipped the step Enrollment Authorization 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 – 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 of a different, possibly higher privileged user that 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, to secure and harden SCEP/NDES implementation, must build and provide its own Policy Module for the purpose.

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

Intune SCEP workflow essentially uses a Policy Module for the purpose of cert request authorization, which brings us to the main component of the Intune SCEP cert deployment architecture – 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

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 sits 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 is used to retrieve the CA cert which also returns the RA Encryption cert with which the device protects the enrolment request message before sending it out to the SCEP service.

In the Intune SCEP workflow, this is not required.

We have already seen that the Trusted Certificate profile is used to establish the PKI trust.

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

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

The enrollment here points to a certificate. Other than the RA certs and the 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 not get the generic NDES webpage anymore. This is because the NDESPugin module starts intercepting the incoming requests to the SCEP endpoint.

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

If you get any other HTTP error code, there’s some issue with the configuration that requires troubleshooting. Probable causes and remediation is available in Microsoft documentation.

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 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 upon receiving the profile makes the certificate request to the SCEP endpoint. But today we will keep it till here.

In the next part of this article, we will look at details, of how the Intune Certificate Connector validates the cert request – the low-level flow of the Intune SCEP workflow. Till 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)