The Big Flaw in Exchange Online Auditing

chrome 2017 10 05 09 06 39

Ingesting Office 365 Audit Events

When I wrote about the Office 365 Audit Log last month, I noted that the log holds entries from many different workloads, including SharePoint Online, Exchange Online, Teams, and so on. The ingestion into the log puts audit data extracted from Office 365 workloads through a normalization process (Figure 1) to make sure that audit events have common properties, such as the date and time.

Office 365 Audit Log Flow
Figure 1: The Office 365 Audit Log pipeline (image credit: Microsoft)

The detailed information held in the events and the quantity of the events depends on the workload. Some workloads generate many events daily, others are more taciturn. Some need to do better – the Teams product group acknowledged that they have work to do here during Ignite. But overall the system works, and the unified audit log delivers a lot of benefit.

Exchange Auditing

Exchange Online generates audit events from two sources. Administrative events are those generated by administrators and background processes when they perform actions like creating new mailboxes or updating the Exchange configuration, including events generated by the datacenter administrators. You do not have to do anything to force Exchange to generate administrative audit events. It happens automatically.

Mailbox Auditing

Mailboxes are the other source of Exchange audit events. Exchange groups mailbox audit events into three categories – owner, delegate, and administrative. You can configure mailbox auditing to capture a range of events, such as hard-deleting messages.

In most cases, audit configurations omit owner events because too many audit events result. But delegate actions are a different matter, if only because they help answer the question “who did what in a mailbox.” Most of the time, you do not care what an owner does in a mailbox because it is their mailbox. But do you do care about what delegates do, including the actions taken in shared mailboxes, because once shared access is available to a resource, the potential for denial exists when things go wrong – like someone sending a poorly-worded message to a customer using the SendAs permission.

Exchange stores mailbox audit events in the Audits folder within Recoverable Items. Figure 2 shows how to examine the audit configuration for a mailbox and find how many audit events exist. In this case, I have a ridiculous number in my mailbox because I configured the retention limit to its maximum (24,855 days), just to see what happens. The command to return details of the retained audit events is:

[PS] C:\> Get-MailboxFolderStatistics -Id Mailbox -FolderScope RecoverableItems | ? {$_.Name -eq "Audits" | Format-Table FolderSize, ItemsInFolder
PowerShell Office 365 Mailbox
Figure 2: Audit configuration and events for a mailbox (image credit: Tony Redmond)

The Problem with Mailbox Auditing

The big problem with mailbox auditing – for both Exchange on-premises and Exchange Online – is that you must enable it for mailboxes to start recording audit events. If you do not enable auditing for a mailbox, Exchange assumes that you don’t care about what’s going on and captures nothing. When the time comes to search the Office 365 audit log, you get a big fat blank.

I do not understand why Microsoft does not enable mailbox auditing by default for Exchange Online. Given the importance of auditing, there is no sense in not having mailbox audit events. Other workloads, like SharePoint Online, take the sensible attitude that they should audit all user actions. Exchange is an outlier on this point.

Three Fixes for the Problem

Three solutions could fix the problem. First, Microsoft could enable Exchange Online mailboxes for auditing when they are created, including when mailboxes move from on-premises servers to Exchange Online.

While we wait for Microsoft to recognize and fix the issue, you can make sure that you enable all your mailboxes for auditing. It is easy to do this with PowerShell. For example, this command finds all user and shared mailboxes that do not have auditing enabled, enables auditing, and updates the audit configuration to capture certain delegate activity.

[PS] C:\> Get-Mailbox -Filter {AuditEnabled -eq $False} -RecipientTypeDetails UserMailbox, SharedMailbox | Set-Mailbox -AuditEnabled $True –AuditDelegate Create, FolderBind, SendAs, SendOnBehalf, SoftDelete, HardDelete, Update, Move, MoveToDeletedItems

As new mailboxes come online, you must remember to enable them for auditing, unless you have a reason not to capture mailbox audit events.

The last solution is for Microsoft to update the Set-MailboxPlan cmdlet so that tenants can change mailbox plans to force auditing when new mailboxes are created. The cmdlet already supports an AuditEnabled parameter along with other parameters to control audit configurations. The issue here is that these parameters are marked “This parameter is reserved for internal Microsoft use.”

Don’t Cry If Auditing Isn’t Enabled

Once an event occurs inside Exchange Online, auditing captures it or not. You cannot recreate an audit event afterwards. This is cold comfort in a compliance scenario when missing mailbox audit events become a real problem and you realize that you forgot to enable auditing for the target mailbox. If you think that Microsoft should do something to fix the problem, vote on UserVoice.

Follow Tony on Twitter @12Knocksinna.

Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.