How to: Multi-Factor Authentication, Office 365, ADFS v3.0 and SSLs via InTune - Part 5

A series on certificate based authentication

I know what you're thinking: does Lucian really have to create another part in this long MFA series? In short, probably not, but I'll have saved your index finger the thousands of years or scrolling you would have done to read the entire brain dump in a one page post.

So to explain this ‘epilogue’, if you will, on MFA, using X.509 SSLs for your second factor of authentication is a powerful means to automate and manage a process for your mobile and external users. This blog post will explain how to leverage an on-premises Microsoft System Centre Configuration Manager (SCCM) 2012 R2 deployment linked to Microsoft InTune to deliver SSL's to mobile and external devices to use in MFA.

InTune, SCCM and Automated Certificate Enrolment on Mobile's

Below is a detailed outline of all that is required to use Microsoft InTune and an on-premises SCCM server, along with a few other moving parts to implement a complete MFA solution. I'm going to assume part of this is already in-place in your environment, but if you'd like any feedback or support, feel free to ask in the comments below.

First things first: lets start with a detailed diagram of what we want to achieve:



Again these components I will assume are already configured and up and running in your environment. For the purposes of this blog series I won't go into detail on how to deploy ADFS, and ADFS WAP or an Enterprise Certificate Authority.

Overview of the communication workflow

Before we start


I'm also going to assume there is an existing Office 365 hybrid deployment with ADFS and Directory Sync already in-place. With that said- the following network changes are required:


There's scarce references online to TCP49443. However, I've completed Fiddler traces and found that the challenge process from ADFS does traverse this port so its important to configure. I've also seen some references to TCP 80 inbound from mobile clients before they switch to TCP 443 in the connection process, so it might worth allowing and port forwarding TCP80.


Your trusted network or LAN should allow all ports between servers. Your ADFS, DirSync, NDES, SCCM, CA, ADDS servers all need to talk on all available ports.

Enterprise Certificate Authority

Lets start with your CA where we'll generate a new SSL template to use for user authentication.

For later: Export your CA's root SSL certificate which we'll need on both SCCM and NDES.

Network Device Enrolment Server (NDES)

We're going to deploy a vanilla Windows Server 2012 R2 server to host the NDES role. Deploy that in your environment and follow the steps bellow to configure NDES:


System Server Configuration Manager 2012 R2


Testing and install confirmation

CRP configuration continued



You'll find that once you run the PolicyManagerSetup, the .exe won't let you check any settings, without uninstalling and reinstalling the SCCM module You can however check the settings n the registry in the following key: HKLM > Software > Microsoft > Cryptography > MSCEP > Modules > NDESPolicy All the items are string values and can be view and changed if need be Note: a restart is required if you change any of these string values


The final piece is to configure the two SCCM policies relating to SSL deployment. The first is the ROOT CA policy which deploys the ROOT CA to the trusted certificates store, while the second policy is the user certificate policy we enroll through NDES.

*Update 2015-04-20* - Added 3 examples for different platforms:

Windows 8, 8.1, RT example:


iOS example:


Android example:


Select the platform you want to deploy this to, in my case I selected all

Assign these two new policies to the desired DEVICE COLLECTION. This is important as assigning to a user collection will result in the SSL's not being deployed, in my experience.

User acceptance testing

The UAT process that I've completed for example purposes is a Windows 8.1 Pro VM. This is a vanilla VM with only Windows updates applied to it, no other software or configuration completed.


Next to allow InTune and SCCM to manage the device, lets turn on Device Management:

In the meantime we can enable MFA on your user account:

Finally, lets enable MFA on the client by changing some registry keys:

To enable modern authentication:
1 HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL REG_DWORD 1
2 HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version REG_DWORD 1
3 HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Debug\TCOTrace REG_DWORD 3
To disable modern authentication:
1 HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL REG_DWORD 0
2 HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version REG_DWORD 1

Sidebar - Certificate Authority - I just wanted to mention that a successful certificate deployment can be seen on your CA in certsrv. If you go to Issued Certificates, you'll see that “svc_ndes” will be requesting SSLs with your “MFA-Mobility-v1”. Ideally you would want something more secure that a service account doing this, though at this stage I've not gone into it enough to check what other options there are to strengthen this process further.

Final words

After all is said and done and you've gone though the Lord of the Rings like journey from start to finish, you will be able to complete a MFA request with your SSLs on your device, authenticating to ADFS and allowing access to Office 365 services.

Microsoft Office Apps and Services Multi-Factor Authentication How to Active Directory Federation Services

Discussion 💬

Follow or start a discussion for this blog (How to: Multi-Factor Authentication, Office 365, ADFS v3.0 and SSLs via InTune - Part 5) on Twitter. If you're after something more in depth, or want to ask me an expanded question: raise an issue in my open GitHub AMA repo.