Provisioning programmable hardware tokens for Office 365 accounts remotely

Many customers are asking about the best practices on provisioning the programmable hardware tokens in situations when end-users are working remotely and cannot burn the tokens themselves, so IT support has to take care of the burning process. To remind you, using programmable hardware tokens is the only way to have a hardware token for MFA if the user is not licensed for Azure AD Premium.

We have compiled a set of simple instructions and tools to share the best practices used by ourselves and by some of our clients to meet this goal.

This guide describes recommended practices of provisioning hardware tokens for Office 365 accounts without Azure AD Premium license when users are working remotely (i.e. from home).

Assumptions

• The provisioning is done by the IT person equipped with software and hardware that allows burning seeds onto programmable hardware tokens (i.e. an Android device with NFC, iPhone 7 or newer for “-i” models etc.). Exact requirements are listed on the product page of each model. No special admin access is needed as the provisioning needs to be done on behalf of the end-users

• The user is remote and only use a Windows machine to login to Office 365 services (if a user has a smartphone or a tablet, a mobile authenticator can be used with MFA, hence no need for a hardware token)

• The user does not have a possibility to burn a hardware token themselves

• There is a way to contact the user and organize screen sharing (using MS Teams, MS SfB, TeamViewer, AnyDesk or a similar tool)

• A hardware token provisioned by IT/Helpdesk using the method described below can be shipped and delivered to the end-user within a short time (i.e. within a month )

Problems to be addressed

• With Azure AD Free, there is no way for Global Admins to import existing seeds to Azure MFA (P1/P2 license is needed for this). Without AD Premium, the seed is automatically generated by the server and is shown as a QR code only to the end-user. Therefore, there is no way to configure this method in advance.

• If MFA for the user is activated and a hardware token is provisioned remotely, the user may be unable to log in to Office 365 while the hardware token is being shipped to her/him

Instructions

1. Contact the user using a tool allowing screen sharing and ask to share the desktop. You can request control and perform the next operations yourself, or guide the user thru the next steps

2. Ask the user to login to Office365 (by going to https://www.office.com ), then go to MFA settings page (short URL: https://aka.ms/mfasetup )

3. Perform the burning process as described in the provisioning manual

[the screen sharing must remain active so you can scan the QR code from the user’s desktop]

4. During the process, make sure you copy and save the text version of the secret key together with the username.

This data will need to be securely stored and will be used in case the user needs to enter the OTP while the token is still being delivered

We recommend saving the secrets (after removing spaces) in a spreadsheet in the following format:

After the token is delivered, it is also recommended to remove the secret from the spreadsheet.

5. After the token has been provisioned, verified and added to the user’s MFA settings, as the user to log out and log in again. When logging in, make sure “Don’t ask again for 60 days” and “Stay signed in” option is activated. This will make sure the hardware token is not needed to log in for some time (while the token is being delivered)

6. Arrange to ship of the token. Instruct the user to call Helpdesk in case the second factor is needed before the token has been delivered.

Addressing login issues

Actions described in step 5 of provisioning instructions above should make sure the user stays logged in for an extended period (ideally for 60 days), which should allow enough time for the token to be delivered. However, there may be situations when the user is prompted to re-login (i.e. a different browser is used, or session cookie has been cleared, or browser storage was corrupted etc.). Follow the recommendations below in case the user needs to enter the OTP while the token is still being delivered.

As described in step 6 above, users must be instructed to call the helpdesk, or any other IT support person/team designated to handle these requests. Important: user identity verification protocol should be in place to prevent social engineering attacks]. The team or person handling these requests should have access to the spreadsheet described in Step 4 above. The secret value stored next to user’s name has to be used to generate the current OTP using one of the methods described in the next section and communicated to end-user over the phone (or instant messaging). Email is also possible, but please note that the OTP is valid only for a limited period (currently around 10 minutes).

Generate OTP from a secret

You can use the following tools to generate current OTP from a secret:

• The recommended tool is our TOTPToolset(online or self-hosted version). Enter the stored secret in the Seed text field to get the OTPs generated. Please note that TOTPToolset can generate “future” and “past” OTPs in addition to the current one, it may make sense to use a future OTP if you plan to send it by email to make sure it stays valid for a longer period.

• You can also use our command-line tool, T2OTP.exe, available here. The syntax to be used is:
• t2otp.exe SECRET
• For example "t2otp.exe 2sk2tsmkjp7kdbck" will generate one OTP for the secret “2sk2tsmkjp7kdbck”