Bug: Azure AD doesn't allow adding FIDO2 security keys which use Self Attestation even when Enforce Attestation setting is set to No
Steps to reproduce:
1. Log in to mysignins.microsoft.com/security-info.
2. Add a new sign-in method using a USB security key.
3. Plug in a security key which uses "Self Attestation" aka "Surrogate Basic Attestation", e.g. Trezor T security key with firmware version 2.1.8.
4. Follow the steps of the provisioning process until reaching the very last step where one has to name the newly added key. Observe that up to this point all steps completed successfully.
5. Enter a name for the security key and click "Next".
6. An error message is displayed: "Something went wrong. You may want to try a different security key, or contact your administrator."
The attached screenshots show the Authentication method policy settings in Azure AD. Note that the "Enforce attestation" setting is set to "No" which should allow adding keys that use any kind of attestation method.
I have verified this bug by compiling two versions of firmware for the Trezor T which differ only in the attestation method they use: Basic Attestation vs. Self Attestation. The one using Basic Attestation got provisioned successfully whereas the one using Self Attestation failed provisioning as described above. Interestingly, Self Attestation and Basic Attestation are both supported in login.live.com.
Andrea Giacomin commented
Same problemi with SoloKeys FIDO2 (Solo, SoloTap and Somu) using firmware 4.0.0. With Enforce Attestation enabled the user cannot register the key even if the AAGUID is explicitly allowed in the key restriction policy.
Is there a list of supported FIDO2 keys and the relative AAGUID? What are the keys that works with enforce attestation enabled?
Pim Jacobs commented
If you look at the Trezor website you can see your key isn't supported with Azure AD and only with live accounts (login.live.com).
Rene Yagmur commented
Same issue. I added the aaGUIDs from yubikey into azure ad, but it wont work ether.