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.
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.
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.
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.
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:
If you get an error 503 or “Service unavailable” its likely that the application pool in IIS has stopped. Otherwise review the eventvwr for more information.
Server SSL certificate
We'll need to also add Binding on port 49443 - this is for traffic relating to SSL requests through the NDES server
Start > Run > mmc
File > Add or Remove Snap-ins
Select Local Computer
Find the web server SSL assigned to SCCM.domain.local
Export the SSL including the private key
COPY THIS TO NDES
Install on your NDES server in Local Computer > Personal > Certificates
Check local server sharing
Copy your internal CA's root CA onto your SCCM server- leave it in C:\SSL\ for example
Deploy the Certificate Registration Point (CRP) SCCM role
Ideally we now would restart SCCM CRP server
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:
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.
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:
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.
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.
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.