Mailbox Audit Logging in exchagne 2010/2013

Exchange 2010 SP1 introduced, among other things, mailbox access audit feature that should help system administrators track users’ mailbox activity. While testing Exchange auditing capabilities I quite often bumped into some various issues and would like to present you with a series of articles about my mailbox access audit tests and their results. We can walk together through the steps of setting up a mailbox access auditing for the particular actions and compare the test results with the expected ones.  From my point of view one of the most important user actions an administrator should be able to audit is Delegate mailbox access.

A lot of businesses want to be able to track who accesses mailboxes in the organization, and who takes certain actions such as deleting mailbox items.  This is particularly true where mailboxes are accessed by delegates, for example when a senior manager has several people who access and manage their mailbox, or for shared mailboxes such as those used by sales and support teams.

Exchange Server 2010 (SP1 or later), Exchange Server 2013 and Exchange 2016 have a feature called Mailbox Audit Logging that provides exactly this capability.  However it is not turned on for mailboxes by default, so the Exchange administrator has to enable for those mailboxes which are considered sensitive or any where access needs to be logged and audited.

You can see whether a mailbox has audit logging enabled by running the Get-Mailboxcommand.

The output there shows you that:

  • Mailbox auditing is not enabled for this mailbox
  • The log age limit is 90 days
  • The actions that are logged for admins, delegates, and the owner themselves

Note how the mailbox owner is not logged by default, because their access would generate a lot of audit log entries. Delegates are logged for basic actions, and administrators are logged for additional administrative actions as well.

To enable a mailbox for audit logging use the Set-Mailbox command

1
[PS] C:>SetMailbox “bharat.mishra” AuditEnabled $true

 

As soon as auditing is enabled on a mailbox, Exchange starts to generate audit items based on the mailbox’s audit configuration. You can see the configuration by running the command:

Get-Mailbox -Identity 'CEO Mailbox' | Format-List Audit*

utput from this command. It tells you that auditing is enabled (AuditEnabled property) and Exchange will keep audit items for 90 days (AuditLogAgeLimit property).

Figure 2: Reviewing a Mailbox's Audit Configuration

 

AuditDelegate property’s default audit actions include SendAs. It’s important to note that Exchange distinguishes between situations in which a delegate uses SendAs (send as if the delegate were the user) and SendOnBehalf (include an indication that someone else sent the message). These are two very different ways that a delegate can send a message for another user. Although the SendAs action is one of the default actions for AuditDelegate, the SendOnBehalf action isn’t. So, if you want to audit both actions, you need to add SendOnBehalf to the list of actions. To do so, you can use the Set-Mailbox cmdlet to change the audit actions for the AuditDelegate property, like this:

Set-Mailbox -Identity 'bharat.mishra' -AuditDelegate `
  "Update, SoftDelete, HardDelete, SendAs, SendOnBehalf, `
  MoveToDeletedItems, Copy"


Searching Mailbox Audit Data with PowerShell

Exchange 2010 and Exchange 2013 provide two EMS cmdlets to search mailbox audit data:

  •  Search-MailboxAuditLog performs an immediate synchronous search across one or more mailboxes and returns information on screen. You’d use the Search-MailboxAuditLog cmdlet if you need to confirm that auditing is enabled and operational for a mailbox or if want to track down a particular audit event. You can also create a report from the data that you extract by piping it to an external file.
  •  New-MailboxAuditLogSearch operates in the background. It extracts mailbox audit data, puts that data into an XML file, and attaches the file to an email message that’s delivered to whatever address you choose. You might use this cmdlet to create a report for an external legal investigator. New-MailboxAuditLogSearch will be discussed in detail in the “Getting Auditing Data for Heavily Loaded Servers” section.

To use the Search-MailboxAuditLog cmdlet, you’d use a command like this:

Search-MailboxAuditLog -Identity Billing `
  -LogonTypes Delegate -ShowDetails -StartDate "1/1/2012" `
  -EndDate "1/31/2012" | ft Operation, OperationResult, `
  LogonUserDisplayName, ItemSubject, LastAccessed, -AutoSize

In this instance, you’re searching one mailbox, so you pass its name as a value to the -Identity parameter. If you want to search several mailboxes, you can replace the -Identity parameter with a comma-separated list of mailbox names passed to the -Mailboxes parameter.

There are a couple of interesting things that you can observe from the sample results in Figure 3.

Figure 3: Searching Audit Data
Figure 3: Searching Audit Data

First, an attempt was made to delete an item, but that attempt failed. The item’s subject isn’t captured so you don’t know exactly what happened here. However, this item serves to illustrate that all operations are logged when auditing is enabled, including those that fail.

Second, the bottom item reports that a message was sent from the mailbox using the SendAs permission. There’s no problem with this. However, you can also see that the item was subsequently updated 17 days later. Those who have suspicious minds might wonder why this happened and contemplate whether it was an attempt to cover something up.

To investigate further, you could do another search to focus in on the suspect audit item. This time, you’d want to search for specific operations within a narrow date range by using a variant of the original EMS command:

Search-MailboxAuditLog -Identity Billing `
  -LogonTypes Delegate -ShowDetails `
  -StartDate "1/28/2012 11:59" -EndDate "1/28/2012 12:15" |
  ? {$_.Operation -eq "Update"} | Format-Table

An edited version of the output is shown in Figure 4.

Figure 4: Investigating Why an Item Was Updated 17 Days After It Was Sent
Figure 4: Investigating Why an Item Was Updated 17 Days After It Was Sent

You can now see that the item was updated in the Sent Items folder and that the TextBody property (i.e., the email message’s body) was updated. You can also see that Outlook (or a program that calls Outlook’s libraries, such as MFCMAPI) was used, along with the IP address of the computer that was used to make the update. This information should be sufficient to have a conversation with the user to clear up exactly what happened and why.

Administrative operations (e.g., deletion of items from a mailbox with the Search-Mailbox cmdlet) can be recognized because LogonType will be set to Admin in the audit items. For example, here’s a command that searches the audit log entries for the CEO’s mailbox to locate hard delete operations (i.e., those that permanently delete items):

Search-MailboxAuditLog -Identity 'bharat.mishra' `
-ShowDetails | ? {$_.Operation -eq "HardDelete"} |
  Format-Table Operation, LastAccessed, LogonType, `
  LogonUserDisplayName, FolderPathName, `
  ItemSubject - AutoSize

As you can see in Figure 5, the results show that an administrator permanently removed one item from the Budgets folder.

Figure 5: Finding Hard Delete Operations
Figure 5: Finding Hard Delete Operations

Unfortunately, through what can only be an oversight in the Exchange code, you’re left hanging as to what that item was, because no information is provided about the subject to help you identify it. This omission wasn’t addressed in Exchange 2013, but let’s hope it’ll be addressed in a future update.

One thing to be aware of is that audit items do not show up in searches straightaway. For some reason, possibly because of caching to ensure that server performance is not impacted or a bug in the search cmdlet, it takes some time before audit items are available to searches. I suspect a bug because the Get-MailboxFolderStatistics cmdlet reports that audit items exist once a client has had a chance to synchronize operations with the server. In any case, the exact delay varies. Sometimes items appear in a few minutes, sometimes it seems to take an hour or so. For this reason, don’t depend on audit searches to report recent operations. Everything eventually settles down and searches for audit items older than six hours appear to be reliable.

 

What is it? Search-MailboxAuditLog cmdlet stops producing any output should I add -ShowDetails switch!

The output expected should contain the following fields: Operation, OperationResult, LogonType, …, ClientIPAddress and many others as described here:http://technet.microsoft.com/en-us/library/ff459237.aspx

 I know for sure that at least in some cases Search-MailboxAuditLog cmdlet with the swith -ShowDetails works correctly

>Search-MailboxAuditLog -Identity “bharat.mishra@exchangetechexperts.com” -showdetails |ft

let’s try to use the other tool for reading mailbox access audit log – the Exchange Control Panel.

Log in to ECP under account that is a member of Exchange Organization Management group or Records Management group (for instance, Administrator account) and click “Run a non-owner mailbox access report”

 

Last but not the least 🙂

Please add your administrator in this role group by the following steps to have this command run successfully,

1. Open EAC, navigate to Permissions > admin roles.

2. Double-click Records Management.

3. Under Members, click “+” to add administrator in the list.

4. Click Save.

Happy Learning :)
will see you in my next topic..



Leave a Reply

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