Last Updated on August 25, 2021 by Oktay Sari
The past few post I mainly wrote about Windows Information Protection and although it is a nice series of posts, I thought it’s about time to write about another topics . In this post we’ll be looking at using OATH TOTP Hardware tokens with Azure MFA instead of other MFA options. Personally I prefer other methods like FIDO2 or simply go with the Microsoft Authenticator app (Software OATH token ) installed on my phone. Although in public preview, I’m very pleased with OATH TOTP Hardware tokens support in Azure.
Why use OATH tokens
Perhaps you never thought about it but, many customers have users who don’t have a phone available when they need to authenticate and use MFA. There are also users who simply don’t want to install any work related apps on their personal phones. No matter how good your communication plan, some users just don’t want to install the Microsoft Authenticator app.
So you want to be able to deploy MFA to all of your users, even those who don’t have access to a (mobile) phone. That is one good reason to use OATH TOTP Hardware tokens with Azure MFA.
Also remember that when you setup a new Azure tenant, it is possible security defaults are already enabled. What does that mean? It means all users will have to register for some form of MFA by default within the first 14 days after first sing-on. Security defaults are available to all customers.
I highly recommend you disable security defaults and use Conditional Access to require MFA. Just keep in mind that Conditional Access requires a license for one of the following plans:
- Azure Active Directory Premium P1 or P2
- Microsoft 365 Business Premium
- Microsoft 365 E3 or E5
- Enterprise Mobility & Security E3 or E5
What is OATH Authentication
An OATH token is a secure one time password that can be used for multi factor authentication. It’s an open reference architecture for implementing strong authentication. The encryption algorithm is an open source standard and, as such, is widely available. Because OATH is an open standard, you’re free to choose any vendor or form factor.
Some authentication methods can be used as the primary factor to sign-in and others can be used as a secondary authentication supplementing basic password authentications. Your password is often one of the primary authentication methods. A FIDO 2 security key for example can be used for both primary and secondary authentication. OATH on the other hand, can only be used for secondary (MFA) authentication.
Prerequisites for OATH TOTP Hardware tokens with Azure MFA
Please keep in mind that OATH TOTP Hardware tokens are available in public preview. In order to use OATH TOTP, your users must have been assigned the appropriate license. You’ll need either
- Azure AD Premium P1
- Azure AD Premium P2
- Any other plan that includes AADP P1 or P2
Besides the license requirements you can only use OATH TOTP Hardware tokens with Azure MFA. The OATH TOTP (Time-based One-Time Password) token needs a refresh window of 30 or 60 second and a secret key of 128 characters or less. Azure AD does not support OATH HOTP! (Event-based One-Time Password)
Configuring OATH TOTP Hardware tokens with Azure MFA
Before you can configure OATH TOTP Hardware tokens with Azure MFA you’ll need to get yourself one of the compatible tokens. Go check out TOKEN2 or deepnet security. I have the FEITIAN OTP c200 OATH Time-Based 2FA Token and it works just fine. You can also check out the Token2 TOTP Toolset to play around.
Upload tokens to Azure AD
You’ve received your hardware token. Now what? Tokens must be uploaded in a CSV file format including the UPN, serial number, secret key, time interval, manufacturer, and mode. Here’s an example of the CSV file I received with my token. Just make sure you fill in the User UPN you want to activate the token for.
- Go to https://portal.azure.com
- Browse to Azure AD> Security>MFA>OATH tokens (here’s the link)
- Click on the Upload button and select the CSV file you received with your token
Once you upload the file, you can check the status by clicking the File upload in-progress text.
It can take a couple of minutes so be patient here. Go get yourself something to drink and wait a little bit longer. Then finally after a minute or 5, you’ll see that the token has been uploaded.
If you don’t see the token yet, click on the Refresh button. If there is an error, download a CSV to resolve any issues and try again.
Activate OATH Token
Once the upload is complete, you can see the Username, Serial Number, Model and more. You’ll also see an option to activate the OATH token.
Click on Activate to continue. Now you’ll have the option to enter your verification code.
This code is generated on your token. Just push the button and fill in the OTP that has been generated. Then finally, click on OK.
Check the status of your OATH tokens to see if they have been activated.
That’s it. You have uploaded your token to Azure and activated it for a user. What’s next?
When a user signs-in to https://aka.ms/mysecurityinfo he or she can see all assigned Authentication methods available for sign-in or MFA. MFA is a secondary authentication method. The Hardware token becomes the default for MFA but this can be changed by the user.
In Azure AD, the administrator can look-up the user and see (almost) the same thing. The authentication methods shown here are the ones you activate to sign-in. These are the Primary authentication methods. The available sign-in methods are:
- FIDO2 Security Key
- Microsoft Authenticator
- Text message (preview)
- Temporary Access Pass (preview)
The reason you don’t see the OATH TOTP token here is because it can only be used as a secondary authentication method. In other words, for MFA.
Use case and scenario’s
This is where it gets interesting…Imagine you have Windows Autopilot setup and you also require MFA (using conditional access policies…) to register or join a device to Azure AD. Users with no phone or users who do not want to setup MFA with, for example the Microsoft Authenticator app would run into trouble during Windows Autopilot enrollment…
ideally you would want to exclude users from this policy only when they use Windows Autopilot devices. This is where Filters for devices (preview) would come in handy…My first test and experience was not that great…but this is the future ? another post idea…
Scenario 1- Require MFA when Azure AD joining a device (using Windows Autopilot)
You are a new employee for company X and you’ll start next week Monday. Your device is delivered to your door and with it, you also received an OATH hardware token. You boot the device and start enrolling with Windows Autopilot.
The next screen tells you to sign-in with a username. Yes…you can also sign in with a security key with Windows Autopilot but that’s for another post….
Now type in your temporary password you received with the welcome letter.
The next screen, is where you need to use MFA for strong authentication. Get your token out, push the button and use the OTP it generated. This is where the Windows 10 device is figuratively shaking hands with the Azure AD device registration Service when registering with and joining Azure AD. More on that a little further down…
The next screen will ask to update your password to something new and make it hard to guess ? like “Th!$ h@s AllW@ys b33n My F@v0r1t3 P@ssW0rd! I N3v3r F0rget….Or m@yb3 D0!” You are going password-less soon right?…
Click on Sign in to continue. While your shiny laptop is running hot, get yourself another drink…..and wait, while Windows Autopilot continues with setting up your device for work…
Yes…this might take several minutes…and a reboot or 2…
And…almost done. Now set-up Windows Hello..
Click on OK and… you are all done…
Scenario 2- Require MFA when using a browser from unmanaged devices
Imagine again, that you are a user without access to a phone and want to sign-in to https://portal.office.com from a (non-compliant) unmanaged device. The administrator configured a conditional access policy to require MFA when using a browser from unmanaged devices.
Go to https://portal.office.com from an unmanaged (personal) device and sign-in with your username and password.
The OATH OTP hardware token is the default authentication method for MFA from the moment it was activated. You can use the OTP generated on your token.
You are now able to read your e-mail or do other work related things you do normally.
Recap this far…
So it seems OATH TOTP Hardware tokens with Azure MFA is a great solution where users don’t have to configure MFA themselves to start with. They can start using their account and when the need to do MFA they can use the OATH TOTP token. I do recommend you use OATH TOTP wisely and only if other options are not available. If possible, make sure users register for other authentication methods at https://aka.ms/mysecurityinfo.
OATH TOTP Hardware tokens with Azure MFA will also work for Self Service Password Reset. However, the number of Authentication methods required to reset a password could ask your users to register a phone number. So if you do select 2 methods like the example below, make sure your users have other options than mobile phones to authenticate.
To complete this post, let’s have a look at what happens behind the scenes…What happens when you require multi-factor authentication (MFA) when registering or joining devices to Azure AD and what can you find in the Sign-in logs?
MFA when Azure AD joining a device
When enrolling the device with Windows Autopilot (see scenario 1), the moment the device talks to the Device registration Service, it requires MFA. Go to Azure Active Directory > Monitoring > Sign-ins. I’ve filtered for firstname.lastname@example.org since he was enrolling the device in scenario 1.
The tab “Basic info” shows the Authentication requirement is MFA for the resource Device Registration Service. The application ID can change depending on the OS. The example below shows 2 records for the Device Registration Service. So you are asking for MFA when Azure AD joining a device. Let’s have a look at the first record:
Continue and click on the tab “Conditional Access” to see which policy is hit and what the result is:
Now click on the “Authentication Details” tab. Here you’ll see the primary authentication method is your password and the secondary is OATH for MFA or MultiConditionalAccess. The Authentication is still in progress…
Upon entering the OTP code generated (during Windows Autopilot) the second record shows more information:
Check the “Authentication Details” tab again. You will see that MFA completed successfully using the OATH verification code.
The “Conditional Access” tab shows the policy was hit successfully.
The next record shows where the device enrolls into Microsoft Intune. Since you’ve already signed in and satisfied MFA, all is good to go.
Require MFA when using a browser
The next example shows the login information when you require MFA when using a browser (from unmanaged devices). This is scenario 2 from the user experience example above.
The Basic Info tab shows that MFA is required. The client app is Browser and the Application is O365 Suite UX.
The Conditional Access tab shows the MFA policy was hit.
Then finally the Authentication Details tab shows the primary authentication method was a password and MFA was successfully completed using a OATH TOTP Hardware token.
Here is some more information you can read
- Authentication methods and features – Azure Active Directory | Microsoft Docs
- OATH tokens authentication method – Azure Active Directory | Microsoft Docs
Hey, as far as I can tell, it requires Global Admin to activate the hardware oath tokens. Have you found a more narrow role that can do the activation?
For obvious reasons we don’t want the support team to have GA….
He Morgan, Not that I’m aware of. Most MFA settings can only be managed by Global admins. There are a few roles that can manage some parts of MFA, but these roles can’t manage Hardware OATH tokens (Authentication Administrator/Authentication Policy Administrator)
It is possible to use the programmable tokens (e.g. the SafeID/DIamond token in you image) as a direct replacement for microsoft authenticator. Using this method you can seed the token using the QR code sent by Microsoft (using a programmable token is one solution for where you don’t have a P1 or P2 license).
You can probably pre-activate OATH tokens for all users but use Conditional Access to control whether MFA is enforced based on groups. Then change group membership to enable MFA. And changing group membership can be delegated for sure
Yes, if you use the SafeID Token Service to manage your tokens for Azure AD or Office 365, then your admin/helpdesk users do not need to have global admin rights. See: https://wiki.deepnetsecurity.com/display/SafeID/SafeID+Token+Service
Thank you for all of this information! I was able to get the CSV uploaded however when I click “Activate” and type in the 6 digit passcode, it fails. There isn’t any other error code so it’s kind of been hard to troubleshoot. Would anyone know what the cause of this is?
Update: According to Microsoft, “The preview is not supported in Azure Government or sovereign clouds.” which is why I believe we cannot get the token activated yet.
[…] until now, OATH hardware token was the only option here. Although this works pretty well (check out this blog post by Oktay), we have a new kid on the block now: FIDO2 security […]