Intune

On-prem NDES vs Microsoft Cloud PKI- Understanding the Similarities/Differences and Making the Smarter choice!

Microsoft announced Cloud PKI as an upcoming offering in August 2023. In March 2024 Cloud PKI become Generally Available for usage which will let us manages the full lifecycle of issued certificates for Intune managed device. Traditionally admins had an option of doing this via on-prem NDES server which was cumbersome to setup and troubleshoot. In this article we are going to do a comparison between this new offering of Microsoft(i.e. Cloud PKI) with the legacy methodology of cert deployment (i.e.On-prem NDES). We will analyze the differences based on each component and then try to reach to a conclusion.

Lets first start with a bit of background:

Background of using Certificates and its Benefits:

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. Certificates are the best phishing-resistant credentials that can be used to improve security.

Using a certificates for authentication has the below benefits over using username/password:

• Seamless and Automated authentication
• Removes the overhead for the user to enter the username/password manually
• More secured than passwords which are prone to leakage.

Basics of SCEP

• Stands for- Simple Certificate Enrollment Protocol is a 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.

Basics of on-prem NDES

• This is a conventional way of distributing SCEP certificates to devices.
• The devices can reachout to the NDES server which in turn goes to the Issuing CA and grabs the certificate on user’s behalf.
• The NDES server is binded with the CA hence both need to be in the same on-prem domain
• As devices reachout to the NDES server over the internet, the NDES needs to be publicly available
• To achieve this, the on-prem NDES is front ended by an App proxy which routes the traffic from internet to the NDES

Below is a block diagram overview of how on-prem NDES works with Intune

More details on the steps mentioned above can be found in the details blog below:

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

Basics of Cloud PKI

• Using Microsoft Cloud PKI organizations can simplify their certificate management with minimal effort.
• The overhead of managing and maintaining an on-prem CA is removed/reduced using the SaaS based certificate registration authority which is hosted in Azure on behalf of the customer
• As the service is hosted in Azure, its Highly Available and we don’t have to worry about its load balancing

Below is a block diagram overview of how Cloud PKI works with Intune:

Comparison:

Now lets do a comparison between On-prem NDES and Cloud PKI infrastructure on the basis of below 7 important criteria:

Now lets understand all the above criteria components in detail.

1-Manageability:

In case of on-prem NDES, as seen in the diagram above, there are many components on prem. Hence the responsibility of managing the same lies on the customer.

• The NDES server has to be patched and its database has to be maintained by server admins.
• The IIS in the NDES server along with the SSL certificate used or IIS needs to be maintained and renewed.
• The App Proxy component needs to be functional/updated by the admins.
• The Intune Connector needs to be updated(if auto update is not allowed) in timely fashion.
• The Issuing/Root CA needs to be maintained/patched and kept secure.

In case of Cloud PKI, most of the components are present in the Cloud and hence the overhead of managing them at the customer’s end is removed.

• The customer only has to manage his RootCA in case he goes with the BYOCA model. However this is not mandatory as he has the option of creating the Root CA in the cloud and removing his on-prem CA altogether.

2-Deployment:

• The deployment of on-prem NDES is comparatively complex
• The pre-reqs from network standpoint needs to be met which means whitelisting URLs in the firewall (to Intune service endpoints)
• NDES role needs to be installed and IIS needs to be setup along with Intune connector.
• Application proxy has to be installed for routing the traffic from internet to the NDES server
• Customer also has to consider load balancing the NDES server which means installing multiple NDES servers/Intune connectors and Application proxies.

Kindly refer to the below guide which explains how to setup the on-prem NDES for cert deployment via Intune

NDES and SCEP setup for Intune- A Complete Guide!

• On the other hand, Cloud PKI deployment is straightforward.
• We just have to create a Root/Issuing CA in the cloud along which the NDES is automatically created and we get the SCEP URL.
• The entire setup takes less than 5 min and we are good to go! There is no need to update any component once the setup has been done

3-Load balancing:

Our certificate deployment mechanism needs to be robust and Highly available. It should be able to balance the traffic in case there are lot of requests coming at a time.

• With on-prem NDES we have the option of deploying multiple NDES servers.
• With each NDES there is an App proxy associated. Hence we get 2 external URLs both of which are provided in the SCEP profile
• The device is provided with both the NDES urls and it choses either one of them randomly while requesting for certificate. If one of the URLs fail(is not accessible), the device reaches out to the 2nd URL. Hence load balancing is achieved.

Below video is a deep dive on how to achieve load balancing in on-prem NDES

• With Cloud PKI, the SCEP URI is hosted on the cloud which is already Highly available.
• Microsoft at the backend makes sure that the SCEP URI is load balanced and there are enough resources in the Scale Unit to cater to high traffic.
• Hence practically there is no need to have multiple SCEP URIs in the cloud. (However the customer always has the option of creating multiple Issuing CAs in the cloud and providing multiple cloud hosted SCEP URIs in the SCEP profile)

4-Supported Devices and Certificates:

This is an important aspect and we need to understand the kinds of devices which are supported and the kinds of certificate which can be issued by either.

• Using on-prem NDES provides us a lot of flexibility in terms of devices supported and the kind of certificate which can be issued.
• We can issue certificates to all kinds of devices in our domain irrespective of whether they are Intune managed or not. (For non-intune managed devices, Group Policy can be used for certificate distribution). We can also issue certificates to network devices.
• We can issue SSL or Client auth certificates via the NDES.

On the other hand the capability of issuing certificates via Cloud PKI is a little limited(as of now) but a lot of interesting and cool features are In development!

• We can only issue Client authentication certificate via Cloud PKI. SSL certificate distribution is under consideration and S/MIME is not supported.
• Currently the only mechanism of deploying the Cloud PKI certificates is via MDM channel (i.e. using Intune). There is no option to export a client certificate from the portal and deploy it to devices via some other means to non-intune managed devices, meaning using Cloud PKI we can issue certificates to Intune Managed devices only.
• Also Online Certificate Status Protocol (OCSP) is not included in Microsoft’s new Cloud PKI and it doesn’t support Smartcards, or YubiKeys. Also Elliptic Curve (EC) keys are not currently supported in Cloud PKI.

5-Control over certificate attributes:

• In case of on-prem NDES we have a very granular control over the attributes of the certificate which would be issued.
• We can specify the name of the NDES template using which the cert will be created.
• If the admin wants to change the configuration of the cert , he can easily change the Certificate Template name in the registry for it to take effect

On the other hand the options in Cloud PKI are a little limited and less granular

• As of now, we don’t have an option of creating a Certificate Template in the Issuing CA and specifying a Template name which should be used to supply the certificates.

6-Cost:

Eventually everything comes down to cost and value for money.! Customers agree to pay for products if they get a good return in terms of feature.

• With on-prem NDES there is no direct cost involved.
• We have to spin up a NDES server which can be virtual, having minimal resources. The NDES server can host other applications as well- hence distributing the cost/minimizing it.
• The other components like hosting IIS, AAD Connect and Intune Connector doesn’t have any cost associated with it.

On the other hand with Cloud PKI- given that its a paid offering, there is a cost involved and hence its a factor to be considered.

• The retail pricing for Cloud PKI license is 2$/user/month. However this is not the final price.Please reachout to your Microsoft Business desk/Account team and they will help you in getting the best possible deal at a discounted price.! Microsoft offers discounts on the retail pricing which makes this even more affordable!
• If the customer gets the license for entire Intune suite which is charged at 10$/user/month and it includes 8+ different products/capabilities, thus bringing down the cost per feature.

7-Troubleshooting:

In case things goes wrong, we have to end up troubleshooting the issue. This varies depending upon which option we chose.

• In case of on-prem NDES there are many components(like the NDES server, App proxy, Connector, IIS) which are hosted on prem. Which means there is a possibility of either of these malfunctioning at any point. Hence the troubleshooting would involve checking logs at all these levels.
• This in my opinion is a double edged sword- Having more troubleshooting options means we have to work harder in finding an issue by checking various logs. However it also means that we have more visibility into the backend flow and where things are failing. Also remediating them by analyzing the logs is in our hands.

The below blog explains the various logs we can check while certificate delivery using on-prem NDES.

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

On the other hand with Cloud PKI the troubleshooting that has to be performed by us is limited.

• The troubleshooting that we can do from Client(end device side) remains the same in both the cases, like making sure the device is getting the SCEP profile/checking the event viewer logs/MDM trace etc
• We can also check if the SCEP URI is accessible but that’s pretty much it.
• Since most of the components are hosted in Azure, customers don’t have to worry about troubleshooting any issues once the setup is in place and working. If there are any service side issues, Microsoft would troubleshoot and remiditate the same.
• On the flip side, the customer has less visibility into the backend working. They cannot see how each step of validation in NDES is happening/if the end device successfully reached to the NDES or not etc. as they cannot access the service side logs.

Making the Right Choice(My 2 cents)

Cloud PKI is a welcome addition to the Intune suite by Microsoft. It has several advantages over maintaining an on-prem NDES/PKI infrastructure. There are minor capability gaps however a lot of features capabilities are under development and would be released soon!

I believe customers should definitely consider this solution which would be another big step towards going cloud native and reducing the on-prem footprint. If they wish to have both- they can always use Cloud PKI with BYOCA solution (where the root CA is on-prem and the Issuing CA is hosted in the cloud). This way they can get best of both the worlds!

• To some the 2$ pricing might look a little steep. But remember that this is not the final pricing and the Microsoft Business Desk/your Account team can help in getting good discounts. Also if you get the entire suite (which contains 8+ product capabilities) the cost comes down significantly.

Lastly i have seen lot of blogs online suggesting that Cloud PKI licensing is another way for Microsoft to make extra money which is not fair. In my opinion we need to remember that Cloud PKI is a offering which makes PKI management easier, faster, more reliable and reduces the on-prem dependency, which obviously comes with a licensing cost. The customers always have the option of either going with the Cloud offering or sticking to on-prem NDES solution which is free. Hence we should not look at this as a forceful move rather this is a direction provided by Microsoft to go fully cloud which is the eventual way forward!