Today many organizations use on-premises multi-factor authentication systems to protect mission critical data in their file servers and their critical Line of Business (LOB) applications. As these workloads (or parts of them) move to the cloud (at least in a hybrid manner, see whitepaper Enabling Hybrid Cloud today with Microsoft Technologies), they need an effective and easy-to-use solution in the Cloud for protecting:
Passwords in use that are often not enough strong and the consumerization of IT has only even increased the scope of vulnerability.
Multi-factor authentication is becoming the new standard for securing access and how businesses ensure trust in a multi-device, mobile, cloud world.
Note Not only do the above organizations need multi-factor authentication for their employees, but many of them are also increasingly building cloud-based applications for consumers and citizens that require multi-factor authentication to ensure a high level of security. These B2C scenarios are growing rapidly and require easy end-user technology.
Furthermore, multi-factor authentication is no longer optional for many of the above organizations; many are required by various governing or regulatory agencies to strongly authenticate access to sensitive data and applications across a broad range of industries.
In such a landscape, phone-based authentication constitutes a very compelling technical approach for multi-factor authentication as it provides enhanced security for businesses and consumers in a convenient form factor that the user already has: their phone.
Azure Multi-Factor Authentication (Azure MFA) addresses user demand for a simple sign-in process while also helping address the organization's security and compliance standards. The service offers enhanced protection from malware threats, and real-time alerts notify your IT department of potentially compromised account credentials.
Azure MFA helps to deliver strong security via a range of easy authentication options. Thus, in addition to entering a username and password during sign in, enabled users are also required to authenticate with a mobile app on their mobile device or via an automated phone call or a text message, allowing these users to choose the method that works best for them. Consequently, in order for an attacker to gain access to a user's account, they would need to know the user's login credentials AND be in possession of the user's phone. Furthermore, support for the above multiple methods enables to support more scenarios such as offline (no carrier) scenarios.
Azure MFA exists in different flavors:
Whilst Azure MFA is powered by a cloud service, the stand-alone version and well as the one included in Azure AD Premium support on-premises, cloud, and hybrid scenarios. The following solutions are indeed available for use with Azure MFA:
Users will be prompted to set up additional verification the next time they sign in.
Note For more information, see the Microsoft TechNet article Adding Multi-Factor Authentication to Azure Active Directory.
Multi-Factor Authentication Server allows the administrator integrate with IIS authentication to secure Microsoft IIS web applications, RADIUS authentication, LDAP authentication, and Windows authentication.
Multi-Factor Authentication Server can be run on-premises on your existing hardware - as a virtual machine (VM) or not -, or in the cloud for instance as an Azure Virtual Machine. Multiple, redundant servers can be configured for high availability and fail-over.
Note For more information, see Microsoft TechNet article Enabling Multi-Factor Authentication for On-Premises Applications and Windows Server.
Note For more information, see Microsoft TechNet article Building Multi-Factor Authentication into Custom Apps (SDK).
As an addition to the white-paper Active Directory from on-premises to the Cloud, this paper focusses on the first above solution and, as such, aims at describing how to enable, configure and use Azure MFA for Azure AD, so that Azure AD users will be prompted to set up additional verification the next time they sign in.
To enable Azure MFA, organizations start by signing up for Azure, if they have not done so already. From the Azure management portal, they create a MFA provider, linking it to an Azure AD directory tenant in our context. Organizations can then enable users in that directory tenant for multi-factor authentication. Organizations can then select the Manage option to access additional Multi-Factor Authentication configuration options and reporting.
Built on existing Microsoft documentation and knowledge base articles, this document covers all of the above steps and provide additional guidance if any.
Note For additional information, see Microsoft TechNet article Using Multi-Factor Authentication with Azure AD.
The aforementioned steps not only apply for cloud users in Azure AD but also for federated users for the following two specific scenarios:
Note This corresponds to the directory synchronization with single sign-on (SSO) scenario to provide users with the most seamless authentication experience as they access Microsoft cloud services and/or other cloud-based applications while logged on to the corporate network. For additional information, see Microsoft TechNet article Directory Sync with Single Sign-On Scenario.
Important note This applies only to browser-based applications.
Multi-Factor Authentication is not supported by non-browser applications, excepted with Office 365 ProPlus/Office 2013 applications with modern authentication enabled. Modern authentication is available to any customer running the March 2015 or later update for Office 2013 but is disabled by default. For additional information on these update, see the blog post Office 2013 updated authentication enabling Multi-Factor Authentication and SAML identity providers.
For the other browser-based applications, an app password must be created. An app password is a password that allows to by-pass the Multi-Factor Authentication (more information on this later in this document). Eventually, app passwords are only available to users that do not have administrative privileges.
-or-
As a result of the on-premises authentication, Active Directory Federation Services (AD FS) or other supported third-party security token services (STS) must send a claim of type "http://schemas.microsoft.com/claims/authnmethodsreferences" with the value "http://schemas.microsoft.com/claims/multipleauthn". Thus, the organizational id will not trigger Azure MFA for the user because it has already received the above so-called MFA claim from on-premises identity infrastructure.
Note For additional information, see Microsoft TechNet article Azure Multi-Factor Authentication options for Federated Users.
This document doesn't discuss how to configure Azure MFA for federated identities along with the Multi-Factor Authentication Server on-premises to secure both cloud and on-premises resources.
This integration scenario implies to configure the Multi-Factor Authentication Server - available for download on the Multi-Factor Authentication management portal - to work with Active Directory Federation Services (AD FS) or other supported on-premises third-party security token services (STS) so that Multi-Factor Authentication is triggered on-premises (or in a Infrastructure-as-a-Service (IaaS) cloud environment such as Azure as per Office 365 Adapter: Deploying Office 365 Single Sign-On using Azure whitepaper.
Note Such an integration is natively supported by AD FS but differs in terms of integration path depending on the version of AD FS. More specifically, for additional information on using the Multi-Factor Authentication Server with AD FS 2.x, see Microsoft TechNet article Using Multi-Factor Authentication with Active Directory Federation Services. For information on using Multi-Factor Authentication Server with AD FS for Windows Server 2012 R2, see Microsoft TechNet article Walkthrough Guide: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.
For the other supported on-premises third-party security token services (STS), the aforementioned Software Development Kit (SDK) is available for use with custom applications and directories.
Beyond this integration, this scenario additionally implies directory synchronization between the on-premises identity infrastructure (based on Windows Server Active Directory (AD) or on other (LDAP-based) directories) and the Multi-Factor Authentication Server to streamline user management and automated provisioning.
This also supposes to deploy:
Note For additional information, see Microsoft TechNet article Installing the Azure Multi-Factor Authentication Users Portal.
Note For additional information, see Microsoft TechNet article
Deploying the Azure Multi-Factor Authentication Server Mobile App Web Service.
With all of the above, the enrolled users can use their on-premises corporate credentials (user name and password) and their existing phone for additional authentication to access Azure AD and any cloud-based application that is integrated into Azure AD as well as their existing on-premises resources.
This scenario is no longer discussed as part of this document. It is rather covered in detail in the whitepaper Leverage Azure Multi-Factor Authentication Server for Azure AD single sign-on with AD FS.
As already mentioned, the Multi-Factor Authentication Server also works out-of-the-box with a wide range of on-premises applications, such as remote access VPNs, web applications, virtual desktops, single sign-on systems and much more. Those scenarios are not discussed in this document either.
To cover the aforementioned objectives, this document is organized by themes which are covered in the following sections:
This document is intended for system architects and IT professionals who are interested in understanding how to enable and configure Azure MFA for Azure AD users to help secure access the Azure management portal, Microsoft services like Office 365, Intune, and Dynamics CRM Online, as well as any cloud-based applications that use/integrate with Azure AD.
Multi-factor authentication, also commonly referred to as two-factor authentication, is a best practice for securing user access. It works by requiring any two or more of the following authentication factor:
After presentation, each required factor must be verified and validated for authentication to occur. Multi-factor authentication is stronger when factors are verified using distinct (or out-of-band) channels.
The security of multi-factor authentication lies in its layered approach. Compromising multiple authentication factors presents a significant challenge for attackers. Even if an attacker manages to learn the user's password, it is useless without also having possession of the trusted device. On the other hand, if the user happens to lose the device, the finder of that device won't be able to use it unless he or she also knows the user's password.
The most common multi-factor methods include hardware tokens like RSA SecurID, certificates, smartcards, and increasingly phone-based authentication methods, which leverage the user's telephone as the trusted device for the second factor of authentication.
As already introduced, Azure MFA is, as its name indicates, an Azure service that helps safeguard access to data and applications by strengthening traditional sign-in approaches. In terms of applications, the service supports both cloud applications that use or integrate with Azure AD as well as on-premises applications using the Multi-Factor Authentication Server.
Generally available and fully backed by a Service Level Agreement (SLA), the service is trusted by thousands of enterprise customers, healthcare organizations, banking and financial services companies, as well as government agencies at the state, local and federal level. The service authenticates millions of logins and financial transactions around the globe each month. It is battle-tested and enterprise-ready.
Note Azure MFA is powered by the market-leading PhoneFactor service acquired by Microsoft in October 2012. With some minor exceptions, all of the features and capabilities offered by PhoneFactor are included in the Multi-Factor Authentication service, including the on-premises PhoneFactor Agent, which has been renamed the Multi-Factor Authentication Server.
Traditionally, strong authentication has been time consuming to deploy and has required significant ongoing resources to support. And it was a hassle for users who had to carry extra devices or whose access was limited to computers with smartcard readers or that had certificates installed.
With Azure MFA and the user's telephone as the trusted device for a second or an additional factor of authentication:
Note For additional information, see Microsoft TechNet article Azure Multi-Factor Authentication.
Azure MFA offers the additional security you demand using the phones your users already carry.
Multiple phone-based authentication methods are available, allowing users to choose the one that works best for them, and, support for multiple methods ensures additional authentication is always available:
As illustrated later in this document, users download the free app Multi-Factor Auth from the device store and activate it using a code provided during set up. When the user signs in, a notification is pushed to the app on their mobile device. The user taps to approve or deny the authentication request. (Cell or Wi-Fi access is required for installing and setting up the app.)
Once the app is installed, it can operate in the following two different modes:
Simply view the notification and if it is legitimate select Authenticate. Otherwise you may choose Deny or choose to Deny and Report the Fraud.
Note It's comparable to software or soft tokens solutions offered by vendors like RSA and Gemalto.
Note Initiative for Open Authentication (OATH) is an industry-wide collaboration to develop an open reference architecture using open standards to promote the adoption of strong authentication across all networks. The cornerstone of the related specifications are the HMAC-based One-Time Password (HOTP) algorithm as per RFC 4226 and Time-Based One-Time Password (TOTP) algorithm as per RFC 6238. For additional information, visit the OATH web site.
Important note OATH shouldn't be confused with the OAuth, which is an open standard for authorization. OAuth2 as per RFC 6749 and RFC 6750 is the current version of the protocol. It focusses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, and mobile phones.
The users always sign in with their existing username and password. After the user's credentials are verified, Multi-Factor Authentication is initiated using the above methods depending on the user's enrollment.
The Multi-Factor Authentication service offers strong protection against even the most sophisticated attacks:
Azure Multi-Factor Authentication enables compliance with regulatory requirements for multi-factor authentication such as the following ones to name of few:
On-demand and scheduled reports are available for auditing of authentication requests.
This section illustrates how to enable the Multi-Factor Authentication for Azure AD. The steps below assumes you already have an Azure subscription with your Active AD directory tenants.
If you do not have an Azure subscription or are using Office 365 and have not signed up for an Azure subscription, you will need to do so prior to enabling multi-factor authentication for your user accounts.
You can sign-up for your free Azure AD tenant and trial Azure account by following the link https://account.windowsazure.com/signup?offer=MS-AZR-0044P.
If you are already a paid Microsoft Office 365 customer, one simple way to add an Azure subscription to your Office 365 account consists in signing up for the $0 subscription by following the link https://account.windowsazure.com/PremiumOffer/Index?offer=MS-AZR-0110P&whr=azure.com/.
If you have a trial
Microsoft Office 365 subscription, you can instead navigate to the Azure Signup page at https://account.windowsazure.com/SignUp with your Office 365 global administrator account.
Note You can log into the Office 365 administrator portal and go to the Azure Signup page or go directly to the signup page, select sign in with an organizational account and log in with your Office 365 global administrator credentials.
Once you have completed your trial tenant signup, you will be redirected to the Azure subscription management page
and can proceed to the Azure management portal by clicking Portal at the top right corner of your screen.
Before (cloud-based) multi-factor authentication can be enabled for users in the Azure AD directory tenant, a Multi-Factor Authentication provider must be created and linked to the directory tenant.
Important note Use of Multi-Factor Authentication is free for Azure AD global administrators when the corresponding Azure AD directory tenant has not been provisioned with Multi-Factor Authentication for directory users. When using for free to secure administrator access, advanced configuration options and reporting are not available. However, if you wish to extend multi-factor authentication to all of your users and/or want to your global administrators to leverage the advanced configuration options and reporting via the management portal, then you must purchase and configure a Multi-Factor Authentication provider. Finally, you can only have one Multi-Factor Authentication provider per tenant.
Note For additional information, see Microsoft TechNet article Administering Azure Multi-Factor Authentication Providers.
To add a Multi-Factor Authentication provider to an Azure AD (Premium) directory tenant, proceed with the following steps:
Important note You need to sign in with an organizational account to manage Multi-Factor Authentication. You cannot manage Multi-Factor Authentication with a Microsoft account.
Note For additional information on usage model, see Multi-Factor Authentication Pricing Details.
Once the Multi-Factor Authentication provider has been created, you need to enable multi-factor authentication on your users. If the Multi-Factor Authentication provider is later deleted, users will default back to single-factor authentication, i.e. passwords.
Note For additional information, see Microsoft TechNet article Enable a Multi-Factor Authentication for a user account.
To create new MFA enabled users, proceed with the following steps:
A notification pops ups.
Important note As previously noticed,
non-browser apps do not have built-in support for interactive prompts that are required by Multi-Factor Authentication. More specifically, in the context of Office 365, this applies to clients such as Outlook, Lync, Word, Excel, PowerPoint, PowerShell, SkyDrive Pro, Exchange ActiveSync (EAS), POP, and IMAP clients, etc.
When you enable Multi-Factor Authentication for such an Office 365 user account, they will be able to use non-browser apps, such as Outlook, Lync, etc., until they have completed multi-factor enrollment or their account status is set to Enforced. In order to continue to use non-browser apps, they must create app passwords for these apps. An app password, is a password that allows them to by-pass the Multi-Factor Authentication and continue to use their non-browser apps. It is advised that you send them an email that informs them how they can use their non-browser apps and consequently not be locked out.
If you had users created prior to enabling Multi-Factor Authentication, you will need to enable Multi-Factor Authentication for these users manually.
To enable existing users for Multi-Factor Authentication, proceed with the following steps:
This page allows you to enable and disable Multi-Factor Authentication for users in your directory tenant. This also allows you to force users to provide their contact methods again, and reset application password.
Important note As previously noticed, non-browser apps do not have built-in support for interactive prompts that are required by Multi-Factor Authentication. More specifically, in the context of Office 365, this applies to clients such as Outlook, Lync, Word, Excel, PowerPoint, PowerShell, SkyDrive Pro, Exchange ActiveSync (EAS), POP, and IMAP clients, etc.
When you enable Multi-Factor Authentication for such an Office 365 user account, they will be able to use non-browser apps, such as Outlook, Lync, etc., until they have completed multi-factor enrollment or their account status is set to Enforced. In order to continue to use non-browser apps, they must create app passwords for these apps. An app password, is a password that allows them to by-pass the Multi-Factor Authentication and continue to use their non-browser apps. It is advised that you send them an email that informs them how they can use their non-browser apps and consequently not be locked out.
To allow Office 365 users the ability to create app passwords to enable non-browser apps access, proceed with the following steps:
Conversely, if you do not wish to enable non-browser apps access with app passwords for Multi-Factor Authentication-enabled users, this functionality can be disabled by selecting Do not allow use of app passwords (users enabled for multi-factor auth will not be able to sign in to non-browser applications) in the above step 2.
Once you have enabled the user account(s) for multi-factor authentication, the user(s) can sign-in and complete the enrollment process. This section walks you through the initial logon process, illustrating how to complete the enrollment process of Multi-Factor Authentication for a user.
Note For additional information, see Microsoft TechNet article Signing in for the first time using Azure Multi-Factor Authentication.
To complete the enrollment process of the Multi-Factor Authentication, proceed with the following steps:
Note After the enrollment process has been completed, users can setup app passwords for non-browser apps (such as Outlook, Lync, etc.). We illustrate this capability later in this document.
At this stage,
you have now been verified into Azure AD.
To login with a configured account, proceed with the following steps:
Note While your preferred authentication method is the default, you can also choose to authenticate using any of the other authentication methods you have configured by selecting the Other authentication methods link.
This section illustrates how to add the Multi-Factor Authentication mobile app to authenticate against Azure AD with the previously configured Multi-Factor Authentication provider.
To configure the Multi-Factor Authentication mobile application, proceed with the following steps:
Note The interface will differ slightly between mobile OS apps.
Note You have now activated your mobile application for Multi-Factor Authentication.
Note In order to use a new Multi-Factor Authentication process, you must first verify the process is working.
Note There are other options available here. These options will be covered later in this document.
To login with the Multi-Factor Authentication mobile app, proceed with the following steps:
To manage the user settings, proceed with the following steps:
This will brings up two options on the right: Enable and Manage user settings.
To manage the contact information and set preferred and backup contact methods from an end-user perspective, proceed with the following steps:
You can add or update your contact information and set preferred and backup contact methods using this page.
Note You will only be able to edit your office phone number using this page if you are a global or user admin and your account is not being synchronized with the Azure AD directory tenant.
App passwords can initially be created when you complete the enrollment process. This said, and as previously mentioned, users can create app passwords later on if they have already completed the enrollment process but have not setup app passwords:
To add app passwords after having completed the enrollment process, proceed with the following steps:
You should see your app password on the app passwords page.
Note For additional information, see Microsoft TechNet article Managing your Azure Multi-Factor Authentication User Settings.
The following section describes the advanced settings that are available for configuration and use with Azure MFA.
Note For additional information, see Microsoft TechNet article Configuring Advanced Multi-Factor Authentication Settings.
When the user gets an authentication request from Multi-Factor Authentication when they are not signing in, access is denied if the user does not approve the request when prompted or cannot be reached for authentication. However, as aforementioned, because the user's credentials are verified before Multi-Factor Authentication is triggered, this is an indication that the user's password has been compromised. The user has the option to submit a fraud alert during the authentication request.
The Fraud Alert feature prevents further login attempts and allows a user to notify their IT department if someone attempts to sign in using their credentials. The IT department should in turn work with the user to reset the user's password.
The Fraud Alert feature is available with the phone call, text message, and Multi-Factor Authentication mobile app push authentication options.
To send a fraudulent report, proceed with the following steps:
Note When a user receives a notification for logon that they did not initiate, they have the opportunity to block the login attempt by pressing 0 then #. This will fail the authentication for the user that is attempting to gain access to their account. If there are multiple attempts to access the account a user can press 1 to report fraud on the account. This will lock the users account and inform the administrators there has been unwanted authentication requests for the user.
To view and manage fraudulent reports, proceed with the following steps:
Note The fraud alert reporting section lets you view fraudulent activity from a specific period of time.
There is a new item in the report for the user. Because the user reported the fraudulent activity, their account is currently marked as Blocked. Once the issue has been investigated, an administrator or the IT department can unblock the user's account so they may begin to use it again.
Notice the user is now unblocked. This user can now login to their applications again.
This section illustrates additional capabilities of the Azure MFA, such as:
To view Multi-Factor Authentication reporting, proceed with the following steps:
You can now see information regarding which users are logging in using the Azure MFA. You can repeat these steps above to view the other reports.
As illustrated, support for multiple methods, including Wi-Fi and offline authentication using the mobile app, and multiple phone numbers make it very rare for a user not to have a means to authenticate. However, in those instances, the user can contact their company IT help desk to request a one-time bypass of additional authentication.
To create a one-time bypass, proceed with the following steps;
Note This option allows an administrator to grant a user a bypass of Multi-Factor Authentication for a certain amount of time. An example is if an administrator was helping a user reconfigure Multi-Factor Authentication, they may want to remove the Multi-Factor Authentication requirement for a single sign-in during a window of time to help the user.
Note If you receive a warning that the name is not in the authentication logs, ensure you have used the entire UPN name and there are no spaces or anything, this step will not work if this is incorrect. Copy from the Usage | user summary report to ensure accuracy.
To view custom greetings, proceeds with the following steps:
Note An administrator can configure voice greeting in a variety of different languages to suit the needs of the application user base. Many companies customize the messages to include their company name, e.g. "This is Fabrikam Corporation calling to authenticate your sign in."
The last
additional capability we'd like to illustrate as part of this paper is the authentication caching. As its name suggests, authentication caching allows a user to skip Multi-Factor Authentication following a successful authentication on subsequent authentication requests for a period of time.
To set authentication caching, proceed with the following steps:
Note Cache type defines the scope or specific conditions that must be met on subsequent authentication requests:
User: Cache successful authentication for a user across all applications.
User, Authentication Type, Application Name: Cache successful authentications for user, authentication type, and application name. Subsequent request must come from the same application to utilize the cache feature.
User, Authentication Type, Application Name, IP (Server/SDK only): Cache based on previous type but also requiring initiating IP to match for the caching feature to authenticate the request.
Note The second time you login, you are not required to do Multi-Factor Authentication. This is because caching has allowed your authentication attempt to succeed. You can continue to login to resources for 5 minutes before you will need to complete another Multi-Factor Authentication.