How to configure passwordless in Azure AD connected environments

  1. General Introduction
  2. Windows Hello for Business and FIDO2 security keys
  3. Enable FIDO2 security keys
  4. Register a FIDO2 key
  5. Test the FIDO2 key
  6. Configure security keys as a sign-in option in Windows
    1. Enable with Intune for all users
    2. Targeted Intune deployment
    3. Enable with Group Policy
    4. Force sync on a single device
  7. Windows Hello for Business deployment for AAD joined devices
    1. For all users
    2. For specific groups
    3. Force sync on a single device
  8. Conclusion
  9. Sources and additional reads

General Introduction

As we all know, passwords are a weak link in our identity processes. But, contrary to what we believe, your password length is not the main enemy when talking about Azure AD, as long as your passwords are not simple. Instead, the main enemy is that passwords can be easily gathered and reused from phishing attacks or breaches. 

The most common attacks, for example, phishing, password spray and credential stuffing, all rely on the fact that your password is either given by the user to the attacker, guessed because it was really simple, or already exposed to attackers because of previous breaches in 3rd parties attacks. Also, in the case of password spray, Azure AD has functions in play to drastically reduce the speed of password spray attacks and increase the time attackers spend guessing a password.

Image from the Microsoft Docs

Regarding why your passwords mostly don’t matter, Alex Weinert, Director of Identity Security at Microsoft, wrote a wonderful article way back in 2019 that I suggest you read:

Your Pa$$word doesn’t matter | Tech Community

But, if you still need to start modernizing your application log-in processes, and most applications in your environment rely only on either Active Directory or Active Directory Federation Services, please still consider a more complex password. In this case, the standard is usually set at 15+ characters, as when a password is created of more than 14 characters, you don’t store the LM hash for it. Of course, you can also disable LM hashes with GPOs, but most places aren’t doing it.

The aim of this post, though, is to discuss Azure AD-connected systems, applications, and cloud-only environments. 

If you haven’t heard of it, you can either natively attach most applications to Azure AD or use Azure AD Application Proxy. Azure AD Application Proxy allows Azure AD to take the reins by letting it manage the authentication and access to the on-premises legacy applications.

MFA does put a patch on the issue of passwords. For now, if everyone had (preferably strong) MFA on their accounts, the compromises would go way down, as the attackers’ costs would go way up. But, as we said, MFA is a patch, not a permanent fix. 

For example, many companies still rely on legacy authentication methods, which do not support MFA, or there are cases where MFA gets “skipped” with the use of man-in-the-middle attacks (such as the ones that can be conducted using evilginx2). While it’s not really a “skip”, it’s functionally a bypass of MFA functions.

Image taken from

While passwordless methods are more secure and convenient, you should know that there is a better and worse ranking. 

For example, adopting passwordless using the Microsoft Authenticator still puts you at risk of being phished with men-in-the-middle attacks, such as the ones we talked about before, and logging into Windows devices with the Authenticator is not supported at the moment. 

Suppose you have a Conditional Access Policy that requires devices to be compliant. In that case, the Authenticator makes more sense as a passwordless method, as you add an additional layer of verification before accessing your company data.

Image taken from Microsoft Docs

Because FIDO2 Keys are not supported on mobile devices, the Microsoft Authenticator is still the best passwordless option for iOS and Android devices. It’s also a very common method for MacOS and Linux users.

As a side note, most of the time, instead of signing in with the Authenticator, on mobile you’ll be able to select “Sign-in options” and be presented with the option of signing in from another device, such as a desktop, where you’ll be able to use FIDO keys.

You can check out the state of FIDO2 Keys support on mobile devices on this page: FIDO2 Keys compatibility | Microsoft Docs

We’ll discuss the other two passwordless methods in the next chapter.

Windows Hello for Business and FIDO2 security keys

Windows Hello for Business and FIDO2 keys directly communicate with the service you are authenticating to. As such, they can only initiate the login flow if you are connected to the right page. And while this is already placing them up in the ranks, they can also provide access to Windows devices from the lock screen.

It’s worth noting that while Windows Hello for Business needs setup on every machine, FIDO2 keys can attach directly to the Azure AD user, making it way easier to use if the user is not always connected to the same device, as it happens with front-line workers. This happens because FIDO2 security keys store the credentials on the key, unlike Windows Hello for Business, where the key pair is bound to the TPM.

It’s also worth noting that Windows Hello for Business can (with some complex deployment options) also integrate with on-prem resources. One such use case is using Hello for Business with certificates to allow integration with the RDP protocol:

Deploy certificates for remote desktop (RDP) sign-in | Microsoft Docs

Here is a small table that recaps what methods are available, based on device type.

DeviceAD FS or Azure AD native certificate-based authenticationFIDO2 security keysWindows Hello for BusinessMicrosoft Authenticator with compliant device CAP
Windows deviceCheckmark with solid fillCheckmark with solid fillCheckmark with solid fillCheckmark with solid fill
iOS mobile deviceCheckmark with solid fillNot applicableNot applicableCheckmark with solid fill
Android mobile deviceCheckmark with solid fillNot applicableNot applicableCheckmark with solid fill
MacOS deviceCheckmark with solid fillEdge/ChromeNot applicableCheckmark with solid fill

While we are on the topic, you can configure users with a one-time-use Temporary Access Password to make users passwordless from day one, but the topic will be discussed further down.

A very useful page to plan your passwordless implementation is the following. It guides you through a wizard that proposes the best options for your use case depending on what your users use.

Passwordless Setup | Microsoft Admin Center

While not discussed here, Azure AD Certificate-based authentication is also a strong and phishing-resistant passwordless method. Since it's now natively integrated into Azure AD, it makes a lot of sense for companies that used to rely on ADFS to achieve the same passwordless result.

Enable FIDO2 security keys

To enable users to use FIDO2 keys, first sign in to the Authentication methods page, then click on FIDO2 Security Key:

Authentication Methods | Entra

From the menu, select “Enable“, then either “All users” if you want the entire organization to be able to use FIDO2 keys or scope the deployment to a specific group. You may also scope the feature to “All users” but exclude a specific group of people.

Under “Configure“:

  • You’ll generally want to leave “Allow self-service set up” set to “Yes“. This allows people to set up their keys.
  • Enforce attestation” to “Yes“, as it allows to verify the quality and certifications of the key.
  • Enforce key restrictions to “No“, as it allows you to set which FIDO keys are allowed by the org and what keys are not.  

Save and end the setup.

Register a FIDO2 key

Before registering a FIDO2 key, the user will be prompted to setup MFA. If you want the user to directly use FIDO2 keys as an authentication method, you can create a Temporary Access Password for them. This will skip the MFA prompt and let the user configure directly the key.
To create a TAP, follow this guide: Configure a Temporary Access Password | Entra

For this tutorial I’ll be using a YubiKey 5 NFC.

  • Log in to Logging in Private Mode might mess up some of the process. Ensure you are using a normal browser page.
    • If you are using Temporary Access Passwords, the user will be prompted to use it to authenticate.
    • If the user had MFA configured, the user will be able to configure the FIDO2 keys directly
    • If the user is authenticating with password-only, the user will be prompted to configure MFA as an additional step.
  • Click Security Info. In this case the user had MFA configured, so we can go straight to FIDO2 keys.
  • Click on “Add method“, then “Security key”.
  • Click on either “USB device” or “NFC device”. In my case, using a YubiKey 5 NFC, I’ll select USB, since I have it attached to the device. Note that this is just for registration, any method can be used for signing in after registration.
  • Insert the key, then press “Next“.
  • You will be redirected to a browser prompt, asking you to create a passkey. Select “External security key or built-in sensor
  • If prompted, accept the following pop-up.
  • Create a PIN for your Security Key, then perform the gesture, such as touching the sensor.

  • Now give the key a name, so that you may recognize it. I generally suggest the ” Vendor + model” naming convention.
  • Click Done.
  • Now if you log-off, you’ll be able to test out the new key.

Test the FIDO2 key

Once you are done with the setup, try signing in with the key. To do that:

  • Access or any other portal, then select “Sign-in options“.
  • Select “Sign in with Windows Hello or a security key“. This might come up as just “Sign in with a security key“.
  • Attach your Security Key, then insert your PIN
  • Perform the gesture, such as touching the sensor.

If all went well, you’ll access the portal.

Configure security keys as a sign-in option in Windows

Before starting, please be aware that for sign-in in Windows, you’ll need the machine to be at least version 1903. There are no requirement on the join type, as FIDO2 keys can be used for both Azure AD Joined devices and Hybrid-AAD Joined devices.

Enable with Intune for all users

To use FIDO2 keys on Windows devices for all users in your tenant:

  1. Either click on the following link, or access Intune, then click on “Enroll devices”, “Windows Hello for Business”. Windows devices enrollment | Intune
  2. Click on Use security keys for sign-in, and set it to Enabled.

Targeted Intune deployment

To target specific device groups to enable the credential provider, use the following custom settings via Endpoint Manager:

  • Open the following link, or go into Devices, then Configuration Policies. Configuration profiles | Intune
  • Select Create a profile, then click on Windows 10 and later, Templates, Custom.
  • Name it however you prefer, preferably specifying FIDO Keys in the title.
  • After clicking Next, configure the next as follows:
    • Name: Whatever you want, I chose FIDO2 for Windows Sign-in
    • OMA-URI: ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
    • Data Type: Integer
    • Value: 1
  • Once you are done, configure the Assignments, then complete the wizard.

Enable with Group Policy

If you are not using Intune, you can enable the feature using GPOs. In this case only Hybrid Azure AD Joined devices are supported. Once you have created the GPO, the setting is located under Computer Configuration \ Administrative Templates \ System \ Logon. Next, click on Turn on security key sign-in, and set the policy to Enabled.

Force sync on a single device

If you want to test things out after applying the Intune policies, run the following command from your local PowerShell or force sync from Intune. Both will sync your settings with Intune.

Get-ScheduledTask | where {$_.TaskName -eq 'PushLaunch'} | Start-ScheduledTask

Windows Hello for Business deployment for AAD joined devices

An option for configuring WHfB is by using Intune device enrollment. The settings are placed under Windows enrollment settings and only allow scoping to all users.

If you want to do it more granularly, you can deploy a configuration policy that will do the trick. Note that the configuration policy has more options, such as “PIN recovery” and “Certificate for on-premise resources”.

For reference, you can also create GPOs and configure hybrid and on-premises services to deploy Windows Hello for Business, but that won’t be discussed in this article as it would be worth a dedicated article.

For all users

  • Either click on the following link, or access Intune, then click on “Enroll devices”, “Windows Hello for Business”. Windows devices enrollment | Intune
  • Click on Use security keys for sign-in, and set it to Enabled. Enabled will configure WHfB for all devices. Not configured will be used if you still want to use the feature but you don’t want Intune to manage it.
  • Review the image below and use it freely as a template for the settings. This is one of the better defaults I’ve come up with, but some settings will depend on your organization’s standards. One note, it’s generally a good idea to require TPM if your devices support it.

For specific groups

  • Open the following link, or go into Devices, then Configuration Policies. Configuration profiles | Intune
  • Select Create a profile, then click on Windows 10 and later, Templates, Identity protection.
  • Give the policy a name, then click Next
  • As before, this is one of the better defaults I’ve come up with, but some settings will depend on your organization’s standards.
  • Once you are done, configure the Assignments, then complete the wizard.

Force sync on a single device

If you want to test things out after applying the Intune policies, run the following command from your local PowerShell or force sync from Intune. Both will sync your settings with Intune.

Get-ScheduledTask | where {$_.TaskName -eq 'PushLaunch'} | Start-ScheduledTask


I hope this post was useful to you. If you spot any mistakes, feel free to reach out to me on Twitter or Linkedin.

Sources and additional reads

Various Microsoft Docs, in particular:

The Yubico reference guide:

What’s SMS Authentication and how to enable it in Azure AD

What’s Text Message Authentication

SMS-based authentication allows users to log in without needing to remember their username and password. After enabling the feature for an account, users can enter their phone number at the login prompt instead of their username. They will then receive an authentication code via text message that they can use to complete the login. 

This service is often mistaken for SMS-based Multi-factor Authentication, but they are not the same.

This authentication method makes it easier for frontline workers to access applications and services. It’s not recommended to enable this feature for users who could use other passwordless methods or a combination of credentials + MFA. It’s also important to note that the desktop Office apps do not support SMS-based auth. Therefore, you can only use the web app version of the apps and only by logging in via You also cannot use the mobile version of the apps, except for Teams, Company Portal and Microsoft Azure.

If you decide to enable the feature, you should consider limiting and standardizing the frontline worker’s permissions to what’s necessary.

If you are curious why you should prioritize other methods over phone-based auth, consider reading this always relevant article by Alex Weinert:

It’s Time to Hang Up on Phone Transports for Authentication – Microsoft Community Hub

Critical Considerations

  • SMS-based authentication isn’t compatible with Azure Multifactor Authentication.
  • The only mobile apps that support SMS-auth are Teams, Company portal and Azure.
  • The users will need to use the web version of the Office apps and log in via
  • You’ll have to set up phone numbers for each account before the users can sign in.
  • A phone number can only be associated with one user.
  • If you have alternatives to phone-based auth methods, use them.

General Requirements


  • Being a Global Admin for the tenant


  • Each user enabled for the feature must have one of the following:
    • Microsoft 365 F1 or F3
    • Azure Active Directory Premium P1 or P2
    • Enterprise Mobility + Security (EMS) E3 or E5 or Microsoft 365 E3 or E5
    • Office 365 F3


  • You can assign phone numbers to users using PowerShell for an easier setup experience.

How to enable the feature

  • Create a group with the users that’ll need to authenticate using SMS.
  • Open Authentication Methods | Azure AD
  • Click on SMS (Preview). The feature is not in preview anymore, even if the portal states so at the moment of writing this guide.
  • Click on “Yes” under “Enable”, then “Select groups”, and select the group you created in the first step. Complete the step by clicking “Select” and “Save”.
  • To set a phone number, go into All Users | Azure AD, then select a member of the group you created in the first step.
  • Go into “Authentication methods”, then click “Add authentication method”. From there, select “Phone number” and insert the phone number the user will use to sign in, then click “Add”.
  • You can also add an authentication method via PowerShell:
# Replace the variables with the user you wish to add the auth method to and phone number you wish to assign

$User = ""
$PhoneNumber = "+1 111111111"

Install-module Microsoft.Graph.Identity.Signins
Connect-MgGraph -Scopes UserAuthenticationMethod.ReadWrite.All
Select-MgProfile -Name beta

New-MgUserAuthenticationPhoneMethod -UserId $User -phoneType "mobile" -phoneNumber $PhoneNumber

# Get the phone number of the user

Get-MgUserAuthenticationPhoneMethod -UserId $User

If you need to script this for multiple users, you can refer to the code below.

This script assumes you created a CSV file in “C:\” named contacts.csv, and that the CSV file has a column named UserName and a column named PhoneNumber. If your CSV file has different column names, you will need to update the script accordingly.

# Install the modules and login to Graph

Install-module Microsoft.Graph.Identity.Signins
Connect-MgGraph -Scopes UserAuthenticationMethod.ReadWrite.All
Select-MgProfile -Name beta

# Import the CSV file containing names and phone numbers

$contacts = Import-Csv -Path "C:\contacts.csv"

# Loop through each user and add their phone number for authentication
# If you changed the column names, replace these placeholders with the actual column names from the CSV file

foreach ($contact in $contacts)
    $User = $contact.UserName
    $PhoneNumber = $contact.PhoneNumber
    New-MgUserAuthenticationPhoneMethod -UserId $User -phoneType "mobile" -phoneNumber $PhoneNumber

To learn more, refer to the following links:

SMS-based Authentication | Microsoft Docs

SMS-based Authentication – Supported apps | Microsoft Docs

Add or remove a user from a Conditional Access Policy (CAP) – Azure AD

What are Conditional Access Policies?

Conditional Access Policies (CAPs) are identity-driven policies that govern user access to resources. We can summarize them as if statements that govern what will be requested, enforced or blocked.

In most organizations, the CAPs govern the enforcement of MFA, the block of logins using legacy protocols, and requiring a compliant device to access company resources.

All policies “think” at the user level.

It is advisable to make changes to CAPs only if you have a basic understatement of the service, since you could risk blocking access to the tenant for all users. In order to learn more, refer to the following documentation:

Azure AD Conditional Access documentation – Microsoft Entra | Microsoft Learn

General considerations

  • It’s a good idea to manage exclusions using Groups. This way, you won’t have to directly modify the policy every time.
  • Since many policies are scoped to include all users, you’ll have to handle exceptions with the “exclude” feature.

How to add or remove a user

  • Log in to Conditional Access – Microsoft Azure
  • Select the desired policy
  • If you intend to add a user to the policy, click on the blue link under “Users or workload identities”, then “Include,” and click the blue link under “Users and groups”.
  • Select or search for the desired user, then click “Select.”
  • If you want to exclude a user, click on the blue link under “Users or workload identities”, then “Exclude,” and click on the blue link just below “Users and groups.” The same user selection screen shown in the previous step will open. Search for and select the user, then click “Select.”

Once done, save using the “Save” button at the end of the page. If the policy is in “Report-only” or “Off“, the flow is not active.

Get all users of an Azure AD Group and add them to another one – Powershell

The following script will get all the members of an Azure AD group and add them to another group. You’ll just need to know the name of the two groups to make it work.

In the code shown below, the source group will be called Group1Name and the destination one Group2Name.

# Replace Group1Name with the name of your source group and Group2Name with the name of the destination one. Everything else will be done automatically

$Group1 = "Group1Name"
$Group2 = "Group2Name"

$group1ObjectID = Get-AzureADGroup -Filter "Displayname eq '$group1'" | Select objectid -ExpandProperty ObjectID
$group2ObjectID = Get-AzureADGroup -Filter "Displayname eq '$group2'" | Select objectid -ExpandProperty ObjectID

$membersGroup1 = Get-AzureADGroupMember -ObjectId $group1ObjectID -All $true

foreach($member in $membersGroup1)
    $currentuser = Get-AzureADUser -ObjectId $member.ObjectId | select objectid
    Add-AzureADGroupMember -ObjectId $group2ObjectID -RefObjectId $currentuser.objectid

Get-AzureADGroupMember -ObjectId $group2ObjectID -All $true

Unfortunately, your password contains a word, phrase or pattern that makes it easily guessable. – Azure AD

Suppose you or a user reset a password, and one of the following errors comes up. In that case, it means that either you are using a guessable password or that somebody in your organization has enabled Password Protection in your environment, and you are using a banned word.

  • Unfortunately, your password contains a word, phrase or pattern that makes it easily guessable. Please try again with a different password.
  • “Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.”

If you are a user, please try a more complex password to circumvent the error. Substituting @ with A, 1 with I, and other widespread ways of changing up a common word will not be counted as “not including a common word”.

If you are an admin, please note the following about this feature. Users often create passwords that use common words based on personal interests or easily rememberable things (e.g. cities, sports teams, celebrities, months, etc.). These passwords are strongly vulnerable to dictionary-based attacks. Azure AD Password Protection, which works either in a “cloud-only” mode or can also synchronize to on-prem, provides a global and custom-banned password list. The global one is maintained directly by Microsoft; the custom one can be modified by the Microsoft 365 / Azure AD admins.

To access the feature settings, click on this link: Password Protection settings | Azure AD

This application contains sensitive information and can only be accessed from domain joined devices – Azure AD

General information

This error message results from the application of a Conditional Access Policy on your tenant that blocks users from accessing cloud resources without a hybrid-joined device. A Hybrid-joined device is an AD-joined client which gets synchronized to Azure AD via Azure Active Directory Connect (AD Connect).

Another version of this error is:

Try signing in another way
To access your service, app, or website, you may need to sign in to Microsoft Edge using XX account

If you are looking to understand which Conditional Access Policy is blocking users, check out this guide:

How to fix

  • If the user is trying to access with a personal device, switching accounts (as suggested in the error message) won’t fix the issue. You’ll need a company owned device.
  • If the user is trying to access it with a company device, then it’s either:
    • Using a personal account, or using the wrong company account. Click on Sign out and sign in with a different account, then sign in with the correct account.
    • Using the right company account, but using Chrome. If this is the case, follow the steps below.
    • Using the right company account on Edge (or on Chrome with the proper extension installed), but the device is not synchronized. To fix this, check if you are synchronizing said device and consider adding it to the right OU / add the right attribute to let it sync.

If you are using Chrome, you’ll either need the Windows Accounts or the Microsoft 365 extensions. These extensions allow Chrome to pass device-specific details. You can deploy the extension automatically using this registry key:

Additional notes

Please note that the “Hybrid join check” type of access control is usually paired with a device compliance check. So expect a possible further block related to this.
To learn more, visit Get started with device compliance | Intune  or read my article on the related error:

To drill down on this type of Conditional Access Policy, check out this link:

Conditional Access: Require compliant or hybrid Azure AD joined device


Online Mailbox cannot be created because an on-premise one already exists – Exchange Online

This issue is mainly present if you are trying to migrate from Exchange on-prem to Exchange Online and you’re not going with the hybrid route. The “double mailbox” way consists in having an online mailbox and a local one, and manually (or automatically using tools) migrating the content online.

The issue is that, if you are synchronizing your on-prem AD with Azure AD, you are most probably including your msExchMailboxGUID into the replicated fields. This attribute will tell Exchange Online not to create an online mailbox, as an on-prem one already exists.

Once you will have cleared this field from the online user, Exchange Online will be able to create another mailbox, populating the msExchMailboxGuid of the online user, leaving you with the possibility of exporting and importing data into your online mailbox.

Please note that this will also automatically clear the following attributes from the online user:

  • alias
  •  legacyExchangeDN
  •  msExchArchiveGuid
  •  msExchArchiveName
  •  msExchBlockedSendersHash
  •  msExchElcMailboxFlags
  •  msExchRecipientDisplayType
  •  msExchRecipientTypeDetails
  •  msExchSafeRecipientsHash
  •  msExchSafeSendersHash
  •  userCertificate

To proceed with the creation of the online mailbox, follow these steps:

  • Open your AD Connect server.
  • Stop the Sync with Powershell (launch it as admin and keep it open after this command): Set-ADSyncScheduler -SyncCycleEnabled $false
  • Open the Synchronization Rules Editor as an admin.
  • Select the In from AD – User Exchange rule, click Edit, then click on yes.
  • Under Precedence write 250 (or the first free one), then click Next until you arrive in the Transformations page. Here look for msExchMailboxGuid, then change the row’s settings to make them match with the image below:
  • Once you are done, click Save, then open the original rule. Note down the Precedence (usually it’s 108), then delete the rule. Go into your newly cloned rule and change the Precedence to the one you noted down.
  • Before you enable the scheduler and perform a full sync, you should test out the changes. This is the documentation link to test everything out without committing changes to Azure AD: Verify changes to AD Connect rules | MS Docs
  • Reenable the scheduler: Set-ADSyncScheduler -SyncCycleEnabled $true
  • Perform a full synchronization: Start-ADSyncSyncCycle -PolicyType Initial

You should now be able to create a second mailbox for your synchronized user by assigning a valid license.

Restrict access to Azure Management apps – Azure AD

If we want to restrict access to the Azure management services for non-privileged users, we can now create a Conditional Access Policy that allows us to do so.

To create a Conditional Access Policy, we’ll need Azure Active Directory Plan 1 or higher, which is either bought standalone, or can be found most notably inside Microsoft 365 Business Premium, or the Microsoft 365 Enterprise plans (E3, E5)

On the other hand, if we just need to restrict access to Azure AD, we have the option to do so from the User Settings in the Azure AD portal:

User Settings | Azure AD

By creating the following Conditional Access Policy, we will restrict users from accessing these apps:

  • Azure portal
  • Azure Resource Manager provider
  • Classic deployment model APIs
  • Azure PowerShell
  • Azure CLI
  • Azure DevOps
  • Azure Data Factory portal
  • Azure Event Hubs
  • Azure Service Bus
  • Azure SQL Database
  • SQL Managed Instance
  • Azure Synapse
  • Visual Studio subscriptions administrator portal

First, open the following link, or go into your Conditional Access Policies:

Conditional Access Policies | Azure AD

Then, under “Users or workload identities“, select all users, and exclude the admin roles you currently use in your organization. You could also create a security group with all admin users as members and then exclude it from the policy.

Under “Cloud apps or actions”, click on “Selected apps”, then “Microsoft Azure Management“.

Finish up by selecting “Block access” under the Grant Access Controls.

From now on, all users except the admins will be blocked from accessing Azure management services.

Additional Context and Number Matching User Guide – MFA

General introduction

In this article I want to illustrate how I would notify my users of the upcoming activation of Additional Context and Number Matching in their MFA requests.

If you are looking for a guide on how to enable Additional Context and Number Matching, follow the guide linked below.

Feel free to use the message below as your own. The images are taken from the Microsoft Docs.


User guide

From [replace with activation date] forward, you will be asked to enter additional details in your MFA (Multi-factor authentication) prompts. 

On your PC screen, you will be presented with a number, and you will be asked to enter this same number inside of your MFA request on your phone to complete the approval.  

You will also get a map that will show the location where the request was made from. This must be taken as a general indication and it’s not always going to be your exact location, since Internet providers are not bound to route your connection from a point closest to you.  

Please deny and report immediately to the IT department if you receive a request that was not done by you, or you do not recognize the location you are being shown. 

PC Screen view and smartphone view 


Find stale Enterprise Applications – Azure AD

If you just blocked users from registering applications, or you are just analyzing your Enterprise applications, you may find that there is a lot of work ahead of you.

First, you may want to find if there are applications with no user assigned. Then you may wonder if there are applications without sign-ins in the last 30 days.

To ease your work, you may find it useful to query all applications for these fields and get the output in a CSV.

This script is freely based on Ravenswood PoC code, with the intent of helping out and refining it a bit.

First, head to Enterprise Applications | AAD and click “Download (Export)”, then download the CSV.

This is done via the portal and not via PowerShell for practicality, since at the moment, to get the same exact filters (e.g. “Microsoft Applications”, “Enterprise Applications”, etc.) that you get on the portal, you would have to query Graph.

Then save this script:

	$AllApplications=Import-Csv .\EnterpriseAppsList.csv
	$applications=$allapplications | where {$_.applicationtype -ne "Microsoft application"}
	ForEach($Application in $Applications){ 
   #Retrieve the objectid and signin logs, format the user assigned to the app 
	$app=Get-AzureADServicePrincipal -all $true | where {$_.objectid -eq $}
    $Log = Get-AzureADAuditSignInLogs -All $true -filter "appid eq '$($App.AppID)'" 

	$userassigned = Get-AzureADServiceAppRoleAssignment -ObjectId $App.ObjectId | Select ResourceDisplayName,PrincipalDisplayName
	if($ -eq "Object"){ 

    #Create a custom object for output 


        ApplicationName = $App.DisplayName 

        ApplicationID = $App.AppID 

        SignIns = $Log.count
	Users = $userassigned.count
    Start-Sleep 5

And finally, launch it:

.\StaleApplicationAnalysis.ps1 | Export-csv StaleApplicationCleanup.csv

The output will be along these lines, with an additional column for the App ID:

If you happen to find any optimization, feel free to let me know, and I’ll update the post.

Microsoft Secure Score not updating

The Microsoft Secure score is a useful page to get an idea of the general improvement areas you should monitor and approach in your tenant.

When you make a change to reflect one of the improvement actions, you might have to wait up to 48 hours to get the points in the portal.

If you have waited the 48 hours (generally, it’s 24 hours, but the job might fail), check that the policies you created were configured as recommended in the “implementation” tab, then try the following.

First, check if there is some degradation with the service.

If there isn’t degradation, try changing the Conditional Access Policy (or the security policy you enabled) and see if the secure score catches up.

If it didn’t, or you are in a hurry, click on the recommended action, “Edit status & action plan”, and resolve the suggestion as risk accepted, then wait for the score to update. Once you see that the full points are awarded, revert the change. This procedure should “force” the sync to grant you full points, then change it with the actual value.

If the above failed, contact Microsoft Support and request a manual restart of the job.

Either that will solve it, or in some cases, just waiting a couple more days will fix it.

Unblock at-risk user – Azure AD

If a user can’t access your tenant and forwards the following message to you, here are the steps on how you can solve it.

Your account is blocked

We’ve detected suspicious activity on your account.

Sorry, the organization you are trying to access restricts at-risk users. Please contact your admin.

The unblock is done by either resetting the user password or clearing the user risk once you have assessed that the risk is resolved.

  • If you have AAD Premium P2 (you can check it on the overview page of Azure AD), remediate the user risk by following this link Identity Protection | Risky users. A password reset is usually suggested and will also clear the user’s risk.
  • If you do not have AAD Premium P2, you can reset the user’s password or let them do it by themselves by using Self Service Password Reset (SSPR) if you have configured it. Alternatively, you can also go on this page, and ignore the user risk, once you have assessed that everything is resolved: AAD Risky Users. All these methods will clear the user risk.

Allow 10 – 15 minutes before the user can access again without getting the error reported above.

How to check which Conditional Access Policy is blocking a user log-in – Azure AD

General Introduction

If you have Conditional Access Policies in place to block certain log-ins, you might get that a user will contact you because their sign-in request is being blocked. Probably both you and the user don’t know which policy is making the log-in fail, since it’s not specified in the error message.

The usual error message is something along the lines of: “Your sign-in was successful, but does not meet the criteria to access this resource. For example, you might be signing in from a browser, app or location that is restricted by your admin.” and the standard error code is “BlockedByConditionalAccess” error 53003

How to solve

To get more details:

  • Click on the failed log-in request
  • Click on “Conditional Access
  • The Policies that have as a result “Failure” and “Grant Controls” set on “Block” are the ones blocking the user.

User blocked due to risk on home tenant – Azure AD

General Introduction

If you just enabled Azure AD Identity Protection for your entire tenant, you might get some complaints from guest users, saying that their sign-in was blocked.

If you got a similar issue, but the user is not a guest but a member of your organization, follow this guide:

You cannot remediate the user risk of a guest. If you try to look for a guest user in Identity Protection | Risky users, you won’t find any.

The user risk is calculated in the “home” tenant, where your user was created, not in the tenant you have guest access / are trying to access. This is also done so that the system may have more insights into user behaviour to calculate the risk.

How to resolve

Now going forward, there are two ways of solving this issue:

  • If the home tenant administrators have AAD Premium P2, they can remediate the user risk by following this link Identity Protection | Risky users. A password reset is usually suggested and will also clear the user’s risk.
  • If they do not have AAD Premium P2, they can reset the user’s password or let the user do it by themselves by using Self Service Password Reset (SSPR), if configured. Alternatively, they can also go on this page, and ignore the user risk, once you have assessed that everything is resolved: AAD Risky Users. All these methods will clear the user risk.

Of course, if you wish, you may disable the user risk policy for guests. This is done by creating a dynamic group in Azure AD containing all the guest (Dynamic security group with a dynamic query of usertype equals guest) and excluding it from the policy.

Enable number matching and additional context with Microsoft Authenticator – Azure AD

General Introduction

It’s been a long time since Microsoft released number matching and additional context for the Microsoft Authenticator. These features allow you to quickly improve your MFA posture, adding a new layer of security and preventing accidental approvals. This is also useful to lower the chances of being compromised by MFA fatigue attacks.
The feature consists in a map shown on your MFA prompt on your phone that indicates where the MFA request is coming from, the name of the application requesting the MFA challenge, and a box to insert the number that will be shown on screen.

Image taken from the Microsoft Docs. Link in the notes

How to enable it

To enable these features follow this link, which will guide you into Azure AD > Security > Authentication methods:

Authentication methods | Azure AD

From here, click “Microsoft Authenticator“.

Click “Yes” under “ENABLE“, then on “Configure“.

Be sure to activate “Require number matching for push notifications“, “Show application name in push and passwordless notifications” and “Show geographic location in push and passwordless notifications“, then save.

You can scope the features to a selected group of users if you want to test them out and go for a gradual rollout. This is done by selecting “Select group” and adding the group for which you want to enable the feature.

Additional notes

Check out this article if you are looking for a communication to send out to users before rolling out the features:

Here is a link to the Microsoft Documentation:

How to use number matching in multifactor authentication (MFA) notifications – Authentication methods policy

Here is a link to the CISA documentation on the topic:

Implementing Number Matching in MFA Applications | CISA

Automatically clean up inactive Guest users – Azure AD

Using Azure AD Access Reviews (available with Azure AD Premium P2), you can automatically remove guest users from your tenant who haven’t had access in a specified number of days. In this guide, we will implement the access review step by step.

This is a great way to clean up your tenant automatically and can be scheduled.

NOTE: The procedure used to clean up only users who didn’t have access in the last 30 days. This has now been expanded to support a variable number of days (ex. 60, 90, etc).

Step by step guide

As a prerequisite, you’ll need to create a dynamic group in AAD, which will contain all guest users who can log in to the tenant:

  • To create the group, go to AAD Groups, then click on “New Group”.
  • Select Group Type as “Security“, give the group a name, and select “Membership type” as “Dynamic User“.
  • Under “Dynamic user members”, click on “Add dynamic query“.
  • The query you will want to create is:
 (user.userType -eq "Guest") and (user.accountEnabled -eq true)

You can create this group also using Powershell, and pasting this command after installing the Graph module.

Import-Module Microsoft.Graph.Groups

$params = @{
	DisplayName = "Guest_review_dynamicgroup"
	MailEnabled = $false
	MailNickname = "fb7kk308-6"
	SecurityEnabled = $true
	Description = "Group used for the automatic guest removal process"
	GroupTypes = @(
	MembershipRule = "(user.userType -eq "Guest") and (user.accountEnabled -eq true)"
	MembershipRuleProcessingState = "On"

New-MgGroup -BodyParameter $params

The accountEnabled attribute lets you filter for users who can log in. Since the access review will deactivate the account for 30 days before deleting it permanently, this way we’ll filter only for the guest users active in the tenant and not the ones ready to be automatically deleted.

  • Once done, click on “Create”.

To create the access review, open this link, then follow the steps listed below:

Identity Governance | Access Reviews

  • Click on “New access review“.
  • Select “Teams + Groups” under “Select what to review”, “Select Teams + groups” under “Select review scope”, under “Group” enter your group, then click on “Guest users only” under “Scope”.
  • You can then filter only for the guest that did not had access in a specified number of days. This is accomplished using this part of the wizard:
  • Click on Next, and under “Select reviewers”, click on “Selected user(s) or group(s)“. The person or people that will manually review the users to delete should be selected just below. If not needed, insert an admin and go ahead. I always give at least 3 to 5 days for the reviewers to check if somebody should not be blocked or deleted. If some guest user should always be excluded from the review, you can add an exclusion in the AAD Group membership rules.
  • In the last paragraph, you’ll want to select auto-apply results to make the automation work. Under “If reviewers don’t respond”, choose “Take recommendations“. The recommendations will be based on whether the user has logged in recently or not. There are no other recommendations that I am aware of at this moment. Under “Action to apply on denied guest users”, select “Block user from signing-in for 30 days, then remove user from the tenant“. Be sure that “No sign-in within 30 days” is selected as reviewer decision helper, as per the image below.
  • If you want this to be fully automated, deselect “Justification required”.
  • Once done, click on “Review + create”, give the review a name and click on “Create”.

Now you will automatically have the guest users who haven’t logged in in the specified number of days blocked. After 30 days, the blocked user will be removed from the tenant.

Additional resources

Jef Kazimer wrote a really cool guide on how to remove unredeemed B2B guest from your Azure Active Directory:

Using Azure Automation with Managed Identities to remove unredeemed B2B guests

Exchange API missing for Veeam modern auth in Azure AD

If you are looking for the Exchange API to configure modern authentication for Veeam, you’ll find that it is no longer present under “Request API Permissions” -> “Microsoft API”.

Instead, what you want to do is go into “APIs my organization uses” under the “Request API Permissions”, then search for “Office 365 Exchange Online“.

It’s basically the same thing, only a bit harder to find, as the search doesn’t show up results if you look for “Exchange”.

IdFix – Pre AdConnect assessment for your on-prem AD

IdFix is a tool to discover and remediate identity problems pre synchronization to Azure Active Directory.

To use IdFix you will need:

  • A domain joined computer / server
  • A user account with at least read access to the AD objects

The process is really straightforward.

Get IdFix from here:

Install and open IdFix, then click on “Query”.

After the process has been completed you will be shown all the problems you might have with your environment, if any.

Screen shot of the tool running
Image from

If no errors are shown, or you are confident you can work around them, you can begin the synchronization.


Set up synchronization:

Microsoft guide on how to use IdFix: