New Cross-Tenant Access Settings in Azure AD

Microsoft 365, formally Office 365, is maturing. It has been more than 10 years since the launch of Office 365, and the type of migrations I see as a consultant are changing.

10 years ago, I was doing migrations into Exchange Online one after another. Office 365 started off as a place to put your email with maybe some limited SharePoint and Skype for Business services attached. As Office 365 matured into Microsoft 365 with much more functionality from SharePoint Online, Teams, added services like Endpoint Management (Formerly Intune), a whole host of security and compliance tools, the sort of projects I have been doing has evolved.

Now a fair amount of the migrations I am doing involve tenant consolidations and splits. Companies and other organizations that use Microsoft 365 are subject to all the standard economic forces that cause legal entities to realign themselves. These organizational changes mean that more and more organizations need ways to collaborate between separate Microsoft 365 tenants. Those organizational consolidations and splits often require a higher level of cross-tenant access between tenants either before or after the tenant migrations, but Microsoft 365 is just not built to support this kind of cross tenant collaboration.

Recently, Microsoft has added a new feature to help manage that exact sort of cross-tenant collaboration. In this blog post, I am going to dive into the new cross-tenant access settings that have recently been added to Azure Active Directory.

What are the new settings?

Microsoft has added the new cross-tenant access settings tab in Azure Active Directory under “External Identities”:

The red arrow in the picture above points to the tab for the new cross-tenant access settings. The two green arrows point to the major relevant sections of this new feature.

We’ll start with the default settings area. “Default settings apply to all external Azure AD organizations not listed on the organizational settings tab. These default settings can be modified but not deleted.”

Within this section of the tool, you can manage the cross-tenant access settings that apply to all other Azure AD tenants. Guest users from other organizations that are not setup with specific settings of their own will receive their access settings from here.

As shown above, the settings are separated into inbound and outbound settings. The inbound and outbound settings are further separated into B2B collaboration for users and groups and applications. The inbound settings also have a section for trust settings.

The trust settings allow you to trust the MFA setup, compliant devices, and Azure AD joined devices from other tenants. I would recommend leaving these options off here, not allowing default trust for external organizations security settings. If you’d like to trust the MFA, complaint devices, or Azure AD joined device settings from another organization that can be done specifically for each organization under the “organization settings” section.

Continuing with the inbound settings for B2B collaboration. Here you can allow or block all external access for users and groups or by application. “B2B collaboration inbound access settings lets you collaborate with people outside of your organization by allowing them to sign in using their own identites [sic]. These users become guests in your Azure AD organization.”

The same settings are available under the Outbound access settings. The difference is these settings control the access users from your Azure AD tenant will have in other tenants. Of course, you cannot grant your users access to any other tenant, but these settings can limit the access you users have in other tenants.

The applications section allows you to modify the access setting by application instead of users or groups. You can add specific applications to this section. I added “Office 365 SharePoint Online” as shown in the screenshot below:

The “Allow access/Block Access” radio button under “External users and groups” and under “Applications” must both be set to either allow or block. If I try to set block access under applications while allow access is set under External users and groups, I get the following error:

Furthermore, the “Applies to” section does not allow you to allow or block specific applications separately. As the feature is currently, I do not see any reason to muck with the “All applications/Select applications” radio button as the above “Allow access/Block access” selection will apply to everything. I don’t see a way to allow access to SharePoint Online while blocking access to Exchange Online. I’m going to assume that bit of functionality will evolve. This feature is still in Preview. I hope and expect that will be fixed before this feature moves to general availability.

Moving on from the default settings to the organizational settings, this section allows you to modify the default settings for specific organizations you add. I would recommend leaving the default settings section as it is for security reasons and adding specific additional permissions to specific organizations here.

To test this out, I spun up a test tenant from the Microsoft Developer portal. In the screenshot above, the green arrow point to where you’ll go to add an external organization. Both buttons do the same thing, so I’m not sure why Microsoft put the same button on this page twice.

You can add another organization here using either the tenant’s name (mcsmlab.com, or mcsmlab.onmicrosoft.com both work for my tenant), or using the Tenant ID. The screenshot below shows the interface where I added a test tenant to my own tenant.

Once a tenant is added here, the cross-tenant access settings portal will look like this:

As you can see there, both inbound and outbound settings are initially set to “inherited from default”, which allows the same access for users from and to that organization as if you had not added that organization here at all. However, I now can customize all the setting I talked about above for this specific organization. Clicking on the blue “Inherited from default” for either inbound or outbound access settings allows me to customize access settings for users from that specific Azure AD tenant.

So now we’re all done right? Users from the m4fk test tenant should have access to all my resources setup in my mcmslab tenant?

Nope.

These cross-tenant access settings do govern the access users from the m4fk tenant would have to resources within my mcsmlab tenant but adding an organization does not create guest accounts.

The cross-tenant access settings allow you to modify the access that guest users from other organizations will have with their guest accounts. Each user from the other organization will still need a guest account setup in your tenant, and permissions within the specific applications in your tenant they will be accessing. You can invite external users directly or you can setup self-service sign-up so they can request access to your resources. That process is unchanged by this new functionality.

This tool allows you to quickly limit the access that guest users from other tenants will have in your tenant. It does not grant new cross-tenant functionality, or even make the existing cross-tenant functionally work “better”. It does not give you an easy way to create a new Global Address List in Exchange Online that will contain users from another tenant, or automatically grant access to all your SharePoint Online sites to users from another tenant with a couple of clicks.

Think of the new feature as a way to easily and globally limit collaboration settings in your tenant, not as a way to allow users from another organization to work in your tenant.

Active Directory Monitoring and Reporting

Active Directory is the foundation of your network, and the structure that controls access to the most critical resources in your organization. The ENow Active Directory Monitoring and Reporting tool uncovers cracks in your Active Directory that can cause a security breach or poor end-user experience and enables you to quickly identify and remove users that have inappropriate access to privileged groups (Schema Admins, Domain Administrators). While ENow is not an auditing software, our reports reduce the amount of work required to cover HIPAA, SOX, and other compliance audits.

Access your FREE 14-day trial to accelerate your security awareness and simplify your compliance audits. Includes entire library of reports.