PSA: Exchange Online stops honoring Sharing policies

As I was preparing some guidance around the upcoming deprecation (replacement) of the EWS-dependent org relationships and sharing policies in Exchange Online, an oddity surfaced. The goal was to illustrate the greater flexibility Sharing policies offer in terms of control, both on the per-user and per-domain basis, as well as the level of details shared, and argue that the proposed replacement is subpar in this regard. And for that, I needed an example or two, all of which turned out to not work as expected.

A short refresher on Sharing policies

Sharing policies are a configuration object that allows you to exert control over the level of details for user-initiated calendar sharing. In Exchange Online, a Default Sharing Policy object is created for every tenant, allowing for sharing free/busy detail with every external organization, as well as publishing of calendars (to be accessed via a browser). Here’s an example:

Get-SharingPolicy | fl

Domains : {Anonymous:CalendarSharingFreeBusyReviewer, *:CalendarSharingFreeBusySimple}
Enabled : True
Default : True

The Domains part is the important one, listing each individual domain you plan to allow sharing with. In this case, we see that sharing is allowed with all external domains (the * entry), with the simple level, meaning external users will only be able to see whether a given time slot is booked, but no details about the event. We also have the special “Anonymous” entry, used to configure calendar publishing (with full details about events). As with most other policies in Exchange Online/Microsoft 365, things are “wide open” in the default configuration, but you can easily amend it.

By creating additional sharing policies, each with its own distinct level of sharing, organizations can granularly control what level of sharing is possible on a per-domain basis, such as only basic availability to be shared or block sharing altogether. As policies are assigned on a per-user basis, you get yet another level of granularity, for example to restrict calendar publishing across the board, while keeping it enabled for a handful of users, with the appropriate level of detail.

The issue

To my surprise, the sharing policy assigned to the user did nothing to prevent him from sharing his calendar with recipients in an external organization, with the most permissive level. Neither the client-side (OWA) nor server-side validation seemed to trigger, effectively allowing such unsanctioned sharing. Most importantly, the external recipient was indeed able to see the full set of events within the shared calendar, with all their details.

The issue can be easily reproduced, and in fact I did so in a freshly provisioned demo tenant just to make sure I’m not seeing the effect of some other (mis)configuration in the current tenant. Here are the steps to try:

• • Have a sharing policy, the default one in ExO should do fine. Note the set of allowed domains therein and the associated permission levels.

    Domains                : {Anonymous:CalendarSharingFreeBusyReviewer, *:CalendarSharingFreeBusySimple}
    Enabled                : True
    Default                : True

    In the example above, which is the default configuration in Exchange Online, sharing is allowed with all external domains (the * entry), but with the simple level of detail, which only exposes the availability of a given time slot, with no additional details.

  • Have any user with the sharing policy assigned share its calendar to any external recipient with “excessive” permissions. In the above example, share to a recipient in any external domain with the “Reviewer” level (“Can view all details”). For example, in the new demo tenant I shared the calendar with my personal mailbox.

  

  • Note the lack of any error when adding the “excessive” permissions via the UI. The permission entry is stamped successfully, as you can also confirm via PowerShell:

    Identity               : f2ff54b6-0fc2-46e3-9205-ca1442327180:\calendar
    FolderName             : Calendar
    User                   : ExchangePublishedUser.vasil@michev.info
    AccessRights           : {Reviewer}

  • On the external user’s side, “accept” the sharing invitation, open the newly added calendar and wait for a minute for the events to populate. You should now see full event details in the shared calendar. Well, you will see events from the past 30 and next 180 days, with all their details, including the body.

While functionalities such as org relationships or the presence of “external” recipient objects within the directory can cause a potential misbehavior, in all tenants I tested the issue was reproducible by following the steps above. There are of course few assumptions therein, most importantly the level of sharing for the default (*) domain being set to “simple”.

It is also unclear whether the issue is on the client or server side. Or both. What we can see on the client side is request being made to the “aggregator” endpoint with the CreateSharingPermission action for the selected folder and permission level. As the request execution remains a black box and only the Success status is returned, it is unclear whether any sharing policy is being evaluated as part of the action.

On a side note, while end users can leverage the Add-MailboxFolderPermission cmdlet (part of the default Role Assignment Policy), sharing to external user via the cmdlet is only possible when a matching recipient object exists within the tenant. For generic external recipients, the cmdlet will fail with an InvalidExternalUserIdException exception. Therefore, we cannot be certain whether sharing policies are being evaluated as part of the cmdlet execution, either.

Summary

In effect, it seems like Exchange Online currently ignores the Sharing policy assigned to the user and allows calendars to be shared to external recipients with full details, even when the policy prohibits this. In fact, it seems clients (both Outlook and OWA) completely ignore to validate the policy configuration, and so does the backend.

Whether this behavior has something to do with the upcoming switch to Cross-tenant Access Policies is unclear at this point. It might, as the scoping mechanism used with XTAP is different, and the Sharing Policy control will likely get removed, or at least be ignored going forward. Which is exactly what we’re seeing with the issue detailed above. The timing also fits, but I’ve no idea how long this issue has being around, as I rarely touch on external sharing in Exchange Online. And Microsoft is yet to comment on it, so we shall have to wait and see.

So here I am, spreading the word. While this is hardly the biggest issue, making such changes in a functionality that has been around for over a decade will likely impact a lot of customers, whether the changes are intentional or not. It might be worth running a quick report on which calendars are being shared with external users in your organization, then adjusting (or even removing) the associated permission entries.