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.

What we will need

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:

• Enterprise Certificate Authority (running on Server 2008 R2 or later)
• ADDS / Domain controller (to create and apply GPO’s)
• ADFS v3 server
• ADFS WAP (proxy)

Enterprise Certificate Authority

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

• We need to create a new certificate template, based on the existing “User” template.
• Go to certsrv.msc or Certificate Management Console.
• Select Certificate Templates.
• Right click, and select Manage.
• This will open up all the certificate templates available.
• Scroll to the bottom and find the “User” template.
• Right click and select duplicate.
• This will open a new window where we need to configure the template settings.
• Name the template something intuitive, eg. “ADFS-MFA-User-Template-v1” or something as such.
• You can set the validity periods etc for as long as you like.
• I’ve left this at defaults, but for security concerns, this can be reduced as required.
• On the request handling page, leave the purpose set to Signature and encryption.
• However, change the minimum key size to something more secure like 4096.
• Unpick allow private key to be exported as this is for better security
• Select CSP Selection and check: Microsoft RSA SChannel Cryptographic Provider.
• Subject Name- nothing to change.
• Issuance Requirements- nothing to change.
• Superseded Templates- nothing to change.
• Extensions- Select application policies and remove all but “Client Authentication” by selecting edit, and remove the two options.
• Security- Add in the security group you are applying this to.
• Then add in the required permission: read, enrol and most importantly AUTO-ENROL.
• Server- nothing to change.
• Save and close the window.
• Back to certsrv main: right click somewhere in the right hand cert template area, and select New > Certificate Template to issue.
• When the new window opens, select and add in the template we’ve just created.

Active Directory Domain Services (ADDS)

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.

Group Policy

• Open GPMC.msc.
• We want to create a new group policy object, or you can add to an existing policy.
• Drill down the tree to Group Policy Objects.
• Right click and select New.
• Name the policy something like “ADFS-MFA-Certificate-AutoEnroll-Policy”
• This makes it easy to see what it is and what it does.
• Next we want to edit the policy, right click the policy and select Edit.
• This is purely a user configuration only, so dril down to the following:
• User Config > Policies > Windows Settings > Security Settings > Public Key Policies
• Open the Certificate Services Client - Auto-Enrolment
• Change the configuration model to Enabled.
• Tick the Renew expired certificates and the update certificates that use certificate templates and okay, close.
• Next we want to assign AD to enrol the user with a user cert.
• Open the Certificate Services Client - Certificate Enrolment Policy.
• Change the configuration model to Enabled.
• AD Enrolment will auto configure the details, which you can view by selecting properties in the window.
• Apply and close that and now you’re done creating the GPO.

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:

• Select the GPO that you’ve just created.
• Under the scope tab, we want to lock it down to a test security group, or even an individual user.
• Remove the Authenticated Users group.
• Add in a testing security group, for example create a group called “MFA-Test-Users”.
• Now we can apply that to the designated OU which will apply the policy.
• Depending on how you want to do this, this can be done to your testing OU, or on the entire domain as we’ve restricted the GPO.

ADFS configuration

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

• Go to ADFS Management Console in Administrative Tools.
• Expand the left hand tree.
• Firstly we want to enable “Certificate Authentication” as a MFA option.
• Go to Authentication Policies.
• Find and select the Global Settings > Select Edit
• We don’t want to enable or enforce anything other than allowing “Certificate Authentication” as an option.
• So in the bottom section check the tick box for “Certificate Authentication”.
• Apply and close the window.

ADFS Step 2

• Go to Authentication Policies.
• Go to Per Relaying Party Trust.
• This applies the policy only to authentication specific to Office 365.
• Select “Microsoft Office 365 Identity Platform”.
• Right click and select “Edit Custom Mulch-Factor Authentication”.
• Add a security group.
• Apply and close the window.

Testing and results

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:

• Log in, for example, to https://outlook.office365.com
• Enter in your organisational UPN or email alis
• When redirected basically to the ADFS WAP, finalise entering your credentials
• The site will refresh and you’ll be asked to select an SSL certificate for MFA
• Select the SSL and continue
• You’ll then be prompted for another input for credentials upon which you’ll be granted access to OWA

Sidebar - make this seamless to the user!

• In IE 11 go to Internet Options
• Select the Security tab
• Select Local Intranet
• Select Sites
• Select Advanced
• Where you can add in a web URL, enter in the ADFS WAP address for your organisation- for example fs.contoso.com
• Save and close
• Close IE and run through the authentication process to for example OWA again
• This time you’ll get pass through Windows credentials and the user will not be promoted to select the SSL
  • CAVEAT:
  • If you have multiple SSL’s based on the user template, you’ll get prompted to select the right one in order to authenticate
  • Make sure you don’t have multiple SSLs using the same user template installed on the users workstation

Lessons learned / Limitations / Summary

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.