posted for Kevin Saye
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.
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.
Out of the box, ADFS 3.0 can determine:
internal or external access networks
Registered or non-registered devices
User / group membership
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:
You can access all “non-sensitive” applications without MFA
If not on the corporate network, you must have MFA to access a specific application
If not on the network and not on a registered device, you must have MFA
If not on the corporate network, you can’t use Outlook, but you can use ActiveSync
If a privileged user, must always have MFA
On a non-standard device, must always use MFA
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.
Implanting MFA takes 3 core steps:
Enable Certificates as an authentication method
Defining MFA at the Global Policy
Requiring MFA on a “Relying Party Trust” basis
[Optional] Defining Issuance Authorization Rules for each “Relying Party Trust”
Configure AD FS -> Authentication Policies -> Edit Global Primary Authentication to allow Certificate Authentication on the location you desire.
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.
Configure AD FS -> Authentication Policies -> Per Relying Party Trust to determine when and to whom MFA is required.
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.
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: