Intune

Architectural Flow behind a SCEP certificate Deployment via Intune

In this post, we shall learn about the flow that happens in the backend during a SCEP certificate deployment via Intune

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

SCEP Certificate Deployment Via Intune

The entire flow and setup has been explained in my below YouTube post-

Background:

#The Concept of using certificates:

For any user to access any application, he has to go through 2 phase-
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.

Conventionally authentication may that be to an App,Wifi,Vpn etc is done by username/password.

However to make this more seamless we introduced the concept of using a certificate for facilitating the authentication.Using a certificate for auth provides the below benifits-

• Seamless authentication
• Remove the overhead for the user to enter the username , password.
• More secured than passwords

Of course the cert which the user is going to use to prove his authenticity has to come from a trusted location. (A trusted 3rd party CA or on-prem CA).

The certs from Intune can be issued via 2 mechanism viz:- PKCS and SCEP

#Intro to SCEP

• Simple Certificate Enrollment Protocol.
• Protocol used for issuance of a cert,originally developed by CISCO
• Based on Request/Response model based on http like Get and Post
• The cert has the private key but the private key is not marked as exportable.
• Which means that the private key never leaves the device which makes SCEP more secured than PKCS
• A SCEP cert can be issued to a user/device or an userless device.

#Significance of using SCEP via Intune:

The end goal here is-

Delivering a certificate from an on-premise CA in the intranet to a device present anywhere in the world over the internet. The device can then leverage this cert for any purpose.

• We enroll devices to Intune
• From Intune we make a SCEP profile
• The SCEP profile comes down to the device and is responsible of getting a cert to the device from the on-prem CA
• All of this is achieved via a gateway server called the NDES.

Architectural Flow behind a SCEP cert Deployment

#Lets break the flow into 2 levels-

• Level 100 – A thousand feet overview
• Level 200- A Deeper dive

THE FLOW- Level 100- A thousand feet overview:

Components Involved:
In the above diagram we can see that following are the components involved:

• Mobile device enrolled to Intune
• The Intune service as the MDM
• Server 1 aka NDES in the Intranet
• Server 2 aka CA in the Intranet.

Flow: (As per the steps in the diagram)

1- A profile (called the SCEP profile) is deployed to the device from Intune service.
2- The device gets the profile and now reaches to the NDES server.
3- The NDES server does its checks and forwards the request to the CA
4- The CA issues a certificate and sends it back to the NDES
5- The NDES talks to the Intune service and uploads the certificate in Intune storage
6- The certificate is now deployed to the end device.

Inference:

• NDES server is having access to the internet(i.e. to the Intune service) as well as the intranet(its joined to the domain and can talk to the CA)
• NDES kinda acts as the mediator/gateway between the device and the CA and via it the communication is happening.
• This is so because obviously given that our CA is super critical and a vital component, we would not want to expose the same to internet and risk our on-prem infra.
• The aim again is, delivering a certificate from the on-prem CA in the intranet to a device in the internet which may/may not be joined to a domain.

Side Note:

Network device enrollment service(NDES)-We can install it and configure it from the server manager.
We connect it to a CA while setting it up.
When we install NDES, IIS is also installed and hence it is discoverable via an internal URL. (http://localhost/….)
Any server in the domain can discover the NDES server via this URL
Now the mobile device has to reach out to the NDES.

THE FLOW- Level 200 – A deeper dive

Until now we have not spoken about any logs, how the re-direction is happening and what checks are happening at each level. So now keeping those in mind, lets just take a deeper look into the same setup but with more insight.

Insight:

• The challenge here is the internal URL of the NDES is not publicly available or resolvable.
• So if any device tries to hit the internal URL of the NDES server hosted in its IIS, there would be no response as the same would not be found by the end device.
• Thus the requirement now is a URL which is externally hosted and discoverable.
• We refer to this as the External URL which we get via an App Proxy.
• We can use any proxy like Azure App Proxy, Web App Proxy etc
• So App proxy’s job in this case is – Providing a public facing endpoint which the devices over the internet can reference to and when a request comes to this URL, the same needs to be forwarded to the internal URL of the NDES and then processed accordingly.

Components Involved:

So now we see some additional components in the picture.

• Intune Connector: Its a connector (small installer) we install on the NDES server. This connector has to be downloaded from the Intune Portal(Device configuration>Connectors). Once installed we have to log into the connector using a cred from our tenant(it can be a service account as well). This establishes the connection b/w The NDES server and the Intune service.
• Hence it is necessary that the NDES server has connectivity to the internet so that it can talk to the Intune service.If there is any proxy in place, the same can be configured in the NdesConnectorUI
• Roles in NDES: We now see that the NDEs server has 3 roles installed in it- IIS, NdesPlugin and CRP
• Proxy: There is an additional component called Azure App Proxy (We can use any other proxy as well like WAP).
• As the Internal URL of the NDES server is not accessible via the internet by a device, the Azure App Proxy saves the day and provides us a public endpoint by providing us a URL which is accessible over the internet. We call this the External URL.
• So all the App Proxy does is, it redirects any traffic from the internet at the external URL to the Internal URL i.e. the IIS of the NDES server

Flow: (As per the steps in the diagram)

#1-

A SCEP profile is made in Intune and delivered to the device.
SCEP profile is nothing but a device configuration profile which tells the device that it is going to get a SCEP certificate.
This profile contains- The Name of the CA, Validity of the certificate, attributes of the certificate and the External URL(which is provided by the Azure App Proxy).The external URL remains the same for all the users targeted by a SCEP Profile

#2-
The mobile device does not know where the CA is, so it cannot go to the CA and get a certificate yet.
Now the mobile device sees that there is a External URL in the SCEP profile.
As this External URL is accessible over the internet, the mobile device hits the external URL i.e. the External URL of the App Proxy.

#3-
The Azure App Proxy forwards the request at the external Url to the Internal URL of the NDES server..
We have already pre-configured to which internal Url the Azure App Proxy is supposed to forward the request to.

#4-
Whenever any device (in the internet or intranet) reaches out to the NDES via the Internal/External URL the request always lands in the IIS of the server.
The internal URL is basically hosted by the IIS component of the NDES server.
So by now, a request from the mobile device has reached to the IIS of the NDES server
IIS accepts the requests made to the URL.
At this point if we check the IIS logs we can see that a device tried to access the URL (internally or externally)

#5.
Now the IIS passes over the control to the NDES Plugin.
The NDES plugin got activated in the server when we installed the Intune connector.

#6-
The Plugin checks 2 thing i.e. the cert bound to the Intune connector during installation and the cert bound to the IIS of the NDES server
(The plugin makes sure that the certificate bound to the connector and the cert bound to the IIS of the server are the same)

#7
The NDES Plugin forwards the request to CRP.
Certificate registration point.

#8-
The CRP verifys this request.
It verifies whether the request is genuine or rogue.
CRP does this verify in 3 phases.

• 1st Phase- (expiration of the SCEP challenge) CRP checks the validity of the SCEP challenge and sees when was the request created by the mobile device.

(if the request was created more than 1 hour back, then the same is rejected)

• 2nd Phase- Genuinity of the challenge/user

It checks whether user is valid or not, the user is active or not, the user generating the request is genuine or not

• 3rd Phase- CRP checks the deviceid and userid of the user from which the challenge was originated.

• #It will leverage the Intune connector and talk with the Intune service to fetch the device id and userid mapping
• #CRP also goes to a location in the registry- HKLM/Software/Microsoft/MicrosoftIntune and makes sure that all the entries there are fine.This registry is created when we install the Intune connector
• #If there were multiple instances of the Intune connector installed without properly flushing out the old one then this could be a corruption in this location which would make the CRP reject the request.
• #CRP in a nutshell verifies the request in 3 phases.

#9-
Now the CRP goes to a registry location- HKLM/Software/Microsoft/Cryptography/mscep
In this registry location there is a key which contains the name of the template which has to be used by the CA to issue certificate to the end devices.
After the CRP has verified the request in the previous step, it goes to the /mscep location in the same NDES server and grabs hold of the key which is populated with the name of the certificate template to be used by the CA to issue certs to the end device.
The CA cannot just issue any random cert.
It issues certs on the basis of a certificate template which the admin has to pre-configured in this registry location.

So in this step the CRP will fetch the name of the certificate template from the registry and using it, it would reach out to the CA.
the CRP is now requesting a certificate on behalf of the user.
It carries the upn of the user with it along with the certificate template name (from the registry) and some other information.

#10-
CA checks the information. It checks if the certificate exists or not, if the cert template is published or not, the validity, the root certificates in place etc…
It issues a cert now which can be viewed in the “Issued cert tabs” in the certutil.

#11-
The cert would be sent back from the CA to the CRP and the cert can be seen in the CRP logs now.

#12-
The CRP informs the NDESPlugin and the IIS and it Notifies that the cert has been issued and can be given to the user.

#13-
The IIS now does a POST operation which signifies that the cert is ready and can be delivered to the device(can be tracked in the logs)

#14
The cert now travels via the Intune Connector to the Intune service and is stored in a SAAS location of the tenant in the Intune service.

#15-
The Intune service delivers the cert down to the device and marks it as Successfully deployed upon confirmation by the device.

#16-
Now the cert is also visible at the device and its logs (Company Portal/Xcode/ADB/Eventviewer depending on the device OS)

Sequence of checking the logs for a cert deployment

The logs that we check is in accordance with the above flow-

Conclusion:

• We can track the status of the cert delivery in each phase which would be in accordance with the flow illustrated above
• Once the cert is down to the device it is upto the device to present the same to a RADIUS server and prove its authenticity.
• We also have the option of binding this SCEP cert with a WIFI profile (also deployed by Intune)
• The advantage being- the end user would be automatically connected to the Wifi (if in range) and he wont have to select the cert manually for authentication.
• We have to remember that Intune is a delivery mechanism and its scope pretty much ends when the cert is down to the device.