Duplicate proxyAddresses sync error

[MaxRie]

Hello everyone,

I have a problem and need help with the solution.

We invite external people as guests to our Azure AD or Entra ID so that they can actively participate in Teams.

Sometimes it is necessary that the same external person also needs a user account in our local environment (AD), for example to access servers or similar locally in the environment.

In the local environment, the user is created in AD (no email mailbox) and only the "Email" field is filled in, as some applications read this attribute and send emails to this address. The "proxyAddresses" field is NOT filled in.

If I then try to synchronize the external user with the Azure AD / Entra ID, I get the message that the "Proxy Addresses" of the guest user and the user in the AD are identical, which gives me a synchronization error.

It's hard to imagine that I'm the only one with this problem. Nevertheless, I have not yet been able to find a solution.

[#2]

@MaxRie 

Hi, Max.

This is expected as an Azure AD-side process named MOERA will calculate what should go into proxyAddresses based on on-premise attributes like mail and userPrincipalName (amongst others).

You can read about it here, where from your description you'll be hitting Scenario 2:

• How the proxyAddresses attribute is populated in Microsoft Entra ID - Active Directory | Microsoft L...

You cannot use the e-mail address from the external guest user on the on-premise account's mail attribute.

Cheers,

Lain

[#3]

Hello Lain,

I've skimmed the article but I still don't understand why Entra ID means to set a proxy address for the AD user. The local AD user has no email mailbox, is not an email active user, is not included in any email distribution lists, ... Only the email field is filled in for the user.


Your last sentence was:
„You cannot use the e-mail address from the external guest user on the on-premise account's mail attribute.“


But I have several examples where I have exactly the same situation. This means that a guest user exists in Entra ID as well as in the local AD and is synchronized into Entra ID. And both objects have the same e-mail address. And I do not receive an error message for this user/guest.

Is this possibly related to the order in which the users are created (first guest or first AD user)?

Cheers
Max

[#4 · Accepted solution]

@MaxRie 

Hi, Max.

MOERA doesn't run for only mailboxes.

MOERA is triggered by any of the key mail attributes containing a value. Off the top of my head, these include:

• mail
• mailNickname
• proxyAddresses

And once MOERA has been triggered (it can take a short while - it's not instant), it will endeavour to populate the various Exchange Online-related attributes Azure-side. That's when you run into the "property conflict" errors.

With respect to ordering, I wouldn't think it matters, insofar as whichever was first should likely contain no error, while all subsequent introductions would fail with the property conflict.

Here's a contrived example I just created.

At the top there's two users with the same mail address. The entry that has a value for proxyAddresses (which is actually a guest user) has no error and MOERA was able to populate the proxyAddresses field. This is because it was created years ago and there was no conflicting entries.

The second entry is missing a value for proxyAddresses, which is a strong clue that there has been a provisioning error. I set mail (on the on-premise "Guest User" account) to the same address only a few minutes ago, so I expect this to be a conflict which has been found during the triggered MOERA process.

Checking the OnPremisesProvisioningErrors attribute of that second account, we do indeed see Azure telling us that proxyAddresses cannot be set as this mail address is already in use.

So, the outcomes here are that:

• Multiple users within Azure AD can contain the same mail address value; however
• This causes the MOERA process to fail updating other Exchange Online attributes; which leads to
• OnPremisesProvisioningErrors is updated to list (there can be multiple error items) the details of the conflict(s).

The resolution in my example is to change the on-premise value of mail for the second account.

If you want to remove the mail attribute from the Azure AD account (i.e. set it to null) that is "joined" to an on-premise account, it's more complicated as you can't set mail to null (see below for the "mail" attribute). Instead, you have to delete the user twice (the first produces a soft-delete and the second a hard delete), after which the account will be recreated on the next AAD Connect cycle.

• Update user - Microsoft Graph v1.0 | Microsoft Learn

This seems to be a Graph-induced limitation as AAD Connect talks directly to Azure AD and is quite happy to set mail equal to null.

Cheers,

Lain

[#5]

Hi Lain,

Thanks you for the explanation.

As far as I have understood, there is no solution for me. Because I need the email attribute for the local AD user for other internal applications, I cannot delete it. And since the guest user in the Entra ID may also need to receive emails, the email address must also remain there.
Is this correct?
If so, can I somehow whitelist these warnings so that I don't always see the same users of the warning, but instead only get notified about new sync warnings?

Cheers
Max

[#6]

@MaxRie 

Hi, Max.

There are possibly ways around this, but it depends on how far you're willing to go.

One option (the one I prefer in such circumstances) for these people that need to be both on-premise and in Azure is to delete their guest account, leaving the "normal" account that originated from on-premise and synchronised out to Azure AD intact.

If you still have an Exchange Server (aka on-premise server) you could then use the Enable-MailUser (or GUI equivalent, but I don't use the GUI so I can't offer steps on that) commandlet against the on-premise account to ensure they're registered as an external contact in Exchange Online.

• Enable-MailUser (ExchangePowerShell) | Microsoft Learn

If you don't have an on-premise Exchange Server, it's still possible, but you have to alter the four or so Active Directory attributes manually, which is more than I can easily explain here.

An additional benefit of this approach is that it's less confusing for the user since they don't have to remember two sets of credentials when accessing your environment.

This lends itself to benefitting your Azure applications and services teams where they only have to manage access for one account instead of two (which can easily lead to mistakes).

But again, it's largely a question of how far you're willing to pursue this.

The one thing that's not negotiable though is that you can't have two people with the same mail address and not run into errors.

In not being a GUI user, I don't know if the Azure Portal offers any way to suppress the reporting of the errors. Certainly, the errors are going to remain persisted within the underlying data, but whether the Portal provides any relief of its own, I cannot say (though my suspicions is it won't).

Cheers,
Lain

[#7]

Hi Lain,

thanks again for your support.

We have a local Exchange to manage the attributes. But I would also know which attributes I have to change in order to create a mail-enabled user from the user.

What I don't quite understand is:
If I would delete the guest user from the Entra ID and change the local AD user to a mail enabled user, then wouldn't it be the case that the local AD user would have to receive a Teams / SharePoint license from our company to be able to access Teams / SharePoint accordingly?
Or am I wrong here?

Wouldn't it then also be the case that the external user would not be able to work with their own company user in his Team-client, but would have to login with a second account (their user from our AD) instead?

Cheers
Max

[#8]

@MaxRie 

Hi, Max.

I wasn't overly-methodical in my approach since I set all the "usual suspect" attributes in one pass, but the ones I set were:

Attribute	Value	Example
mail	<the external mail address>	lain_robertson(at)hotmail.com
mailNickname	<the prefix of the external mail address>	lain_robertson
msExchRecipientDisplayType	6	6
msExchRecipientTypeDetails	128	128
targetAddress	<same as mail above>	lain_robertson(at)hotmail.com

Note: These forums strip out mail-like addresses, so I've used "(at)" instead of the "@" symbol in the example values.

With respect to the licencing, yes, the synchronised account from Active Directory would need to have the licences transferred off the Azure guest account onto it - if it needs any, that is.

So, it's no extra cost. It's just moving the licencing from one account to the other if necessary.

It's worth noting though that no licence is required to exist purely as an Exchange Online "mailuser" object. If they need to exist as a "mailbox", then they will need a licence, but not for just a "mailuser".

And yes, you're right about the impact on Teams and logging in twice. But given Teams just added the ability to log in to multiple accounts concurrently, this ought not to be a big issue.

But now matter how you try and work it, they're going to have to use two logins at some point anyway, since to access the internal Active Directory resources, they're having to use those credentials instead of their Azure guest credentials anyway.

It sounds like a little bit of a "six one way, half a dozen the other" kind of scenario you're facing, where nothing really represents a perfect answer.

Don't read too much into this next statement as I don't know nearly enough about the relationship between your company and theirs, but I can't help wondering if other options relating to classic Active Directory forest trusts combined with Azure guest users might not have been a "better" path. The administrative overhead would be greater but it could bring the remote partner closer to an SSO experience

Or another option could be using AAD Connect to filter out the on-premise Active Directory partner accounts if they don't actually need to be in Azure (which would implicitly solve all potential conflict scenarios), meaning they'd continue to use their Azure guest account for all Azure stuff. (Not that this would have any bearing on the partner still needing to know how to use two accounts.)

Anyhow, don't overthink those as they're way off topic from where this all started. Just figured I'd drop it in here in case you wanted to do your own research on it.

Cheers,

Lain

[#9]

Hi Lain,

Thanks again for the detailed explanation.

However, there is one point where I have to disagree, or rather, I have to ask for clarification.

You write:
„With respect to the licencing, yes, the synchronised account from Active Directory would need to have the licences transferred off the Azure guest account onto it - if it needs any, that is.

So, it's no extra cost. It's just moving the licencing from one account to the other if necessary.“


But we do not give licenses to external users in Entra ID. The external user has received his license from his own company and can therefore access SharePoint/Teams.

However, if I then delete the external user in the Entra ID and the external user uses the internal user from the AD, he then again needs a license that WE have to provide him with.

This means that there are extra costs involved.

Cheers
Max

[#10]

@MaxRie 

Hi, Max.

Azure licencing is an absolute minefield, but if you're only leveraging SharePoint and OneDrive external sharing (linked below) then you're correct, and there would be additional cost if you removed the guest account.

• Overview of external sharing in SharePoint and OneDrive in Microsoft 365 - SharePoint in Microsoft 3...

I'd mistakenly assumed the guests might be accessing more than that, which is what my comments around transferring the licencing related to.

We operate in both the B2C and B2B spaces where access to more than just SharePoint is required, so  for us, we are frequently required to add additional licences on our side at our cost.

If the on-premise Active Directory accounts are exclusively to provide these external people with access to domain-joined resources and you don't need those Active Directory accounts synchronised  into Azure, perhaps consider my earlier suggestion that it might be easier just to exclude these new Active Directory accounts from being synchronised to Azure via AAD Connect. That would solve your conflict problem and allow you to not have to make any changes Azure-side at all.

Cheers,

Lain

[#11]

@LainRobertson 

Hi Lain,

as I mentioned at the beginning, I only have this error in some cases and not in others.

I have now picked out one case where the error does not occur and one where the error does occur.

According to your statement, this should not be the case.
Can you explain to me why I don't get an error in the first case?

Cheers
Max

[#12]

@MaxRie 

Hi, Max.

Yes, your picture appears to make perfect sense (I'm making an assumption at this stage).

Rather than checking the guid beginning with "ad9b" from your first set, you want to be checking the one beginning with "e164". Remember, it's the one without a value for proxyAddresses that will feature the error (if there are any).

This comes back to what I mentioned about which was populated first:

• From the first batch of two, "ad9b..." was the first to claim "stefan.kampkoetter".
• In the second batch, "04a8..." was the first to claim "andre.rauer".

It's not about guest vs. member - the type of user has no bearing on this - nor does being synchronised vs. Azure-native. It's purely first in wins, with anything later losing the right to that mail address featuring in the proxyAddresses.

Cheers,

Lain

[#13]

Hello Lain,

since I didn't know exactly where the error should be, I just got everything with
Get-MgBetaUser -UserId "e164c9c4-24eb-4ffe-a0c8-012450aa288f" | fl
and looked at it. However, I could not find any errors. Maybe I'm looking at the wrong place?

In the first example, the guest user was in the Entra ID first and only then the AD user.
This is exactly where I would have expected the error because the guest user would have had to use the proxy address. But no

In the second example it is the other way around and this is exactly where the error is.

That somehow doesn't make sense to me.


Couldn't a solution for me be to delete the guest user in the Entra ID so that the AD user gets the proxy address?
Could I then somehow restore the user or would it have to be re-invited and all authorizations / access reassigned?
Or is there another way to somehow delete the proxy address for this user?

Cheers
Max

[#14]

@MaxRie 

Hi, Max.

I don't know as I haven't tried "tricking" the system before - that's not my preferred path. You'd have to give it a go in order to know.

That said, I do think that it won't solve the error generation. MOERA is still going to trigger, run into a conflict and report an error no matter which order the accounts are tinkered with in.

So, if you remove one account so that the other can claim the address, and then bring the removed account back after that has happened, I'd expect that once MOERA has run, you'll simply find that the error simply transfers/manifests on that restored account.

Cheers,

Lain