How to enable password + user certificate authentication in ADFS 3.0

posted for Kevin Saye

 Overview:

With the large usage of consumer and enterprise devices from inside and outside the organization, many customers are asking what Microsoft’s native MFA (Multi Factor Authentication) options are.

This blog discusses the how to architect, implement and troubleshoot: internal and external devices, password and/or certificates and users and/or groups to accomplish multi factor needs for ADFS aware applications.

What is Multi Factor Authentication and what does Microsoft offer?

While different people have different interpretation of MFA, most will agree it is generally view and accomplished by combining 2 different factors to identify the user.  The most common are what you know (password) and what you have (some artifact that cannot be in 2 places at once).

The most common deployments are password + hard token.  More cost effective are “soft” tokens, which are forms of software running on a device that cannot be cloned.

Microsoft offers 2 forms of “MFA” out of the box: certificates and software such as PhoneFactor.  ADFS 3.0 supports both for passive profile applications.

Architecting ADFS for MFA:

Out of the box, ADFS 3.0 can determine:

1. internal or external access networks

2. Registered or non-registered devices

3. User / group membership

4. Devices with and without user certificates

ADFS also has a pluggable ecosystem for third party solutions.  Microsoft maintains a “step by step” list of ADFS solutions here: http://technet.microsoft.com/en-us/library/adfs2-step-by-step-guides(v=WS.10).aspx.

Using the above 4 options we can construct enforcement policies such as:

1. You can access all “non-sensitive” applications without MFA

2. If not on the corporate network, you must have MFA to access a specific application

3. If not on the network and not on a registered device, you must have MFA

4. If not on the corporate network, you can’t use Outlook, but you can use ActiveSync

5. If a privileged user, must always have MFA

6. On a non-standard device, must always use MFA

7. If not accessing from in country locations (need: http://www.ip2location.com/ database) must use MFA

As you can see from above, we can combine many forms of policy and enforce it at ADFS.

Implementing a MFA restriction:

Implanting MFA takes 3 core steps:

1. Enable Certificates as an authentication method

2. Defining MFA at the Global Policy

3. Requiring MFA on a “Relying Party Trust” basis

4. [Optional] Defining Issuance Authorization Rules for each “Relying Party Trust”

Enable Certificates as an authentication method:

Configure AD FS -> Authentication Policies -> Edit Global Primary Authentication to allow Certificate Authentication on the location you desire.

Defining MFA at the Global Policy

Configure AD FS -> Authentication Policies -> Edit Global Multi Factor Authentication Policy to determine what other options qualifies as MFA.  Below you see I have selected certificates, which will qualify user certificates as MFA.

Requiring MFA on a “Relying Party Trust” basis

Configure AD FS -> Authentication Policies -> Per Relying Party Trust to determine when and to whom MFA is required.

[Optional] Defining Issuance Authorization Rules for each “Relying Party Trust”

To require a specific “Relying Party Trust” to use certificate type or to deny/allow based on device and or protocol, you can define an Issuance Authorization Rule to allow / disallow based on any claim you choose.  Example below says “must be cert” but the options are endless.

Troubleshooting / Logging MFA Access:

Enable Auditing in the Federation Services Properties.

When you user logs in with multiple factors, you will see:

If they log in with forms based authentication and a certificate you will see:

If they log in with integrated authentication:

If the user logs in from the intranet, you will see:

To see what the application is and if it came through a proxy: