Skip to main content

Using a hardware token for MFA with Azure AD

What does a hardware key do?

Hardware keys provide another method of authentication beyond SMS messages, authenticator app notifications, and authenticator app codes. They give users the ability to login securely to a service that supports Multi-factor Authentication (MFA) without the necessity of using one of the methods mentioned above.

Why might I need a hardware key?

Some users may not wish to install what they consider company apps on their own mobile phone, therefore they may not wish to install an authenticator app to allow or deny access through MFA. If users are not required to have a corporate owned mobile phone, the hardware tokens provide a cheap and easy alternative to provide MFA authorisation. 

What does a hardware token look like?

There are different types of hardware keys for different scenarios, but this is a good example of a cheap and effective hardware key. This was purchased from Token2 direct (https://www.token2.com) for around 22 Euros and comes highly recommended. I have no affiliation with Token2 (hint, hint Token2) so I do not stand to gain from recommending their tokens. 


Licenses required

An Azure AD Premium P1 or P2 license is for the non-programmable hardware keys. An Azure Basic license is sufficient with a programmable key, but the installation method differs to the instructions below. See https://azure.microsoft.com/en-gb/pricing/details/active-directory/ for more information on Azure AD licensing. 

Setup

With Token 2, it was necessary to request a CSV file before setting up MFA for the hardware token in Azure AD. This is to provide the shared key secret which provides secure access to Azure AD using MFA. To do this navigate to https://www.token2.com/shop/page/request-secret-keys and follow the instructions on their page. This CSV file came minutes after it was requested. The file was downloaded and extracted. To edit the CSV, right click the file and click Edit this should open the file in Notepad. Do not edit it in Excel. 


The CSV file shown above has been edited to include the User Principal Name (UPN) instead of the default UPN in the CSV file supplied by Token2. Some of the characters in the image above have been crossed out for obvious reasons.   

Navigate to Azure Portal at https://portal.azure.com > Azure Active Directory > Security > MFA  > OATH tokens and click on Upload, then select your CSV file.


Browse to your token, select it and click Open at the bottom of the window.

Once the upload is complete the token will be shown in the portal. 

The details have been obscured. If there is a problem with the CSV file, an error message will be shown.


Activation

To activate the token, you will need to provide the number off the hardware token itself so have it available.  Click Activate as shown in the image below.




Turn your hardware key on if required. 


Enter the code and click on Ok near the bottom. If the upload is successful, a message like this will appear.


If it is not successful, refresh the code and try again. Once this is complete, the user will have to change their default MFA method. To do this, get them to navigate to https://mysignins.microsoft.com/security-info. 





Click Change as highlighted above. 


Click the drop-down box and select Authenticator app or hardware token - code and click Confirm. 


You will notice that the default method has successfully changed. 

Log in experience


When logging in, the user will receive a prompt after entering their username and password. 


Do not be put off by the clumsy phrasing of the message, the code from your hardware token will work. Enter the code and click Verify then the user will be logged in.  

Are you planning to use hardware tokens in Azure AD? If so, has this article helped? Please let me know in the comments below. 

Comments

Post a Comment

Popular posts from this blog

Session control policies in Microsoft Defender for Cloud Apps - block copy, cut, and paste in web apps

In this article, I attempt to outline the process for creating session control policies using Conditional Access (CA) and Microsoft Defender for Cloud Apps or MDA for short. When I first set this up, I was unaware of the need to have a user sign in between setting up the CA policy and setting up the policy in MDCA which then allows session control policies to be applied. I will guide you through this, the policy setup and testing.  An overview of the setup process looks like this: 1. Setup the CA policy 2. Have a user login 3. Apply the MDA access policy and add your conditions.  4. Test it 1. Setup the CA policy Pre-requisites: -  a. the app should be available as an "Enterprise App" in Azure AD. Secondly, the app should support and be configured for SAML SSO.  b. Azure AD P1 licenses are required. My understanding was always that MDA required Microsoft 365 E5 or equivalent licenses for applying policies, but Microsoft states in the following article that Azure AD P1 license
Post a Comment
Read more

Priviledged Identity Management in Azure AD

What is it? Privileged Identity Management or PIM is a service that provides just in time access to privileged roles in Azure and Azure AD. It does this with an approval process which can be manual or automatic. This article will concentrate solely on the Azure AD setup and management of PIM.  What is required? An Azure P2 license. This can be purchased as a standalone license or as part of the EMS E5 license suite. A Global Administrator account will have access to administer PIM by default, but an account can also be added to the Privileged Identity Administrator role for this purpose. A good understanding of the process, which accounts will be managed this way, and why is required is important. It is also necessary to identify who will be responsible for approving, renewing, and reviewing privileged accounts in Azure Active Directory.   Where do I find PIM? PIM can be found by logging into https://portal.azure.com and searching for PIM and clicking on "Azure AD Privileged Iden
Post a Comment
Read more

Microsoft Purview Endpoint DLP for MacOS

Get onboarded The first step is to get the macOS device enrolled in Intune for easy management. To do so, follow this guide: https://learn.microsoft.com/en-us/mem/intune/user-help/enroll-your-device-in-intune-macos-cp The guide is a little out of date, but the principals work all the same. Now to get the device onboarded into Microsoft Purview. https://learn.microsoft.com/en-us/microsoft-365/compliance/device-onboarding-offboarding-macos-intune?view=o365-worldwide As you will have seen in the article above, onboarding uses the same mechanism for onboarding macOS to MDE. Once the configuration profiles are installed as seen in Intune > Devices > macOS > macOS devices > click the device name > Device configuration . They should have a nice green tick next to the word “Succeeded” under the “State” header. I had a bit of a brain spasm with the naming, I would use Microsoft’s naming suggestion as seen in their guide.   Create the DLP policy To configure the DLP
Post a Comment
Read more