If password-based authentication is in place, the additional use of a second factor (or multi-factor (MFA) authentication) is highly recommended to enhance the security of identities and to strengthen the authentication process. The Microsoft Authenticator app running on a smartphone is commonly used as a second factor because it’s simple to use and allows to store multiple accounts. However, there are situations where employees might not have a company smartphone and don’t want to use their private smartphone for company-based authentication. And sometimes you also have to use MFA for non-personal accounts or accounts that are rarely used. A common example of this are break glass accounts that are only used in emergencies. How to deal with such situations?

• Part 1/2: Non-Programmable Tokens (this post)
• Part 2/2: Programmable Tokens

One option to overcome this issue is the use of hardware tokens (and yes, there are other options available as well, but that is out of scope for this blog post series). For this series I will use non-programmable and programmable tokens from Token2. But the same procedure (more or less) can be used for other token vendors.

Login Experience

Imagine a user logs in for the very first time in an environment where MFA is needed. After entering user name and password, the user will now be forced to set up MFA by submitting additional information.

This is where the user cannot continue the process. Successful authentication and access is not possible.

Non-Programmable Tokens

Azure AD allows the use of time-based one-time password (TOTP) tokens as a second factor. These tokens show codes that are refreshed every 30 or 60 seconds. Every token comes with a pre-loaded secret (or “seed”) that is used together with other factors (time and time interval) to generate codes. These codes must later be manually entered by the user as the second factor.

For proper MFA authentication, Azure AD must understand the relationship between user accounts and assigned tokens, and it must know the secret that has been pre-loaded onto the token. Only with that information at hand, the codes can be created on the server side (Azure AD) and on the client side (token) individually using an algorithm. Now, how to make this happen?

First, when tokens are ordered, the pre-loaded secrets (seeds) must be requested from the vendor. The process varies from vendor to vendor. Token2 allows you to request the seeds directly from the order. The seeds can then be securely transferred using various methods.

Now as we have the seeds, we can configure Azure AD to use the tokens. All relevant details for the tokens must be added into a CSV file that later needs to be imported. These fields must be submitted:

• upn > User Principal Name of the user that will use the token
• serial number > serial number of the device
• secret key > seed that has been submitted by the token vendor
• time interval > interval to generate new codes, 30 or 60 (seconds)
• manufacturer > manufacturer of the token
• model > model of the token

Now, the CSV file can be imported.

Currently, Global Administrator permissions are still needed for this step.

After a successful import, the tokens will be visible and can be activated. When a token is activated for a user, the code must be entered. Afterwards the token can be handed out to the user.

After the user received the token, he should now be able to login. Instead of showing the MFA registration process (because the MFA/token registration has been done by the administrator), the user is now prompted to enter the code from his token.

The user is then successfully logged in. To see the configured token details on the user’s account he can navigate to the “My Account” page (myaccount.microsoft.com) or just display his profile. The “Security Info” section shows the MFA (and SSPR) methods that are enabled for the user. The token is visible.

This is it. Watch out for part 2/2 where I will cover programmable tokens.

Cheers
Marcel