GAL segmentation and Ethical walls in Microsoft Teams

It’s not uncommon for various types of organizations to want to restrict one or more of the form of communication between their users. For example, in the EDU sector students are often limited to seeing and communicating with just their peers. Another example are financial institutions which can get into a lot of trouble for any documented case of exchanging “insider” information, and so on.

“Ethical wall” or “ethical firewall” is a term used to designate a solution, or set of settings that prevent users from communicating with each other. In the Exchange world, this is usually enforced by transport rules. Another feature commonly used in such scenarios is GAL segmentation (also known as GAL segregation), or the process of splitting users into specific “groups”, limiting their visibility into users from the rest of the organization.

Now, Microsoft has released a feature that allows Teams to use the same controls in order to enforce a basic form of ethical wall. More specifically, this is a setting that instructs the Teams client to honor any Exchange Address Book policy configured for the user, instead of using the default company-wide search. You can find the corresponding setting in the Microsoft Teams & Skype for Business Admin Center, under Org-wide Settings, Teams Settings, Search, or directly via: https://admin.teams.microsoft.com/company-wide-settings/client-settings. The setting itself is called Scope directory search in Teams using an Exchange address book policy (ABP), as shown below:

As the name suggest, the setting relies on the configuration you’ve already made in Exchange Online. In my case, I have created the following custom ABPs:

Get-AddressBookPolicy

Name            GlobalAddressList AddressLists             OfflineAddressBook RoomList
----            ----------------- ------------             ------------------ --------
All Contoso ABP \New GAL          {\All Users, \All Rooms} \New OAB           \All Rooms
Teams           \New GAL          {\CustomAttribute15}     \New OAB           \Rooms15

The Teams policy includes only users for which the value of CustomAttribute15 is set to “Teams“. Yes, I’m simple like that.

Get-AddressList CustomAttribute15

Name                      DisplayName               RecipientFilter
----                      -----------               ---------------
CustomAttribute15         CustomAttribute15         CustomAttribute15 -eq 'Teams'

So, a user that has this ABP assigned will only be able to see limited set of users in the GAL, as shown below:

If the setting works as expected, it should prevent this user from searching for any users outside of the list shown above in any of the Teams clients or contacting them via the New chat box. So let’s try this. If I log in with the same user to Teams, and head out to the Chats section to initiate a new private chat with a user not included in the ABP, I get the following:

The same experience is observed if I try to search for a user not in scope of the ABP I’m assigned to via the Search box on top. In contrast, objects that are part of the ABP are returned just fine. The same behavior is observed when trying to schedule a new meeting, so the setting does seem to have effect.

The good news ends here though. As evident from the above screenshot, Teams is happy to suggest that I contact “Vasil Michev”, even though this user is NOT part of any address list I’m allowed to look at. And since there no actual message delivery restrictions enforced, I am able to contact this user just fine. Any user that is able to see my account in any address list he has access to is of course able to initiate a chat as well, as well as use any other type of communication method with me. And, I’m able to search for and initiate private forms of communication with any user we share membership of any Team with.

So in a nutshell, while the functionality can somewhat limit who a given user can see and initiate communication with from the Teams clients, it works by simply trimming the list of entries presented at few UI elements. There are multiple exceptions and no server-side functionality is added to actually block users from reaching each other, unlike the transport rules we can use for Exchange Online. Overall, a good first step, but it leaves a lot to be desired.

This entry was posted in Exchange Online, Microsoft Teams, Office 365. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *