Implementing multi-factor authentication as a part of securing your environment is a wise decision. For implementing multi-factor authentication in Azure, I would recommend reviewing the following resources:

 

Providing a default level of security in Azure Active Directory – Microsoft Entra | Microsoft Learn

Turn on MFA with security defaults or Conditional Access – Microsoft 365 Business Premium | Microsoft Learn

Enable Azure AD Multi-Factor Authentication – Microsoft Entra | Microsoft Learn

 

I recently worked with a customer that was implementing an organization wide multi-factor authentication conditional access policy. As a part of this implementation, users were advised to register strong authentication methods using Microsoft Authenticator prior to the enablement of the conditional access policy. The goal was to have all end users prepared for policy enablement and not have interactive authentication interrupted by multi-factor registration.

 

Users were provided instructions that directed to them to access https://myaccount.microsoft.com. Once authentication was successful to my account portal selecting security info directs the users to the location where they can self service register a strong authentication method. At this point users were instructed to add an authentication method utilizing Microsoft Authenticator as the default application for multi-factor authentication. In this example I have two users MFATest1 and MFATest2 that both followed the directions.

 

MFATest1

 

MFATest2

 

In the case of user MFATest1 and MFATest2 each user was showing a Microsoft Authenticator registration with push multi-factor authentication.

 

In addition to providing end users with instructions on enabling strong authentication methods administrators were creating reports using the Microsoft Graph API. The reports detailed the strong authentication methods enabled for the users. When administratively determining who is enabled for multi-factor authentication capturing the strong authentication methods of the users is often utilized for this purpose.

 

Here is an example for MFATest1.

Capture the authentication methods for the user.

$mfaTest1=Get-MgBetaUserAuthenticationMethod -UserId mfatest1@domain.com

List the authentication methods for the user.

$mfaTest1

Id

—

28c10230-6103-485e-b985-444c60001490

a5c2ef35-1db2-49c3-8631-e12a5025859e

List the details of the authentication methods for the user.

PS C:\> $mfatest1 | Select-Object id,additionalProperties -ExpandProperty additionalProperties

 

Key Value

— —–

@odata.type #microsoft.graph.passwordAuthenticationMethod

createdDateTime 2023-08-08T12:23:33Z

@odata.type #microsoft.graph.microsoftAuthenticatorAuthenticationMethod

displayName iPhone 14 Pro Max

deviceTag SoftwareTokenActivated

phoneAppVersion 6.7.12

clientAppName microsoftAuthenticator

 

Here is an example for MFATest2

Capture the authentication methods for the user.

$mfaTest2=Get-MgBetaUserAuthenticationMethod -UserId mfatest2@domain.com

List the authentication methods for the user.

$mfaTest2

Id

—

28c10230-6103-485e-b985-444c60001490

6ce10fca-fb88-4109-95e4-66d27c3e9f6d

List the details of the authentication methods for the user.

PS C:\> $mfatest2 | Select-Object id,additionalProperties -ExpandProperty additionalProperties

 

Key Value

— —–

@odata.type #microsoft.graph.passwordAuthenticationMethod

createdDateTime 2023-08-08T12:23:33Z

@odata.type #microsoft.graph.microsoftAuthenticatorAuthenticationMethod

displayName iPhone 14 Pro Max

deviceTag SoftwareTokenActivated

phoneAppVersion 6.7.12

clientAppName microsoftAuthenticator

 

When reviewing a user that has not registered a strong authentication method the additional identifier is missing when listing the authentication method details.

 

PS C:\> Get-MgBetaUserAuthenticationMethod -UserId 9ee2446b-f4c9-41cb-a73b-66a1937b45bb

 

Id

—

28c10230-6103-485e-b985-444c60001490

 

The identifier 28c10230-6103-485e-b985-444c60001490 is present on all users as all users have a password authentication method.

 

With the end users showing an MFA capable device and administrative reports indicating users had registered strong authentication methods the conditional access policy requiring multi-factor authentication was enabled. When the policy was enabled some users were experiencing the following dialog when signing in.

 

Typically, this dialog is presented to user when MFA registration, self service password reset registration, or combined registration is enabled or required. In this case self service password reset was disabled and the registration was to enroll a device for multi-factor authentication. The user MFATest2 already has a strong authentication method stamped on their account and should not be required to register for multi-factor authentication.

 

In the Azure Portal we reviewed the authentication methods assigned to the account MFATest2.

 

 

Why is Microsoft Authenticator listed under non-usable authentication methods? Is this the same for other accounts that are working? In this instance account MFATest1 is not showing the same issue. When reviewing the authentication methods assigned to MFATest1 the following is found:

 

In the case of user MFATest1 Microsoft Authenticator is showing as a usable authentication method.

 

The work to enable multi-factor authentication and register strong authentication methods was performed within the last 30 days. This allows us to query the audit logs in Azure and determine the flow of steps taken. For account MFATest2 this is the audit log flow associated with the addition of a strong authentication method and multi-factor authentication enablement. There are entries for “Azure MFA StringAuthenticationService” with an activity of “Update User”.

 

 

When reviewing the properties of the audit log entry the following information is present:

 

Activity

Date (UTC)

8/8/2023, 12:38 PM

Activity Type

Update user

Correlation ID

c653c0e4-91d1-454d-ade9-dd076c6a975f

Category

UserManagement

Status

success

Status reason

User Agent

Initiated by (actor)

Type

Application

Display Name

Azure MFA StrongAuthenticationService

App ID

Service principal ID

797b413b-1b35-45ad-a30a-11c0eb96fa8f

Service principal name

Additional Details

UserType

Member

 

Target

Type

User

Id

d1bec8bc-cfcd-4b1a-9038-205b9435a5ae

Display Name

User Principal Name

MFATest2@domain.com

 

MFATest2@e-mcmichael.com

StrongAuthenticationPhoneAppDetail

[]

[{“DeviceName”:”iPhone 14 Pro Max”,”DeviceToken”:”apns2-41a5642b6047a6ceb39c327a26c9147b4c8b58f7d7f824f879b04e9c23677f19″,”DeviceTag”:”SoftwareTokenActivated”,”PhoneAppVersion”:”6.7.12″,”OathTokenTimeDrift”:0,”DeviceId”:”00000000-0000-0000-0000-000000000000″,”Id”:”6ce10fca-fb88-4109-95e4-66d27c3e9f6d”,”TimeInterval”:0,”AuthenticationType”:3,”NotificationType”:2,”LastAuthenticatedTimestamp”:”2023-08-08T12:38:24.2254241Z”,”AuthenticatorFlavor”:null,”HashFunction”:null,”TenantDeviceId”:null,”SecuredPartitionId”:0,”SecuredKeyId”:0}]

MFATest2@e-mcmichael.com

Included Updated Properties

“StrongAuthenticationPhoneAppDetail”

MFATest2@e-mcmichael.com

TargetId.UserType

“Member”

 

The information highlighted in red reflects the old value of NULL for strong authentication methods and the new value of the Microsoft Authenticator registration.

 

For account MFATest1 this is the audit log flow associated with the addition of a strong authentication method and multi-factor authentication enablement. There are entries for “Azure MFA StringAuthenticationService” with an activity of “Update User”. We also see events indicating User started security info registration and user registered security info.

 

 

 

This sequence of events lists extremely important details about the registration of a strong authentication method and then it’s subsequent use for MFA. What we observe in the case of the users that are working:

1. The strong authentication method is set on the user account. (Account is added in https://myaccount.microsoft.com)

    

   StrongAuthenticationPhoneAppDetail
   

   []
   

   [{“DeviceName”:”iPhone 14 Pro Max”,”DeviceToken”:”apns2-41a5642b6047a6ceb39c327a26c9147b4c8b58f7d7f824f879b04e9c23677f19″,”DeviceTag”:”SoftwareTokenActivated”,”PhoneAppVersion”:”6.7.12″,”OathTokenTimeDrift”:0,”DeviceId”:”00000000-0000-0000-0000-000000000000″,”Id”:”a5c2ef35-1db2-49c3-8631-e12a5025859e”,”TimeInterval”:0,”AuthenticationType”:3,”NotificationType”:2,”LastAuthenticatedTimestamp”:”2023-08-08T12:35:33.183712Z”,”AuthenticatorFlavor”:null,”HashFunction”:null,”TenantDeviceId”:null,”SecuredPartitionId”:0,”SecuredKeyId”:0}]
   

 

1. The user starts security info registration. (The user scans the QR code for adding the account and selects next to begin validation)

   Date (UTC)
   

   8/8/2023, 12:35 PM
   

   Activity Type
   

   User started security info registration
   

   Correlation ID
   

   730563f2-3031-4a65-aa00-13fbc17910eb
   

   Category
   

   UserManagement
   

   Status
   

   success
   

   Status reason
   

   User started the registration for Authenticator App with Notification and Code
   

   User Agent
   

   Initiated by (actor)
   

   Type
   

   User
   

   Display Name
   

   Object ID
   

   d4bf89ba-ef39-4858-99c5-d0a44acfe8d2
   

   IP address
   

   N/A
   

   User Principal Name
   

   MFATest1@domain.com
   

 

1. The default type is changed to Microsoft Authenticator (The user responds to the MFA prompt on the phone providing the correct number matching code)

 

MFATest1@e-mcmichael.com

StrongAuthenticationMethod

[]

[{“MethodType”:6,”Default”:true},{“MethodType”:7,”Default”:false}]

MFATest1@e-mcmichael.com

Included Updated Properties

“StrongAuthenticationMethod”

MFATest1@e-mcmichael.com

TargetId.UserType

“Member”

 

1. The user finishes registration of security information. (Authenticator is now a usable method for multi-factor authentication)

 

Activity

Date (UTC)

8/8/2023, 12:35 PM

Activity Type

User registered security info

Correlation ID

faf9110a-7088-49b2-9efe-75cec7aea6af

Category

UserManagement

Status

success

Status reason

User registered Authenticator App with Notification and Code

User Agent

Initiated by (actor)

Type

User

Display Name

Object ID

d4bf89ba-ef39-4858-99c5-d0a44acfe8d2

IP address

N/A

User Principal Name

MFATest1@domain.com

 

When looking at the Microsoft Authenticator installations on MFATest1 and MFATest2 there are accounts present on the devices.

 

 

 

If both users MFATest1 and MFATest2 followed the same directions to register security information and enable multi-factor authentication, then why are we seeing a difference? In the case of MFATest2 the user successfully scanned the QR code and registered the strong authentication method but closed the browser windows before completing the verification. For a strong authentication method to be registered and usable the user must complete the verification by entering the code provided. In the case of MFATest1 the full procedure was followed, and the strong authentication method was added and verified.

 

This scenario has exposed two particular challenges.

1. The https://myaccount.microsoft.com page showed that a valid MFA device was registered in both user cases but could only actually be utilized by one of the users.
2. Administratively the presence of a strong authentication method does not provide insight in the ability to use that method to satisfy multifactor authentication.

 

Our product engineering team is aware of both scenarios. There are active work items to allow end users to not only see what authentication methods are registered but also provide feedback to the end user regarding their ability to be utilized for multifactor authentication. On the administrative side work continues in our graph and powershell integration to not only display the strong authentication methods but provide the same insight that the Azure portal does when making a determination of the users strong authentication methods and their ability to satisfy multi-factor authentication.

 

With this scenario there was little that could be done to mitigate the outcome other than ensuring that users followed the directions as published. When configuring conditional access the policy could have been rolled out over time by using group membership thereby lessoning the overall impact to the organization. As our product engineering engagements finish and our interfaces evolve more information allowing the accurate assessment of this situation will be available.