Auditing Administrators’ Actions with Exchange 2010

No one likes to think that someone else is checking up on his or her work, but it’s an unfortunate fact of modern corporate life that actions often need to be audited and justified. For this reason, Microsoft Exchange 2010 introduced administrator auditing, which companies can use to audit the operations that administrators perform within an Exchange organization.

Apart from providing definitive proof about what account was used to add a mailbox, change a connector’s properties, set up a new email domain, or perform another Exchange operation, maintaining an audit log can help satisfy legislative requirements by demonstrating that strict controls are imposed on the work performed by Exchange administrators. Some administrators won’t welcome this increased oversight, viewing it as yet another example of big brother looking over their shoulder as they struggle to keep the email system up and running. Others will consider this increased oversight as part of modern life, much in the same way that people accept they’re under the eyes of video surveillance wherever they go.

The Admin Audit Log agent—one of the standard cmdlet extension agents shipped with Exchange 2010—monitors administrative operations on Exchange 2010 servers, no matter what administrative interface is used. This is possible because the Exchange Management Console (EMC) and Exchange Control Panel (ECP) are built on top of the set of cmdlets exposed through the Exchange Management Shell (EMS), which means the execution of all business logic in Exchange 2010 flows through a common path. No indication is given in any administrative interface that auditing is in place, so administrators might be unaware that the details of their actions are being recorded.

Using the administrator auditing feature in Exchange 2010 isn’t too difficult. I’ll show you how to enable and configure administrator auditing and search the data that Exchange gathers about administrative actions. I’ll also show you how to enable and configure a new mailbox auditing feature introduced in Exchange 2010 SP1. With this feature, you can discover when administrators and delegates log on to mailboxes and what actions they took.

Enabling Administrator Audit Logging

Administrator auditing consists of two components: the Admin Audit Log agent, which monitors administrator actions for auditing, and administrator audit logging, which writes the audit data to an audit mailbox. The agent is enabled by default, whereas the logging is disabled by default. Both the agent and the logging must be enabled for administrator auditing to occur.

To enable administrator audit logging, you need to use the Set-AdminAuditLogConfig cmdlet, which controls how the logging functions across the organization. In EMS, run the command

Set-AdminAuditLogConfig-AdminAuditLogEnabled $True 

(Although this command wraps here, you'd enter it all on one line in EMS. The same holds true for the other commands that wrap.) This new audit setting has to replicate across the organization before it’s effective on all servers, so it might take an hour or so before you can be sure that all administrators’ actions are being logged. However, logging will begin much sooner on the servers in the Active Directory (AD) site in which the Set-AdminAuditLogConfig command was run because the updated configuration will be available sooner to those servers. If you later want to disable administrator auditing, you’d run the Set-AdminAuditLogConfig command again, except this time you’d set the -AdminAuditLogEnabled parameter to $False.

Setting Up the Audit Mailbox

In the release to manufacturing (RTM) version of Exchange 2010, you have to create and configure a standard mailbox to act as the repository. You configure it by setting the Set-AdminAuditLogConfig cmdlet’s -AdminAuditLogMailbox parameter to the mailbox’s SMTP address. The address must be valid and belong to an authoritative domain in the organization. So, for example, the command might look like

Set-AdminAuditLogConfig

  -AdminAuditLogMailbox

  '[email protected]'

In Exchange 2010 SP1, you don’t need to create and configure an audit mailbox. Instead, Exchange 2010 SP1 automatically creates the AdminAuditLogs folder in the Microsoft Exchange arbitration mailbox and stores the audit data in that folder. This arbitration mailbox is a more secure location for the audit data. Administrators can’t grant themselves access, log on, and remove any audit entries that they don’t want others to see, as they could with the standard mailbox. The arbitration mailbox uses a disabled account, so it takes more work to log on to it—and that work will leave some traces, revealing that an administrator might be up to no good.

No matter whether you’re running Exchange 2010 SP1 or Exchange 2010 RTM, only one audit mailbox is used for an organization. This can pose some problems in widely distributed organizations; actions performed in one part of the network might have difficulty being registered in the audit mailbox. Even in highly centralized environments, it’s still possible to see errors caused by the unavailability of the database that hosts the audit mailbox. During the period when the database can’t be accessed, Exchange won’t be able to capture audit entries. Exchange writes event 5000 (whose source is listed as MSExchange Management Application) into the application event log each time it’s unable to log an audit entry. Administrator auditing will resume when the database becomes available, but any actions that occur when the mailbox is unavailable aren’t captured.

Fine-Tuning the Audit Configuration

Once administrator auditing is running, the Admin Audit Log agent evaluates cmdlets as they’re run against an audit configuration to decide whether the use of the cmdlet needs to be audited. By default, the agent captures information about the execution of every cmdlet that creates or amends data. It ignores the execution of cmdlets beginning with Get, Search, and Test to avoid cluttering up the audit log with entries for cmdlets that simply read or retrieve information or that test Exchange components.

If a cmdlet needs to be audited, the Admin Audit Log agent creates an entry containing details about the cmdlet’s execution in the Inbox of the audit mailbox. Table 1 lists the default data that’s captured and logged. If a cmdlet performs an action against several objects, the agent creates a separate audit entry for each object. For example, if an administrator uses the Set-Mailbox cmdlet to set new storage quotas for several mailboxes, the agent creates a separate entry for each mailbox when that database is updated with the new storage quota.

Table 1: Data Captured and Logged in Audit Entries

You can fine-tune the audit configuration to control exactly what information is captured. To view the current audit configuration, you use the Get-AdminAuditLogConfig cmdlet. For example, the command

Get-AdminAuditLogConfig | Format-List

provides output like that in Figure 1. In this output, note the value of {*} for both AdminAuditLogCmdlets and AdminAuditLogParameters. These values tell Exchange to audit every cmdlet (excluding the exceptions noted previously) and every parameter in those cmdlets.

Figure 1: Retrieving the current configuration for administrator audit logging

If you want to audit a specific set of cmdlets (i.e., actions), you can use Set-AdminAuditLogConfig. You specify which actions to audit with its -AdminAuditLogCmdlets parameter. For example, the command

Set-AdminAuditLogConfig

  -AdminAuditLogCmdlets 'New-Mailbox,

  New-DistributionGroup,

  New-MailboxDatabase, *Transport*'

tells Exchange to audit the creation of new mailboxes, distribution groups, and mailbox databases. Plus, it tells Exchange to audit any action taken to manage the Microsoft Exchange Transport service (i.e., the use of any cmdlet whose name contains Transport) .

If you want to capture only certain details about the new mailboxes created by administrators, you can use the Set-AdminAuditLogConfig cmdlet’s -AdminAuditLogParameters parameter. For example, the command

Set-AdminAuditLogConfig

  -AdminAuditLogCmdlets 'New-Mailbox'

  -AdminAuditLogParameters 'Name,

  DisplayName, *Custom'] 

captures only the name, display name, and values set for any of the 15 custom attributes (i.e., attributes whose names end with Custom such as CustomAttribute1) of the new mailboxes created by administrators.

You can write your own entries in the audit mailbox. For example, if you want to document a script being run or note a particular administrative operation you performed to solve a problem, you can use the Write-AdminAuditLog cmdlet in a command such as

Write-AdminAuditLog -Comment

  'Server acting up; cleared by

  increasing HeapSize to 30000'

You can insert up to 500 characters of text into the comment parameter, which is captured in the CmdletParameters property of the audit entry. If you use Write-AdminAuditLog, it’s a good idea to write information into the custom audit entries that can be related back to other documentation, such as the reference number for a support ticket.

The audit configuration applies to administrative activity across the entire organization. All of the audit data goes into one mailbox, so it’s all too easy to overload this mailbox if you audit of an extensive set of cmdlets and parameters. You have to arrive at a balance between capturing the required audit data but not so much data that it’s difficult to find an instance when necessary. Some trial and error will likely be necessary to find the right list of cmdlets and parameters to audit.

If you’re using Exchange 2010 SP1, you can also use an aging mechanism to control the amount of data in the audit mailbox. By default, audit entries are held for 90 days. The Managed Folder Assistant removes audit entries after their retention period expires. If you want to change the retention period, you can update it with the Set-AdminAuditLogConfig cmdlet’s -AdminAuditLogAgeLimit parameter. For example, the command

Set-AdminAuditLogConfig-AdminAuditLogAgeLimit 182.00:00:00

 sets the audit log retention period to 182 days (approximately six months).

The aging mechanism was introduced in SP1, so you won’t have this option if you’re running Exchange 2010 RTM. In that version, all of the audit data remains in the audit mailbox until you remove it.

Searching the Administrator Audit Data

Exchange 2010 RTM doesn’t provide any out-of-the-box tools to search the audit logs and analyze administrators’ activities. With this version, you have to open the audit mailbox and peruse the audit records to discover what has been captured.

Exchange 2010 SP1 addresses the lack of search tools two ways:

 Using Search-AdminAuditLog

With the Search-AdminAuditLog cmdlet in Exchange 2010 SP1, searching the audit logs is relatively painless. Here are a few examples to demonstrate the possibilities that exist for discovering what administrators are doing.

Search for actions performed by one or more administrators. Suppose you want to know the kind of operations being performed by certain administrators. You can identify the administrators by their aliases, email addresses, display names, or distinguished names (DNs), separated with commas. For example, the command

Search-AdminAuditLog

  -UserIds Administrator, AJR |

  Format-Table RunDate, Caller,

  CmdletName -AutoSize

tells Exchange to search for the actions of everyone who performed an action when logged in under either the alias Administrator or AJR. As you can see in the sample results in Figure 2, most of the administrative activity that’s unearthed has to do with mailbox databases and database availability groups.

Figure 2: Searching for actions performed by specific administrators

Search for the execution of specific cmdlets. Suppose you want to know who has recently mounted or dismounted mailbox databases. To locate the audit records, you specify the cmdlets that are used for these purposes, as in

-Search-AdminAuditLog

  -Cmdlets Dismount-Database,

  Mount-Database | Format-Table RunDate,

  Caller, CmdletName, ObjectModified

  -AutoSize

The ObjectModified property tells you the name of the database in which the mount or dismount operation was performed. In the sample results in Figure 3, those databases were DB1 and PFDatabase1. Figure 3: Searching for the execution of specific cmdlets

Search for audit records captured in a particular date range. Suppose you want to find out who was creating new mailboxes on a specific day. You can use a command such as

Search-AdminAuditLog

  -StartDate '08/13/2010 00:00'

  -EndDate '08/13/2010 23:59'

  -Cmdlets New-Mailbox |

  Format-Table RunDate, Caller,

  ObjectModified, Succeeded -Autosize

In the output set, note the Succeeded property, which specifies whether the cmdlet was successful. Some attempts to run the New-Mailbox cmdlet might fail, which is the case in the sample results in Figure 4. An attempt to create the Hicks, Cassie mailbox was unsuccessful for some reason.

Figure 4: Searching for specific actions within a date range

One quirk with the Search-AdminAuditLog cmdlet is that it doesn’t return the comments inserted into the audit log with the Write-AdminAuditLog cmdlet. As you’ll recall, the comments store information that administrators want to add to the audit log, so it’s important to be able to access that data. The data is held in the CmdletParameters property of the audit entry, but if you include this property in the output set, all you see is the string Comment. The data is in the audit log, but you need to extract it by directing the Search-AdminAuditLog cmdlet’s output into an array, then looking at the appropriate element in that array. For example, the code

$AuditArray = Search-AdminAuditLog

  -StartDate '11/1/2010 00:00'

  -EndDate '11/1/2010 23:59'

$AuditArray[1].CmdletParameters 

creates an array, then examines the CmdletParameters data in array element number 1.

Another quirk I noticed is that Exchange sometimes caches audit entries because they don’t immediately show up in searches. I can’t reproduce the problem all the time, but several times the audit entries didn’t appear in searches until five to 10 minutes after they were created. The entries eventually show up, so data isn’t being lost. You just have to be a little patient.

You also have to be patient if you attempt to execute a search when the database that hosts the audit mailbox is unavailable. To let you know, Exchange will give you the following message: The attempt to search the administrator audit log failed. Please try again later.

Using the Canned Reports

In Exchange 2010 SP1, ECP provides five canned reports in Auditing Reports page, as Figure 5 shows. ECP uses cmdlets to obtain and process data from the administrative audit log, the mailbox audit log, and mailbox properties. For example, to generate the litigation hold report, ECP uses the Get-Mailbox, Search-AdminAuditLog, and Search-MailboxAuditLog cmdlets.

Figure 5: Using ECP’s canned reports

The litigation hold report lists the users who have been enabled for litigation hold (using EMC, ECP, or EMS) for a specified date range. This onscreen report tells you the account that enabled the hold and when the hold was applied.

The non-owner mailbox access report lists mailboxes that have been accessed or changed by a user other than the owner. If any events are found, they’re listed along with information about what the non-owner did inside the mailbox. For example, if a non-owner sent a message using SendAs permission, you’ll be able to see the message’s Subject line and whether the send operation succeeded. However, you won’t be able to see who the message was addressed to or what it contained. You’d have to conduct a separate mailbox search to retrieve this information. Although this onscreen report lets you quickly check mailboxes that are being accessed by non-owners, it isn’t a comprehensive audit report that will satisfy external litigators. It only points to activities that might need further investigation.

The administrator role group report lists the changes that have been made to role groups over a specified period. These actions grant permissions to users to perform the different administrative actions made available through membership of role groups. For example, membership in the Mailbox Import Export role group is required before you can import data from a PST into a mailbox and membership in the Discovery Management role group is required before you can execute a multi-mailbox search. Once again, this onscreen report only points to activities that might need further investigation, such as an account being granted a permission that it shouldn’t possess.

If these three canned reports don’t meet your needs, you can create custom reports. As the “Using Search-AdminAuditLog” section demonstrated, you easily explore the raw data with Search-MailboxAuditLog and other cmdlets.

The final two canned reports export the administrator audit log and the mailbox audit log so that you can peruse the data. Unlike the other three reports, these two reports aren’t displayed on screen. Instead, they’re emailed to the specified recipients. After you click either the Export the administrator audit log option or the Export mailbox audit logs option in ECP’s Auditing Reports page, the basic steps in generating an export are:

Figure 6: Exporting the administrator audit log Nothing seems to happen when you click the Export button, but in the background Exchange starts searching for the required data. (It would be nice if ECP acknowledged the export request.) After the search results have been generated, Exchange sends the data to the recipients in the form of an XML attachment called SearchResult.xml. As you can see in the sample SearchResult.xml file in Figure 7, it contains the raw XML code. When you open the file in a browser or any other application that can open XML files, it reveals the actions taken by administrators. Figure 7: Opening the SearchResult.xml attachment

You won’t be able to access the attachment with Outlook Web App (OWA) unless you modify the OWA mailbox policy to permit XML files to be viewed. It’s probably a bad idea to do this to the general-purpose OWA mailbox policy because it can create the potential for end users to unwittingly access XML content that might be malicious. It’s a better idea to create a special OWA mailbox policy that permits access to XML attachments and assign that policy to administrators’ mailboxes.

Enabling and Configuring Mailbox Auditing

Exchange 2010 SP1 introduces the ability to audit when owners, administrators, and delegates access mailboxes. Unlike administrator auditing, which is enabled on an organization-wide basis, mailbox auditing is enabled on an individual basis. This makes sense, as you probably don’t want the overhead of gathering audit data for every single mailbox in the organization. Instead, you can audit only those mailboxes that contain confidential information, such as executives’ mailboxes or discovery mailboxes that hold the results of multi-mailbox searches.

An example of the kind of problem that mailbox auditing seeks to address is when rogue administrators give themselves full access to another user’s mailbox, then log on to the mailbox to examine its contents. Although other versions of Exchange record an event indicating that the administrator logged on to the account, they don’t tell you what the rogue administrator did afterward. But if the mailbox has been enabled for auditing in Exchange 2010 SP1, the audit will capture details of any auditable actions performed by the administrator. The same data is also captured for users who have been assigned delegate access to the mailbox by its owner.

Mailbox auditing is enabled through the Set-Mailbox cmdlet. For example, if you want to protect the CEO’s mailbox, you could use a command such as

Set-Mailbox -Identity 'CEO Mailbox'

  -AuditOwner $Null -AuditDelegate Update,

  Move, MoveToDeletedItems, SoftDelete,

  HardDelete, SendAs, SendOnBehalf

  -AuditEnabled $True

In this command, setting the -AuditEnabled property to $True turns auditing on for the mailbox. The -AuditDelegate parameter tells Exchange to audit any action that updates content, moves items, deletes items, empties the Deleted Items folder, or sends messages from the mailbox if that action is performed by the delegate. In this context, a delegate is someone who logs on to the mailbox using SendAs, SendOnBehalf, or FullAccess permission. You can also audit administrators’ access to a mailbox by specifying the -AuditAdmin parameter (which isn’t shown here). Auditing can be enabled for mailbox owner access as well, but it isn’t typically done because of the high number of audit items that result.

Mailbox audit data is stored in the Audits subfolder of the Recoverable Items folder in the user’s mailbox. Mailbox audit items are kept for 90 days by default, but this setting is customizable up to 68 years.

Searching the Mailbox Audit Data

To search the mailbox audit data, you can use:

Because I already covered how to use the ECP canned report in the “Using the Canned Reports” section, let’s jump right to the Search-MailboxAuditLog cmdlet. An example of how to use this cmdlet is

Search-MailboxAuditLog

  -Identity 'CEO Mailbox' -ShowDetails

  -StartDate '11/14/2010 00:01'

  -EndDate '11/17/2010 23:59'

  -LogonType Delegate -ResultSize 100 |

  Format-Table Operation, OperationResult,

  LogonUserDisplayName, ItemSubject,

  LastAcccessed

This synchronous search looks for audit entries in the CEO’s mailbox and reports any found that occurred through delegate access. Figure 8 shows sample results.

Figure 8: Searching the mailbox audit data for actions performed by delegates

An example of the how to use the New-MailboxAuditLogSearch cmdlet is

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

  '[email protected]' 

This background asynchronous search looks for audit entries in the three specified mailboxes and sends the output to an SMTP address, which doesn’t necessarily have to be an Exchange mailbox.

Considerations to Keep in Mind

It’ll take some time for companies to decide whether they want to implement administrator or mailbox auditing, what kind of actions they will audit, how long to keep the audit data, and how they will use that data. When you help your company make those decisions, you need to keep a couple of considerations in mind.

First, you need to keep in mind that capturing audit data for administrator actions or mailbox access doesn’t replace the need for careful recording of server and organization configuration changes. To help ensure the smooth operation of your Exchange organization, you still need to document changes when you perform activities such as:

Second, you need to keep in mind that administrator auditing works only on Exchange 2010 servers. It won’t work, for instance, if an administrator makes a change to a mailbox database or transport connector on an Exchange 2007 server in a mixed mode organization. That issue will go away as servers are upgraded to Exchange 2010.