Use Office 365 Audit Data to Highlight Unused SendAs Permissions

Understanding Events in Audit Log the First Step

Generating a report about some aspect of Office 365 is all very well, but it doesn’t lead to much unless there’s some action that can be easily taken due to the reported data. Take the report on Exchange Online SendAs and other permissions. It’s nice to know which accounts hold permissions over different mailboxes, but what will you do with that information?

In a small tenant, it might be easy to review the data and identify problems, like someone keeping Send As permission for a shared mailbox long past the time when their job mandates this access. In a medium to large tenant, you can slice and dice the report data to highlight issues, but it’s a lot harder to pinpoint definite problems.

Using Technology to Highlight Items

Microsoft is adding a lot of machine learning and artificial intelligence to Office 365 at present. Taking that as a hint, we can use technology to help filter the report data and identify the accounts to focus on. And best of all, this is easy to do in PowerShell.

The output from the script is a CSV file listing all the Send As, Full Access, and Send On Behalf Of permissions assigned to accounts. The first step is to read in the data from the CSV file, filtering items so that only SendAs records are loaded into an array.

Grabbing Data from the Office 365 Audit Log

The next step is to find a way to check each SendAs assignment against usage. The easiest way I know is to search the Office 365 audit log for SendAs events. Data is kept for 90 days for Office 365 E3 accounts (but only if their mailboxes are enabled). Data is kept for 365 days if an account has an Office 365 E5 license. Either way, I think 90 days is enough on the basis that if someone hasn’t used their right to impersonate another user or shared mailbox to send email in the last three months, maybe they don’t need that permission and it can be removed.

We can collect the SendAs events for the last 90 days by running the Search-UnifiedAuditLog cmdlet, unpacking the AuditData content in each audit event, and storing the data. Fortunately, we already have a script to do the job, which stores its output in another CSV file.

Comparing Audit Data with Permissions

A few lines of code later, we have the SendAs audit events loaded and we’re ready to start checking. The basic idea is to go through the assignments and check each against the audit data to see if the permission has been used. If it has, we store some usage details (last time and number of uses), and if it hasn’t, we note that fact too.

Hey Presto! After running through the permissions, we have a filtered list of accounts who haven’t used their assigned Send As permissions in the last three months and another set who have. You can review the assignments by piping the analyzed data to Out-GridView (Figure 1) or use the output CSV file for further processing.

You can pick up a copy of the script to analyze and filter SendAs records from GitHub. Remember that you need the other scripts to fetch SendAs records from the Office 365 audit log and report mailbox permissions to provide the two inputs.

Humans Decide Next Step

At this point, the script finishes and it’s up to the tenant administrators to decide what to do about the defunct permissions. Perhaps you want to send a polite email to users to tell them that you plan to remove the permission in a week’s time, or maybe you just go ahead and remove the permission on the basis that if anyone misses it, they’ll scream.

This is a great example of how to put together PowerShell scripts as building blocks for a solution. The code isn’t all that complex. It’s simply a matter of knowing where to find the data and how to use it. Isn’t that always the case?