Updated Intune and NDES reference architecture, multiple NDES patterns

Now that Microsoft Intune ¹ is accessed via the Microsoft Azure ² portal, there has been a steady stream of weekly updates to the platform, improving things (for the most part) along the way. As of the end of November 2017 ³, there was announced an interesting new feature that should become part of most Intune environments.

The key feature of note is the new ability to have multiple Network Device Enrolment Servers (NDES) ⁴ configured for use with Intune.

The excerpt from the article confirming this:

NDES allows mobile devices running without domain credentials to obtain certificates based on the Simple Certificate Enrolment Protocol (SCEP)⁵. With this update, multiple NDES connectors are supported.

Why is that significant?

The existing integration of NDES with Intune meant that you had the ability to leverage SCEP via NDES to have Intune enrolled devices automatically request and receive certificates from your internal CA for use with such awesome things like WiFi profiles for 802.1X ⁶ authenticated WiFi with certificates.

With this update, you can now have multiple NDES servers in your environment. Again, why is that significant? NDES is limited in configuration to proxy certificate requests to a single intermediate certificate authority. So, with multiple NDES support, your standard CA architecture that would likely consist of multiple intermediary CA’s ⁷. Configuring your CA hierarchy, and examples of multiple intermediate and/or multiple issuing CA’s. ], can now be leveraged by Intune.

Here’s how we were doing this in the past with a single NDES server:

Updated reference architecture

As you can see we’re limited to NDES communicating with a single intermediary CA. This poses problems around designing a highly available, cloud first environment. You never want to have a single point of failure as public cloud providers don’t like you having a single instance anywhere. Azure for example has always recommended at least two instances in an availability set.

Note: Yes, you can now have premium storage with the same SLA as two instances in an availability set, but, you still have a single instance bottleneck. My opinion.

So, here’s a couple of examples of how you could deploy multiple NDES servers in your environment:

Deployment #1 - Active/Passive design, “higher availability” (not high availability)

To clarify the heading there- this isn’t a highly available solution. There’s a district difference which I won’t go into the nuances of high availability here, but, just for your information there would still a manual process involved to update SCEP profiles in Intune. This is because each SCEP profile would point to a single NDES on-premises namespace. Theres no option to direct to an alternate should the primary be offline. There’s also no options for load balancing either. Such is the way NDES is designed/built.

I consider it “higher” availability as you have multiple instances of NDES talking with the same intermediary CA and using the same certificate template. Should one NDES go offline, you would have a pretty speedy means to “fail over” to the alternate NDES server. But, like I mentioned earlier: it’s a manual process to change the SCEP connection in the Intune profile**.**

Deployment #2 - Active/Active with different CAs and/or different certificate templates

To deploy in an active/active pattern, this required that each NDES server leverage either a different intermediate CA and optionally a different certificate template type. This means that in Intune you can have more than one template type and both NDES servers servicing different profiles.

A good example is a specific requirement for an extremely short period of time for certificate expiry for one app/service in Intine, while also needing a very long expiry for another app/service. Even though Intune says you can set an expiry in the profile you create through Intune and the Azure portal, that does not hold true to the certificate template configuration on your CA. Therefore, you need multiple NDES servers and to leverage different certificate templates with different expiries.

Conclusion

The overall solution options and patterns and advancement of Intune makes for some good use cases and expands the possibilities of certificate based authentication.

What I would like to see next is the ability to see the template name in Intune that NDES is using to make it easier to follow the bouncing ball. Something that the Intune connector for NDES could pick up and forward to Intune maybe.