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, 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.

Thank you,

Lucian

Category:
Intune
Tags:
, , ,

Join the conversation! 5 Comments

  1. It is great to have this option but in many use cases it will be…if NDES is down for my Intune devices, enrolment stops … so we balance an enrolment outage (which you hope would be brief, ie you have service restoration options) against the cost of additional NDES services, and not just the financial cost but complexity of configuration cost as well.

    Reply
  2. I would love to utilize this capability but we need it supported within Office 365 for Government Customers (G-3).

    Reply
  3. Is it possible to deploy multiple Intune NDES connectors to support multiple non-interconnected AD forests that share the same tenant. For e.g. we have domain.com in UK , domain-na.com in US , domain-ap.com in Australia and these three domains are part of the same org and the same tenant. Each domain has its own CA infrastructure which means Intune/NDES will need to register with multiple unique CA.

    Could you please let me know if this is possible

    Reply
    • Hi mate, thats likely possible. The only caveat is that you’ll need seperate policies in Intune that reference each specific NDES server. Apart from that, you should be good!

      Reply
      • Hi, have you tested the configuration with separate NDES profiles in Intune and multiple unique CA and got it working?

        This is the answer the I got from MS support:
        “Configuring two NDES profiles with two CAs is not supported in Intune, you can have a second NDES but they have to go to the same CA”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: