EN 
05.11.2024 Miriam WELCOME IN MY WORLD

This website is originally written in the Czech language. Only part of the content is machine (AI) translated into English. The translation may not be exact and may contain errors.

Tento článek si můžete zobrazit v originální české verzi. You can view this article in the original Czech version.
Azure AD přihlašování bez hesla a vícefaktorové ověření (MFA)

Azure AD passwordless login and multi-factor authentication (MFA)

Edited 20.12.2021 12:40 | created | Petr Bouška - Samuraj |
Following on from our last article, which looked at the Self-Service Password Reset or Account Unlocking Portal (SSPR), we'll look at what Microsoft refers to as Passwordless Sign-in. Here using the Microsoft Authenticator application. As a main focus, we'll look at Multi-Factor Authentication (MFA). We'll mention authentication methods again and look at managing them in Azure AD.
displayed: 6 969x (6 851 CZ, 118 EN) | Comments [0]

Part of the information regarding MFA and registration of verification methods is newly described in

This article follows the previous description of Azure AD modern authentication, self-service password reset (SSPR)

Passwordless Sign-in and Microsoft Authenticator

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:

Microsoft Authenticator schválení

On the mobile phone with the Microsoft Authenticator app, a sign-in approval should appear.

Microsoft Authenticator app schválení přihlášení

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.

Přihlašovací dialog Microsoft Authenticator přihlášení

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.

Microsoft Authenticator přihlášení v aplikaci

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.

Microsoft Authenticator přihlášení v aplikaci nově

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).

Microsoft Authenticator přihlášení v aplikaci s polohou

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
Azure AD povolení Passwordless Authentication

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.

Microsoft Authenticator nastavení Phone sign-in 1 Microsoft Authenticator nastavení Phone sign-in 2

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)

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.

MFA přihlášení 1 heslo MFA přihlášení 2 kód

Or approval of a notification in the Microsoft Authenticator app.

MFA přihlášení 1 heslo MFA přihlášení 2 notifikace

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.

MFA přihlášení bez hesla

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

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.

Azure AD 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.

MFA konfigurace

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

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
Azure AD ověřovací metody u uživatele

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.

Author:

Related articles:

Azure AD / Entra ID identity and authentication

Articles related to user and device identity (not only) in Microsoft Entra ID. Different login and authentication options. Areas such as modern authentication, multi-factor authentication, password-less login, etc. Often involving the use of FIDO Authentication, for example using the FIDO2 security key or Windows Hello for Business.

Azure, Microsoft 365, Office 365, Cloud

Various popular topics regarding the public cloud. More focused on Microsoft services, i.e. IaaS, PaaS, SaaS Azure, Entra ID directory services (formerly Azure AD) and hosted Microsoft 365 / Office 365 services.

If you want write something about this article use comments.

Comments

There are no comments yet.

Add comment

Insert tag: strong em link

Help:
  • maximum length of comment is 2000 characters
  • HTML tags are not allowed (they will be removed), you can use only the special tags listed above the input field
  • new line (ENTER) ends paragraph and start new one
  • when you respond to a comment, put the original comment number in squar brackets at the beginning of the paragraph (line)