In this article we will explore the mailbox audit logging functionality of Exchange 2010, how to enable it, what it can audit and how to access and read its logs.
In every organization, there are always mailboxes with sensitive information. These might be the mailboxes of the CEO, directors, users from the HR or Payroll departments, or simply mailboxes for which you have to perform discovery actions to demonstrate compliance with regulatory or legal requirements. Although normally administrators are not concerned with the content of user’s mailboxes, there might be someone less honest that attempts to access someone’s mailbox in order to obtain information of value for their own benefit.
Previous versions of Microsoft Exchange did not provide a full range of compliance capabilities. Managed Folders or Journaling simply were not enough to perform basic audits or to be fully compliant with legislation such as the Sarbanes-Oxley Act. Exchange 2010 introduces some welcomed new features, including Retention and Litigation Hold, Single Item Recovery or Archiving.
In this article, we will explore yet another new feature introduced in SP1 known as Auditing Mailbox Access, which allows us to record operations on a mailbox such as the deletion or copy of e-mails.
Until Exchange 2007 SP2 was released, it was difficult, if not impossible, to provide information regarding who logged on to a certain mailbox or who deleted an e-mail from the shared Service Desk mailbox, for example. Exchange 2007 SP2 introduced a feature called Mailbox Access Auditing. Although with similar name, this is a complete different way of auditing actions on a mailbox as can be seen in the article Exchange 2007 Mailbox Access Auditing by Neil Hobson.
With Exchange 2010 SP1 this task has become much easier and more reliable. Administrators can implement Mailbox Auditing and run audit reports to obtain details regarding actions taken on a mailbox. After enabling audit for one or more mailboxes and configuring the level of detail that we want to capture, audit entries are captured in the Audit subfolder of the Recoverable Items folder (known as Dumpster) and can be interrogated using the Exchange Management Shell [EMS] or the Exchange Control Panel [ECP] as I will demonstrate below.
It is possible to configure 3 levels of auditing:
Administrative, which audits mailbox moves, imports/exports to and from PSTs, mailbox discovery searches and actions performed using the MFCMapi tool;
Owner, where actions taken by the owner of the mailbox are audited;
Delegates that have the SendAs, SendOnBehalf or FullAccess permission to someone else’s mailbox.
The following table shows all the actions that can be audited:
An e-mail is copied to another folder or to the Personal Archive
An item (excluding folders) is created in the mailbox (a message is sent, for example)
A mailbox folder is accessed
An e-mail is permanently deleted
An e-mail is opened or viewed in the preview pane
An e-mail is moved to another folder
An e-mail is deleted
An e-mail is sent using SendAs permissions
An e-mail is sent using SendOnBehalf permissions
An e-mail is deleted from the Deleted Items and moved to the Dumpster
The properties of an item are updated
These actions are audited by default;
FolderBind actions performed by delegates are consolidated, meaning only one log entry is generated per folder access within three hours;
As normal users use their mailboxes in a continuous basis, auditing the Owner might not make much sense in most cases as it would capture a lot of information and generate a high volume of audit entries.
You might be wondering why we have all these options for Admin if only mailbox moves, exports/imports or discovery searches are logged. If you think about it, a mailbox search is nothing more than a FolderBind, followed by a MessageBind and finally a Copy or Move.
Enabling Mailbox Audit Logging
Configuring auditing for mailboxes can only be done using the Set-Mailbox cmdlet. By default no mailbox is enabled for auditing, so let’s enable one and check the default configuration which should match the previous table:
Figure 1: Enabling mailbox audit
The AuditLogAgeLimit specifies for how long we want to keep these entries in the mailbox. By default, this is set to 90 days, but can be reduced or increased up to approximately 68 years (or 24855.03:14:07 to be more precise). If set to zero (00:00:00), all log entries will be deleted immediately.
If the default actions are not ideal, we can tweak them to meet our requirements:
Figure 2: Tweaking mailbox audit settings
How to Access Audit Data?
To demonstrate audit logging, I first assigned the account Nuno FullAccess and SendAs permissions to the CEO’s mailbox. Then, I logged into the CEO’s mailbox, read and deleted a couple of e-mails.
As mentioned previously, audit information is written to the Audit subfolder of the Dumpster, which is hidden to any client, meaning normal users cannot access it. To check if this folder has any logs, we can run the following cmdlet which will show 31 logging entries already:
Figure 3: Checking the Audit folder
There are three ways available for administrators to search these logs providing they have Organization Management and Records Management permissions:
Synchronously, by using theSearch-MailboxAuditLog cmdlet which searches one or more mailboxes and displays the results in the EMS window;
Asynchronously, by using New-MailboxAuditLogSearchto search one or more mailboxes and send the results by e-mail to the specified recipients in a XML document;
By using the Auditing tab in the ECP to run auditing reports or export entries from the mailbox audit log.
Let’s start with the Search-MailboxAuditLog cmdlet and see if we captured Nuno’s actions:
Figure 4: Searching the audit log entries
Note that because MessageBind is not audited for Delegates, the fact that I read a few e-mails is not audited.
We can see that I deleted an e-mail from the Inbox. However, ItemSubject is blank which means we do not know what e-mail was actually deleted (this also happens for SoftDelete actions)… Hopefully this will change in the future.
On the other hand, operations like MessageBind, SendsAs or Create log the ItemSubject as you can see from the screenshot below. It also tells us that the client used was Outlook Web App [OWA]. In this case I used the –StartDate parameter and refined the search to only show Operations of the type SendAs:
Figure 5: Filtering the results of the search
Although you can use the –Mailboxes parameter to specify more than one mailbox to search, you cannot use –ShowDetails together with –Mailboxes which makes the cmdlet not return any useful information. For this reason, you will have to use one of the following methods if you want to search multiple mailboxes at a time.
To test the second search method, we’ll use the New-MailboxAuditLogSearch cmdlet to search a couple of mailboxes for any Admin operations and send the results by e-mail to the CEO. Remember that this cmdlet performs an asynchronous search, meaning after you execute it you can close the EMS as the search is performed behind the scenes like the New-MoveRequest cmdlet. To achieve this, we run the following cmdlet:
New-MailboxAuditLogSearch –StartDate “10/08/2011” –EndDate “10/09/2011” –Mailboxes CEO, Nuno –LogonTypes Admin –StatusMailRecipients firstname.lastname@example.org -ShowDetails
If no mailboxes are specified, Exchange will perform the search against all mailboxes enabled for auditing.
Once the search is finished, an event 4003 is saved in the Application Event Log and an e-mail is sent to the e-mail address or addresses specified in the –StatusMailRecipients parameter, which can be distribution groups or external mail-enabled contacts as well. This e-mail contains the search criteria, such as who requested it, the period searched and which mailboxes were searched. Opening the attached XML file will show all the results.
Figure 6: E-mail received by the CEO when the search is finished
Figure 7: The XML file with the audit results
As XML files are hard to interpret, you might want to parse it through a graphic formatter or use PowerShell to make it easier to read:
Figure 8: Parsing the XML file using PowerShell
The final method is basically the first two but performed from the ECP. This provides a much easier and user friendly way of performing both types of searches. To use it, login to the ECP, go to Manage My Organization and then click in Roles & Auditing. There you will see, among other options, the Run a non-owner mailbox access report… (based on the Search-MailboxAuditLog cmdlet) and the Export mailbox audit logs… (based on the New-MailboxAuditLogSearch cmdlet) options:
Figure 9: The Auditing tab in the ECP
Figure 10: Synchronous single mailbox search
Figure 11: Asynchronous multiple mailbox search
In figure 10 you will notice some differences from when we ran the same search through the EMS: it does not return as much information but it shows the subject of the deleted e-mail! On the other hand, the search in figure 11 produces and e-mails the exact same report as before (figures 6 to 8).
Bypass an Account From Auditing
In some situations, you might have special accounts such as the Blackberry Enterprise Server [BES] account that you want to exclude from auditing. After all, if you enable Delegate auditing and have a BES server, this account alone will fill the audit event folder with events you are most probably not interested in. For these cases, you can configure them to bypass mailbox audit logging, so that actions performed by these accounts for any mailbox are not logged. However, you cannot specify the BES account, for example, to bypass audit logging to a specific mailbox only.
Once again, you have to use the EMS to configure bypassing with the following cmdlet:
Set-MailboxAuditBypassAssociation svc_BES -AuditBypassEnabled $True
Auditing users that have the capability of assigning FullAccess permissions, setting the AuditBypassEnabled option or enabling/disabling audit is harder. Nothing prevents a user with this level of permissions from assigning himself FullAccess to the CEO’s mailbox, bypass his account from auditing and do what he wants on the mailbox. For these users, the only option is to use Auditing Mailbox Access together with Administrator Audit Logging so that, for example, if an Administrator uses the Set-MailboxAuditBypassAssociation cmdlet it is automatically logged.
The new auditing capabilities of Exchange 2010 are very much welcome. Now it is easier to audit actions performed in a mailbox but there is still some work left to do. Differences between running searches through the EMS or the ECP may cause confusion to some administrators and the fact that the subject of an e-mail that was deleted is not visible if using the EMS are major flaws in my opinion. However, it is still a big improvement from previous versions and I am hopping Microsoft will address these issues in the next Service Pack.