- Run Exchange Online commands using Azure Automation - Tue, Jul 25 2023
- Connect to Exchange Online with PowerShell and certificate-based authentication - Wed, Jul 19 2023
- Office Deployment Tool (ODT): Deploy Office using custom XML files - Thu, Mar 30 2023
You may have heard of MFA notification fatigue, or MFA spamming. MFA notifications were previously seen as very helpful to the end user; instead of having to open an app and enter the six-digit code displayed, a user could simply click Approve or Deny. Much simpler. I used it myself. When paired with my Apple Watch, I didn't even need to get my phone; I could approve a sign-in from my wrist.
But what happens when a user's password is breached? All of a sudden, your phone (or watch) is buzzing constantly with approval requests. Would your users know or be aware enough to realize it isn't them trying to sign in?
Remember, an attacker only needs to succeed once. Our defenses have to work every time. Of course, this technique has been exploited to bypass MFA. Attackers can then register their own MFA device and no longer need the end user to approve their requests.
Number matching
Number matching is the solution to this problem. To enable number matching, log in to Azure AD. Navigate to Security > Authentication methods.
Azure AD Security Authentication methods
Click the Microsoft Authenticator. Switch to the Configure tab.
You will see three sections:
- Require number matching for push notifications: This setting determines whether number matching is on for the selected group/all users.
- Show application name in push and passwordless notifications: This configuration controls whether or not the application name is shown to the user in the notification.
- Show geographic location in push and passwordless notifications: This neat feature displays a small map with the rough geographic area of where a sign in request is coming from.
These will be set to All users and Microsoft Managed by default.
This means that Microsoft is in charge of rolling out these features. I recommend you enable these changes for a specific group to start with, or have a strong, clear message to your users about what the changes are and how they will appear.
You do not need to make any changes on a user's device, as long as they have the Microsoft Authenticator installed.
On the deployments I manage, I have enabled number matching and geographic location, leaving the application name as Microsoft managed.
Enabling number matching and geographic location
The screenshot below shows what end users will see when they sign in.
Number matching experience for end users
Temporary Access Pass
Another recent addition to Azure AD is the Temporary Access pass feature. As access requirements become more complex, scenarios in which you may be legitimately unable to meet sign-in criteria crop up.
For example, one of the most common issues I face when working in support is that a user has, at some point in the last few months, changed their mobile phone but has not transferred their MFA profile properly. The next time they are prompted to complete an MFA challenge, the app, while installed on their new phone (or not installed in some cases), does not respond.
As administrators, we can work around this by setting the user account to require re-registering of MFA (from Azure AD > Users > User account properties > Authentication methods).
Require re register multifacator authentication
This is sometimes insufficient. Depending on the conditional access policies you have in place, you may only allow registration of MFA devices in trusted locations, but the user may be at home or abroad. For any number of legitimate reasons, the user may not be able to satisfy all the requirements. This is where the temporary access pass (TAP) comes into play.
A TAP is generated by an administrator for a specific user, is valid for a limited time, and signifies to the sign-in process that the sign in meets all the criteria of any conditional access policy.
To enable or check settings for TAP, go to Azure AD > Security > Authentication methods. Click Temporary Access Pass.
Temporary Access Pass settings
Ensure that TAP is enabled for all users. Then, on the Configure tab, you can review the settings for each TAP.
The defaults are fairly reasonable, I think. The only option you may wish to consider is whether or not a TAP is single use. The default is that a TAP can be used as many times as needed within its lifetime. When single use is enabled, it can only be used once, even if the lifetime of the TAP has not been reached.
Default settings for Temporary Access Pass
To issue a TAP for a user, go to Azure AD > Users > User account properties > Authentication methods and choose Add authentication method. From the dropdown menu, choose TAP.
Issue a Temporary Access Pass for a user account
When you click Add, the TAP is created and displayed. You then need to pass this to the end user.
The lifetime and expiration details are also displayed, which will be helpful when you inform the user of how to use the pass.
When the user attempts to sign in as normal, select 'I cannot use my Authenticator App.' On the choices screen, they will see the option to use a TAP.
Subscribe to 4sysops newsletter!
Use Temporary Access Pass
Your user is then signed in as normal and free to use the system; they should make it a priority to rectify whatever prevented them from signing in normally.
