In this blog post, I’ll provide a step by step guide on how to enforce admin reauthentication when elevating a role in Azure Privileged Identity Management (PIM) using a Conditional Access policy.
But why would you want an admin to reauthenticate?
Once an admin signs in to the Azure portal, they typically don’t need to authenticate again during that session. Sounds convenient, right? But here’s the problem. If an admin needs to access PIM to elevate their role, they can do so without reauthenticating, because they’re already signed in. This creates a potential security risk. If a bad actor gains access to an authenticated session, they could elevate the admin’s role and cause serious damage to your environment.
By enforcing reauthentication through Conditional Access, you add an extra layer of protection. The admin will be required to verify their identity again before they can elevate to a privileged role, helping to prevent unauthorised access and safeguard your platform.
In this blog post I will:
create an Authentication Context.
create a Conditional Access policy (including the Authentication Context), that prompts for reauthentication when an admin attempts to elevate a role in PIM.
associate the Authentication Context with a PIM role
test the configuration
Task 1:Create an Authentication Context
Authentication Context can be used to enhance the security of data and actions within applications. These applications might include your own custom apps, line of business (LOB) solutions, SharePoint, or services protected by Microsoft Defender for Cloud Apps.
For example, an organisation may store files in SharePoint sites, ranging from something simple like a lunch menu to something more sensitive like a secret BBQ sauce recipe. While everyone might have access to the lunch menu site, access to the secret BBQ sauce recipe site could require users to be on a managed device, use a FIDO2 security key, and accept specific terms of use. Authentication Context can help enforce these policies.
Authentication Context can also be applied in Privileged Identity Management (PIM). For instance, you might require administrators requesting high privilege roles, such as Global Administrator, to authenticate using a FIDO2 key, only allow access from a trusted location, a compliant device and so on.
In this blog post, we’ll focus on a specific use case, prompting administrators to reauthenticate before an admin role is assigned to them via PIM.
In the search bar, type Conditional Access and click Microsoft Entra Conditional Access
3. From the left pane, click Authentication Contexts
4. Enter a name, description and click save
Task 2:Create a Conditional Access policy and associate it with the newly created Authentication Context
Click Policies from the left pane and + New policy
Give your policy a suitable name
Target the users/groups
Click target resources. From the drop down (Select what this policy applies to) click Authentication Context.
The Authentication Context I created earlier is visible for me to select.
Don’t save changes just yet
Continue to step 2 below
2. Scroll down and click sessions
Click Sign-in frequency
Click Every time
Click the select button
3. Switch the toggle to on and click create
Note: You may wish to leave the toggle on report only mode which will ensure the policy does not apply but will provide you with audit logs. Once convinced all is working as it should do, you can enforce the policy by turning it on. Ensure you test with a group of pilot users.
Task 3: Assign the Conditional Access policy to PIM
Search for and access PIM (Microsoft Entra Privileged Identity Management)
2. In this example, I’ll be assigning the Authentication Context I created earlier to the User Administrator role. I have a demo user name Darren who has been assigned the User Administrator Role in PIM. Darren is able to elevate/request for the role and the role is automatically removed after a number of hours.
3. From the left pane, click roles. Search and click User Administrator
4. From the left pane, click Role settings
5. Click Edit to access the default settings.
6. Click the option Microsoft Entra Conditional Access Authentication Context. The Authentication Context I created earlier is visible, which is attached to the Conditional Access Policy which forces the admin to reauthenticate every time.
7. Click update
Task 4: Test the Reauthentication Policy
I’ll be logging in to Azure Portal with a demo user named Darren. I have already assigned Darren’s account to the User Administrator through PIM. Therefore, Darren is eligible to activate this role when needed. Darren is also included within the Conditional Access Policy scope.
I login as Darren and go through MFA
Note: we’ll see the Authentication Context and policy trigger later
2. Whilst logged in as Darren, I search for PIM and click my roles from the left pane.
Click activate
3. Darren is presented with a message requesting for additional verification.
4. Click the message: A Conditional Access policy is enabled and may require additional verification. Click to continue
5. Darren is prompted to login again (reauthenticate)
6. and after reauthenticating, Darren can continue to active the role.
Passkeys in the Microsoft Authenticator app using an iPhone
Setting up a passkey via a physical Yubikey 5 (usb-c)
Note: This post is targeted at users who want to set up passkeys in the Microsoft Authenticator app or register a physical key. Your administrators must have enabled the capability to use passkeys before you can complete the steps below. To use passkeys via the Authenticator app, you need Android 14 or later, or iOS 17 or later (at the time of writing this post). Additionally, make sure that your Microsoft Authenticator app is updated to the latest version.
Configure Passkeys in the Microsoft Authenticator App on an iPhone
Access https://mysignins.microsoft.com and login
Click security info from the left pane
Click + Add sign-in method
4. Click the option, Passkey in Microsoft Authenticator
5. You may be prompted to go through MFA before you are able to add a new sign-in method. Please continue with this. When done, continue to step 6.
6. Read the pre-reqs and click next
7. Don’t click Next just yet. You will need to follow the instructions mentioned on your screen first.
Open the Microsoft Authenticator app on your phone. Tap on the account/email address you will be setting this passkey for. Keep the app open while you proceed with the setup.
Click Create a passkey. If this option does not appear, ensure that you have met the pre-reqs I mentioned at the beginning of this post.
8. You will be prompted to sign-in. Click the Sign-in button and login
9. If it is the first time you’re setting up a passkey via the Microsoft Authenticator app, you’ll be prompted to enable a couple of settings on your phone before you are allowed to continue.
10. We’re done with the configuration on the phone. Continue to the step 11 below.
11. Return to your laptop/desktop and click next to complete the process.
That’s it. If you’re interested in configuring a physical key, such as a YubiKey, the next section goes through the process.
Configure a passkey via a physical Yubikey 5 (usb-c)
Access https://mysignins.microsoft.com and login
Click security info from the left pane
Click + Add sign-in method
3. Click the option Security key
4. You may be prompted to go through MFA before you are able to add a new sign-in method. Please continue with this. When done, continue to step 5.
5. Select the type of security key. I select USB device
6. Have your physical key ready, after clicking next, you’ll be prompted to plug it in.
7. Click next and then select Security key (If this option does not appear, click the option other ways to sign-in and then click Security key). Click next.
8. Read and click OK
9. Read and click ok
10. You will be prompted to insert you physical key
11. You will be prompted to create a new PIN
12. Your physical YubiKey will flash and you will be prompted to place you finger on it
13. Passkey saved, click ok
14. Finally, you will be prompted to give your Physical key a name so you can easily identify it.
15. Done
I hope you found this post useful. Catch you at the one
In this blog post, I demonstrate how to use an Adversary in The Middle (AiTM) phishing attack to capture a user’s session token utilising a tool called Evilginx. There are several methods to protect against such attacks and I will be concentrating on phishing resistant MFA.
IMPORTANTDISCLAIMER: The user accounts involved are demo user’s. The information provided in this blog post is intended for educational and demonstration purposes only. Evilginx is a powerful tool that can be used to steal session tokens, which can lead to unauthorised access to user accounts. This tool should only be used for legitimate penetration testing on systems where you have explicit permission to do so. Unauthorised use of Evilginx or any similar tool is illegal and unethical, and can result in severe legal consequences. Always ensure you have proper authorisation before conducting any security testing.
What is Evilginx? Evilginx is an advanced phishing framework that provides a way to bypass multi-factor authentication (MFA) protections by capturing session tokens. It operates as an Adversary-in-The-Middle (AiTM) proxy, intercepting communication between a victim and a legitimate service to steal authentication credentials and session tokens. Unlike traditional phishing attacks that trick user’s into divulging their passwords, Evilginx focuses on obtaining credentials and session tokens, enabling attackers to login without entering user credentials. This makes it a powerful tool for penetration testers and security researchers who need to assess the resilience of their systems against such sophisticated attacks, however, it can also be used by bad actors.
Here’s how it works in few steps:
Attackers create fake login pages that look almost identical to legitimate ones, such as login pages for Microsoft, Google, Facebook and more.
When user’s enter their credentials, Evilginx captures them and forwards them to the real site, making it seem like a normal login process.
It can also intercept multi-factor authentication (MFA) codes, allowing attackers to gain unauthorised access.
This makes Evilginx particularly dangerous because of its capabilities to bypass security measures like MFA.
To protect yourself, always verify the URL of the login page, use phishing resistant MFA, and be cautious of unexpected login requests.
Let’s dig deeper and understand the process via the diagram below
How does Adversary-in-The-Middle (AiTM) take place using Evilginx
Click the image below to enlarge
Now, let’s see the process in action
Note: I’ve already installed and configured the Evilginx application.
Let’s explore how Evilginx can capture a user’s session token and gain access to data.
I launch Evilginx on my server
2. I type:
lures create microsoft365 lures get-url 0
Click image to enlarge
3. I copy the fake url as shown in the image above. A malicious actor typically requires the user to click on this URL, often distributed through a phishing email.
For demonstration purposes, we’ll assume that the a real user has clicked the malicious link received through a phishing email.
I launch a browser and manually enter the URL of the fake login page.
Enlarge the image below.
Question: Can you spot anything suspicious in the image below?
In case you didn’t spot the suspicious detail, take a closer look at the website address, the letter ‘o’ in ‘micros’ has been replaced with a zero.
Bad actors often use cloned login pages that can appear convincing and legitimate. This highlights the importance of continuously educating ourselves and others about the risks of phishing attacks.
⚠️ WARNING: Please do not attempt to access the fake URL shown above on your own device.
4. Now, let’s assume the user proceeds to log in. For this demo, I’ll be using a test account:
This account is protected with multi-factor authentication (MFA) using the Microsoft Authenticator app. However, it’s important to note that I am not using phishing-resistant MFA.
I proceed to log in via the fake login page. Meanwhile, the Evilginx application is actively listening and capturing authentication logs in the background.
5. I click Next and am prompted to enter my password to authenticate with Microsoft Entra ID.
6. I enter my username and password, then click Sign in. I complete the MFA challenge via my Authenticator app when prompted. As mentioned earlier, this account does not currently use phishing-resistant MFA.
After logging in, I am briefly signed in before being automatically logged out. However, by this point, the Evilginx tool has already captured the necessary authentication information.
7. Let’s take a look at what Evilginx has captured.
8. At this point, I have successfully captured the user’s credentials, including the username and password, through the fake login page.
Evilginx has now captured the user’s session, including the MFA acceptance, a critical point in demonstrating how traditional MFA can be bypassed in such attacks. Let’s dig a little deeper.
9. I run the sessions command and can see that the username, password, and session token have all been successfully captured.
10. I type sessions 13 and press Enter to inspect the captured session in more detail.
11. The session token is now visible, this includes the full session data that Evilginx has intercepted, allowing an attacker to potentially hijack the authenticated session without needing the user’s credentials or MFA prompt again.
12. Next, I prepare to replay the stolen session token. I highlight and copy the token from the Evilginx output.
13. I’ve downloaded Firefox and installed a cookie editor extension to assist with injecting the session token.
14. I launch Firefox and navigate to https://office.com.
15. I click the Sign in button on office.com and am redirected to the official Microsoft login page.
16. I clear all existing cookies using the cookie editor extension.
17. Inside the cookie editor, I click the Import option and paste the stolen session cookie. I then click Import again.
I return to the fake login page. I type my username and click Next, but instead of entering a password, I select the option: Use your face, fingerprint, PIN, or security key instead, as shown in the image below.
2. I’m prompted to use a security key, but this prompt is for the fake domain (login.micr0soft.com). My passkey is registered to the legitimate domain (login.microsoft.com), so authentication fails. As a result, Evilginx is unable to capture the session token.
No sessions saved by the Evilginx app
I hope this post was useful. Thanks for reading and see you at the next one.
In this 2 post blog series, I’ll explore emergency “break glass” account best practices, the importance of phishing resistant MFA (Multi Factor Authentication), how phishing-resistant MFA can protect against credential and session token theft via a phishing attack by a bad actor, and finally I will go through a step by step demo on configuring a physical FIDO2 (Fast Identity Online) supported passkey, specifically a YubiKey. I purchased a YubiKey for 30 euros from Yubico. Please note that Yubico offers various types of YubiKeys including different types of USB connectors and physical keys which meet different compliance standards, so it’s essential to research your options before making a purchase. Additionally, since FIDO2 is an open standard, several other vendors offer physical keys, giving you multiple options to choose from.
IMPORTANTNOTE Part 2 will provide a detailed, step by step demo on configuring a YubiKey. I recommend reading this post (Part 1) first to understand best practices and how FIDO2 works to secure your account. However, if you wish to skip to Part 2, click the following link: Part 2 – Configure a YubiKey For An Emergency Access Account In Entra ID | Cloud Build
Image of a Security Key NFC (Near Field Communication) by Yubico. This is the key I purchased.
Explanation of NFC: Near Field Communication (NFC) is a wireless technology that enables devices to communicate with each other when they are in close proximity, typically within a few centimetres. Think about when you touch your card or Apple Pay on your phone against a card reader to make a payment. If supported, you can utilise the NFC capabilities allowing you to touch they key on a NFC reader built in to your phone or a internal/external NFC reader built in to your laptop.
As mention above, part 2 covers the step by step demo, so before diving into the steps for configuring my YubiKey as a secure phishing resistant MFA method, I’d like to go through some important points, starting off with best practices you should consider when setting up an emergency access account.
Emergency Access “Break Glass” Account Best Practices
Emergency accounts also known as break glass accounts are crucial accounts that provide access to critical systems during an emergency. Microsoft recommends that organisations have two cloud only emergency access accounts permanently assigned the Global Administrator role. These accounts are highly privileged and should not be assigned to specific individuals. They are limited to emergency scenarios only and where normal accounts can’t be used or all other administrators are accidentally locked out. Here are a few points to note when creating your emergency break glass accounts:
Assign Both Emergency Accounts Permanent Global Administrator:
Having two break glass accounts ensures that if one account becomes inaccessible, you have a fallback account.
Use Non-Obvious Names:
Avoid obvious names like emergency@.onmicrosoft.com or breakglass@.onmicrosoft.com. Instead, use random human names to make the accounts obscure, making it more challenging for attackers to target them during attacks like password spraying.
Create Cloud Identities:
Create your break glass accounts using the *.onmicrosoft.com domain inside Entra ID. Avoid syncing accounts from on-premises to prevent access issues if on-premises systems fail.
Configure Complex Passwords:
Use strong passwords, ideally with a minimum of 16 characters as recommended by Microsoft at the time of writing this post. Although it is possible to create passwords up to 256 characters long, a minimum of 32 characters is common. Feel free to increase the length of the password as per your requirements. However, be aware that no matter how strong the password, bad actors can still steal user credentials via a phishing attack, therefore still a potential risk and the reason why it is recommended to use phishing resistant MFA, such as FIDO2 supported devices. More on this later.
Secure Password Storage:
If you’re using passwords, follow Microsoft’s recommendation to separate the password into two or three parts, write each part on separate pieces of paper, and store them in secure, fireproof safes in different locations. Ensure only authorised individuals have access.
Use Phishing Resistant MFA:
For multi-factor authentication (MFA), use a phishing resistant method like a FIDO2 Security Key. Again, ensure you store these physical keys in a safe location and only allow authorised individuals access.
Audit and Monitor Access:
Configure monitoring to notify you if the emergency break glass accounts are used, allowing for swift action.
Diversify MFA Methods:
Avoid using the same MFA method as your admins. For instance, if admins use passkeys via their phones or certificate based authentication (CBA), use a physical pass key for the emergency accounts to avoid issues affecting mobile devices such as a wider mobile network outage.
Avoid Assigning to Individuals:
Do not attach break glass accounts to an individual, such as an engineer’s mobile phone, to prevent issues if the person is unavailable. Just imagine if that individual is on holiday, it’s not good practice from both a convenience and security point of view.
Exclude from Conditional Access Policies:
Ensure at least one emergency access/break glass account is excluded from all Conditional Access policies.
Regular Validation and Documentation:
Validate your emergency accounts every 90 days or sooner if needed. Document a step by step process to allow authorised IT staff access to the accounts in emergencies. Training and clear documentation are crucial. The last thing you want is to discover an issue during a real emergency which could have been prevented through testing and validation.
Now that we have covered best practices for emergency break glass accounts, you may have read or heard that Microsoft announced mandatory multi factor authentication (MFA) will be enforced for Azure sign ins. This will gradually be rolled out to other portals, such as admin.microsoft.com, and more. So, what does this mean? Well, any user account logging into the admin portals will be required to enable MFA before they can log in.
Previously, it was possible to log into the Azure portal using an account without MFA enabled, but this will no longer be possible going forward. Why? Because one of the most effective security measures available to organisations is multifactor authentication (MFA). Research by Microsoft shows that MFA can block more than 99.2% of account compromise attacks. Since emergency accounts are commonly used to log into admin portals, these accounts are not exempt from this new rule. Attackers could exploit emergency break glass accounts to access your environment with Global Administrator privileges and cause significant damage. Previously, a large number of organisations would create emergency break glass accounts without enabling MFA, which was normal. However, this recent announcement from Microsoft means that organisations will no longer be allowed to login to admin portals using any account including emergency break glass accounts with a password alone. MFA must be enabled with phishing resistant MFA being highly recommended, however, other MFA methods are allowed. In my opinion, it makes sense to secure these highly privileged accounts.
Great, we’re nearly there. What’s next? I would like to provide a quick overview of passkeys and how passkeys can protect you against a bad actor stealing user credentials and session token via a phishing attack using tools such as Evilginx. Let’s learn more.
What are passkeys? Passwords can be compromised through various methods, including phishing attacks, regardless of their complexity. FIDO2 supported passkeys enable phishing-resistant, passwordless authentication. They replace weak credentials with strong, hardware backed public/private key credentials, reducing the chances of user credentials and session token being stolen.
A common attack method involves a bad actor attempting to steal user credentials by tricking them into clicking a malicious link. Adversary in the Middle (AiTM) attack tools, such as Evilginx, can intercept communication between the user and login providers like Microsoft, Facebook, or Google, capturing the necessary information to access the user’s data. Evilginx is capable of capturing session cookies, which validate a user’s session after MFA is completed. Put simply, Evilginx can bypass non-phishing resistant MFA, making it ineffective and allowing unauthorised access to the user’s data.
When configuring a FIDO2 supported method, such as a physical YubiKey, the process involves the generation of two keys:
A private key, which remains on the physical YubiKey and never leaves the device. This is similar to how other phishing resistant methods function, such as Windows Hello For Business. This private key never leaves the physical device, so in the case of a YubiKey, the private key is stored securely on the YubiKey. With Windows Hello for Business, the private key remains on the device, such as the laptop, stored in a secure TPM (Trusted Platform Module).
A public key is provided to the relying party. In my case, the relying party is Microsoft, because I’ll be using my FIDO2 supported physical passkey to log in to admin portals such as the Azure portal.
Because passkeys are phishing resistant, they are highly recommended. Apart from physical FIDO2 security keys, there are other phishing resistant MFA methods available, including Certificate Based Authentication (CBA), passkeys via the Microsoft Authenticator app and one I mentioned earlier, Windows Hello for Business.
Why are passkeys secure? When configuring a passkey, there are a number of security features that prevent a hacker from misusing your credentials. One of the key security features is proximity, which means the user must have proximity between the authenticator and the laptop. In this case, the authenticator could be a physical FIDO2 security key or a passkey on the Authenticator app. This prevents users from being tricked by a bad actor, for example, if the bad actor attempts to steal a user’s session token via a phishing attack, it would be of no use, because the hacker is most likely sitting someplace far away from the laptop, and therefore the proximity check fails and access is denied.
Another important security feature is that the FIDO2 supported device is tied to a specific website address or relying party. This means that if a bad actor tries to fool the user by directing them to a fake URL via a phishing attack, the authentication attempt would fail when the user attempts to use their phishing resistant device, such as a YubiKey. This is because the private key stored on the device will only respond to the specific website it was originally registered with. So, even if a hacker tries to mimic the real website by creating a good looking clone pointing the user to login.micr0soft.com (disguising the o for a zero), the FIDO2 supported key won’t complete the authentication process because it was originally registered against login.microsoft.com and not the fake login.micr0soft.com.
Still confused? I demonstrate the YubiKey registration process in the diagram below.
Click the image below to enlarge.
How does a hacker steal user credentials and session token?
One of the methods I am focusing on in this post is where bad actors steal user credentials via a phishing attack, by fooling the users to click a link which directs the user to fake login page. The user assumes that they are accessing a genuine login page and upon the entering a username, password and even going through non-phishing resistant MFA, the bad actor captures the users session token and then replays it on their own device. Yes, there are tools such as Evilginx which can bypass MFA. This allows the hacker direct access to the user’s data such as email, one drive data and so on, without having to authenticate again.
In the video below, Merill Fernando (Principal Product Manager @ Microsoft Entra) demonstrates how Evilginx works and provides a couple of controls which can prevent such an attack when an Adversary in the Middle (AiTM) attack tool such as Evilginx is used.
DISCLAIMER: Evilginx has the potential for malicious use. It’s crucial for defenders to account for such attacks and devise strategies to safeguard their users from these types of phishing threats. Evilginx should only be employed in lawful penetration testing engagements with explicit written consent from the targeted entities or for educational objectives.
Note While phishing-resistant MFA provides strong protection against phishing attacks and greatly reduces the risk of credential theft, it does not completely prevent token theft, for example, if a bad actor uses malware on a user’s device. This is why it’s essential to adopt a defense in depth strategy, which includes multiple layers of security measures, including endpoint protection on your devices.
In the below video Alex Weinert (VP Identity Security at Microsoft) provides several solutions to help protect against token theft.
Passkeys Available via Phone Using the Authenticator App In the next post, I demonstrate how to set up a physical FIDO2 support passkey from Yubico. However, I wanted to mention that passkeys are also available without needing to purchase a physical key. Modern smartphones come equipped with built in FIDO2 authentication capabilities, providing you with phishing resistant protection and allowing you to use biometric features like fingerprint or face recognition as passkeys. With the Microsoft Authenticator app, you can register and use these passkeys on your iPhone or Android phone to securely log into your accounts. This provides a convenient and cost effective way to enhance your online security without having to purchase physical security keys.
I know what you’re thinking! “If passkeys are available for free using phones via the Authenticator App, why should I purchase a physical key?”
Great question! While passkeys on smartphones offer a great level of convenience and security, there are several reasons why an organisation might still opt for physical security keys. Here are a few benefits:
Device Flexibility: Physical passkeys can be used with any device, including shared workstations, without relying on employees’ personal mobile phones. If you don’t allow the use of personal mobile phones in your organisation, you could purchase physical passkeys.
Enhanced Protection: Physical keys can offer an extra layer of protection against malware and other attacks that might target vulnerabilities in mobile devices.
Compliance Requirements: In some industries, compliance requirements may mandate the use of physical keys. Therefore, while smartphone based passkeys are excellent for many users, physical keys still play a crucial role depending on your organisational requirements.
Emergency Break Glass Accounts: A physical FIDO2 key would be a better option than a mobile phone for an emergency break glass account. It ensures that access is not dependent on the availability or functionality of a specific mobile device. YubiKeys don’t contain moving parts and are designed to be simple and robust, with a solid construction that contributes to their reliability. They don’t require batteries or an external power source, as they draw power directly from the USB or NFC connection when in use, making them ideal for offline storage and offsite locations.
In Part 1, I covered emergency account best practices and the benefits of FIDO2 supported passkeys. If you haven’t read the post, I highly recommend doing so to get a understanding of the foundational concepts and best practices that will enhance your overall security. It’s worth the read! You can check out part 1 by clicking the following link Part 1 – What is a FIDO2 key and How to Set One Up for Emergency Access in Entra ID | Cloud Build
In this blog post, I will guide you through the step by step process of configuring a YubiKey purchased from Yubico. As explained in part 1, the open standard technology used under the hood is FIDO2, which is also used by other vendors. It’s not only Yubico that provides these FIDO2 based security keys.
Now that you have had an overview of passkeys and how bad actors steal user credentials and session token, let’s continue to part 2, enabling my YubiKey (FIDO2) which I purchased from Yubico.
Access entra.microsoft.com
Click protection and authentication methods from the left pane
3. Click Passkey (FIDO2) which is set to disabled by default
4. Click the toggle to enable, click select groups and then browse and locate your security group in which your emergency break glass account is a member of. In my case, I have created a DemoGroup which includes the emergency break glass account.
5. Next, click Configure
6. There are several default configuration options. Let’s go through these one at a time.
Allow self-service setup The default option is set to yes, which means users can self register a passkey by logging into the my sign-ins portal accessible via https://mysignins.microsoft.com/security-info. If set to No, users can’t register a passkey.
Note: Currently in preview, administrators can use Microsoft Graph and custom clients to provision FIDO2 security keys on behalf of users. At the time of writing, there is no option to provision FIDO2 keys on behalf of users via the Azure or Entra portal, therefore, users have to enable this capability themselves via the my sign-ins portal I shared above. Public preview: Microsoft Entra ID FIDO2 provisioning APIs
Enforce attestation The next option is Enforce attestation.
When this option is set to Yes, Microsoft relies on the FIDO Alliance Metadata Service (MDS) to determine security key compatibility with Windows, Microsoft Edge browser, and online Microsoft accounts. The FIDO Alliance Metadata Service (MDS) is a centralised repository of the Metadata Statement that is used by the relying parties to validate authenticator attestation and prove the genuineness of the device model. Vendors such as Yubico report data to the FIDO MDS. Vendors are responsible to publish all root attestation certificates to the FIDO Alliance MDS; otherwise, attestation verification can fail. In simple terms, attestation involves performing a check against a central verification database to ensure the FIDO2 key being used is listed and verified in a central database.
Administrators can enforce which hardware security key providers are allowed in their environment. For example, an organisation may only allow particular models of YubiKey deny all other providers. YubiKeys are identified by a AAGUID which can be accessed at the following url, YubiKey Hardware FIDO2 AAGUIDs – Yubico
I purchased a security key NFC with firmware version 5.7. Accessing the link above, I’ll be able to locate the unique AAGUID for this model of device. If I enter the AAGuid into the configuration within EntraID, only this model of security key will be allowed in my organisation. I could add additional AAGUIDs if needed.
If you wish to use passkeys in Microsoft Authenticator, clicking the check box labelled Microsoft Authenticator automatically adds the two AAGUIDS for Apple and Android to the list, allowing you to use passkeys in the free Microsoft Authenticator app. If you wish to learn more, click the following Microsoft Learn link, How to enable passkeys in Microsoft Authenticator for Microsoft Entra ID
The images below show how an AAGUID is added and include the check box to enable passkeys in Microsoft Authenticator. I won’t be covering passkeys in the Microsoft Authenticator app but you can learn more at the link I posted above.
Ok, we’re done. The option to use PassKeys (FIDO2) is enabled.
The user experience
In the next steps, I will login using my emergency break glass account and enable the option for physical PassKeys.
5. I am required to configure MFA before I can enable a security key. I click next.
6. Click Next again
7. I already have the Microsoft Authenticator App installed on my phone. I click next
8. I open the Authenticator app on my phone and scan the QR code provided
9. A two digit code appears on screen and a prompt on my Microsoft Authenticator App requesting I enter the two digit code. After entering the code, I receive a notification approved message.
12. I click add sign-in method and select Security Key again. This time I receive two options. I click USB device.
13. Click Next. If I had selected NFC in the step above, I would receive the message below. By selecting USB, the message would be similar but there would be no mention of “tap your security key on the reader”.
14. I am redirected to Windows Security. I select Security key and click Next
15. I click ok
16. Click ok. Notice the key will be locked down to login.microsoft.com. If a bad actor attempts a phishing attack and redirects the user to a fake url, the YubiKey will not allow access and authentication would fail.
17. I am prompted to insert my YubiKey into my laptop. Plug the physical key into the USB port depending on which USB device you purchased.
18. Once the YubiKey is detected, I am asked to create a new pin. This pin will be stored inside my YubiKey.
19. After creating a PIN, I am prompted to place my finger on the YubiKey and I receive a notification that the Passkey has been saved.
20. Name the Key, for example YubiKey 5 NFC, and click next.
21. We’re all set. Click done
22. The new YubiKey is now visible as one of my sign-in methods.
23. I remove the YubiKey from the USB port in my laptop.
To test the YubiKey. I’ll access portal.microsoft.com
Type my username
Instead of entering a password, I click the option, Use your face, fingerprint, PIN, or security key instead
24. Select Security key and click next
25. I enter the pin I created earlier, and click OK
26. The YubiKey flashes and I am prompted to place my finger on the YubiKey. I’m in.
That’s it.
Enforcing users to use phishing resistant MFA If you wish to enforce the use of phishing resistance MFA for certain or all users, you can use authentication strengths via conditional access policies in Entra ID.
A few points to note
Conditional Access requires Entra ID P1 licenses. It is not a free feature.
Attestation enforcement governs whether a passkey (FIDO2) is allowed only during registration. Users who register a passkey (FIDO2) without attestation aren’t blocked from sign-in if you were to enable the option enforce attestation later.
Enforce key restrictions should be set to Yes only if your organisation wants to allow or disallow certain security key models or passkey providers, which are identified by their AAGUID. You can work with your security key vendor to determine the AAGUID of the passkey or check the vendors website. If the passkey is already registered, you can find the AAGUID by viewing the authentication methods for the user in Entra ID by clicking authentication methods from the left pane. The AAGUID is also visible from the my sign-ins portal.
If your organisation doesn’t currently enforce key restrictions and already has active passkey usage, you could collect the AAGUIDs of the keys being used today. Add them to the allow list and enable enforce restrictions. This task can be completed with an automated script that analyses logs, such as registration details and sign-in logs.
Currently in preview, administrators can use Microsoft Graph and custom clients to provision FIDO2 security keys on behalf of users. At the time of writing, it was not possible to automatically provision the rollout of FIDO2 security keys to users from the portal.
I hope you found this two part blog series useful. Thank you for tuning in and catch you at the next post.
Subscribe
Subscribe to new tech posts.
We will never send you spam email or forward your details to third parties.
