Provisioning programmable hardware tokens for Office 365 accounts remotely

This guide describes recommended practices of provisioning hardware tokens for Office 365 accounts without Azure AD (Microsoft Entra ID) 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 8 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 can only use a Windows machine to log in 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 (Microsoft Entra ID) 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 through the next steps

2. Ask the user to log in to Office 365 (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.

Provisioning programmable hardware tokens for Office 365 accounts remotely

[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:

 Provisioning programmable hardware tokens for Office 365 accounts remotely

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, ask 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)

 Provisioning programmable hardware tokens for Office 365 accounts remotely


6. Arrange to ship 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 the 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 the 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.

    Provisioning programmable hardware tokens for Office 365 accounts remotely


  • You can also use our command-line tool, T2OTP.exe, described here. The syntax to be used is:

     t2otp.exe SECRET 

    For example "t2otp.exe 2sk2tsmkjp7kdbck" will generate one OTP for the secret “2sk2tsmkjp7kdbck

    Provisioning programmable hardware tokens for Office 365 accounts remotely