Your password probably starts with a capital letter and ends with either a number or exclamation mark. You probably reuse passwords across multiple sites, many of which have been compromised. Due to the weakness of traditional user names and passwords, Multi Factor Authentication has exploded in popularity over the past several years as customers look to reduce their exposure.
Deploying Azure MFA is usually very straight forward. If you don’t want user’s to receive text messages, that’s fine. The MFA admin selects which methods of communication are allowed and during registration, the user selects the preferred option from the list. Most users have access to broadband or Wi-Fi and can answer the second factor of authentication with the appropriate response.
But what if they cant? What if your user is in an isolated environment though and cannot be reached? What are some options to authenticate these cowboys?
This article introduces 3 options for addressing this scenario. We can accommodate the isolated user with a “Time-Based One-Time Password” (TOTP) solution. Codes are generated locally by combining a secret key with the current timestamp using a cryptographic hash function to generate a one-time password. The user enters these codes as a second factor of authentication and life is good.
The first (and easiest) solution for the isolated user is to deploy the Microsoft Authenticator application. The Microsoft Authenticator app can receive notifications both over cellular and Wi-Fi connections. In addition, the application can generate access codes locally. These codes don’t require internet or data, so you don’t have to worry about having phone service to sign in, or that the app will use up your data plan. When you close the app, it doesn’t keep running in the background so it won’t drain your battery. You can close the app and ignore it until the next time that you sign in.
The Microsoft Authenticator app works across all platforms and accomplishes the goal of allowing the user to enter the current code into the verification window in an isolated environment.
The second solution involves deploying an on-prem Azure Multi-Factor Authentication Server. This solution ties into our Azure MFA service to provide MFA auth to a subset on-prem resources, specifically ADFS, RADIUS, and IIS. This process involves importing third-party Open Authentication (OATH) time-based, one-time password (TOTP) tokens, and then using them for two-step verification. For example, a customer could utilize ActiveIdentity tokens which are OATH TOTP tokens whose secret key was imported into the Azure Multi-Factor Authentication Server.
OATH TOTP tokens support the following formats:
Portable Symmetric Key Container (PSKC) CSV if the file contains a serial number, a secret key in Base 32 format, and a time interval
The third and final solution employs third party MFA solutions and their various flavors of OTP could be leveraged from within ADFS. Once installed and registered with ADFS, it is possible to enforce MFA as part of the global or per-relying-party authentication policy. These solutions are all supported with ADFS.
|Gemalto Identity & Security Services|
|inWebo Enterprise Authentication service|
|Login People MFA API connector for AD FS 2012 R2 (public beta)|
|Microsoft Corp.||Microsoft Azure MFA|
|RSA, The Security Division of EMC
|RSA SecurID Authentication Agent for Microsoft Active Directory Federation Services|
|SafeNet Authentication Service (SAS) Agent for AD FS|
|Mobile ID Authentication Service and Signature Services|