A couple of weeks ago, I took interest in Azure Multi-factor Authentication (MFA) and wrote a series on 4Sysops, detailing the Azure MFA Service and the on-premises Multi-Factor Authentication Server:
- Azure Multi-Factor Authentication – Part 1: Introduction
- Azure Multi-Factor Authentication – Part 2: Components
- Azure Multi-Factor Authentication – Part 3: Configuring
- Azure Multi-Factor Authentication – Part 4: Portals
- Azure Multi-Factor Authentication – Part 5: Settings
- Azure Multi-Factor Authentication – Part 6: Onboarding
- Azure Multi-Factor Authentication – Part 7: Securing AD FS
- Azure Multi-Factor Authentication – Part 8: Delegating Administration
Since an organization asked me this week to look at their on-premises Multi-Factor Authentication implementation and the authentication methods they’re offering towards colleagues,
I wrote down the real-world pros and cons per authentication method. I’m sharing these here, so you, too, can make an educated choice for authentication methods for your colleagues and your organization(s).
Authentication methods
Per version 6.3.1, Microsoft’s on-premises Azure Multi-Factor Authentication Server supports the following seven authentication methods to complement usernames and passwords:
- Phone call
- Two-way SMS
- Two-way SMS with PIN
- One-way SMS
- One-way SMS with PIN
- OATH token
- Mobile App
Let’s look at each one with their advantages and disadvantages:
Phone call
This authentication method configures the Azure MFA Service to call a colleague, after he or she has successfully logged on with user name and password, by placing a phone call to the (mobile) phone number that is recorded in Active Directory (or possibly within the Azure MFA solution, when you want to deviate from that setup, because colleagues want or require privacy). The colleague presses # during the call to log on, or presses 0 # to report fraud.
| Advantages | Disadvantages |
| This method works with all types of phone numbers and phones (supporting DTMF). | Only phone numbers from the United States (country code + 1) can be configured as number that is used to place the phonecall. |
| This method works everywhere where the specified number is available. Any mobile device does not need to have a data connection. | Since any number is supported, colleagues may use a Lync, Skype or other soft phone on any device, defeating the purpose of multi-factor authentication in some cases. *
|
| The colleague doesn't need to enroll a phone number in advance, to enable this authentication method. This data can be made available via Active Directory, or if necessary, within the Microsoft Azure Multi-factor Authentication (MFA) solution. (when the colleague wishes to keep this number shielded) | The device used by the colleague should have a working telephony connection (connection, range, battery). (The PC needs to have a working data connection). |
| This method supports fraud detection based on the geographical location. The location or the colleague is compared to the location when the colleague previously authenticated. When it is not possible (within reason) to travel between the two locations in the time period between the two authentication attempts, then this is reported. (by default) | This method takes a colleague (bundle) credit for calling, when the colleague is abroad (roaming fees). |
| This method does not strictly require access to the on-premises Azure MFA User Portal or Mobile Portal for colleagues. | The method may be less reliable abroad. |
Since the phone call method relies heavily on DTMF and expects a superimposition of tones of 941 hertz (Hz) and 1209 hertz (Hz)n as a response, the authentication method may be circumvented or mislead by people using this signal in their voicemail greeting message or answer rule.
Two-way SMS
With this authentication method, a colleague, after he or she has successfully logged on with a user name and password, gets a SMS text message with an ever-changing code (a time-limited one-time Password). The colleague needs to send the OTP back to the number who sent it to hem/her within the timeout (60 seconds, by default).
| Advantages | Disadvantages |
| This method works everywhere where the specified number is available. Any mobile device does not need to have a data connection. | Only phone numbers from the United States (country code + 1) can be configured as number that is used to send and receive the SMS text message.
|
| The colleague doesn't need to enroll a phone number in advance, to enable this authentication method. This data can be made available via Active Directory, or if necessary, within the Microsoft Azure Multi-factor Authentication (MFA) solution. (when the colleague wishes to keep this number shielded)
|
This method only works with devices that are capable of receiving and sending SMS text messages. Typically, this requirement restricts this authentication to mobile phone numbers and mobile devices. |
| This method supports fraud detection based on the geographical location. The location or the colleague is compared to the location when the colleague previously authenticated. When it is not possible (within reason) to travel between the two locations in the time period between the two authentication attempts, then this is reported. (by default) | The mobile device that is used must have a working telephony connection (connection, range, battery). (The PC needs to have a working data connection). Any mobile device does not need to have a data connection. |
| This method requires a colleague’s (bundle) credit for sending the SMS text message. When the colleague is abroad roaming fees typically apply to sending back the SMS text message, but may also apply to receiving them.
|
|
| The method may be less reliable abroad.
|
|
| Intercepted OTPs may be used to impersonate the colleague when a malicious person also has knowledge of the user name and password. |
Two-way SMS with PIN
This authentication method is very similar to the previous authentication method.
A colleague, after he or she has successfully logged on with user name and password, once again receives a SMS message with ever-changing code. The colleague should however, send back the OTP together with his/her well-known (and fixed) PIN-code within the timeout (default 60 seconds).
This authentication method has the same advantages and disadvantages as two-way SMS, but with the additional advantage that intercepted SMS messages cannot be directly used for the second step for authentication.
However, this advantage is slightly offset by the increased support demand when colleagues have to memorize an auto-generated PIN. PIN management is available, but the colleague needs the on-premises Azure MFA User Portal for it.
One-way SMS
With this authentication method a colleague, after he or she has successfully logged on with a user name and password, gets a SMS text message with ever-changing code (time-limited one-time Password). The colleague, then needs to enter the code in the same authentication portal or application in which he or she has entered the user name and password.
| Advantages | Disadvantages |
| This method works everywhere where the specified number is available. Any mobile device does not need to have a data connection. | Only phone numbers from the United States (country code + 1) can be configured as number that is used to send and receive the SMS text message.
|
| The colleague doesn't need to enroll a phone number in advance, to enable this authentication method. This data can be made available via Active Directory, or if necessary, within the Microsoft Azure Multi-factor Authentication (MFA) solution. (when the colleague wishes to keep this number shielded) | This method only works with devices that are capable of receiving and sending SMS text messages. Typically, this requirement restricts this authentication to mobile phone numbers and mobile devices. |
| The mobile device that is used must have a working telephony connection (connection, range, battery). (The PC needs to have a working data connection). Any mobile device does not need to have a data connection.
|
|
| This authentication method is only usable for ADFS and RADIUS authentication and authentication towards the on-premises Azure MFA User Portal.
|
|
| The method may be less reliable abroad.
|
|
| Intercepted OTPs may be used to impersonate the colleague when a malicious person also has knowledge of the user name and password.
|
|
| This authentication method does not support the fraud detection built into Azure MFA.
|
|
| Roaming fees for receiving SMS text messages may apply abroad. |
One-way SMS with PIN
This authentication method is very similar to the previous authentication method. A colleague, after he/she has successfully logged on with user name and password, once again receives an SMS message with an OTP. The colleague should however, supply both the OTP and their well-known (and fixed) PIN in the same authentication portal or application in which he or she has entered the user name and password.
This authentication method has the same advantages and disadvantages as one-way SMS but with the additional advantage that intercepted SMS messages cannot be directly used for the second step for authentication. It is safer.
However, this advantage is slightly offset by the increased support demand when colleagues have to memorize an auto-generated PIN. PIN management is available, but the colleague needs the on-premises Azure MFA User Portal for it.
OATH token
With this authentication method a colleague has a hardware token or a software-based variant of a supported hardware token (Yubico, Feitian, Secutech, Vasco) in addition to knowledge of the user name and password for their account. This token creates a time-limited One-Time Password (OTP) every minute. While authenticating, the colleague supplies the code of the token or app in the authentication portal or the application after the user name and the password. (or, depending on the implementation, in the same field as the password, behind or in front of their password)
| Advantages | Disadvantages |
| This method does not rely on a working voice connection or data connection. It just works. (however, the device used for the application (for example, the PC or the iPad) needs a data connection…) | OATH tokens need to be provisioned by Azure MFA administrators with their serial number and other information, so the Azure MFA solution may reliably predict the OTPs generated by the token. You may encounter token drift challenges.
|
| This authentication method does not require a phone device when you use hardware tokens. The hardware token does not need replacement batteries during its technical lifetime.
|
The provision of tokens has logistical challenges around loss, replace, and theft scenarios. |
| Hardware tokens are incredibly resilient and tamperproof. | This authentication method is only usable for RADIUS and forms-based IIS authentication.
|
| This authentication method does not support the fraud detection built into Azure MFA.
|
|
| Microsoft has only recently added the ability to provision OATH tokens using *.csv files. |
Mobile App
For this authentication method a colleague installs in advance the Azure Authenticator or Phone Factor Multi-Factor Auth app on a compatible mobile device, in advance. The colleague then configures the app via the Azure MFA Mobile App Portal using a QR code (a square barcode for use on mobile devices).
After the colleague logs on successfully with his or her username and password in an application, he or she gets a notification from the app for the second authentication.
The colleague accepts or rejects (fraud message) the authentication request within the app.
| Advantages | Disadvantages |
| This method supports fraud detection based on the geographical location. The location or the colleague is compared to the location when the colleague previously authenticated. When it is not possible (within reason) to travel between the two locations in the time period between the two authentication attempts, then this is reported. (by default)
|
The colleague needs to have access to the Mobile App portal to allow the app to be configured for use. |
| This method works when the mobile device has no working voice connection,(connection, range). The PC and the mobile device must, however, both, have a working data connection, such as a (public) Wi-Fi connection.
|
Installation and configuration of the mobile app needs to have been performed, before the colleague may take advantage of this authentication method. |
| By using the Azure Authenticator app, Mobile Device Management (MDM) is within easy reach. This functionality is part of the app and can be enforced. | Not all mobile operating systems are supported by Microsoft. IOS (Apple-based devices), Android and Windows Phone are supported, but not, for example, BlackBerry. |
Concluding
The advantages and disadvantages per authentication method may limit your organization’s ability to use authentication methods for your multi-factor authentication project.
Choose your authentication methods wisely. If you intend to provide more than one authentication method to your colleagues, be sure to manage the Azure MFA implementation sufficiently and/or give your colleagues access to the User Portal, so they may change their preferences themselves.
Further reading
Multi-Factor Authentication – Microsoft Azure
Getting started with Windows Azure Multi-Factor Authentication
How often does a mobile user have to re-authenticate when using MFA? Is there a default timeout period?
An authentication request that requires MFA, will trigger MFA when reauthentication needs to take place.
In terms of AD FS, authentication is required per web session. Typically, this means you will be prompted for Multi-Factor Authentication when you close and reopen the browser, or when you hit the default security token expiration time-out of 480 minutes (whichever comes first).
For applications and services hosted through IIS, the default Authentication Time-out for Forms Authentication is 30 minutes. You can change the value, if need be.
For applications and services authenticating through RADIUS, you can set the session idle time-out. Here's more information on how to change it when you're using Microsoft Network Policies and Authorization.
i'am wondering the one-way OTP+PIN its not supported by IIS authentication, so now I have to configure an AD FS server to activate this method.
i could see that automated phone calls can be configured for US numbers, Will the other country will not be able to configure the feature ?
Hi Pradeep,
Currently, only US numbers are allowed to be configured as the Caller ID Phone number from the Azure Multi-Factor Authentication Portal. You can use any (working) international phone number your users would like to use as the number to be called for authentication.
Can I enable MFA for my Outlook Anywhere user base while using the on prem version of MFA?
Yes, you can.
This blogpost by Machmed Magdy explains it in detail.
However, please be aware that you can't use 1-way SMS in this scenario.
Hi Sander,
We are having 2 MFA servers in Master/Slave concept and 2 Portal servers(Installed in separate servers) and placed under load balancer. In web config of Portal server 1 we have pointed it to Master MFA and portal server 2 is pointed to slave. Will it be possible to add Slave server URL in web.config of portal server 1 so that the connection can reach slave in case of master goes down?
I believe we need to manually promote master for failover.
Even we promote the slave as master the portal server 1 is pointed to Master MFA so the traffic will try to reach master MFA which will lead to connection time-out, correct me if i am wrong. Please provide your suggestion as it will me very helpful for future deployment.
Note: MFA servers are not placed in load balancer.
Hi Pradeep,
For the on-premises Azure Multi-Factor Authentication (MFA) Server, all traffic for portals is web-based traffic: the traffic between the mobile device(s) and the mobile portal(s), the traffic between the user(s) and the user portal(s), and the traffic between the mobile and user portal(s) and the Web Service SDK.
It looks like you've placed the Web Service SDK on both the MFA Servers and that you've pointed the portals to the actual hostnames of the MFA Servers. Depending on your requirements, there are two solutions:
You could implement CNAME records in DNS that would point to the MFA Servers and point the portals to these DNS names instead of the actual hostnames. Using short TTLs, you can manually switch the server, while eliminating traffic between datacenters.
Again, with a different DNS name for the Web Service SDK, you could load-balance the portals between the two MFA Servers. That way, when one of the servers becomes unavailable, the portals would still point to a MFA Server address that would respond. In a scenario with multiple datacenters, this would cause some inter-datacenter traffic.
Hi Sander,
We are receiving intermittent server error when users are registering with One-way-sms, Other methods are working without any issues. The servers are placed under loadbalancer in Active/Standby mode. Please provide your inputs for this issue.
Note :server persistence (Sticky session) has been enabled in LB.
I know email verification is not technically considered multi-factor authentication when coupled with username and password, but, other products similar to your product do offer email and phone verification within their MFA product. Is there any plan for this to happen within your MFA solution? Currently I am facing the task of building out the email and phone verification as a separate solution from the MFA piece.
Hi Sander,
Any idea how to determine the response text while using post authentication method in MFA Server ( IIS Authentication)
We currently have MFA Server configured with RADIUS with our NetScaler. This is working great and user get MFA challenge when logging into Citrix.
Now we want to integrate MFA Server with our AD FS server, by installing the AD FS adapter.
Question I have is, do users get 2 MFA challenges ? One when logging into Citrix (radius) and when they go Office 365 via ADFS (with ADFS MFA Adapeter) do they get a second MFA challenge?
So does MFA Server issue one MFA token that can be used across RADIUS and ADFS (adapter) MFA authentication?
In your intended implementation, your Azure Multi-Factor Authentication Server will have two interfaces. Each of the interfaces incorporates separate caching and/or lifetime settings. These settings are not shared between interfaces.
When your colleagues access a RADIUS-interfaced application, system and/or service, they are prompted for multi-factor authentication. The RADIUS interface caches the authentication. When these colleagues access additional RADIUS-interfaced applications, systems and/or services, they are not prompted for multi-factor authentication. When these colleagues now access an AD FS-interfaced application, system and/or service, the colleagues are prompted for multi-factor authentication, again. Now AD FS issues a ticket with a lifetime. During this lifetime, When these colleagues access additional AD FS-interfaced applications, systems and/or services, they are not prompted for multi-factor authentication.
If you feel your colleagues are prompted for multi-factor authentication too often, implement Azure MFA Caching.
Sander,
Thanks for the explanation.
Only question i have is.
If we have MFA with ADFS server and 2 Relying Parties (RP1 and RP2) and first go to RP1 and do MFA and if we go to RP2 do we need to MFA again? And do we need to configure per RP mfa or do we need to configure Global MFA auth policy for this to work?
By default, AD FS issues claimtokens with a validity of 8 to 10 hours.
Regardless of the way you trigger multi-factor authentication through AD FS (either globally or per Relying Party Trust), once you've hit an application that requires multi-factor authentication, the associated claimtypes will be in the claimtoken for the validity period of the claimtoken. Therefore, you will not be prompted for a while.
Now, I do see organizations decrease their claimtoken validity periods to 1 hour, when implementing multi-factor authentication.
Hi Sander, you get an adfs token (cookie) that you are authenticated by adfs. This cookie gives you SSO to RP1 and RP2. As I understand MFA uses his own token/cookie. So i'm in doubt that when we have an adfs cookie and we hit RP2 this adfs cookie also works for MFA? So does the adfs cookie also applies to MFA?
Or do we need to configure MFA caching for this?
Typically, AD FS issues a server-wide WebSSO token and a per-RPT ADFS token.
When the WebSSO Token contains the information that you were prompted for multi-factor authentication and succeeded, then all Relying Party Trusts (RPTs) triggering Multi-Factor Authentication will not prompt for multi-factor authentication during the WebSSOLifeTime (By default 8 hours).
I want to thank you for your answer.
Im trying to find out what the per user MFA licensing unlocks in Azure AD. Does that give access to the Conditional Access and MFA Server sections of the AAD admin center? Does that license allow the use of third party security tokens(we have to use these for compliance)? Essentially, I am asking if the MFA licensing adds the same level of access/features as the AD Premium P2 licensing?
Hi Treyl,
As per my experience, of the three levels of access you've specified, the per-user Azure MFA licensing only provides the means to manage Azure MFA cloud-side as detailed here.
It doesn't provide Conditional Access, as this requires the Azure AD Premium P1 license.
It doesn't provide a way to configure 3rd party MFA , as this requires the Azure AD Premium P2 license.