I’m dealing with these issues already for a long time. But meanwhile, after a couple of support cases, the fog seems to lifting.
When you don’t have the following setup, you can stop reading:
- create accounts for partners in your on-premises Active Directory (AD)
- sync these accounts to Azure Active Directory (AAD)
- Exchange RecipientType is MailUser
- you assign one of the following licenses:
- Customer Lockbox (in combination with SPO)
- Microsoft 365 Advanced Auditing
For the others, feel free continue reading. It might open your eyes for some issues your facing.
A lot of companies creating user accounts for their partners or contractors in their local, on-premises Active Directory. This is an absolute normal process as these accounts are used for granting permissions, access, etc. to on-premises resources or just for creating a badge, for charging reasons or similar for processing in a HR system.
This is not a bad thing and so we do as well. It can get complicated, when you start using Azure Active Directory and its services. As soon as you do this, you will start syncing your accounts from local AD to AAD and here you might start to see issues.
As soon when you assign a license, which contains Exchange related features, a process called ProxyCalc. This process takes care for consistency and to avoid having values in a users proxyAddresses collection, which contains not verified domains. You can read more about it here.
It is clearly written that this applies only for “mailbox users”:
The same process for only including verified domains also occurs for proxyAddresses, but with some additional logic. The check for verified domains only happens for mailbox users.
But also the following statement:
A mail-enabled user or contact represent a user in another Exchange organization and you can add any values in proxyAddresses to these objects.
This is quite confusing. In the end this means as soon as meat one of the facts, the process is triggered and addresses with non-verified domains will be stripped:
- The user has been assigned a service plan that includes Exchange Online even if the user was not licensed for Exchange. For example, if the user is assigned the Office E3 SKU, but only was assigned SharePoint Online. This is true even if your mailbox is still on-premises.
- The attribute msExchRecipientTypeDetails has a value.
- You make a change to proxyAddresses or userPrincipalName.
What’s the consequence?
Now you might think:
So what? These addresses are stripped-off. E-mails sent to such recipients are still delivered.
Issue profile cards
One of the issue is straight visible. The profile card doesn’t show the actual e-mail address of the MEU.
Issue multiple objects for single person
This is not obvious as the previous one, but has quite a negative and confusing impact. As the address is stripped-off the proxyAddresses collection, the lookup for such an user in the workload Microsoft Teams will fail. This leads into having a guest account created with this particular address as targetAddress.
Now you have two user objects for this one natural person in your tenant:
- one with userType Member
- one with userType Guest
This also means that authentication takes place in different locations (member either in the tenant or on-premises AD, while guest is authenticating against it’s own authority).
But this is not the only issue: There is a huge delay across different substrate search engines and directories, which can take up to several days until all systems are on the same page! I’ll cover this in another post.
Which license triggering this?
Sadly there is no documentation about this. In my tests, I’ve found the following licenses triggering this:
- Exchange Online (obviously!)
- Customer Lockbox (w/o EXO only SPO!)
- Microsoft 365 Advanced Auditing
- Microsoft Communications DLP
- Microsoft Customer Key
- Microsoft Data Investigations
- Microsoft Defender for Office 365 (Plan 2)
- Microsoft Information Governance
- Microsoft ML-based classification
- Microsoft MyAnalytics (Full)
- Microsoft Records Management
- Office 365 Advanced eDiscovery
- Office 365 Privileged Access Management
- Office 365 SafeDocs
I strongly believe there is room for improvement in this topic. It is absolutely confusing and I can understand the view from different PGs, but they only look at their single piece.
I wish they would have a look at the whole picture. This would improve not only this particular topic!