Azure conditional access policies provide a broad range of settings that administrators can utilize to enforce protections in their environment. It is common to see policies that attempt to control mobile device access to Exchange Online – and apply to a common protocol Exchange Active Sync.

 

I recently worked an interesting escalation where a customer was reporting a behavior I had not previously noticed. In this case the customer created a policy that applied to mobile devices and Exchange Active Sync – the policy contained a set of criteria to block access. The specifics of the overall policy did not matter – just that it contained a block action and applied to Exchange Active Sync.

 

When we reviewed the sign on events for a particular user – we discovered the following:

• The sign on was successful.
  
• Conditional access failed due to meeting a policy where a block was applied.
  

   

   

Here is a sample logon from the sign on logs we were able to gather from the customer.

 

Date:2021-06-21 02:30:18

User:UPN

User Name:NAME

Application:Office 365 Exchange Online

Status:Success (0)

Is Interactive:True

IP address:IPAddress

Client App:Exchange ActiveSync

Device ID:N/A

Device OS:Android

Device Browser:N/A

Location:El Progreso, Yoro, HN

Correlation Id:af236446-b0f4-47e5-9b00-ddbcce28baba

Conditional Access:failure

Request Id:73ceb107-3015-496e-9715-1882316c7301

MFA Required:No

Risk State:none

Risk Level (aggregate):none

Risk Level (real-time):none

Risk Detail:none

Risk Event Types:N/A

Alternate SignIn Name:UPN

 

Naturally this lead to the question of how a sign on could be “success” and conditional access “failed”. Typically when conditional access encounters a policy that applies with a block action – the sign on is “failed” and conditional access is “failed”. The expectation in this instance was that the sign on would be blocked in Azure Active Directory – this information seems to contradict that expectation.

 

In this particular instance what we were observing is expected. When a conditional access policy applies to Exchange Active Sync and contains a block action – Azure Active Directory does not block the access. In this instance a good user name and password was passed so an access token was granted. When the conditional access policy was evaluated and a determination that a block should occur was made – the overall request was tagged with a blocked action. Unlike other conditions where Azure Active Directory performs the block – the request is forwarded to Exchange Online tagged with the blocked action. Azure AD relies on Exchange Online to process the block and prevent the device from accessing any data.

 

Why is this by design? When it comes to mobile devices Azure Active Directory and Exchange Online share some overlap. In Exchange Online you also have the concept of approved devices, quarantined devices, and other device policies. By passing the flags into Exchange Online this allows Exchange Online to evaluate the device and any policies that may exist there. For example, repeated bad logon attempts or bad user name / passwords may result in the device being quarantined in Exchange Online.

 

Ultimately this issue was discovered because the user was flagged in Cloud App Security. Cloud App Security was identifying a successful logon from a location where logons were not desired. In this instance – that’s correct. The logon was successful and did occur from a location the user was prevented access.

 

In the long term a change is being evaluate to more accurately reflect the conditions. The anticipated change will log a failure for the sign on when the protocol is Exchange Active Sync and the conditional access status is failed. This should allow for more accurate reporting and less ambiguity about the outcome of the sign on operation from an Azure Active Directory standpoint.

For the last several days I’ve been working with a customer that had a third party SAML application published in Azure Active Directory. They were engaging us to look at what appeared to be an odd behavior in the sign on / authentication experience of the user.

In this particular scenario the application was browser based and being accessed through the third party site. The third party site was configured for SAML based authentication to Azure. During the session the user would utilize the applications sign out functionality. The expectation at this time was that the user would be able to reopen the connection to the third party application and not be redirected for authentication. In testing this appeared to be true – a user was not prompted for credentials again in the first day. If the user came back after 72 hours they were re-prompted for credentials.

Our original working assumption was that the reason for the authentication was how the token lifetime was being interpreted. Using fiddler we observed the following scenario:

• User accesses an internal company portal and selects the application.
  
• The user is redirected to the third party applications website and selects to sign on.
  
• The sign on request is redirected to Azure via login.microsoftonline.com.
  
• The request does not come with an existing authentication cookie. The request is redirected to the federation endpoint on-premises.
  
• The user authenticates to the forms based authentication endpoint in the federated on-premises solution.
  
• The token is returned to login.microsoftonline.com.
  
• The authentication session is returned to the third party.
  

 

We can see in the federation return that the persistent authentication cookies were set. Here is a sample cookie from fiddler.

 

Set-Cookie: ESTSAUTHPERSISTENT=0.ASkARErL9Yw2dU2I89hHRJ_-smKmQ_mBm_pHo39NBcMffS8pABo.AgABAAQAAAD–DLA3VO7QrddgJg7WevrAgDs_wQA9P_SAKceI10neWuC-T3WHd5fGMRQVB9AyIBljUtpDvE14VkEpbtaaiI0m3HGAtAyeBD9aMwnK6QPi3ZVWoKrQQyuxbxxi4bJLAgaXlvn5PXZmtkE349poyoDJww5kkRVlHRvzcj57or9hSCo5XRafA8kSRZGKjR9sK4qzOCattU2WVUEsFfR836mQtE6ngGog_FFtVh6lv2q-7mCo0EvRINEAL5bjgLHVNYwLAoQEhV25DuYLC8pUdt3CbjUkPpoEqSVwYp-a43hR0ka_B68pNy82eDLVcqbguaPOsSDX9lGHbgO2HlEi0alDiULSQ68N–zuVEKzTlI4wGyPdS-YQR1DwTgmrNRlshyGcG5uNVnibvxscLAQA9qwNOcOXBHLFNV3EUeIQqBLj0CThVIKEJ4-Kc2waT1rRV3f3Z_OxalNM4A7RAx_XZc0no7hTqReWbdBmSGLXXa2m7d3c9wrd_7toV3Iv0uOtU0n86zkqw; domain=.login.microsoftonline.com; expires=Sun, 22-Aug-2021 14:14:07 GMT; path=/; secure; HttpOnly; SameSite=None

 

The date highlighted in red was 90 days from the date of the request. This leads us to reasonably believe that the federated solution is returning a token for the full expected validity period.

 

The next step was looking at any legacy token issuance policies. In this case the Azure tenant had no custom token issuance policies so there would be no intentional override of the token lifetimes.

 

Following the review of token issuance policies we dug deeper into the sign on logs. A review of the individual sign on showed nothing out of the ordinary. There were no conditional access policies that would have impacted token lifetime.

 

At this point it remained a mystery as to why the users were re-prompted for authentication. Remember – the symptoms we were investigation were users were only re-prompted for authentication after 72 hours.

 

Collecting further information our engineering teams were engaged to review the sign on logs. This is when the scenario unfolded further. Our engineering team returned with an answer this was by design. The azure session associated with the authentication expired after 24 hours of inactivity. I thought the timeout only occurred at 72 hours? With further work we discovered that after the initial logon the second test of access was being performed within 24 hours. In this case the tenant was configured to not display the keep me signed in dialog on sign on. The keep me signed in dialog is a decision offered to the user that sets a persistence value for the session (not the authentication token). When persistence is disabled – the session is configured with a rolling 24 hour expiration. In this case the test was performed within the 24 hours – which reset the last session access time and added 24 more hours. Testing was discontinued and we returned greater than 24 hours after the test at which time the user was re-prompted for authentication. To review the scenario:

 

• User accesses an internal company portal and selects the application.
  
• The user is redirected to the third party applications website and selects to sign on.
  
• The sign on request is redirected to Azure via login.microsoftonline.com.
  
• The request does not come with an existing authentication cookie. The request is redirected to the federation endpoint on-premises.
  
• The user authenticates to the forms based authentication endpoint in the federated on-premises solution.
  
• The token is returned to login.microsoftonline.com.
  
• The authentication session is returned to the third party.
  
• Within 24 hours the user repeats the test.
  
• User accesses an internal company portal and selects the application.
  
• The user is redirected to the third party applications website and selects to sign on.
  
• The sign on request is redirected to Azure via login.microsoftonline.com.
  
• A valid authentication token exists and the session is valid.
  
• The user is not re-prompted for credentials.
  
• User access an internal company portal and selects the application two days later.
  
• The user is redirected to the third party applications website and selects to sign on.
  
• The sign on request is redirected to Azure via login.microsoftonline.com.
  
• The request comes with an existing authentication token – the associated session in Azure is now invalid. The request is redirected to the federation endpoint on-premises.
  
• The user authenticates to the forms based authentication endpoint in the federated on-premises solution.
  
• The token is returned to login.microsoftonline.com.
  
• The authentication session is returned to the third party.
  

 

In the end the desire is that the user not be re-prompted and to understand the authentication flow in play here. If you desired to control this – how would this be controlled.

 

The first step would be to create a conditional access policy that applies to this application and includes any scoping filters desired. In this policy you can override the persistence flag and set the connection to be persisted. This eliminates the 24 hour session timeout and places the session on a rolling 90 day expiration. This coincides with the default token time issued – and would result in the user being prompted after 90 days. If you wanted to control this even further – you would also add sign on frequency and specify a number of days or hours. The sign on frequency would override the 90 day rolling session – by invaliding authentication at the designated time. This would force the user to re-authenticate. The authentication experience would differ in overall experience depending on the single sign on state of the federation configuration.

 

For more information see:

Azure Active Directory allows administrators to gate bad password attempts through the use of smart lockout. For information on the application of this feature see:

Prevent attacks using smart lockout – Azure Active Directory | Microsoft Docs

Mitigate credential attacks – Azure AD B2C | Microsoft Docs

I recently worked an interesting escalation where the customer established a smart lockout was configured to trigger block actions at 5 bad password attempts. As the customer was testing this solution they discovered that they were able to, on occasion, pass more than 5 bad password attempts before the user was locked out.

We were able to prove this by initiating a test and reviewing the sign on logs. The sign on logs showed rapid bad password attempts that in this instance locked the account out at 8 attempts.

Why was the actor allowed to pass 8 bad passwords when the lockout is 5? Each azure data center processes the bad passwords and lockout counts independently.

“Each Azure AD data center tracks lockout independently. A user has (threshold_limit * datacenter_count) number of attempts, if the user hits each data center.”

 

In this instance the collective number of attempts reached a limit where smart lockout was engaged. This does not mean that smart lockout did not work – it just worked as designed in the current implementation. Our engineering groups indicated that they’re continuing to refine this process to account for multi-datacenter processing.

In Azure Active Directory administrators and end users can invite external parties to access their resources through guest accounts. When a resource is accessed a guest account is provisioned in the tenant that shared the source.

Here is a sample of a guest account provisioned as the result of accessing a one drive sharing link.

 

PS C:\> Get-AzureADUser -ObjectId 2812ee91-3822-4b0e-b650-f9d57a4ac5bd | fl

 

 

ExtensionProperty : {[odata.metadata, https://graph.windows.net/f7d9d2a4-dded-4f6f-90a9-5011281137b9/$meta

data#directoryObjects/@Element], [odata.type, Microsoft.DirectoryServices.User],

[createdDateTime, 6/14/2021 2:31:01 PM], [employeeId, ]…}

DeletionTimestamp :

ObjectId : 2812ee91-3822-4b0e-b650-f9d57a4ac5bd

ObjectType : User

AccountEnabled : True

AgeGroup :

AssignedLicenses : {}

AssignedPlans : {}

City :

CompanyName :

ConsentProvidedForMinor :

Country :

CreationType :

Department :

DirSyncEnabled :

DisplayName : Timothy McMichael

FacsimileTelephoneNumber :

GivenName :

IsCompromised :

ImmutableId :

JobTitle :

LastDirSyncTime :

LegalAgeGroupClassification :

Mail : tmcmichael@domain.org

MailNickName : tmcmichael_domain.org#EXT#

Mobile :

OnPremisesSecurityIdentifier :

OtherMails : {tmcmichael@domain.org}

PasswordPolicies :

PasswordProfile : class PasswordProfile {

Password:

ForceChangePasswordNextLogin: True

EnforceChangePasswordPolicy: False

}

 

PhysicalDeliveryOfficeName :

PostalCode :

PreferredLanguage :

ProvisionedPlans : {}

ProvisioningErrors : {}

ProxyAddresses : {SMTP:tmcmichael@domain.org}

RefreshTokensValidFromDateTime : 6/14/2021 2:31:01 PM

ShowInAddressList : False

SignInNames : {}

SipProxyAddress :

State :

StreetAddress :

Surname :

TelephoneNumber :

UsageLocation :

UserPrincipalName : tmcmichael_domain.org#EXT#@tenant.onmicrosoft.com

UserState :

UserStateChangedOn :

UserType : Guest

 

When reviewing the attributes in Azure Active Directory mail enabled attribute are present and populated. These include:

ProxyAddresses : {SMTP:tmcmichael@domain.org}

MailNickName : tmcmichael_domain.org#EXT#

Mail : tmcmichael@domain.org

 

With the mail enabled attribute present the forward synchronization process creates a mail enabled contact in Exchange Online. Here is an example of the mail enabled contact:

 

PS C:\> Get-Recipient 2812ee91-3822-4b0e-b650-f9d57a4ac5bd | fl

 

 

RunspaceId : 4cab3762-6d2a-4c7d-8d12-bdf8ccd840ee

Identity : tmcmichael_domain.org#EXT#

Alias : tmcmichael_domain.org#EXT#

ArchiveGuid : 00000000-0000-0000-0000-000000000000

AuthenticationType : Managed

City :

Notes :

Company :

CountryOrRegion :

PostalCode :

CustomAttribute1 :

CustomAttribute2 :

CustomAttribute3 :

CustomAttribute4 :

CustomAttribute5 :

CustomAttribute6 :

CustomAttribute7 :

CustomAttribute8 :

CustomAttribute9 :

CustomAttribute10 :

CustomAttribute11 :

CustomAttribute12 :

CustomAttribute13 :

CustomAttribute14 :

CustomAttribute15 :

ExtensionCustomAttribute1 : {}

ExtensionCustomAttribute2 : {}

ExtensionCustomAttribute3 : {}

ExtensionCustomAttribute4 : {}

ExtensionCustomAttribute5 : {}

Database :

ArchiveDatabase :

DatabaseName :

Department :

ExternalDirectoryObjectId : 2812ee91-3822-4b0e-b650-f9d57a4ac5bd

ManagedFolderMailboxPolicy :

EmailAddresses : {SMTP:tmcmichael@domain.org}

ExpansionServer :

ExternalEmailAddress : SMTP:tmcmichael@domain.org

DisplayName : Timothy McMichael

FirstName :

HiddenFromAddressListsEnabled : True

EmailAddressPolicyEnabled : False

LastName :

ResourceType :

ManagedBy : {}

Manager :

ActiveSyncMailboxPolicy : Default

ActiveSyncMailboxPolicyIsDefaulted : True

Name : tmcmichael_domain.org#EXT#

Office :

ObjectCategory : NAMPR04A004.prod.outlook.com/Configuration/Schema/Person

OrganizationalUnit : nampr04a004.prod.outlook.com/Microsoft Exchange Hosted

Organizations/tenant.onmicrosoft.com

Phone :

PoliciesIncluded : {}

PoliciesExcluded : {{26491cfc-9e50-4857-861b-0cb8df22b5d7}}

PrimarySmtpAddress : tmcmichael@domain.org

RecipientType : MailUser

RecipientTypeDetails : GuestMailUser

SamAccountName : $RQ7JB1-DC52DJT8HKE5

ServerLegacyDN :

ServerName :

StateOrProvince :

StorageGroupName :

Title :

UMEnabled : False

UMMailboxPolicy :

UMRecipientDialPlanId :

WindowsLiveID : tmcmichael_domain.org#EXT#@tenant.onmicrosoft.com

HasActiveSyncDevicePartnership : False

AddressListMembership : {\All Recipients(VLV), \All Mail Users(VLV)}

OwaMailboxPolicy :

AddressBookPolicy :

InformationBarrierSegments : {}

SharingPolicy :

RetentionPolicy :

ShouldUseDefaultRetentionPolicy : False

MailboxMoveTargetMDB :

MailboxMoveSourceMDB :

MailboxMoveFlags : None

MailboxMoveRemoteHostName :

MailboxMoveBatchName :

MailboxMoveStatus : None

MailboxRelease :

ArchiveRelease :

IsValidSecurityPrincipal : True

LitigationHoldEnabled : False

Capabilities : {}

ArchiveState : None

SKUAssigned :

WhenMailboxCreated :

UsageLocation :

ExchangeGuid : 00000000-0000-0000-0000-000000000000

ArchiveStatus : None

SafeSendersHash :

SafeRecipientsHash :

BlockedSendersHash :

WhenSoftDeleted :

UnifiedGroupSKU :

ExchangeVersion : 1.1 (15.0.0.0)

DistinguishedName : CN=tmcmichael_domain.org\#EXT\#,OU=tenant.onmicrosoft.com,OU=Microsoft

Exchange Hosted Organizations,DC=NAMPR04A004,DC=prod,DC=outlook,DC=com

ObjectClass : {top, person, organizationalPerson, user}

WhenChanged : 6/14/2021 10:37:40 AM

WhenCreated : 6/14/2021 10:37:19 AM

WhenChangedUTC : 6/14/2021 2:37:40 PM

WhenCreatedUTC : 6/14/2021 2:37:19 PM

ExchangeObjectId : ec0d0393-c684-418f-aae3-a84b7de2af0b

OrganizationId : NAMPR04A004.prod.outlook.com/Microsoft Exchange Hosted

Organizations/tenant.onmicrosoft.com – NAMPR04A004.prod.outlook.com/Configurat

ionUnits/tenant.onmicrosoft.com/Configuration

Id : tmcmichael_domain.org#EXT#

Guid : ec0d0393-c684-418f-aae3-a84b7de2af0b

OriginatingServer : BN6PR04A04DC001.NAMPR04A004.prod.outlook.com

IsValid : True

ObjectState : Unchanged

 

Over the course of time guest users may have a need to access on premises resources of business processes may move to create mail contacts on premises for the users. In this example we will provision a mail user for this resource to provide access to not only on premises Active Directory resources but also Azure Active Directory resources. The object will be mail enabled so that it appears in the global address list.

 

Here is an example of the mail users attributes.

 

[PS] C:\>Get-MailUser TimExternal | FL

 

 

RunspaceId : 2825f621-657b-4e98-99b2-27b9d1c233a1

DeliverToMailboxAndForward : False

ExchangeGuid : 00000000-0000-0000-0000-000000000000

MailboxContainerGuid :

AggregatedMailboxGuids : {}

ArchiveGuid : 00000000-0000-0000-0000-000000000000

ArchiveName : {}

ArchiveQuota : Unlimited

ArchiveWarningQuota : Unlimited

ProhibitSendQuota : Unlimited

ProhibitSendReceiveQuota : Unlimited

IssueWarningQuota : Unlimited

ForwardingAddress :

ArchiveDatabase :

ArchiveStatus : None

DisabledArchiveDatabase :

DisabledArchiveGuid : 00000000-0000-0000-0000-000000000000

MailboxProvisioningConstraint :

MailboxRegion :

MailboxRegionLastUpdateTime :

MailboxProvisioningPreferences : {}

ExchangeUserAccountControl : None

ExternalEmailAddress : SMTP:tmcmichael@domain.org

UsePreferMessageFormat : False

JournalArchiveAddress :

MessageFormat : Mime

MessageBodyFormat : TextAndHtml

MacAttachmentFormat : BinHex

ProtocolSettings : {}

RecipientLimits : Unlimited

SamAccountName : TimExternal

UseMapiRichTextFormat : UseDefaultSettings

UserPrincipalName : TimExternal@tenant.com

WindowsLiveID :

MicrosoftOnlineServicesID :

MailboxMoveTargetMDB :

MailboxMoveSourceMDB :

MailboxMoveFlags : None

MailboxMoveRemoteHostName :

MailboxMoveBatchName :

MailboxMoveStatus : None

MailboxRelease :

ArchiveRelease :

ImmutableId :

PersistedCapabilities : {}

SKUAssigned :

ResetPasswordOnNextLogon : True

WhenMailboxCreated :

LitigationHoldEnabled : False

SingleItemRecoveryEnabled : False

ComplianceTagHoldApplied : False

DelayHoldApplied : False

RetentionHoldEnabled : False

EndDateForRetentionHold :

StartDateForRetentionHold :

RetentionComment :

RetentionUrl :

LitigationHoldDate :

LitigationHoldOwner :

RetainDeletedItemsFor : 14.00:00:00

CalendarVersionStoreDisabled : False

UsageLocation :

MailboxLocations : {}

IsSoftDeletedByRemove : False

IsSoftDeletedByDisable : False

WhenSoftDeleted :

InPlaceHolds : {}

RecoverableItemsQuota : Unlimited

RecoverableItemsWarningQuota : Unlimited

UserCertificate : {}

UserSMimeCertificate : {}

AccountDisabled : False

StsRefreshTokensValidFrom :

DataEncryptionPolicy :

OtherMail :

GuestInfo :

Extensions : {}

HasPicture : False

HasSpokenName : False

IsDirSynced : False

AcceptMessagesOnlyFrom : {}

AcceptMessagesOnlyFromDLMembers : {}

AcceptMessagesOnlyFromSendersOrMembers : {}

AddressListMembership : {\All Mail Users(VLV), \All Recipients(VLV), \Default Global Address List,

\All Users}

AdministrativeUnits : {}

Alias : TimExternal

ArbitrationMailbox :

BypassModerationFromSendersOrMembers : {}

OrganizationalUnit : home.tenant.com/tenant Objects/Users

CustomAttribute1 :

CustomAttribute10 :

CustomAttribute11 :

CustomAttribute12 :

CustomAttribute13 :

CustomAttribute14 :

CustomAttribute15 :

CustomAttribute2 :

CustomAttribute3 :

CustomAttribute4 :

CustomAttribute5 :

CustomAttribute6 :

CustomAttribute7 :

CustomAttribute8 :

CustomAttribute9 :

ExtensionCustomAttribute1 : {}

ExtensionCustomAttribute2 : {}

ExtensionCustomAttribute3 : {}

ExtensionCustomAttribute4 : {}

ExtensionCustomAttribute5 : {}

DisplayName : Tim McMichael (External)

EmailAddresses : {smtp:TimExternal@tenant.mail.onmicrosoft.com,

smtp:TimExternal@tenant.com, SMTP:tmcmichael@domain.org}

GrantSendOnBehalfTo : {}

ExternalDirectoryObjectId :

HiddenFromAddressListsEnabled : False

LastExchangeChangedTime :

LegacyExchangeDN : /o=tenant Home/ou=Exchange Administrative Group

(FYDIBOHF23SPDLT)/cn=Recipients/cn=be4631edc3bf4500986d9811e33d368c-Tim McM

MaxSendSize : Unlimited

MaxReceiveSize : Unlimited

ModeratedBy : {}

ModerationEnabled : False

PoliciesIncluded : {11c1f0d3-7114-4275-ab8b-fc0db18d2164, {26491cfc-9e50-4857-861b-0cb8df22b5d7}}

PoliciesExcluded : {}

EmailAddressPolicyEnabled : True

PrimarySmtpAddress : tmcmichael@domain.org

RecipientType : MailUser

RecipientTypeDetails : MailUser

RejectMessagesFrom : {}

RejectMessagesFromDLMembers : {}

RejectMessagesFromSendersOrMembers : {}

RequireSenderAuthenticationEnabled : False

SimpleDisplayName :

SendModerationNotifications : Always

UMDtmfMap : {emailAddress:8626424235, lastNameFirstName:62642423539837625846,

firstNameLastName:84662642423539837625}

WindowsEmailAddress : tmcmichael@domain.org

MailTip :

MailTipTranslations : {}

Identity : home.tenant.com/tenant Objects/Users/Tim McMichael (External)

IsValid : True

ExchangeVersion : 0.10 (14.0.100.0)

Name : Tim McMichael (External)

DistinguishedName : CN=Tim McMichael (External),OU=Users,OU=tenant

Objects,DC=home,DC=tenant,DC=com

Guid : c39606b7-ef2d-45c4-a877-869454b686fa

ObjectCategory : home.tenant.com/Configuration/Schema/Person

ObjectClass : {top, person, organizationalPerson, user}

WhenChanged : 6/14/2021 2:56:38 PM

WhenCreated : 6/14/2021 2:56:19 PM

WhenChangedUTC : 6/14/2021 2:56:38 PM

WhenCreatedUTC : 6/14/2021 2:56:19 PM

OrganizationId :

Id : home.tenant.com/tenant Objects/Users/Tim McMichael (External)

OriginatingServer : Azure-DC-0.home.tenant.com

ObjectState : Changed

 

Azure AD Connect is responsible for replicating the new mail user from on-premises Active Directory to Azure Active Directory. When synchronization is successful the following synchronization error may be noted.

 

PS C:\> (Get-AzureADUser -SearchString timexternal@tenant.com).provisioningErrors | fl

 

 

ErrorDetail : <ServiceInstance Name=”exchange/NAMPRD04-001-01″

xmlns=”http://schemas.microsoft.com/online/error/2010/07″&gt;

<ObjectErrors>

<ErrorRecord>

<ErrorCode>ExFEBFF0</ErrorCode>

<ErrorParameters>

<ErrorParameter>Enable-MailUser</ErrorParameter>

</ErrorParameters>

<ErrorDescription>The execution of cmdlet Enable-MailUser failed.</ErrorDescription>

</ErrorRecord>

<ErrorRecord>

<ErrorCode>Ex1472D1</ErrorCode>

<ErrorParameters />

<ErrorDescription>The proxy address “SMTP:tmcmichael@domain.org” is already being used by the

proxy addresses or LegacyExchangeDN of “tmcmichael_domain.org#EXT#”. Please choose another proxy

address.</ErrorDescription>

</ErrorRecord>

</ObjectErrors>

<LinkErrors />

</ServiceInstance>

Resolved : false

Service : exchange

Timestamp : 6/14/2021 3:02:39 PM

 

 

As the error indicates – the proxy address assigned to the mail user on-premsies now collides with the proxy address of the guest account in Azure AD.

To resolve this issue we must decide which of the two objects will be removed. In most cases – the guest account is removed so that the full provisioning process may occur on the mail users from on premises.

 

remove-AzureADUser -ObjectId 2812ee91-3822-4b0e-b650-f9d57a4ac5bd

 

Once the object with the duplicate attributes is removed a reprovision of the object can be triggered. This should force re-evaluation of the object.

 

Redo-MsolProvisionUser -ObjectId (Get-MsolUser -UserPrincipalName onPremUPN).objectid

 

When completed the administrator may validate that the provisioning errors are cleared by running the following command and verifying no returned errors.

 

(Get-AzureADUser -SearchString onPremUPN).provisioningErrors | fl