This is my take on the Azure AD Cross-Tenant access settings. This was something I was hoping to configure a while back. However the capabilities weren’t available at that time, but the need for some kind of a trust relationship between two Azure AD tenants was bubbling up. Gone of days organizations set up trust between 2 AD environments. The functionalities have been moved to cloud identity being the source of truth.
Why Cross-Tenant Access Matters?
Simple answer, this answers the age-old question, traditional Active Directory environments support domain trusts and resources via that trust. When will we have an Azure AD to Azure AD trust? and more importantly the Guest Account access process has some drawbacks. Guest accounts are better in once-off tasks, but when you have to give access to a whole set of users from another Azure AD tenant, you don’t want to create hundreds of guest accounts to cater to the requirements.
Organizations don’t always have the requirement to consolidate/ migrate 2 tenants in an M&A situation. Most of the time it’s where employees need to collaborate with the employees in the other organization and the IT departments still want to maintain security while cross-access is happening. Or a quick and recommended method to accessing the other tenant until such time consolidation is planned.
Some Issues I faced without a Good B2B Process
In an M&A situation, how can I onboard users quickly and get them to access the parent company’s Azure AD tenant’s apps?
How to automate the Guest account creation process without everyone going through the consent setup before registering as a Guest in the Azure AD?
Of course, each and every one of the Guest account users has to accept the invite or follow the URL so their accounts will be activated.
Once the actual user behind the Guest account leaves the business, can I automate the Guest account removal?
How to provide access to resources with the Guest account status
Improvements in B2B Collaboration
While this works as inviting Guests to your Azure AD tenant and then providing access to resources, earlier there was no scoping mechanism, whereas now you can scope out the user groups or specific users that need to be added as Guests as well as which applications they need to be a part of.
What Does B2B Direct Connect Bring to the Table?
Rather than going to the technical details straight away, I would like to explore what are the improvements and how they can eliminate some of the B2B Collaboration issues.
Guest User management – This eliminates the fact that you have to maintain Guest accounts in your Azure AD tenant. With B2B Collaboration, if you don’t have proper Access Reviews setup, chances are you are keeping stale Guest accounts of the users who are probably left the business in the other tenant, or users who doesn’t need access anymore.
Ability to determine the user account access type depending on the requirement. Meaning that if the external party’s account is an MSA (Microsoft Account) but not a Work or School account, you can provide them a Guest account. Whereas if the external party is coming from an Azure AD and if you think this will be a long-term engagement, you can create trust between the 2 tenants and provide them with B2B Direct Connect.
Shared Teams Channels – If you are planning to go with the B2B Direct Connect method, it gives you the option of adding the users in the External Azure AD tenant to Shared Teams channels. This gives them the “wonderful” (yes I mean the word wonderful!) option of not switching Teams when they want to collaborate with the other Azure AD tenant users who are in the same channel. Now, how good is that?
Other Trust Settings Worth Mentioning
Honor Multi-Factor Authentication Claims
If you are planning to go with the B2B Direct Connect method, you can set the MFA trust settings to honor incoming access requests from the external Azure AD tenant.
Honor Device Trusts
Same as MFA trusts, this will make sure it trusts the external Azure AD tenant user’s device’s join status (AAD Join or Hybrid AAD Join) when checking for an authentication session for a device claim. If the session contains a device claim indicating that the policies have already been met in the user’s home tenant, the external user is granted seamless sign-on to your shared resource. This can be set up in the B2B Direct Connect Trust Settings.
Honor Compliance Status
This will make sure it trusts the external user device’s Device Compliance state and if it’s met in their home tenant, it will be followed in the resource tenant as well.
Scoping Your B2B Direct Connect
I think this is a fantastic option in the B2B Direct Connect Feature. Imagine you need to give access to the external Azure AD tenant users, but only to one group or to a set of users. You can scope this out. Provide the group or the user ID of the external tenant and viola! you are done.
This can be done either way. Meaning that you can scope which users in the home tenant to allow access in the external tenant (Outbound Access) or visa versa (Inbound Access)
B2B Direct Connect Limitations At This Stage
There are some limitations at the time of writing. This is only working for Shared Teams Channels. Within the Shared Teams Channels, members can create files, IM, add apps, and bound to the Teams policies.
While this is a good way to easily provide access, you might want to keep an eye on the sign-in activities as well. This can be done from the Entra portal > Users > Sign-in Logs
Add the filter Cross tenant access type
And Select B2B direct connect
This will show all the Cross-tenant B2B direct connect related sign-ins
If you check the same in the Home Tenant, you can understand if the external user has satisfied the Azure AD MFA requirement
Wrapping Up | What Does This Tell About the Future?
I have a strong feeling that this feature will be expanded to other areas as well. A unified Exchange GAL? App Access? Other Sharepoint resources access? An API to automate user workflows? I will leave you with that.