Journey To Passwordless: Restrict FIDO2 key usage & conclusion

Blog series

1. Passwordless: But why?
2. Enable passwordless
3. Temporary Access Pass
4. FIDO2 Security keys
5. Windows 10 device onboarding and Windows Hello for Business
6. PowerShell administration without a password
7. Microsoft Authenticator app
8. Restrict FIDO2 key usage & conclusion

Advanced settings

In the last blogpost of the series it gets a bit more technical. Because for FIDO2 Security Keys as a login method, some additional settings can be configured in the Azure Portal.

• Allow self-service set up
• Enforce attestation
• Enforce key restrictions - Restrict specific keys (Allow/Block)

Allow self-service set up

This setting must remain set to “Yes” as of 07/2021. If this setting is set to “No”, it is no longer possible for a user to add a FIDO2 security key. However, since it is also not possible to register a key for the user, “No” would effectively prevent the use of new keys.

Enforce attestation

If attestation is enforced, the FIDO2 key must identify itself to the Entra ID (Azure AD) (Relying Party) during initial registration.

In order for the FIDO2 key to support this at all, the manufacturer must submit a metadata statement with the supported features of the FIDO2 security key during certification, which is then distributed by the FIDO2 Alliance. For each key model, the vendor assigns an Authenticator Attestation Globally Unique ID which later identifies the exact model.

During the registration process, Entra ID (Azure AD) requests certain features of the key using a policy statement. If no supported security key is found, registration is not possible.

If the key supports all requirements, in this case attestation, the FIDO2 key sends additional information back to Entra ID (Azure AD). In addition to the AAGUID, this includes a signature that is created with the private key of the Attestation Certificate. This private key is written to the FIDO2 Security Key by the manufacturer during production and is not deleted even during a full reset of the key.

The Entra ID (Azure AD) can use this signature to verify that the FIDO2 key really matches the specified model, preventing a FIDO2 key from just pretending to support all requirements. For this purpose, Entra ID (Azure AD) uses the public keys stored in the metadata statement or checks whether the signature was signed by a certificate (trust chain) specified in the metadata statement.

Authenticator Attestation GUID (AAGUID)

The Authenticator Attestation Globally Unique ID is a unique identifier with a length of 128 bits. It is assigned by the manufacturer of the key, whereby it is sufficient for the manufacturer to define one AAGUID per model series. In the case of Yubikey, there are also some duplicates since the AAGUID does not refer to the interface of the key (e.g. USB-C or USB-A), but to the installed security chip.

The format corresponds to RFC4122 and is represented as five hexadecimal segments separated by a dash.

Example: 0076631b-d4a0-427f-5773-0ec71c9e0279

This GUID can be retrieved from various locations in Entra ID (Azure AD).

Security Info Portal

Each user can display the AAGUID in the Security Info area itself.

Azure AD Portal

As an administrator, you can also access the corresponding information in the authentication methods of the user, via View details.

Graph API

And of course, this info is also available in the Graph API.

https://graph.microsoft.com/beta/users/849189be-c4c1-4873-aabd-570604214c0a/authentication/methods

{
    "@odata.type": "#microsoft.graph.fido2AuthenticationMethod",
    "id": "3f0S9SVSIKt4Ti9ZtgFjSHf7ahkNN3js0FTPe5dPD4o1",
    "displayName": "FEITIAN AllinPass FIDO2",
    "creationDateTime": "2021-05-13T14:19:39Z",
    "createdDateTime": "2021-05-13T14:19:39Z",
    "aaGuid": "12ded745-4bed-47d4-abaa-e713f51d6393",
    "model": "Feitian BioPass FIDO USB/NFC/BLE",
    "attestationCertificates": [
        "4f94e8b002c79416507e9d9d390eca3153e1a5e8",
        "9e3808651ecfa53162772e9d2bc62bfe568350a9"
    ],
    "attestationLevel": "attested"
}

Well known AAGUIDs

The following AAGUIDs are currently known to me. I will expand this list if and when I find more AAGUIDs. Yubico also offers an overview on its own website.

Enforce key restrictions - Restrict specific keys

With this setting you can prevent the use of certain security keys. You have the choice whether you want to maintain a block or an allow list.

A block list makes sense, if it is known that certain FIDO2 keys should not be used, because they do not meet the desired security requirements.

By means of an Allow list, for example, the use of certain FIDO2 keys released by the company could be enforced.

During the setup, the user is not aware of these requirements. Only in the last step of the setup, after assigning a name, the key is rejected.

In the Entra ID (Azure AD) audit log this is displayed as status clientError and the reason User failed to register Fido.

Conclusion

The use cases of passwordless considered in this blog series show how extensively this topic is already supported in the Microsoft cosmos. Especially in environments where users work 100% with cloud services, there is really no reason not to go this route.

In addition to the many security advantages, the sign-in with FIDO Security Keys, especially if they can be unlocked with biometric features, offers a big plus in terms of user comfort. For users, this type of authentication has now become standard with modern smartphones and can finally be used in the workplace. While Windows Hello for Business has offered this for some time with its support for cameras and fingerprint sensors, the use of FIDO2 keys brings advantages in areas where a fixed workstation is not used and work is more likely to be done at a kiosk PC.

Certain limitations, such as the fact that it is not possible to provision a FIDO2 key for an end user, or that they are not yet supported on smartphones, slightly tarnish the positive overall impression. However, there is a good alternative with the Authenticator app.

In an environment that is strongly dominated by Windows 10 clients, the advantages for the user are already enormous. However, if you leave this context, you have to hope for Apple or Google and fall back on the sign-in methods available in ChromeOS and macOS. This is where the convenience for the end user is lessened, especially in the kiosk PC scenarios mentioned above.

What I haven’t examined at all in this series is working in a hybrid environment. Here, too, passwordless work is already possible today, but the planning and implementation effort is much greater. Depending on the usage scenario, it can quickly become necessary to set up a PKI environment or adapt the existing one. These are all no hindrances, but the “rapid” implementation of a PKI also entails major risks.

My excursion into the world without a password does not come to an end here, but the next posts will appear in a separate series and will not be ready in the next few weeks.