In this blog post I’ll go into the configuration and implementation of Active Directory Federation Services v3.0 Multi-Factor Authentication (MFA). This is in line with a recent proof-of-concept project I conducted for a large customer in the FMCG sector. ADFSv3 MFA coupled with some new functionality that Microsoft is working on in Office 365, MFA in Office 2013 which will be covered by part 4 of this series, offers a fantastic solution to organisations wanting to leverage MFA by way of adhering to company policy or simply to further secure their users accessing Office 365 cloud services.
The good we secure for ourselves is precarious and uncertain until it is secured for all of us and incorporated into our common life
As explained in the previous posts in this series there are a number of ways you can implement MFA in your organisation. There is however one way that through testing I’ve found to have the most merit for organisation’s that are running a hybrid configuration with office 365 and want to leverage Office 2013’s new MFA functionality (part 4 will have the final bit of info for this piece).
ADFSv3 implemented MFA functionality over its predecessor that while the addition was interesting at the time, even I overlooked it and didn’t address it again until Microsoft announced MFA functionality coming to Office 2013. Moving forward lets configure the foundations to Office 2013’s ADAL MFA with the configuration of ADFSv3 MFA.
To achieve MFA with ADFSv3 there are several ‘moving parts’ or components required to implement MFA. The mechanism that we will be using is X5.09 SSL certificates from an internal Enterprise Certificate Authority (CA) running on Windows Server 2008 R2 (or Server 2012 R2 if you have that). Using SSL certificates is the standard / default token mechanism in ADFS v3 and although using the standard / default might sound like nothing too special, it is quite powerful.
The components necessary for this configuration are as follows:
An Enterprise CA is required to enrol users and devices to obtain an X.509 SSL for authentication. This SSL is the second factor after you enter your credentials. While I won’t go into the configuration of a CA in terms of deployment in your ADDS environment, below will outline the requirements needed to create a certificate template for our MFA purpose. For your reference, to deploy a ECA on Server 2008 R2, follow these steps or these steps.
Once you’ve deployed your ECA, we’ll need to configure a new User Certificate template- follow the bellow steps for this process:
Certificate Template Setup
Now that we’ve created a certificate template, there is a very nice means of enabling auto enrolment for domain joined workstations / users. We can leverage Group Policy Objects to configure auto enrolment and apply this policy to devices that can can communicate with the ECA. I won’t go into details on what’s required as this can be complex depending on your network, but lets assume there’s unrestricted communication between your ECA and your clients.
Now that we’ve setup a new GPO, we can apply this to an OU, a user or a group. For the purposes of this test, lets apply this GPO to a testing group:
We now have an enterprise certificate authority configured on our Windows Server 2008 R2 based domain. We have created a certificate template for users to enrol with and configured auto enrolment via group policy objects. The next step is to configure Active Directory Federation Services (ADFS) v3 to enforce the second factor of authentication on our test users, while maintaining the existing hybrid infrastructure to Office 365 untouched for non MFA users.
ADFS Step 1
ADFS Step 2
Working with a domain joined laptop, when accessing Office 365 services via your browser, preferably IE11, you’ll run through the authentication process as normal, until MFA kicks in on ADFS. How does this work? In a hybrid infrastructure environment Office 365 authentication will be diverted back to the ADFS WAP, then via ADFS to ADDS. Essentially meaning that Office 365 does not store users passwords, unless you use AD Premium that can sync password hash information.
The authentication process when hitting the ADFS servers will trigger the Certificate Authentication MFA rule and prompt the IE session to select a local user certificate to complete the log on process. I’ve tested with and found it run through as follows:
Sidebar - make this seamless to the user!
Thus far we can use SSL X.509 certificates to authenticate as a second factor of authentication to Office 365 OWA. This is handy if you want additional security and only use web clients. However, as its not the year 2020 and we don’t all live in a web browser window, Chromium users on their Chrome books are the exception, we use Outlook 20XX or Office 20XX thick clients. Enabling MFA will BREAK authentication for non MFA enabled clients. This means when they communicate with the ADFS servers nothing will happen and you’ll be watching a “unable to connect” message forever.
Enter in Active Directory Authentication Library or ADAL that enriches the thick client experience to allow for browser based or style authentication. In the final part of this series i’ll go over the latest news from Microsoft on MFA available in Office 2013! As a bonus exercise I’ll explain how to leverage Microsoft Enterprise Mobility Suite (EMS), namely Microsoft InTune to deploy these X.509 certificates to mobile devices allowing mobile clients (compatible with ADAL) to complete the MFA process.