Azure B2B Collaboration

Collaboration and its intricacies

Photo by Kaleidico on Unsplash

B2B collaboration is the backbone of most business’, whether that may be as a result of deep rooted Managed Service Providers (MSP’s), Contractor presence or quite simply and most often real business use-cases.

In this article, we will explore what settings we can configure for use with Azure B2B collaboration and highlight some security considerations.

Exploring Azure Portal

Within your Azure tenant you are presented with a plethora of options which can impact your enterprise as a whole in many different ways. We’ll be exploring the external collaboration portion..

Azure Active Directory > User Settings (Image by author)

External Collaboration

Firstly, we have to highlight that historically there were two ways of identifying an external user within Azure Active Directory (AAD). This would be either as External or as a Guest. The difference being that ‘external’ users whom are in a directory authenticated outside of the home tenant. Guest users were treated as ‘managed guests’ authenticating directly inside the home tenant.

Now, Microsoft seems to have actively made the decision to migrate to simply using ‘Guests’.

Now these settings are logically grouped into three categories;
1) Guest user access, this defines what permissions the guest users will have in terms of 2) Guest invite settings, this defines who can invite guest users, if they can invite 3) Collaboration restrictions, this sets the scope for which invitations are allowed.

Some considerations to note from my experience on each of the categories:

1. Guest user access. Where do we start. Guests are guests right? We do not manage there identity but we allow them access to our resources and confidential information. If we do not manage their identity then why should they see others?
2. Guest invite settings. Allowing members to invite can alleviate a lot of administrative workload but you will likely want some restrictions in place such as domain restrictions from the subsequent category.
3. Collaboration restrictions. Now one fundamental finding to note around this setting is that if this is most inclusive (i.e. invitations are allowed to be sent to any domain) yet you are applying a domain restriction at SharePoint then users will still receive an invitation, thus becoming joined to AAD but will not be able to access the resource. Why do we care? That is another user within your environment that could access other less restrictive resources or exploit other configuration loopholes.

Azure Active Directory > User Settings > Manage external collaboration settings (Image by author)

Wrapping up

At the end of the day you have to consider business impact. Whilst enforcing the most rigid security measures may be the what is required of what you may want, there has to be the processes in place that support that. For example, who is going to support the process of managing a non-whitelisted domain and what is the process (from a internal user perspective) of requesting that.

I hope you’ve enjoyed the article. If you have any questions, ideas, or suggestions, please feel free to reach out via Twitter or in the comments below!

Thanks for reading!