Office 365 Permissions inventory: Send As

Considering how popular my basic article on getting user’s permissions across all Office 365 recipients has been, I’ve decided to expand it to series of articles covering the different types of permissions. This time around, the premise is that you are not looking into what permissions specific user has, but instead want to get the complete inventory of given permissions type. The first article will deal with the easiest type of permissions, namely Send As.

What makes getting Send As permissions easy is the fact that you only need to call the Get-RecipientPermission cmdlet once. And here’s the best part – you don’t actually have to loop over all recipients or pipe them to the cmdlet! Simply run the cmdlet without specifying the Identity parameter and all Send As entries configured across the service will be returned. Including some “hidden” ones. Take a look:


Recipient permissions PowerShell example

The list will probably go on as other system mailboxes are included by default. The point however is that you don’t have to get the list of recipients beforehand and pipe them or do cycles – it’s both faster and simpler to use the Get-RecipientPermission cmdlet directly! Now, we can modify it a bit to make sure only relevant entries are included. Here’s an example:

Get-RecipientPermission -ResultSize Unlimited | ? {$_.Trustee -ne "NT AUTHORITY\SELF" -and $_.Trustee -ne "NULL SID"}

Send As permissions PowerShell example

Things look much simpler now and as you can see multiple entries across different recipient types were returned. To get this exported to a CSV file, use:

Get-RecipientPermission -ResultSize Unlimited | ? {$_.Trustee -ne "NT AUTHORITY\SELF" -and $_.Trustee -ne "NULL SID"} | Export-Csv -nti SendAsReport.csv

There you have it, fast and easy. If only other types of permissions could be queried in such manner!

Still, the people that would be looking at a permission inventory report such as the one generated above would often prefer to have some more details included in the report. For example the exact recipient type and the email address of the recipient (as the Identity/display name is often not enough to identify the object). So, it might be a good idea to try and modify the output. Unfortunately, as the cmdlet returns string output instead of the actual object, this will mean executing additional cmdlets and thus increasing the complexity and time to run. Regardless, here’s another example which includes the Recipient type and email address:

$list = @("UserMailbox", "SharedMailbox", "RoomMailbox", "EquipmentMailbox", "MailContact", "MailUser", "MailUniversalDistributionGroup", "MailUniversalSecurityGroup", "DynamicDistributionGroup", "RoomList", "PublicFolder", "TeamMailbox", "GroupMailbox", "GuestMailUser", "DiscoveryMailbox")

Get-RecipientPermission -ResultSize Unlimited | ? {$_.Trustee -ne "NT AUTHORITY\SELF" -and $_.Trustee -ne "NULL SID"} | Select @{n="DisplayName"; e={$global:temp = Get-Recipient $_.Identity -RecipientTypeDetails $list ;$temp.DisplayName}}, @{n="EmailAddress";e={$temp.PrimarySmtpAddress}}, @{n="RecipientType";e={$temp.RecipientTypeDetails}}, Trustee, AccessRights, AccessControlType, IsInherited, InheritanceType | Export-Csv -nti SendAsReport.csv

The $list variable is used in order to enumerate all the available recipient types. The reason we need to do so is because the Get-Recipient cmdlet does not return Office 365 group mailboxes by default (or Team mailboxes for that matter), and you have to explicitly specify the type if you want to include the additional details for objects of that type. To reduce the time the last report takes in large organizations, the temporary variable $temp is used for all three newly added properties. Otherwise, one would have to run the Get-Recipient cmdlet three times, thus increasing the overall run time.

The more additional properties you want included in the report, the more cmdlets you will have to run. And the more complex the script becomes, so at a certain point it makes no sense of doing this with one- or two-liners. Instead, one should use a full script solution with proper reuse mechanisms, error handling and so on. I guess what I’m trying to say is that adding additional properties is certainly possible, but it has its cost. Personally, I prefer to stick with the simple cmdlet we used in the first few examples.

Before closing off the article, it’s worth giving some examples of using the Trustee parameter. The idea is that you can get a list of all recipients for which a particular user has Send As permissions granted, without having to loop over them. So again, faster and simpler than the usual methods. Here’s how to do it:

Get-RecipientPermission -Trustee vasil

and the same format can be used against other object types:

Get-RecipientPermission -Trustee secgrp

1 thought on “Office 365 Permissions inventory: Send As

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.