Part of the information regarding MFA and registration of verification methods is newly described in
- Multi-Factor Authentication (MFA) in Microsoft Entra ID
- Multi-Factor Authentication (MFA) authentication method registration and login
This article follows the previous description of Azure AD modern authentication, self-service password reset (SSPR)
Passwordless Sign-in and Microsoft Authenticator
- Enable passwordless sign-in with the Microsoft Authenticator app
- Passwordless authentication options for Azure Active Directory
- Sign in to your accounts using the Microsoft Authenticator app
Microsoft refers to passwordless authentication when we use something we have (mobile phone, security token - FIDO2) and something we know (biometrics - fingerprint, PIN (to me, PIN seems like a password, but anyway)). MS recommends Windows Hello for Business, FIDO2 security keys or Microsoft Authenticator app, which we'll briefly look at. These methods are considered the most secure ways to sign in - What authentication and verification methods are available in Azure Active Directory?
We can use Microsoft Authenticator App for verification in SSPR (Self-Service Password Reset), for passwordless sign-in (Phone Sign-in) or for MFA (Multi-Factor Authentication). We can use it independently (Phone Sign-in) or together with a user password (Notification or Code).
The prompt to approve a notification may look like this:
On the mobile phone with the Microsoft Authenticator app, a sign-in approval should appear.
Passwordless sign-in process
When signing in, we first enter (select) our username (email). Then, the sign-in approval using the app is displayed. If a password prompt appears, there should be a link below saying Use an app instead, which we can click to switch.
In the Microsoft Authenticator app on the mobile phone, a notification and an offer of three digits will appear. We select the number corresponding to the sign-in screen and click Approve. We confirm with a fingerprint or PIN.
Updated on October 21, 2021. Apparently in the latest update of the Microsoft Authenticator app, the behavior has changed. It no longer offers three possible digits, but the value needs to be manually entered and confirmed.
Updated on April 5, 2023. Microsoft is enhancing the security of authentication using the Microsoft Authenticator app and adding new elements. These have been available for some time, but it depends on the organization's settings (authentication methods policy). At a certain date, it should be automatically activated for everyone. The main visible change is the display of the app name and geographic location during push notification and passwordless sign-in. Another is requiring number matching for push notifications (traditional notifications).
Enabling passwordless sign-in
To enable Passwordless Authentication, we must first turn on combined registration of security information. Then we enable Passwordless Phone sign-in for all or selected users.
- Azure Active Directory admin center - Security - Authentication methods - Policies
- select Microsoft Authenticator and turn on Enable - Yes
- for Target, we choose all users or selected groups and users
- we can also choose Configure, whether both modes are allowed (default) or only Passwordless and Push Notification mode
- save with Save
Setting up the Microsoft Authenticator app
For a user to use passwordless sign-in, they must have this option enabled. They must have the authentication method Microsoft Authenticator app assigned (registered) to their account (https://aka.ms/mysecurityinfo). And in the app, for the given account, phone sign-in must be set up (Enable phone sign-in).
We expand the account, choose Set up phone sign-in and go through the wizard. We must have a screen lock set up (the documentation mentions fingerprint or PIN, but the app also mentions password or pattern). Then, the device registration is performed for the user in the Azure AD tenant.
Note: For phone sign-in, the device must be registered in the Azure AD tenant for the user. A device can be registered in only one tenant, so it can be used only for one work or school account.
Azure AD Multi-Factor Authentication (MFA)
- Tutorial: Secure user sign-in events with Azure AD Multi-Factor Authentication
- Plan an Azure AD Multi-Factor Authentication deployment
- How it works: Azure AD Multi-Factor Authentication
- Multi-factor authentication for Microsoft 365
If we sign in with a username and password, it's single-factor authentication. It's only information that we know, and if an attacker obtains it, they can easily log into our account. Therefore, it's safer to add another factor, something we have (phone, smart card, token) or something we are (biometrics - fingerprint). We then talk about multi-factor authentication.
Azure AD Multi-Factor Authentication (MFA) provides an additional layer of security by using a second form of verification when accessing data or applications (services). First, we authenticate in the standard way (most often with a username and password). In certain cases, the first step (entering the password) can happen automatically. This is followed by the second step (MFA query), where we must use additional verification.
The requirement to use MFA can be set only for certain types of sign-ins. If certain conditions occur, such as signing in from an unknown device or signing in to a specific service or application. In other cases, classic verification may be sufficient.
Examples of sign-in using MFA
First, we enter (select) our username (email) and password. Then we use one of the registered methods. It can be, for example, SMS, through which we receive a verification code.
Or approval of a notification in the Microsoft Authenticator app.
If we use the Microsoft Authenticator app for sign-in, it's already multi-factor authentication. So we can choose to enter a password and (for example) confirm a notification in the app. Or sign in with the app, where we confirm a number.
Authentication methods
Authentication methods for MFA are similar to those for SSPR, but email and security questions are not supported. These include:
- Microsoft Authenticator app - supports (push) notifications, the user simply approves with Approve, and verification code (OATH verification code), which is generated every 30 seconds (doesn't need internet connection, it's an OATH Software Token) and the user enters it in the sign-in dialog
- mobile app - using a verification code, third-party apps like Google Authenticator are also supported
- OATH Hardware Token - generates a verification code that the user enters in the sign-in dialog, can be programmable (similar to OATH Software Token) or with a pre-programmed Secret Key (or Seed), which we must enter in the Azure AD administration
- SMS - a verification code is sent via SMS and the user enters it in the sign-in dialog
- voice call - an automated call to a number, the user accepts it and confirms with the
#
key
Enabling MFA
We can enable Multi-Factor Authentication in several ways.
- Conditional Access policies - policies define when and who must use MFA, requires an Azure AD Premium P1 license
- enable per-user - MS doesn't recommend this and marks it as Legacy, we can set it for selected users, MFA is always used (except for remembered MFA, Trusted IPs, etc.), requires an Azure AD Office 365 apps license
- for everyone using Security Defaults - turning on Security Defaults sets MFA for all users, uses the Microsoft Authenticator app, MS controls in which situations MFA is required, it's part of the Azure AD Free license
According to the Azure AD license, not only the ability to enable, but also the features of MFA differ. For example, Azure AD Free supports only mobile apps (not phone). More details in Licenses - Feature comparison of versions
Security Defaults
Enabling or disabling is done in
- Azure Active Directory admin center - Properties - link Manage Security defaults
Per-user MFA
We can open the settings from several places, for example
- Azure Active Directory admin center - Users - All users - at the top there is a link Multi-Factor Authentication
If we want to disable it (for example, to use another setup method), we must set all users to Disabled. Other options are Enabled, where the user uses MFA, but for Legacy applications (not supporting MFA) they can use a password. Or Enforced, where for Legacy applications they must register and use app passwords. The switch between Enabled and Enforced happens automatically.
The data we see here relates only to Per-user MFA. We shouldn't combine them with Security Defaults or Conditional Access policies, and we won't see the status here if it's set by one of these methods.
Conditional Access policies
- Tutorial: Secure user sign-in events with Azure AD Multi-Factor Authentication
- What is Conditional Access?
MS states that before using Conditional Access policies, we must disable both Security Defaults and per-user MFA. Policies are set in
- Azure Active Directory admin center - Security - Conditional Access - Policies
Microsoft's documentation includes examples of common and recommended policies Common Conditional Access policies.
Registration of authentication methods
If we enable MFA for a user, and they don't have registered MFA authentication methods, then during the next login (using modern authentication), a wizard for entering them will appear. Minor details differ depending on how we enable MFA. If we use combined registration of security information, the wizard is very similar to SSPR.
If we use Conditional Access, the user is prompted to register when MFA login is required. If the user doesn't use applications (accesses) that are protected by MFA, they may not need to register authentication methods. This can be dangerous; all users should have these methods registered. The solution is to enforce registration using a special Conditional Access policy that requires MFA for all accesses. We apply it to a group where we include users who are not registered. And we gradually remove them.
If we have an Azure AD Premium P2 license, we can use MFA registration policy.
MFA Settings
Part of the Multi-Factor Authentication configuration is located in
- Azure Active Directory admin center - Security - MFA
Additional settings can be found at the link
- Azure Active Directory admin center - Security - MFA - Getting started link Additional cloud-based MFA settings
We can access the same page also from
- Azure Active Directory admin center - Users - All users - at the top, link Multi-Factor Authentication - Service Settings
Here you can find the selection of allowed verification methods in the Verification options section. We can enable or disable password generation for old rich applications - App passwords. We can define trusted public IP addresses, from which MFA doesn't occur - Trusted IPs. And also allow remembering MFA on a trusted device for a given number of days - Remember multi-factor authentication on trusted device.
Detailed information about the configuration is in the article Configure Azure AD Multi-Factor Authentication settings.
Reauthentication
It's important for users how complex the login is and how often they need to repeat it. Especially when introducing MFA, when the login process is more complicated, it's good to look at options for when user verification is needed.
There are a number of settings that can lead to reducing the need for user verification.
- Azure AD Seamless SSO - automatic login in the corporate network from a corporate device (synchronized users with PHS or PTA)
- sign-in frequency policy within Conditional Access - requires Azure AD Premium license
- option to stay signed in (Remain signed-in) - we can disable it in Company branding, an option when logging in via browser, allows the session to remain active (persistent cookie) even when closing the browser (doesn't affect Azure AD Session Lifetime, which is 90 days by default)
- option to remember MFA (Remember MFA on trusted device) - setting within MFA, option during MFA login (Don't ask again for X days), saves a persistent cookie in the browser, if we set a value less than 90 days, Office clients will also need to authenticate more frequently
By default, the browser requires authentication every time it's newly launched and accesses an application or service. Office clients (applications) retain authentication for 90 days. On devices that are not registered or connected to Azure AD, each application authenticates separately (and maintains its own OAuth Refresh Token). Managed devices, i.e., those that have an object in the Azure AD tenant (are registered or connected) receive Primary Refresh Tokens (PRT). This allows SSO to be used between applications.
Azure AD MFA for On-Premises systems
- Remote access to on-premises applications through Azure AD Application Proxy
- Integrate your existing Network Policy Server (NPS) infrastructure with Azure AD Multi-Factor Authentication
We can use MFA in Azure AD for internal applications as well. Those that don't support direct connection to Azure AD can use Azure AD Application Proxy. This way they are published to the Azure AD tenant and can use Conditional Access policies.
Another option is for applications that support RADIUS. On Microsoft Network Policy Server (NPS), we can install an extension for Azure AD MFA. There are certain limitations. Conditional Access policies can't be used, so MFA is always used. With the CHAPv2 protocol, only notifications from Microsoft Authenticator app and voice call are supported.
Applications that support modern authentication (WS-Fed, SAML, OAuth, OpenID Connect), and authenticate directly with Azure AD, can use Conditional Access policies.
Managing user authentication methods
Azure AD uses two separate groups of contact information. The first are visible to other members of the organization as part of the user profile. They can be synchronized from On-Premises AD DS. The second, authentication methods, are private and used only for verification. Users can manage them on the Security info page of their profile (MyAccount).
The Administrator can see registered methods of users in the report
- Azure Active Directory admin center - Password reset in the Usage & insights section
- Azure Active Directory admin center - Security - Authentication Methods in the User registration details section
Setting and deleting methods by the administrator
They can manage them for individual users in
- Azure Active Directory admin center - Users - All users
- select the desired user and click on them
- in the left menu, choose Authentication methods
The Administrator has the following options:
- delete an existing method
- add a new method (phone or email)
- reset password (set a temporary one that the user must change)
- set that at the next login, the user will be required to re-register authentication methods for MFA (original ones are not deleted, we can do it manually)
- revoke existing MFA session - deletes saved sessions and MFA needs to be performed at login
Some similar options, and additionally the option to delete application passwords, are located for individual users in
- Azure Active Directory admin center - Users - All users - at the top there is a link Multi-Factor Authentication
MFA blocked user - non-functional registration of authentication methods
- Azure Active Directory admin center - Security - MFA - Block/unblock users
We were solving a mysterious problem where a user was registering verification methods for the first time and nothing was working. No SMS arrived, no calls came through, neither Microsoft Authenticator nor Google Authenticator apps could be registered. When scanning the QR code, an error was returned that it was an invalid QR code or QR code is already used. We tried a different phone, a different SIM card, various resets of the account in Azure AD.
In the end, it was about the fact that the account may have Block sign in set (we see it under the account - Profile), which was not the problem. But the user may also be blocked for MFA. And this is where our account was. Here is the information:
A blocked user will not receive Multi-Factor Authentication requests. Authentication attempts for that user will be automatically denied. A user will remain blocked for 90 days from the time they are blocked. To manually unblock a user, click the “Unblock” action.
And for the blocked user, the reason was:
User blocked their account through the phone menu
It could have happened that the user received a login confirmation, where there is also an option Deny. If we use it, we get another question asking if we think it is an abuse of our account and want to report it Report Fraud. According to the settings in MFA - Fraud alert, the user may be blocked.
There are no comments yet.