When a recipient is synchronized to Azure Active Directory the proxy addresses that are assigned to the recipient are determined by a process called ProxyCalc. The synchronization process stores the on-premises Active Directory values in shadow values within Azure Active Directory. The ProxyCalc process reads the shadow values and calculates the actual proxy address values visible in Azure Active Directory. At the conclusion of this calculation the values are synchronized into the recipient in Exchange Online. The rules for ProxyCalc may be found in the following article: How the proxyAddresses attribute is populated in Azure AD – Active Directory | Microsoft Learn.

 

I recently worked on an escalation with a customer that presented an interesting scenario involving ProxyCalc. All users who’s user principal name differed from their primary SMTP address also had a secondary SMTP address in Azure Active Directory of the user principal name. Unlike examples contained within the previously cited document the users were fully provisioned with mail, mailNickName, and proxyAddresses submitted through the synchronization process. In addition, the secondary address appeared regardless of the license status of the user. This seems inconsistent with the scenarios outlined in the cited documentation where adding the UPN as a secondary proxy address appears to occur during licensing scenarios.

 

The remote mailbox is provisioned in the on-premises Active Directory. The user principal name is different from the primary SMTP address and does not appear in the proxy addresses attribute of the recipient.

 

[PS] C:\>Get-RemoteMailbox UPNTest | fl userPrincipalName,primarySMTPAddress,emailAddresses

 

 

UserPrincipalName : UPNTest@domain.net

PrimarySmtpAddress : UPNTest@domain.com

EmailAddresses : {x500:/o=ExchangeLabs/ou=Exchange Administrative Group

(FYDIBOHF23SPDLT)/cn=Recipients/cn=a0b7e9472d3b4f678b47d62d2908575e-f80c3258-a7,

SMTP:UPNTest@domain.com}

 

When reviewing the properties of the user in Azure Active Directory the proxy addresses show that the user principal name was added as a secondary address.

 

PS C:\> Get-MsolUser -UserPrincipalName upntest@domain.net | fl userPrincipalName,ProxyAddresses

 

 

UserPrincipalName : UPNTest@domain.net

ProxyAddresses : {smtp:UPNTest@domain.net, smtp:UPNTest@domain.onmicrosoft.com, SMTP:UPNTest@domain.com}

 

This did confirm that the user principal name was added as a secondary proxy regardless of the licensed status of the user <or> the attributes submitted through the directory synchronization process.

This is by design. The user principal name will always appear as a proxy address on mail recipient. The user principal name cannot be removed from the recipient unless the user principal name is changed on-premises. This essentially reserves this from use on any other mail enabled object.

 

Implementing improved error handling and error cleanup.

In version 2.9.8.19 new error handling was implemented to improve the clean up experience during migration failures and increase the reliability of migrations.

 

The first improvement involves implementing error handling in the function that moves on-premises groups between organizational units. The move command is called up to three times in the module. The first call moves the group from the OU that it is currently into the non-sync OU specified in the migration command. It was possible in the original code that if an exception occurred on moving the group to the non-sync OU this would not cause the migration to fail. This in turn created an endless loop in the migration process scanning for the distribution list deletion in Office 365. The migration would neither succeed nor fail. The current code now attempts the move to the non-sync OU and if an exception occurs will retry the operation up to 5 times waiting 5 seconds between each attempt. If the move is not successful in 5 tries the migration is halted. The second call involves moving the group from the non-sync OU back to the sync OU. The code now attempts this operation 1 time and if the move fails a post create error is created alerting the administrator that manual movement is required. Failing this move was an optional task. The last potential call for a move occurs when the migration fails. If the migration fails after moving the group to a non-sync OU the group will remain there until the administrator move the group back to the sync OU. If the migration fails a single attempt at moving the group back to the original OU is performed. If an error is encountered the migration will end as a result of the previous failure.

 

The second improvement provides some clean up capabilities in response to failure. There are two scenarios that potentially require cleanup after a failed migration. The first scenario is the temporary distribution group created in Office 365. In order to speed operations and limit downtime that the group is unavailable in the cloud operations that potentially take a significant amount of time are performed on a temporary distribution list created in Office 365 as a part of the migration. In previous versions if a failure was encountered after this temporary distribution list was created but before it was renamed as part of migration the group would often be orphaned if a failure occurs. New logic is now implemented that tracks the migration status and if the migration fails between the creation of the temporary distribution list and the renaming / finalizing operation of the migration the temporary distribution list is automatically cleaned up. The second scenario is that failed migrations prior to disabling the distribution list on premises often resulted in the distribution list remaining in the non-sync OU. New is now implemented that tracks the migration status and if a failure occurs prior to disabling the on-premises distribution list an attempt is made to move the list back to the original OU. This should allow the synchronization process to detect the original distribution list and provision the recipient again in the cloud limiting the likelihood of an extended outage pending administrator intervention. It is important to note that the module does not trigger a synchronization in response to this event but rather waits for the current sync cycle to run. If your sync cycles are not default the outage in the cloud may be longer than anticipated.

 

These changes should hopefully improve the reliability of the migrations and prevent manual cleanup.

 

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.

In Azure Active Directory users of Office 365 may be required to enroll in multi-factor authentication and self service password reset. During an interactive logon request users will be prompted to enter the enrollment and configuration process.

 

I recently worked with a customer where a user that was fully enrolled in multi-factor authentication was receiving the dialog “More Information Required” and “Your organization needs more information to keep your account secure.”

 

 

When selecting the next option, the user was prompted with the following dialog. “Additional authentication is required to complete this sign-in.”

 

 

This screen is fairly familiar as it is usually seen when performing combined registration for new users enabling multi-factor authentication and self-service password reset. What is odd about this dialog is that it is not presenting what options need to be enabled to complete security registration. The only option to proceed is skip setup. Skipping setup allows the user to authenticate successfully and access the service. If the user ends up in a loop at this stage selecting sign in with another account then selecting the same account already signed in will break this loop. The same dialog sequence is present on any interactive logon that occurs to Office 365.

 

On the surface there was nothing out of the ordinary with the account in question. The necessary security registrations were present to satisfy multi-factor authentication and the user was able to log in where MFA was required. The one item that did stand out was that the account did have administrator rights. If multi-factor authentication was not an issue the next logical place to review was self-service password reset.

 

When looking at the self-service password reset settings within the tenant this organization choose to disable SSPR for administrator accounts.

The SSPR policies were applied to all users.

 

 

The prompt that is being displayed was due to the conflicting settings between the scope of SSPR application and administrators being excluded from the policy. When the administrator policy has been disabled the self-service password reset settings need to be changed to “selected” and applied to a group that does not include administrator accounts. The other method to mitigate this issue is to migrate from legacy per user MFA and self-service password reset to new authentication policies. The new authentication policies allow more fine-grained control of authentication methods and groups / users are applicable too. How to migrate to the Authentication methods policy – Microsoft Entra | Microsoft Learn

 

My suggestion in this case was to set up a custom attribute on administrator accounts. Using an Azure dynamic group all users where the custom attribute was not present were added to the group. This group was then selected for targeted self-service password reset application. This removed the all scope and excluded administrators from SSPR application.