Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Announcing the public preview of Azure AD support for FIDO2-based passwordless sign-in
Published Jul 10 2019 09:00 AM 155K Views

Howdy folks,

 

I’m thrilled to let you know that you can now go passwordless with the public preview of FIDO2 security keys support in Azure Active Directory (Azure AD)! Many teams across Microsoft have been involved in this effort, and we’re proud to deliver on our vision of making FIDO2 technologies a reality to provide you with seamless, secure, and passwordless access to all your Azure AD-connected apps and services.

 

In addition, we turned on a new set of admin capabilities in the Azure AD portal that enable you to manage authentication factors for users and groups in your organization. In this first release, you can use them to manage a staged rollout of passwordless authentication using FIDO2 security keys and/or the Microsoft Authenticator application. Going forward you’ll see us add the ability to manage all our traditional authentication factors (Multi-Factor Authentication (MFA), OATH Tokens, phone number sign in, etc.). Our goal is to enable you to use this one tool to manage all your authentication factors.

 

Why do we feel so strongly about passwordless?

Every day, more and more of our customers move to cloud services and applications. They need to know that the data and services stored in these services are secure. Unfortunately, passwords are no longer an effective security mechanism. We know from industry analysts that 81 percent of successful cyberattacks begin with a compromised username and password. Additionally, traditional MFA, while very effective, can be hard to use and has a very low adoption rate.

 

It’s clear we need to provide our customers with authentication options that are secure and easy to use, so they can confidently access information without having to worry about hackers taking over their accounts.

 

This is where passwordless authentication comes in. We believe it will help to significantly and permanently reduce the risk of account compromise.

 

Passwordless sign in flow 2.png

 

 

Now, all Azure AD users can sign in password-free using a FIDO2 security key, the Microsoft Authenticator app, or Windows Hello. These strong authentication factors are based off the same world class, public key/private key encryption standards and protocols, which are protected by a biometric factor (fingerprint or facial recognition) or a PIN. Users apply the biometric factor or PIN to unlock the private key stored securely on the device. The key is then used to prove who the user and the device are to the service. 

 

Public preview of Azure AD support for FIDO2 based passwordless 2.jpg

 

Check out this video where Joy Chik, corporate vice president of Identity, and I talk more about this new standard for signing in. To learn more about why this should be a priority for you and your organization, read our whitepaper.

 

Let’s get you started!

To help you get started on your own passwordless journey, this week we’re rolling out a bonanza of public preview capabilities. These new features include:

  • A new Authentication methods blade in your Azure AD admin portal that allows you to assign passwordless credentials using FIDO2 security keys and passwordless sign-in with Microsoft Authenticator to users and groups.

Public preview of Azure AD support for FIDO2 based passwordless 3.png

 

Public preview of Azure AD support for FIDO2 based passwordless 4.png

 

Public preview of Azure AD support for FIDO2 based passwordless 5.png

 

FIDO2 hardware

Microsoft has teamed up with leading hardware partners, Feitian Technologies, HID Global, and Yubico, to make sure we have a range of FIDO2 form factors available at launch, including keys connecting via USB and NFC protocols. Sue Bohn has more details on those partnerships.

 

Please be sure to verify that any FIDO2 security keys you’re considering for your organization meet the additional options required to be compatible with Microsoft’s implementation.

 

passwordless.jpg

Our passwordless strategy

Our passwordless strategy is a four-step approach where we deploy replacement offerings, reduce the password surface area, transition to passwordless deployment, and finally eliminate passwords:

 

Public preview of Azure AD support for FIDO2 based passwordless 8.png

 

Today’s product launches are an important milestone for getting to passwordless. In addition, the engineering work we did to provide authentication methods management for administrators and user registration and management, will allow us to move even faster to improve credentials management experiences, as well as bring new capabilities and credentials online more simply. We’re working with our Windows security engineering team to make FIDO2 authentication work for hybrid-joined devices.

 

Of course, we look forward to feedback from you across all of these features, to help us improve before we make them generally available.

 

Regards,

 Alex (Twitter: @Alex_A_Simons)

 Corporate VP of Program Management

 Microsoft Identity Division

 

Additional links

 

95 Comments
Iron Contributor

@Ash_677-1 using a dedicated security group fixed the issue for me. Curiously, enabling FIDO2 in AAD with the "all users" option didn't - it had to be "selected users" with the dedicated security group to get it all working. Thanks for your assistance.

Copper Contributor
Ash_677-1 - Thanks! That fixed it for me. After changing it and explicitly listing the users (it's only 3 of us), we are able to add our keys.
Iron Contributor

@n0creativity @Rob Hardman @Steve Whitcher  ok big update. Seems like our MS Support Engineer was wrong in his assessment that you cannot register FIDO2 keys from a hybrid joined device.

 

To test the reply from MS I took an Azure AD joined device and attempted to register my Yubico key. Once I got to the end to name and save the key, I was again prompted with an error but this time one that actually provided info instead of 'We're sorry, we ran into a problem.'.

 

The error stated the key type I am trying to register is not allowed by my administrator. So I went and checked my FIDO2 auth settings since I remember limiting the allowed key type to the one Yubico type I have. It seems I had forgot (or missed) to put the slider on Allow key types instead of Block key types so I was allowing all key types except the one I had.

 

Once I corrected my mistake I was able to register the FIDO2 key from my hybrid joined device without issue. 


*feeling very dumb right now* :)

Copper Contributor

Hi,

 

1. Will this work with Mobile Phone Clients:

React / JS Single Page Application Apps on Android and Apple devices?

 

2. If we have multple users using the SAME mobile phone e.g. BOB  uses phone during day and Peter uses the same phone at night, can they both log into the react spa apps with their own NFC devices and authentication with the AAD?

 

3. Will SSO work between our 3 react JS SPA apps on the same mobile phone, they all configured with AAD login using MS Identity 2.0?

 

Microsoft

There is no add method once I click the security info

Copper Contributor

I am using the public preview of Azure AD support for FIDO2-based passwordless sing-in.  I am seeing a few "generic "Authenticator app" entries in the Security Info section of mysignins.microsoft.com/security-info. It lists my methods of authentication like my Alternate phone, Office phone, Microsoft Authenticator entry, alternate email, etc.  All entries look fine with the exception of the 2 generic Authenticator app entries. These 2 entries do not show anything in the second column (the other entries all have details (for example Microsoft Authenticator lists the device name it is installed, Phones list the phone #, etc). The generic Authenticator Entries have nothing listed in the second column.  They do have a Delete link in the 4th column but selecting Delete issues the following error - Refresh page (the title of the popup window) The text of the error - "We're still setting up things. Please refresh the page to delete the Authenticator App." with an OK and Cancel.  Have tried several times over several days with the same results.

Are the generic entries anything to be concerned about? Should I be able to delete them?  Is there anyway for me to report this issue?  Please let me know if you need any additional information. 

 

Microsoft

@Ed Kelly - Thanks for reporting this. Our engineering team recently released a hotfix for this issue. Can you please check again and let us know if it works? Thanks!

Copper Contributor

I was able to delete both of the "generic" authenticator entries today.  I do not know what they were but at least i am now able to delete them.  Is there anything I should be concerned about regarding the entries?  Thank you for letting me know the fix was available.  If the fix was to give me the ability to delete the entries, it worked. Thank you.

Microsoft

@Ed Kelly - Good to know, thanks! Nothing to be worried about. It was just a bug and it's fixed now :)

Copper Contributor

We want to change over all of our Office 365 (and separately, also our Win10) to require use of a YubiKey with no Authenticator app.  Failing that, we would allow only YubiKey and Microsoft Authenticator (not any other authenticator app, since we are afraid of users downloading any random authenticator app that could be subject to a man-in-the-middle attack).  Is there any way to achieve this?

Steel Contributor

One problem you would be facing now is the initial enrollment for the users. As it is today, you still have to login the first time with a password to be able to enroll both the Authenticator app and the FIDO2 key. I know Microsoft is working on this but no announcements yet. But if you could get the user to visit a support desk for the initial rollout (only they know the very complex password), it could be possible - at least in theory :)

Copper Contributor

 

Hello All,
 
I'm trying to setup Yubico NFC keys with my azure tenant but unfortunately without success... probably I'm missing something so i would like to share all steps that I'm following, maybe will be good also for somebody else in the future. 
 
enable the preview features
2. Enable and configure FIDO2
allow self-service set up - yes
enforce attestation - yes
enforce key restriction policy - yes
restrict specific keys - allow 
AAGUID -> 2fc0579f-8113-47ea-b116-bb5a8db9202a based on this table since i have YubiKey 5 NFC with firmware 5.2.4 -> https://support.yubico.com/support/solutions/articles/15000028710-yubikey-hardware-fido2-aaguids
 
3. following the official guide here -> https://support.yubico.com/support/solutions/articles/15000024567-using-yubikeys-with-azure-mfa
i've add the oath with -> ".\ykman.exe oath add t.test@consoto.com " and than add based32 key
4. Prepare the csv file for upload to the cloud like this:
upn,serial number,secret key,timeinterval,manufacturer,model
t.test@consoto.com,1234567, 1234567890abcdef1234567890abcdef,60,YubiKey,HardwareKey
5. Upload the file to the azure portal, and than try to Activate using the Yubikey Authentication app code, but i got this error:
 
Activating OATH token
Failed to activate the selected OATH token.
 
I guess i miss something but i dont know what and where, any advice will be appreciated!
 
BR,
Nick

Microsoft

Hi @nikynikyy , 

 

It looks like you may be confusing hardware OATH token setup with FIDO2 security key setup. YubiKeys support so many different protocols!

 

To use the keys with FIDO2, please check out these setup instructions: 

 

For Admins (policy & device setup for your tenant): https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-password...

 

For individual users (getting the key set up for a single account): https://docs.microsoft.com/en-us/azure/active-directory/user-help/security-info-setup-security-key  

 

If you do want to set the keys up as hardware OATH tokens for use as a second factor with Azure MFA, start here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-method...

 

Cheers, 

--Libby Brown

Copper Contributor

Hi,

 

Thanks for a nice write-up!

 

I got very exited and tried to register Fido2 security keys with my Azure AD account, but I faced the error message "We detected that this browser or OS does not support FIDO2 security keys.". After some troubleshooting I concluded that it seems Ubuntu/Linux workstations are not supported or being blocked for Fido2 authentication for Azure AD logins. Fido2 usually works well on Ubuntu/Linux workstations, too.

 

I also tried registration and use of Fido2 keys with Azure AD on a Windows workstation, then it worked flawlessly.

 

Do you know when Fido2 for Azure AD will be supported or unblocked for non-windows operating systems?

Copper Contributor

I followed your instructions and was able to get the FIDO 2 keys working. I have a few questions I received from my testers as well as my own.

 

Is there a way to encourage users to take the security key with them? My director is concerned that people may leave the device plugged into the computer, rather than taking it with them.

 

Is there a way to lock the computer when the key is removed? Windows Hello has a dynamic lock feature that works for Bluetooth, but I don’t know if there is a way to make it work with a USB device.

 

Is there a way to change the default login method to security key? I will probably be disabling password at some point, but it doesn’t seem to be the default for my test users.

 

The security key seems to bypass the second factor credential providers in Windows 10, is that expected behavior? The "Windows Components/Windows Hello for Business/Configure device unlock factors" setting could be used to create more advanced logon flows.

Microsoft

Thanks for your questions, @mseverns - 

 

1) Not at this time, in fact some keys are designed to leave in the PC (See Yubico Nano.) This is one reason we require a PIN or biometric gesture to complete the authentication with the key - you need the key and the thing you know/are to be successful. 

 

2) This is not supported for FIDO at this time. (Consider a FIDO sign-in completed via NFC tap - what would the corresponding logout gesture be?) We recommend looking at things like timeout policies if this is a concern. 

 

3) We are now using a Most-recently-used credential setting on the user such that if they used a FIDO credential last, and are on a device/browser that supports FIDO for their next login, we will prompt automatically for it. 

4) Security keys are considered strong authentication credentials, meaning they convey both the thing you have (key) and the thing you know or are (PIN or bio.) So it's unnecessary to require a 3rd factor as well. 

 

Hope these answers help! 

Copper Contributor

Thanks for the answers @Libby Brown 

 

I hope you guys will consider adding some of those functions at a later date.  Windows Hello was a great foundation for multifactor configuration, but I know how you guys like to reinvent the wheel.  Specifically regarding answer number 4, Windows Hello by itself also meets the strong authentication credentials requirement, but the functionality to configure that setting obviously exists, I am using it to ensure an authentication flow that is more advanced for users that are off site.  So I can say sure Biometric is fine if you are in office, but if you want to log in from home you are going to have to show not just biometric, but also windows hello pin or security key.

Brass Contributor

Why can't users when registering for MFA not directly select for a security key (fido) as part of the MFA enrollment as an option?

Now only Phone/Text or Mobile App are available as options, but you cannot select the Security Key during enrollment.

Once MFA Enrolled you can add the security key as an additional authentication option.

 

SharedScreenshot.jpg

Brass Contributor

We have encountered the same problem as @Peter_Lindqvist with supported Ubuntu and latest stable versions of Chrome and Firefox. Setup proved to be working in non-Azure scenarios so looks like Microsoft is blocking or not recognising the user agent string. Can you provide an authoritative reply so that we can update our documentation (though we would hope not to have to further disappoint our numerous Linux users).

Copper Contributor

@ffinlo:

A short update: On Ubuntu using Chrome I was able to get the Azure Fido2 to work by setting the User agent to say "Chrome - Windows" (https://developers.google.com/web/tools/chrome-devtools/device-mode/override-user-agent). Since Fido2 does works, perhaps, non-Windows OSes will get unblocked when Security Keys get promoted from public preview?

Copper Contributor

I'm also a cross platform user waiting patiently for support in Linux. To the wish list I would like to add support for biometric FIDO2-devices such as the Macbook finger print reader and the upcoming Yubikey Bio. I can already register my fingerprint reader as a device on other FIDO2 enabled websites so the support is there from the FIDO Alliance and Apple. Lastly, a better ui for managing security devices would be nice. You want to encourage people to move away from passwords, don't you :smile:

Copper Contributor

Commenting to follow

Copper Contributor

Hi! Anyone else missing "Allow self-service set up"?

Michael_Berntsen_2-1605253591154.png

 

Copper Contributor

I have enabled this in my tenant and was testing it with some test accounts but the option of adding a security key has disappeared even though I have set mobile SMS as a method. I have tried everything to get the auth method to show up for my test users without success. It is almost like MS have removed the function for end users. I am on Azure AD for Microsoft 365. Should this function work on the free Azure licenses rather than P1 or P2?

Brass Contributor

Me again, using another login. I have found the same issue on two other Tenants I manage. The FIDO2 option is not these for end users to configure. This is delaying my FIDO2 testing now.

Copper Contributor

Hi Guys

Same here, I was just about to setup FIDO2 for our company, but in the Azure Active Directory - Security - Authentication methods - FIDO 2 option -> there I am missing "Allow self-service set up". It is just not there. 

AdrianFrick_0-1605620187256.png


Therefore (I guess) testing with multiple users try to add a new AuthMethod in user account security info, i dont get the option for a "Security key".

AdrianFrick_1-1605620333468.png


(Requirements according multiple manuals are all fulfilled)

Any guesses? 

 

Brass Contributor

It works for me (non admin regular user account), without self enrollment in the Azure portal visible either:

SharedScreenshot.jpg

 

 

Have you enabled Fido 2.0 for specific users/groups, as the "all users" slider is disabled in your screenshot on the Azure Fido settings?

@AdrianFrick

 

Brass Contributor

@Frank Rijt-van  I suspect, another form of MFA is required to stop a hacker removing FIDO2 without getting authenticated...

Copper Contributor

Also missing the FIDO self-service option in the portal. Further confirmed it is false via API, so seems the likely culprit for why we can't get security key to show up for users. Unable to update to true via API - receiving an access denied message.

 

Used graph explorer to GET https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurat... to view, and then PATCH same with a JSON body that set isSelfServiceRegistrationAllowed to true. Per documentation at https://docs.microsoft.com/en-us/graph/api/fido2authenticationmethodconfiguration-update?view=graph-....

 

Hoping Microsoft gets this resolved soon so we can all proceed with FIDO.

Cheers.

Brass Contributor

@DarinDugan  I thought I was going mad, as on Saturday it was there, but after trying on two other tenants and hearing from others, I am relieved.

Microsoft

Hey folks, 

 

Mea culpa on the "Allow self-service set-up" setting disappearing. We don't currently have any other way to register keys besides self-service, so I requested the setting be hidden, but I didn't realize that logic had already found its way through other parts of the service. The hotfix is rolling out. 

 

Thanks for your patience, and for getting going with FIDO2 security keys! 

--Libby Brown

PM, Microsoft Identity 

Brass Contributor

Thanks for the info!

We started today with our FIDO keys and couldn't get them working, now I understand why. Just bad timing. ;)

 

@Libby Brown Is there any information about the ETA for the hotfix on all tenants?

 

//Jasper

Brass Contributor

@Libby Brown Any Updates on a ETA for a fix? This is holding up my pilot deployment now.

Brass Contributor

@Danny69 

 

MS Support fixed the issue for us using the graph API:

 

Resolution: we have followed the below steps to resolved the issue.

 

Document followed: https://docs.microsoft.com/en-us/graph/api/fido2authenticationmethodconfiguration-get?view=graph-res...

 

Open Graph Explorer by login to URL https://developer.microsoft.com/en-us/graph/graph-explorer and Sign in with Global Administrator of tenant.

 

Run query GET  https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurat...

 

In general will permission error after running above command as we need to provide consent to "Policy.ReadWrite.AuthenticationMethod" permissions.

 

Next to user account --> Click on settings button--> Select permissions--> Select Policy.ReadWrite.AuthenticationMethod and click on consent and save it.

 

After running GET query  https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurat....

 

found Option "isSelfServiceRegistrationAllowed" is set to FALSE which means self-registration for security key is not enabled.

 

Run query PATCH https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurat...

In Request body "{

"@odata.type": "#microsoft.graph.fido2AuthenticationMethodConfiguration",

"isSelfServiceRegistrationAllowed": "true"

}

 

Now the value is true.

 

Hope this helps!

 

//Jasper

Brass Contributor

Wow that worked, thanks a million. I have never used MS Graph before. It looks pretty powerful. I can carry on testing now.

 

Cheers

 

Danny

Brass Contributor

@Jasper_HDa 

 

I spoke too soon. Now I am unable to change the target of the 

Authentication method policy (Preview)
as any changes I make are not saved......aaaaaarrrrrggghhhhh!!!!!
 
Wait, managed to fix it by resetting the settings a couple of times, which let me set different targets...
Brass Contributor

I have enabled Conditional Access and now get prompted fo MFA when using Chrome browser. This is a known issue because Azure is NOT seeing Chrome as a joined device. I have tried the workaround using the extension from MS but am still getting the issue. I am on Win10H2. Any ideas?

Brass Contributor

@Danny69 Chrome with the Windows Accounts extension works fine over here on trusted devices. What is your CA policy? And lookup in Azure AD on the authentication logging why MFA was triggered.

Portal.azure.com goto Azure AD goto Users, select the correct user and verify his/her "sign-in activities".

Brass Contributor

@Frank Rijt-van  i am just testing CA. I am testing my own account, by giving grant condition to office365 when either the device is Hybrid azure joined (on prem bound to AD) or MFA is passed. On Edge browser, I am not prompted to give MFA, but on Chrome browser on the same laptop I am. I have briefly googled, and it looks like I am not alone. Could there be an issue with Win10 2004H2?

Brass Contributor

The signin logs affirm what I thought.

 

Device ID
0475b044-83fa-4eda-be7b-edcc6a23b7c1
Browser
Edge 86.0.622
Operating System
Windows 10
Compliant
No
Managed
No
Join Type
Hybrid Azure AD joined
 
whereas with Chrome the info is not being passed to Azure and it is classed as an untrusted device....
 
Device ID
 
Browser
Chrome 87.0.4280
Operating System
Windows 10
Compliant
No
Managed
No
Join Type
 
Brass Contributor

https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji

 

The latest comments on this shows that there appears to be a bug and a fix is on the way.

Copper Contributor

Thanks guys. Self service for security works now again. The option appears again in the GUI. 

Brass Contributor

Is anyone else seeing issues using CA with Chrome browser. It is not detected as a trusted device. This is now driving me mad. Works fine on Chromium Edge.

Brass Contributor

A fix is on the way according to MS. 

  • Addresses an issue that prevents access to Azure Active Directory (AD) using the Google Chrome browser because of a Conditional Access policy error.

For all builds of Win10

 

https://wccftech.com/windows-10-kb4586819-18362-1237-and-18363-1237/

 

Version history
Last update:
‎Aug 03 2020 01:49 PM
Updated by: