In the current Azure environment, a user from another tenant can be represented by various identity objects. Most users have a cloud guest account, while a subset also possesses Mail contacts, alongside their guest user status. Additionally, some users have licensed accounts.
In this blog post, we will explore each of these representations and the process of merging/rationalizing these to ensure a single representation of the user in the resource tenant. This unified representation will be enabled for B2B collaboration with their home identity and mail-enabled for integration within Exchange.
Existing B2B Users
A user can have the following representations:
Guest account with the Invitation State as Pending Acceptance.
This is usually the case when the user was invited as a guest, but they never accepted the Invitation.
Cross tenant sync will fail for such accounts. Cross-tenant synchronization uses an internal attribute called the alternativeSecurityIdentifier to uniquely match an internal user in the source tenant with an external / B2B user in the target tenant. But since the invitation was never redeemed, alternativeSecurityIdentifier property will not be populated for the user.
Assuming that Automatic Redemption is enabled for both the tenant, you can reset the redemption/resend the invite to populate the alternativeSecurityIdentifier.
Reference Article
Reset guest redemption status - Microsoft Entra External ID | Microsoft Learn
Note: You may want to supress the invitation message to avoid end user notifications.
Multiple Guest account with the Invitation State as Pending Acceptance.
This typically occurs when multiple accounts are created for a user in the Home Account. Both accounts may be invited, and subsequently, one account is deleted while the email address is transferred to the remaining account.
Here in example:
- The user had the below account in Home tenant.
o Display Name: Lidia Holloway
o Email: Lidia.Holloway@contoso.com
- User was provided with another account for administration in Home tenant.
o Display Name: Lidia Holloway (GA)
o Email: Lidia.Holloway@fabrikam.com
- User was invited as a guest in the resource tenant with email address as Lidia.Holloway@contoso.com. The user never accepted the invitation.
- User was invited as a guest in the resource tenant with email address as Lidia.Holloway@fabrikam.com. The user never accepted the invitation in this case as well.
- Lidia Holloway (GA) account was removed from the Home Tenant and the email address Lidia.Holloway@fabrikam.com was added as an alias to the Lidia Holloway account.
- End State
Home Tenant:
o Display Name: Lidia Holloway
o Email Addresses:
SMTP: Lidia.Holloway@contoso.com;
smtp:Lidia.Holloway@fabrikam.com
Resource Tenant
Account1
o Display Name: Lidia Holloway
o Email Addresses: SMTP: Lidia.Holloway@contoso.com
o Invitation State: Pending Acceptance
Account2
o Display Name: Lidia Holloway
o Email Addresses: SMTP: Lidia.Holloway@fabrikam.com
o Invitation State: Pending Acceptance
The recommendation here would be to retain the one that matches the PSMTP Address of the Home Account and delete the other one.
Note: The account scheduled for deletion may have group memberships and email threads with other users. It is advisable to transition the Legacy Exchange Distinguished Name (DN) and group memberships to the account being retained. To achieve this, capture the Legacy Exchange DN and group memberships, delete the unnecessary account, and then transfer these attributes to the retained account.
Multiple Guest account with the Invitation State as Accepted and Pending Acceptance.
This is similar to the previous one, except that one of the invitations was accepted.
It is advisable to retain the account that is in an accepted state, as it may have permissions across various M365 workloads. There may also be situations where the PSMTP address of the home account was changed; in such cases, CTS should update the mail attribute according to the CTS configuration. If it does not automatically update despite the configuration, ondemand provisioning can be used to force the update.
Note: Just like the previous scenario, it is advisable to transition the Legacy Exchange Distinguished Name (DN) and group memberships to the account being retained.
Existing Contact Object
Contact Object
A user may be added as a Contact in the resource tenant, often when GAL Sync Solution is configured between organizations. There can be both Sync and Cloud-only contacts. These contacts might hold memberships in various synced and non-synced groups.
To achieve a single representation, it is recommended to capture the Legacy Exchange Distinguished Name (DN) and group memberships from the contact object and delete it. After this, perform the scoping and let the CTS create the B2B object. Finally, transition the Legacy Exchange Distinguished Name (DN) and group memberships to the B2B account.
Contact & a B2B Object
A user can be added as both a Contact Object and a B2B Object in the resource tenant, often occurring when invited as a guest with an existing contact object. Provisioning in EXO depends on the email address and creation order of these objects. The B2B object’s Invitation State can be either Pending Acceptance/Acceptance state.
If the B2B object’s Invitation State is Pending Acceptance, then it’s advisable to first remediate that. To achieve a single representation, the recommendation again would be to delete the contact object and transition the Legacy Exchange Distinguished Name (DN) and group memberships to the B2B account.
Contact + Multiple B2B Objects
A user can have a contact along with Multiple B2B Objects. In such scenarios, it is recommended to first rationalize the B2B Objects and proceed with the contact rationalization.
Internal /Dual Mailbox Users
Finally, there may be instances where users are classified as Internal Users in both tenants. Dual mailbox users cannot be enabled for B2B collaboration because the assigned email addresses will conflict with those of their home accounts. These dual mailbox users should be excluded from identity rationalization processes and should coexist with corresponding cloud external member objects created via cross-tenant synchronization. This setup can result in the user appearing twice in people search across Microsoft 365 applications unless one of the entries is hidden; however, hiding one entry could lead to additional complications.
A final note would be to perform the rationalization during off-business hours, preferably on weekends, to allow for rollback if needed. Also, consider nested groups when transitioning group membership.
Updated Jan 03, 2025
Version 2.0
pri2agarwalz
Microsoft
Microsoft
