Office 365 permissions inventory: Send on behalf of

Continuing the series of Permission inventory reports in Office 365, in this article we will take a look at Send on behalf of permissions. This permission entry is stored as part of the GrantSendOnBehalfTo attribute for recipient objects, thus in order 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 exists and a report covering all recipients can take hours to complete.

Luckily, we can use a workaround that gets the job done quite faster. Instead of fetching all recipients and checking for Send on behalf of permissions for each 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 quite smaller compared to the overall object count. Of course, one would probably want to include just the needed information in such report, or in other words to change the output from above. The cmdlet should be changed to something like:

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

The output can still be improved, for example by expanding the array 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 via a simple one-liner!

There are however other issues with the above method. Most obvious, it covers only Mailbox objects. A 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 us build a more robust solution, but can actually improve usability and even achieve some automation in terms of scheduling the report. It will also lay the ground work for covering our next challenge, Full Access permissions.

Without further ado, here’s a sample script that you can use to gather a complete inventory of the Send on behalf of permissions in your organization.

https://github.com/michevnew/PowerShell/blob/master/Mailbox_Permissions_inventory_SOB.ps1

Few important notes about the script should be made. First of all, the script does not handle connectivity to Exchange Online. The reason 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. Yet another reason to not include the connectivity part 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 the connectivity part also allows us to “dot source” the script and expose the Get-SOBPermissionInventory cmdlet to your existing sessions. Of course, one can also borrow the cmdlet code and paste it in 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 prefer it to be exported 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 parameter, 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. In reality, you will probably be interested in User and Shared mailboxes only, so you can specify the corresponding switches to include just those types. For example:

.\Mailbox_Permissions_inventory_SOB.ps1 -IncludeUserMailboxes -IncludeSharedMailboxes

Hopefully, this small script will help satisfy all the needs around reporting Send on behalf of permissions. As always, any feedback is appreciated. Now on to the next post, where we will handle the Full Access permissions scenario!

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

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.