Introduction
With many organisations adopting "cloud native" devices in Microsoft Intune, one obstacle faced is deploying internal AD CA certificates to devices to ensure a successful issuance of both user and device certificates. These certificates would typically be used for a digital signature certificate for VPN and 802.1x wireless networks.
There are various certificate deployment options available in Microsoft Intune.
Private and public key pair (PKCS)
Cloud PKI - Microsoft's new cloud-based certification (CA) authority solution included in Intune Suite.
For organisations opting to use SCEP, a range of on-premises infrastructure is required to successfully allow Intune enrolled devices to receive a certificate. These include:
Certificate Connector for Microsoft Intune – The Certificate Connector for Microsoft Intune is required to use SCEP certificate profiles with Intune when you use a Microsoft CA.
Certification Authority – A Microsoft Active Directory Certificate Services Enterprise Certification Authority (CA).
NDES server role - Network Device Enrollment Service (NDES) server.
Proxy - Typically a Microsoft Entra application proxy. Other options are available like a Web Application Proxy Server or third-party reverse proxy.
Microsoft provide some very good documentation for configuring the required SCEP infrastructure.
In this blog post, I want to talk about options for load balancing SCEP URLs to remove single points of failure and promote availability for organisations who want to explore it or require it.
Why should I consider SCEP load balancing?
When configuring SCEP infrastructure, you should ask yourself:
How many devices will be assigned to the SCEP profile/s in Intune?
What operating systems are required?
What will my SCEP certificate be used for?
What would be the impact to my organisation if my SCEP infrastructure was down and devices failed to receive a certificate?
A typical implementation of SCEP is configuration of one of each of the required on-premises infrastructure e.g. one NDES Server, one Certificate Connector and so on. If one of the required on-premises infrastructure were go to down or offline, the likelihood of SCEP certificate failures is almost guaranteed. So we have single points of failure to contend with. What can we do about it?
What is SCEP URL load balancing?
Intune natively supports load balancing SCEP URLs. Essentially what this means is you can add one or multiple SCEP URLs in the SCEP profile and Intune will handle the load balancing process when the profile is pushed down to devices.
This means, you don't have to introduce any third-party load balancing solution, Intune does it for you! The behaviour for managing the SCEP server URL/s is specific to each device platform and it's important to know the differences:
Android: The device randomises the list of URLs received in the SCEP policy, and then works through the list until an accessible NDES server is found. The device then continues to use that same URL and server through the entire process. If the device can’t access any of the NDES servers, the process fails.
iOS/iPadOS: Intune randomises the URLs and provides a single URL to a device. If the device can’t access the NDES server, the SCEP request fails.
Windows: The list of NDES URLs is randomised and then passed to the Windows device, which then tries them in the order received, until one that's available is found. If the device can’t access any of the NDES servers, the process fails.
So when we say Load Balancing, we're essentially talking about Intune randomising the SCEP URL when pushed down to a device so it can use one out of X URLs specified in your SCEP profile. Cool!
Note: For iOS/iPadOS, it's important to note that Intune will send one of the SCEP URLs to the device. So if that URL is unreachable, SCEP will fail until the device tries the process again on its next policy cycle and uses the SCEP URL which is reachable.
Note: For macOS devices, I've tested adding two SCEP URLs into a macOS SCEP profile. I found that the device received two SCEP certificates. Microsoft does not provide documentation for how macOS devices can randomise SCEP URLs. Which indicates that it's natively not supported currently for macOS?
Requirements
So let's talk about if you wanted two NDES servers for SCEP availability.
To be able to add additional SCEP URLs into a SCEP profile. You'll obviously need additional SCEP infrastructure. So it would simply (i say simple, SCEP is never simple) be a case of configuring a second NDES Server with the additional configuration bits such as a Certificate Connector, Entra application proxy and a Enterprise Application for the NDES URL. From a NDES perspective, a common name for this topology is Active/Active, meaning devices could use either of the active NDES servers as part of the SCEP issuance process.
Certificates
As we're configuring an Active/Active topology, we simply use the same single (Server and Client Authentication) certificate for both of your NDES servers.
Note: Remember if you have a certificate that satisfies both requirements from the client and server certificate templates, you can use a single certificate.
Just make sure your security permissions are configured correctly on the certificate template to request the certificate on both of your NDES servers for IIS and revocation permissions for the certificate connector.
NDES Service Account
You can use the same NDES Service Account for both NDES servers to keep it simple.
Entra Application Proxy
If you're using Entra Application Proxy to publish your NDES URL externally. For availability, you'll want two Entra application proxy agents running for both of your NDES servers. I'd strongly recommend using Connector Groups in Entra ID to optimise your deployment. When using Connector Groups, you can assign your Entra App Proxy (used for SCEP) and NDES Enterprise Applications to a Connector Group. Microsoft recommend installing a separate Entra Application Proxy to the Default group as best practice also.
In a Active/Active NDES topology. You would add your two Entra App Proxies and two NDES Enterprise Applications to the same Connector Group.
Certificate Connectors
A certificate connector is required on both of your NDES servers. Again, mirror the set up configuration on both of the certificate connectors. Both connectors must be running the same version as best practice.
Architecture Recommendations
For an Active/Active SCEP topology. You have a couple of options and considerations for availability.
Option 1
You configure two active NDES servers and point both to a single SubCA. The challenge with this topology, is there is a single point of failure at the CA level but availability at the NDES level. Which might be ok for some organisations.
Note: I've used a macOS device in the diagram but appears not supported natively on macOS.
Option 2
To remove single points of failures. You could introduce a second SubCA. Just make sure you issue your SCEP certificate template on SubCA02 and configure the required certificate permissions for the second NDES server.
Final Thoughts
It goes without saying, adding additional infrastructure to support an Active/Active NDES topology is something that needs to be well thought out. Maintaining healthy NDES server/s is a task no one really likes doing, but if availability this is required for your organisation I hope this helps and adds some clarification.
Finally, caution is advised if you want to introduce load balancing to existing SCEP infrastructure and production SCEP profile in Intune. Changes to SCEP profiles can revoke existing certificates. So if you plan to test this, be sure to create testing SCEP profiles and avoid changing the production SCEP profile.