I have the following use case: Company ABC is running in a cloud-only Azure AD/O365 environment. They have deployed Okta successfully, for SSO with MFA. ABC has a Division D which, for operational reasons, they need to move to a separate Azure AD tenant (XYZ). It's not going to be sold off. ABC will own XYZ, and XYZ users will continue to be FTEs of ABC. ABC is willing to deploy Okta to XYZ.

The desired outcomes after this move are:

• XYZ users must continue to have seamless use of ABC-licensed apps including Outlook, Teams, OneDrive, SharePoint, and Box.com.
• XYZ users must be able to send/receive emails in their ABC mailboxes using their original ABC email address.
• XYZ users must not lose any past emails in their ABC mailboxes or any history in Teams, OneDrive, SharePoint, etc.

My test environment consists of 2 Azure tenants/domains (ABC and XYZ), each with its own O365 subscription. I created test users in each domain. To create some usage history for the ABC users, I saved docs in OneDrive and SharePoint, sent emails between users (including attachments), and created Teams Channels and chats (with attachments). The XYZ users were created 1:1 to the ABC users (each Div D user will need an account in XYZ).

I have successfully achieved each of the outcomes by converting ABC users (aka Internal Members) into External Members as documented here: https://learn.microsoft.com/en-us/azure/active-directory/external-identities/invite-internal-users. Additional ref: https://learn.microsoft.com/en-us/azure/active-directory/external-identities/user-properties.

The conversion process involves making "sure the User.Mail property of the internal user object (the user's Email property in the Azure portal) is set to the external email address they'll use for B2B collaboration." The User.Mail property is equivalent to the user's Other emails property which appears in the Azure Portal's user properties UI. This User.Mail (aka Other emails) property is the address the user's B2B invitation is sent to.

The login process for External Members is similar to that for a typical B2B (External) Guests (e.g., a consultant, partner or vendor); they will use their external domain (XYZ in this case) credentials to log into ABC's apps. One MAJOR difference, however, is the typical External Guest setup process changes an existing user's UPN or creates a new guest user with a UPN containing their external email address with the "*EXT*" suffix. The process I followed, converting an Internal Member to an External Member, does not change the user's UPN. They must use the email listed under User.Mail (aka Other emails) to login.

Again, in my pure Azure AD and O365 test environment, I have this solution working beautifully, as desired. My question is: can Okta accommodate this? I am not aware of the Azure AD User.Mail (aka Other emails) property being sync'd with Okta's attributes, either through Azure AD as an IdP or through Office 365 federation including user Import and user Provisioning. And, as mentioned above, this field is CRITICAL for External Members to be able to login to the source domain (ABC). If Okta can't accommodate the External Member setup, is there a way to accomplish this user move and the desired outcomes with Okta?

Any and all help will be greatly appreciated.

Thank you in advance,

Ed