I engaged in a conversation on the internet where it was stated that there isn’t a way to restrict FIDO2 authentication methods for specific set of users. Well, there kind of is. And in this short blog post I’m going to walk you through how it can be done. It’s not such an elegant solution that you could scale it to be your organization wide go-to-solution, but for a smaller number of specific users this works really well and is still easily maintainable. Let’s start!
Setting the goal
In this blog post I’m going to introduce a way to restrict FIDO2 authentication methods that can be used to further narrow down FIDO2 options from the tenant wide restriction.
The problem
The problematic scenario we’re introducing is this:
- We’re configuring our tenant’s emergency access accounts, two of them
- We’re excluding these accounts from all conditional access policies except the one that only targets emergency access accounts
- We want to use the strongest authentication methods available, but we would not want to allow (legitimate or illegitimate) registering of other methods
- We want to control what specific passkey authentication method our EA accounts can use
Instead of emergency access accounts, this could be any small set of important highly privileged accounts given your circumstances.
The solution
So how do we go about restricting the passkey method?
“Tenant wide” restriction
I used quotes because it’s not literally tenant wide as we can also choose to target specific groups instead of ‘All users’. This setting can be found from Entra ID > Security > Authentication Methods > Policies > Passkey (FIDO2)
From here we can use the ‘Configure’ tab to restrict passkeys using AAGUIDs. We can choose to either allow or block these AAGUIDs. Here we’re allowing three specific ones. Notice that the AAGUID is not a unique GUID to a specific device or hardware security key. It’s a GUID that refers to a model of a passkey.
Okay, this is the first option we have to configure passkeys in our organization. This restriction affect authentication method registration. If Passkey (FIDO2) method is enabled and ‘Allow self-service set up’ is set to ‘Yes’ then users can register passkey methods in aka.ms/mysecurityinfo.
If you want to restrict passkeys to only allow specific ones, then set ‘Enforce key restrictions’ to ‘Yes’. Then choose the either Allow or Block action and add AAGUIDs to the list.
Okay, we’ve got passkeys enabled and restricted for all users, users can register and start using them. If we’d start scoping out targeted users here, we would create a situation where some organizational users could not register passkeys for their protection and that’s not what we want. So how do we target our emergency access accounts then?
Custom authentication strength as secondary control
There’s a secondary control that you can use to further configure and target authentication methods using Conditional Access Authentication Strengths. This control does not affect the authentication method registration experience, but affects the use of the methods during sign-in.
Let’s create one: we’re navigating to Entra ID > Security > Authentication Methods > Authentication strengths > New authentication strength
- Give your authentication strength a name and description
- Check the Passkeys (FIDO2) box
- Click on ‘Advanced options’
Let’s input one of our AAGUIDs we had in our “tenant-wide” policy here and save the authentication strength.
Now we should have our new custom authentication strength where we have restricted the passkey requirement using allowlisting for AAGUIDs. We now need to still target this to our emergency access accounts though. In my test environment I had an user account called Nestor acting as EA account.
Because we couldn’t use any other control to restrict targeted users, we’re using Conditional Access policy where the policy assignment can be targeted to our specific users (finally). We’ll also utilize our newly created authentication strength where we require our specific passkey and no other passkey or authentication method satisfies this requirement.
So here we go! We’ve no achieved our goal of restricting user sign-in for our specific accounts (emergency access accounts) without ruling out other users of passkey usage.
Reasoning
In the case of emergency access accounts, we actually do prefer FIDO2 passkeys because they are among the strongest methods out there and also because they are quite resilient as well. It’s often the case that some admins in the organization have access to the emergency access accounts. So much so that they could either by mistake or by purpose register additional authentication methods for the EA account like Microsoft Authenticator that is linked to their mobile phone. By requiring a specific passkey AAGUID that we store in a safe place we throw yet another obstacle in a defense-in-depth fashion to our adversary’s way.
I must include that for me this is absolutely not a mandatory configuration to be able to say that your EA accounts and process is safe.
Testing the solution
I also wanted to test the scenario. The idea is basically this:
- Have an user account that has two passkey methods registered
- Using the custom authentication strength, require that only one of the registered methods can be used to sign-in to Microsoft Admin Portals
- Test sign-in
- Using the passkey that does not meet the requirement
- Using the passkey that does meet the requirement
Forbidden passkey
Let’s try signing in with our passkey that is not Yubikey Bio. We’ll input the Security key PIN code and hit OK
We get the red text error stating that our passkey does not meet the criteria and that we should try a different passkey. Fair enough! Let’s try a different one.
Allowed passkey
Because our other key was not up to the requirements, let’s try a passkey that should meet the AAGUID allow-list criteria. This time our physical passkey has a fingerprint reader that we need to touch.
And we got in to Azure Portal using this method.
Logs
I wanted to check what the logs say about the failed sign-in attempt. In the below image, we have the failed sign-in marked with a green rectangular. What seems a little surprising to me is that the Conditional Access = Not Applied. Let’s open more details about this log row.
We can here see more details like the Sign-in error code and Failure reason
Authentication Details shows us our method that did not meet the requirement.
And Conditional Access tab maybe surprisingly states that none of the policies were applicable. I wonder how this works. Because it basically has to check at least three things from the CA policy before it can doom the sign-in event as failed.
- User
- Application
- Grant control: Authentication strength requirement
For my case here, this was almost everything that the conditional access policy had configured so I expected to see my targeted policy here listed.
Summary
Restricting FIDO2 passkeys like this is doable, it works, but using this in large scale would expose the poor scalability as it is hard to track the advanced passkey configurations made inside the custom authentication strengths which do act as the secondary layer of passkey configuration in the tenant. But for some specific scenarios like the EA accounts or Global Admins etc. this might be the only way at the moment how you could further restrict passkeys beyond the authentication method policies.
Stay secure!
