Back to blog

Office 365 Permissions Inventory: Send on behalf of

Mar 31, 2017 by Vasil Michev

Continuing on from our series on Permission inventory reports in Office 365, this next article will take a look at Send on behalf of permissions.

This permission entry is stored as part of the GrantSendOnBehalfTo attribute for recipient objects, which means that to get the full inventory we need to query all recipients. This can be a problem in large organizations where thousands and thousands of objects exist and a report covering all recipients can take hours to complete.

Luckily, we can use a workaround that gets the job done faster. Instead of fetching all recipients, and checking for Send on behalf of permissions individually, we can invoke the server-side filtering capabilities Exchange offers. Here’s an example on how to do that:

Get-Mailbox -Filter {GrantSendOnBehalfTo -ne $null}

Chances are that even in large multinational companies, the number of objects returned by the above cmdlet will be smaller than the overall object count. Depending on what information you need, you would probably want to change the output. The cmdlet should be changed to something like:

Get-Mailbox -Filter {GrantSendOnBehalfTo -ne $null} | select GrantSendOnBehalfTo,PrimarySmtpAddress,RecipientTypeDetails

The output can still be further improved, for example by expanding your selection of holding multiple recipients in the first line, or adding other attributes as needed. Once you are satisfied with the output, you can append the “export to CSV” part, and get the full inventory report using a simple one-liner!

There are some issues with the above method. The most obvious is that it only covers Mailbox objects. Another known limitation for the Get-Mailbox cmdlet is that Team mailboxes are not returned by default. Office 365 Groups, although still designated as GroupMailbox objects, require the use of a different cmdlet. Other recipient types can also have Send on behalf of permissions configured, for example Distribution Groups.

In other words, to get a complete inventory, it’s a good idea to use a full script instead of one-liners. This will not only help you to build a more robust solution, but can actually improve usability and achieve some automation in terms of scheduling the report. It will also lay the ground work for covering our next challenge, Full Access permissions.

Here’s a sample script that you can use to gather a complete inventory of the Send on behalf of permissions in your organization.

Send on behalf of script

There are a few important notes about this script. First of all, it does not handle connectivity to Exchange Online. One of the reasons for this is that there are multiple ways to connect to the service now, depending on the type of tenant you use and its location. Moreover, with ExO Remote PowerShell finally supporting Modern authentication, you might already be using accounts protected with MFA, in which case a different connection method is used. Another reason to exclude this connectivity is that people usually prefer to handle that in a separate script, which can fetch credentials stored securely, instead of having to enter them manually (or god forbid hardcode them in the script). Connectivity is still checked before executing the cmdlets and if no existing session is detected, the script will halt.

Not including this connectivity also allows us to “dot source” the script and expose the Get-SOBPermissionInventory cmdlet to your existing sessions. Of course, you could also copy the cmdlet code and paste it into another script if necessary. The script also incorporates the splatting concept to make sure the cmdlet is executed, and the actual job is performed without the need for user interaction. The default output is returned to the host console and also stored in the $varPermissions variable, in case you want to further modify or export it. If you would prefer to export to CSV by default, simply remove the comment mark from the last line.

The script accepts switch parameters, designating the different recipient types. None of the parameters are mandatory and if you run the script without any parameters, all recipient types supporting Send on behalf of permissions will be returned. This includes: User, Shared, Room, Equipment, Discovery, Team mailboxes, as well as Distribution, Mail-enabled Security and Office 365 groups. Chances are you’re only interested in User and Shared mailboxes, so you can specify the corresponding switches to include those two types. For example:

.\Mailbox_Permissions_inventory_SOB.ps1 -IncludeUserMailboxes -IncludeSharedMailboxes

Hopefully, this small script will help you to successfully report on Send on behalf of permissions. As always, any feedback is appreciated. Keep an eye out for our next post, where we will be handling Full Access permissions!