Hardware Tokens for Office 365 and Azure AD Services Without Azure AD P1 Licences

Posted on 2 CommentsPosted in Azure Active Directory, Azure AD, AzureAD, MFA, multi-factor auth, Multi-Factor Authentication, token2

A recent update to Azure AD Premium 1 (P1) licence has been the use of hardware tokens for multi-factor authentication (MFA). This is excellent news if your MFA deployment is stuck because users cannot use phones on the shop floor or work environment or they do not want to use personal devices for work activities. But it requires a P1 licence for each user. Now a P1 licence gives lots of stuff in addition to hardware token support for MFA, such as (but not exclusively) Conditional Access, which is a better way to implement MFA than when used without P1, which requires MFA in all circumstances and for all apps from all locations.

But if you want MFA in all circumstances and for all apps from all locations, and also need hardware tokens, this is where programable tokens come into play. I recently purchased a miniOTP-2 token from Token 2 (www.token2.com) and they provided me with a C300 token as well so that I could write this blog post.

In the scenario that I am going to describe here, I have two different programable tokens and I will walk through the MFA registration process for a user (using the new user interface for this service that was released end of Feb 2019).


Enabling the new MFA Registration Process

Open the Azure AD Portal from https://aad.portal.azure.com, click Azure Active Directory from the primary menu and then select User settings from the sub-menu. Under Access panel, click Manage settings for access panel preview features. You will see the following:


In this I have previously turned on the preview features for registering and managing security info that was rollout out early 2018 and now I can see a second option for the same, but called refresh.

Set both of these options to All (or a selected group if you want to preview for a subset of users initially). Click Save.

For what follows, it will work even if you have None set for both options, just the screenshots will look different and the latest refresh of this feature is much easier for users to work with – so I recommend it is turned on for both options.

Configure MFA Settings for your Tenant

In the Azure AD portal sub-menu click MFA under Manage MFA Server and click Additional cloud-based MFA settings under Configure. This opens another tab in your browser where you will see the Multi-Factor Authentication / Service Settings.

Under Verification Options ensure that Verification code from mobile app or hardware token is enabled. Other options such as “app passwords”, “skip for federated users”, “trusted IPs” (available if you ever once had the AAD P1 licence on your tenant even if you do not have it now) and “remember multi-factor authentication” can be set to your requirements.

Register a Programable MFA Token for a User

Once you have MFA settings configured you can enable the service for a user and have the token registered for the user. If you have a P1 licence you upload the token serial number to Azure AD, but if you do not have a P1 licence then you need to use a programable token as these appear to act just like authenticator apps you get on your phone.

In Azure AD you can register a user’s token by logging in as the user (they would do this for you) by visiting https://aka.ms/mfasetup. End to end this process takes about 10 seconds – so its very possible to add this process into new user joining procedures or have help desk visit the user or the other way around. This process needs an NFC burner app and device (Android phone is good), but don’t require the user to do this themselves using their phone – burn the token for them using a help desk PC or phone. If you get the end user to walk through all these steps you will confuse them totally!

The new UI for end user security settings:


As mentioned above, the UI you see is based upon the User settings options in Azure AD. If you have just the original refresh enabled, you will see the following instead:


In the first of the above two screenshots I have already registered some MFA devices. If the user has never registered a device before then they will see the following when browsing to https://aka.ms/mfasetup from the initial login and then the MFA registration page, with the registration process ready to start:

image image

If you have already registered some security info, then you will be able to add a hardware token from the + Add Method button and selecting Authenticator App and clicking Next.


The initial steps will show you the following dialog, depending upon if you are a new user (on the left) or adding a new MFA method (on the right):

image image

You are walked through the process of installing the Microsoft Authenticator app on your phone. In this case though, we have a hardware token instead of the app, and so you need to click I want to use a different authenticator app instead. The Microsoft Authenticator App supports push notifications, which hardware tokens do not, and so the QR code provided for the Microsoft Authenticator app will not work for hardware or other authenticator apps.

image image (QR code intentionally blurred)

Now you need to scan the QR code using the Token 2 Android app or click Can’t scan image and copy and paste the secret key into the Token 2 Windows app. Links to the apps are available from the Token 2 website software page (with the Windows app shown below):


Click the QR button (or Scan QR button if using the NFC Burner 2 software) and scan the QR code on the screen. This enters the seed in HEX into the app. If you need to enter the QR code by hand, click enter Base32 and type in the secret key value that you get under the Can’t scan image link.

Next, turn the hardware token on (it will remain on for 30 seconds) and hold it to the NFC reader on your Android device (usually next to the camera) or plugged into your PC.


Click the Connect button (or Connect Token depending upon the app you are using) – one of the Android apps are shown below:


Then finally click burn seed.


Turn off the token and turn it back on again – this displays the next valid code. The code that was displayed when the token was first turned on and before the new secret was burned to the device is not valid.

Click Next on the registration wizard on the computer screen. You are asked to enter the code displayed on the token. Azure AD has a 900 second range for codes, so any code displayed in the last 7 or so minutes should be valid to use


Success – if not, turn the token off and on again and try again. If not, go back, scan the code again and burn to the device another time – you are not restricted on the number of times you do this (though doing this wipes previous users of the token from using it again).


Click Done and see your first method of providing MFA shown to the user.


I recommend you add the users phone (for a call or text) as a second method at this point (in case they loose the token, they have a second route in). The user experience for when adding a phone looks as follows:


It is a shame we cannot rename the MFA method – that would be useful, as we could indicate the token name/type and then login to Azure AD could ask for this token by name.

If you were adding a new token to a user with existing MFA methods already in place, you end up in a very similar place:


Success – a new “app” added:


Then at next login when going to the MFA registration page, you need to enter your code:


Note that you don’t need the code yet for logging into Office 365 and Azure AD generally – you have to enable MFA for that and that is the next step.

Enforcing MFA for User

For all other logins apart from the MFA registration page, you need to finish by enforcing MFA for the user. If you have a P1 licence and Conditional Access then this will happen based on the rules, but where you don’t have AAD P1 licence, then you need to enforce MFA for all logins. Do this by browsing to the multi-factor authentication and users page via the Office 365 admin portal > active users > ellipses button > setup multifactor authentication:

Search for your user:


Once you have found the user to enable, select the user and then click the Enable hyperlink:


Followed by enable multi-factor authentication


The comment about “regularly sign in through the browser” is not valid for modern authentication supporting apps such as Microsoft Teams or where you have enabled Modern Authentication for Skype for Business Online and Exchange Online (you need to do this if your tenant exists from before August 2017)


Finally for completion, there is an MFA setting called Enforce. Enforce requires MFA for all logins including rich client applications that do not support MFA – therefore if you have modern authentication enabled and are using Outlook 2013 (with the Modern Auth settings for Outlook 2013 turned on) or Outlook 2016 and later then having the end user remain in Enable mode is fine. If you are using older clients that do not support MFA then Enforce mode will force them to use App Passwords for non-browser apps, and you want to try and avoid that.

Therefore we need to take the user to a minimum of Enable mode in Office 365 MFA so that MFA is triggered for all logins. This step is probably done after hardware token registration as when we set up the token for the user or when we sent the user through the registration workflow we did not first enabling MFA for the user – therefore the user is registered for MFA but not required to use it to login.

Set the user to Enable mode to trigger MFA for all logins:


Token2 Hardware OAuth Tokens and Azure AD Access

Posted on Leave a commentPosted in active directory, Azure Active Directory, Azure AD, AzureAD, MFA, multi-factor auth, phone factor, token2

This blog post walks through the process of logging into Azure AD resources (Office 365, other SaaS applications registered in Azure AD and on-premises applications that utilise Azure AD App Proxy).

First step is to order your desired hardware. For this article we are looking at the devices manufactured by Token2 (www.token2.com). These include credit card style and dongle type devices. The options are available at https://www.token2.com/site/page/product-comparison

For the purposes of this blog post I have been using the TOTP emulator on the Token2 website. This allows you to create virtual TOTP devices and step through and test the entire process without buying a physical token. The TOTP device emulator can be found at https://www.token2.com/site/page/totp-toolset. Each time you browse to this site a new device is emulated, but using key=XXXX, where XXXX is the 32 character device seed. Longer testing will require you to keep a record of the seed ID and use it in the emulator, or keep the browser window open.

Step 1: Order Devices

For this, I am using the emulator mentioned above, but you would order a number of devices and upon arrival request the unique secret identifiers for each device over encrypted email. In Feb 2019 a programmable device with time sync is being released which will allow you to set the secrets yourself and ensure that clock drift on the device is not a reason for them to stop working after a few years!

The secret is required for upload to Azure AD and is required in the form of a CSV file with six columns:

upn,serial number,secret key,timeinterval,manufacturer,model

For example, it could look like this for a two emulated devices:

upn,serial number,secret key,timeinterval,manufacturer,model


Ensure each UPN in the first column matches the device you are issuing to the user and upload the CSV file to Azure AD. This is done from Azure Portal > Azure Active Directory left menu > MFA (in Security area) > OAUTH tokens (in settings area):


Click Upload and browse for your CSV file. As long as there are no errors it will upload fine. Errors are displayed in the notifications area. Once the upload is complete click Refresh to see the imported hardware tokens. Tokens assigned to users that do not exist will appear after the user is created, if the user is created within 30 days.

I have in the below screenshot uploaded one token for a test user.


The token needs activating before it can be used. Activation is to confirm the token works and so you will need the next six digit sequence from the device and so have physical access to the device. End user activation is planned, but as of writing in Jan 2019 the administrator needs to activate the hardware token.

Click Activate and enter the current TOTP six digit number. The CSV file contains information about the time change for the device, which is 30 seconds for these Token2 devices, and so you need to enter the current, previous or next ID (next ID is shown in the emulator and not on the hardware token).


Click Activate button when the six digit code is entered. The green ticky ticky next to the number just means you have entered a six digit number, and not that it is the correct number!

After activation you will see the Activated column ticked.


You can now distribute the token to the user.

Step 2: Require token for login

Other blog posts and documentation on the internet cover the requirements for forcing the user to use an MFA device, so here I will just cover what is different when tokens are used. Firstly the user does not need to register their device – the upload of the CSV file and the activation of the token by the administrator covers this step. This does mean though that the user needs the token before they next are required to login with the MFA device or they will not be able to login. Therefore distribution of token following activation, or activation before MFA requirement is currently needed. End user activation which is coming soon will reduce this distribution gap.

Secondly, the code from an Authenticator app (such as Microsoft Authenticator or Google Authenticator) can be used as well as the code from the hardware token device (if the app is registered as well). Microsoft allow multiple devices to provide codes, so the user message on-screen at login will not say “Enter the code from your token2 device” but currently says “Please type in the code displayed on your authenticator app from your device”, but the current code from your hardware device and not only a registered app will work here as well. This is probably the most confusing stage of the process. The hardware token works wherever authenticator app is displayed – maybe this will change.

Finally, the user will only be required for an MFA login if either MFA is enabled for the account or conditional access enabled and the login or application access triggers an MFA requirement. The second of these is the better one to use. The admin configuration to force the user to enter their token one time code though is as follows:

  1. Ensure that MFA service settings allows verification code from mobile app or hardware token as shown:
  2. Ensure that the IP range where MFA is skipped is not the range the user is currently located on, otherwise the user will not be prompted for their MFA token. This IP range is configured in the above settings as well.
  3. Ensure that the user requires MFA to login from the MFA users page as shown. Select the user and click Enable:
    image  image
  4. Or, if using Conditional Access, that the Grant option includes MFA as one of the requirements as shown:#
  5. In the first step above you can see that phone calls, text and notification through app are all also enabled. These do not need to be enabled for the hardware device to work.
  6. The user needs an Azure AD P1 or P2 licence to use hardware tokens.

Step 3: The user login experience

When the user logs in or accesses an app that is MFA restricted via Conditional Access they will see the MFA login prompt as shown:


The code entered needs to come from their hardware device, as shown below:


The token changes every 30 seconds and is valid for a short while either side of the time it is displayed for on the device. Over time tokens will suffer from clock skew and eventually stop working. The new token2 programmable tokens available in Feb 2019 can have their clocks resynced to fix this issue.

As mentioned above, any registered authenticator app or hardware token uploaded against the user will work – the UX asks for an app at present, maybe this wording will get more clarification when the user has a token registered as well.

Step 4: User experience

Apart from the login, the other place where a user will see their token listed is the My account > Security and Privacy option (click your picture in an Office 365 app to see My account menu). If you have MFA enabled for the user (not just Conditional Access) then the user will see “Additional security verification” on the Security & Privacy page. Here is says “Update your phone numbers used for account security” – but this will list your hardware token as well. This is shown below:


In the above you can see that the user has an iPhone as well as the token, where the hardware token ID matches the serial number on the device that they hold, as well as a phone in this scenario. This allows the user to have a backup MFA method of more than one authenticator (Microsoft Authenticator on iPhone or MFA by phone call in this case) as well as the Authenticator app or hardware token. Your users can now have up to five devices in any combination of hardware or software based OATH tokens and the Microsoft Authenticator app. This gives them the ability to have backup devices ready when they need them and to use different types of credentials in different environments.

The use of a hardware token and its OAUTH code currently still requires a password before MFA token. Password-less token only is expected later in 2019.