This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses using the common considerations for multitenant user management. Administrators will find that the process described here is familiar to them.

·        Directory Object Considerations – When a guest user account needs to be created, the user object is created by manually sending the invitation from the portal. This user object is of type Guest. Such accounts can be converted to user type of member but such conversion might have problems with Exchange Online that handles B2B accounts. Mail enabled accounts cannot be invited as guest users. A guest account can be mail-enabled by inviting the cross-org user, showing the account in the Global Address List, and setting up the user type to member.

The difference between using GAL synchronization rather than using Azure AD B2B collaboration is that a mail contact object is created in the first case but some limitations apply. A mail-contact object and a mail-enabled guest user cannot coexist in the same tenant with the same email address simultaneously. If the mail-contact object is already present with the same email address as a guest, then a guest user account can be created but it cannot be mail-enabled. If the guest user account with an email is already present, then creating a mail-contact object will throw an exception.

The recommendation between GAL synchronization and the Azure AD B2B collaboration is that the latter should be preferred. This allows external guest users to show up in the GAL and to create external member users that are not mail enabled. GAL synchronization misleads because the user object created might not have sufficient permissions as the mail-contacts are not security principals. Group memberships and resource access cannot be transferred to a mail-contact object.

·        Azure AD conditional access considerations - Even when a user object is fully created, the state of a user, device or network in the users’ home tenant isn’t conveyed to the resource tenant.

If the conditional access policies require multi-factor authentication, guest users will require to register/respond to the MFA in the resource tenant even if the MFA was satisfied in the home tenant. If the CA policies require the device to be marked as compliant, then the guest user cannot access it because device identity is not registered in the resource tenant. The same holds true for CA policies that require Hybrid Azure AD joined device. If the CA policies require approved client applications or app protection policy, then the guest users will still not be able to access it because InTune requires device registration.

If the conditional access policies are satisfied, even then there might be unintended consequences such as sign-in risk and user-risk which is determined in part by the user behavior in the home tenant. Also. the named location definitions are defined in the resource tenant which are used to determine the scope of the policy.