Managing Compliance in Microsoft Exchange Server 2010

Auditing mailbox access

Users gain access to mailboxes in different ways:

• Users log on and use their mailboxes as normal.

• An administrator can delegate full access to a mailbox to another user. See Chapter 6 for more information on this topic.

• Administrators can grant themselves access to a user’s mailbox and then log on to it.

Normally administrators do not concern themselves about what happens inside user mailboxes. However, there are mailboxes that contain sensitive information that might need to be protected against attempts to conceal or remove items that are required by the company, typically to justify actions that the company or its employees took in a particular situation such as discussions with other companies relating to a merger, sale, or acquisition. Internally, sensitive information is often captured in discovery search mailboxes that must be monitored to detect any attempt to interfere with the data.

Mailbox auditing is a feature introduced in Exchange 2010 SP1 that backs up best practice by allowing administrators to configure mailboxes so that details of specified actions are captured by Exchange. Audit entries are captured in the Audit subfolder of the Recoverable Items folder (the dumpster) and can be interrogated with the Search-MailboxAuditLog cmdlet. Mailbox actions are divided into three categories:

• The mailbox owner It is not normal to audit user actions, as they typically have full control over their mailbox contents. In addition, because mailbox owners use their mailboxes on a consistent and ongoing basis, the volume of audit entries is highest when auditing is enabled for the mailbox owner. For these reasons, when you compare the mailbox audit configuration for owners against the other categories, you’ll see that the list of audit actions for owners is blank.

• Delegates Other users who have been assigned the SendAs, SendOnBehalf, or FullAccess permission can access some or all of a mailbox and take actions to affect its contents.

• Administrative operations These are operations such as mailbox moves, mailbox imports from PST, and mailbox discovery searches that are performed by administrators and affect mailbox contents in some way, if only to open folders.

Table 15-9 lists the various actions that Exchange can audit for a mailbox. Those marked with an asterisk (*) are part of the default set of actions that are marked for auditing when you enable auditing for a mailbox. For example, if you enable auditing for a mailbox, then Exchange will record details of all instances when a delegate sends a message using the SendAs permission. On the other hand, instances when delegates access the mailbox and send a message using SendOnBehalf permission are not captured unless you specifically mark this action for auditing. The decision to include one action over another in the default set of logged actions is probably explained by the fact that a message sent using the SendAs permission represents a higher degree of impersonation than one sent using the SendOnBehalf permission. We will discuss how to configure actions for auditing in a little while.

Table 15-9. Actions that can be audited for a mailbox

Enabling mailboxes for auditing

The first step in the process is to enable the mailboxes that you want to audit by running the Set-Mailbox cmdlet. You cannot configure mailbox auditing with EMC or ECP. In this example, we enable auditing for the default discovery search mailbox.

Set-Mailbox -Identity 'Discovery Search Mailbox' -AuditEnabled $True

We can then check that the audit setting is in place with the Get-Mailbox cmdlet:

Get-Mailbox -Identity 'Discovery Search Mailbox' | Format-List Name, Aud*

Name             : DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}
AuditEnabled     : True
AuditLogAgeLimit : 90.00:00:00
AuditAdmin       : {Update, Move, MoveToDeletedItems, SoftDelete, HardDelete, FolderBind,
SendAs, SendOnBehalf}
AuditDelegate    : {Update, SoftDelete, HardDelete, SendAs}
AuditOwner       : {MoveToDeletedItems, SoftDelete, HardDelete}

You can see that the act of enabling auditing for the mailbox has also assigned the default set of actions to be audited for the different categories of users who log onto the mailbox. You can also see that a property called AuditLogAgeLimit is present. This controls how long Exchange retains audit entries in the mailbox and the default value is 90 days. Once audit entries expire, they are removed from the mailbox by the MFA the next time it processes the mailbox.

You can set the value of AuditLogAgeLimit to anything up to 24,855 days. This amounts to just over 68 years, which should be sufficient for even the most retentive administrators. Oddly, for whatever reason, the actual coded maximum is 24,855 days, 3 hours, 14 minutes, and 7 seconds, which produces an audit age limit like this:

AuditLogAgeLimit : 24855.03:14:07

You can clear out all existing audit entries by setting the AuditLogAgeLimit property to 00:00:00. If you do this, Exchange will prompt you to confirm that all of the entries should be deleted and will proceed if you confirm that this is what you want to do.

You can decide to include or exclude audit actions for administrators, delegates, or owners by writing out the required actions into the AuditAdmin, AuditDelegate, and AuditOwner properties. For example, the owner of the default discovery search mailbox folder will never log onto it, so we can set the audit settings for the owner to “null”. On the other hand, we might want to tweak the settings applied when administrators access the mailbox. Here’s how we can make the change:

Set-Mailbox -Identity 'Discovery Search Mailbox' -AuditOwner $Null -AuditAdminUpdate,
Move, MoveToDeletedItems, SoftDelete, HardDelete,SendAs, SendOnBehalf -AuditEnabled
$True

To reverse the process and turn off auditing for a mailbox, we set the AuditEnabled flag to $False as follows:

Set-Mailbox -Identity 'Discovery Search Mailbox' -AuditEnabled $False

Accessing mailbox audit data

Mailbox audit information is written into the Audit subfolder of the Recoverable Items folder. However, this folder is invisible to any client so you cannot simply log onto the mailbox and browse through the audit entries. Instead, you have to submit a search with EMS and have Exchange retrieve and display the found entries to you. Searches are performed in two ways:

• The Search-MailboxAuditLog cmdlet performs a synchronous search for one or more mailboxes and returns the results on screen.

• The New-MailboxAuditLogSearch cmdlet can search across one or more mailboxes asynchronously in the background and return the results via email.

First, let’s perform a simple search for audit entries for a single mailbox. In this example, we are looking for entries for a particular day, so we pass a start and end date. We then select a number of fields to be output for each entry that is found. Specifying the –ShowDetails parameter instructs Exchange to output details for each audit entry that it locates and passing “Delegate” to the –LogonType parameter restricts output to entries performed by a user who has delegate access to the mailbox. If you search many mailboxes for entries from an extended period, it is more than likely that Exchange might return thousands of entries. In this situation, you can use the –ResultSize parameter to specify how many entries you want to be returned. By default Exchange will output 1,000 entries.

Search-MailboxAuditLog -Identity 'Ruth, Andy' -ShowDetails -StartDate '5/12/2010
00:01'
-EndDate '5/18/2010 23:59' -LogonType Delegate -ResultSize 100 |
Format-Table Operation,
OperationResult, LogonUserDisplayName, ItemSubject, LastAcccessed

Operation      OperationResult  LogonUserDisplayName  ItemSubject          LastAccessed
-----------    ---------------  -------------------   ----------           -------------
SendOnBehalf   Succeeded        Executive Assistant   Travel Requests      11/05/2010 15:52:31
SendAs         Succeeded        Andrews, Lisa         Note from Peter      11/05/2010 15:54:41
SoftDelete     Succeeded        Smith, John                                11/05/2010 15:58:46
SendOnBehalf   Succeeded        Executive Assistant   Business directives  11/05/2010 16:05:09

This output is what you’d expect from a mailbox that has granted access to different users to perform actions on their behalf, which we see in the SendOnBehalf and SendAs entries.

Full access is obviously available to user John Smith because this user has been able to delete an item in the mailbox.

If you change the value passed to the –LogonType parameter to “Admin” you will see any operations performed against the mailbox as a result of administrative activity. For example, if a mailbox search is performed, you will probably see entries like this:

FolderBind       Succeeded      Administrator             11/05/2010 18:24:13

Of course, if you find something of interest, there is a lot more detail in an audit entry that can reveal additional information. For example, entries for a mailbox move will show detail like that shown here, whereas the ClientInfoString property for a mailbox search will contain “Client=Management; Action=E-Discovery (mailbox search)”, so it’s relatively easy to determine what administrative process accessed the mailbox.

FolderPathName           : \MailboxReplicationServiceSyncStates
ClientInfoString         : Client=MSExchangeRPC
ClientIPAddress          : 2002:c0a5:4134::c0a5:4134
ClientMachineName        : EXSERVER2
ClientProcessName        : MSExchangeMailboxReplication.exe
ClientVersion            : 14.1.160.2
InternalLogonType        : DelegatedAdmin

The New-MailboxAuditLogSearch cmdlet is designed to operate behind the scenes to fetch audit entries for perhaps many mailboxes on servers across the organization and respond with an email with an XML attachment that contains the search results. The XML data are complete but need to be poured through a formatter to make sense of them, or at least, to make sense for those of us who are not fluent in interpreting raw XML. The command to create a typical background mailbox audit log search looks like this:

New-MailboxAuditLogSearch -Name 'Unauthorized Delegate Access review' -LogonTypes
Delegate
-Mailboxes 'CEO Assistant', 'CEO', 'Senior VP-Finance' -StartDate '1/1/2010'
-EndDate '12/31/2010'
-StatusMailRecipients'ComplianceAuditMailbox@contoso.com'

Figure 15-36 shows how EMS acknowledges the submission of a new mailbox audit log search. The command that is run creates a search through the audit entries for delegate access that are stored in the three specified mailboxes between the start and end date. If you don’t specify any mailboxes, Exchange will return audit data for every mailbox on an Exchange 2010 server in the organization that has been enabled for auditing.

When the search is complete, Exchange records the fact in event 4003 in the Application Event Log and sends an email containing the results to the email address or addresses specified in the –StatusMailRecipients parameter. Figure 15-37 shows an example of the type of email delivered to these recipients. The text of the message contains the search criteria and the attached XML file contains the actual results. The recipients for mailbox audit reports must be mail-enabled objects known to the organization. Normally, they will be mailboxes or groups, but you can arrange for the email reports to go to external recipients such as your auditors, providing that you create a mail-enabled contact that contains their address.

Figure 15-36 Launching a mailbox audit log search with New-MailboxAuditLogSearch.

Figure 15-37 Viewing the message with details of a mailbox audit log search and the XML file containing the results.

No one could pretend that mailbox auditing is complete in terms of functionality or presentation. Forcing all interaction through EMS is acceptable if the output was easier to extract and interpret, but that’s not the case. Eventually, Microsoft might do the work in a future version or service pack to integrate mailbox auditing into ECP and make this interesting and worthwhile functionality more accessible to administrators.