Managing Compliance in Microsoft Exchange Server 2010

Auditing administrator actions

As even a brief reading of this book reveals, an administrator has the ability to change many settings or create many new objects that influence the way Exchange operates. Up to Exchange 2010, there was no facility available to be able to track who did what and when at an administrative level. The addition of Windows PowerShell and its ability to affect many objects with relatively simple commands reinforced the need to be able to log what happens within an Exchange organization.

Exchange 2010 includes the ability to audit actions taken by administrators in EMC and EMS. This is intended to allow organizations to maintain records of who did what and when to execute the cmdlets used to manage Exchange. Apart from providing definitive proof about what account was used to add a mailbox, change properties on a connector, set up a new domain, or any of the myriad day-to-day operations that occur in an Exchange organization, maintaining an audit log can help satisfy legislative requirements by demonstrating that strict controls are imposed on the work that administrators do with Exchange.

Some administrators will not welcome this development and will view 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 increased oversight as part of modern life, much in the same way that we all seem to be under the eyes of video surveillance wherever we go. Auditing is not enabled by default. The Set-AdminAuditLogConfig cmdlet controls how administration logging functions across the organization.

Set-AdminAuditLogConfig -AdminAuditLogEnabled $True

When logging is enabled, administrators see no indication that their actions are being captured in the audit log unless they search the audit log.

Enabling administrative logging instructs the Admin Audit Log agent, one of the standard set of cmdlet extension agents shipped with Exchange 2010, to begin capturing details of administrative events. The admin audit agent runs on all Exchange 2010 servers to monitor the running of all cmdlets and record details of the cmdlets that you configure to be audited. As described in Chapter 3, “The Exchange Management Shell”, the execution of all business logic in Exchange 2010 flows through cmdlets so the agent is able to monitor all administrative operations.

A number of other configuration settings are used to control the finer details of administrator audit logging. You can view the current audit configuration settings for the organization with the Get-AdminAuditLogConfig cmdlet. For example:

Get-AdminAuditLogConfig | Format-List

AdminAuditLogEnabled     : True
TestCmdletLoggingEnabled : False
AdminAuditLogCmdlets     : {*}
AdminAuditLogParameters  : {*}
AdminAuditLogAgeLimit    : 90.00:00:00
AdminDisplayName         :
ExchangeVersion          : 0.10 (14.0.100.0)
Name                     : Admin Audit Log Settings
DistinguishedName        : CN=Admin Audit Log Settings,CN=Global
Settings,CN=contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com
Identity                 : Admin Audit Log Settings

Auditing is performed on a cmdlet basis and can be further refined to select specific parameters to audit. By default, the use of every cmdlet and every parameter is audited, so the preceding configuration has values of “{*}” (asterisk). In fact, Exchange ignores auditing for cmdlets beginning with “Get,” “Search,” and “Test” so as not to clutter up the audit log with entries for cmdlets that simply retrieve or read information. The purpose here is to audit operations that create or manipulate objects. Enabling the audit of every cmdlet is a bad idea because it will generate a huge mass of audit entries, including entries for actions that are probably not of great concern such as a user updating her OOF.

To focus on a specific set of cmdlets, we define the cmdlets in a list passed in the –AdminAuditLogCmdlets parameter for the Set-AdminAuditLogConfig cmdlet. For example, this command tells Exchange that we want to audit any use of the New-Mailbox and New-DistributionGroup cmdlets and any cmdlet that has “Transport” in its name.

Set-AdminAuditLogConfig -AdminAuditLogCmdlets 'New-Mailbox, New-DistributionGroup,
*Transport'

Exchange now captures details about any creation of new mailboxes and distribution groups plus any action taken with the cmdlets used to manage the transport service. Let’s assume that you only want to capture certain details about new mailboxes. This command captures details of the name, display name, and custom attributes for new mailboxes.

Set-AdminAuditLogConfig -AdminAuditLogParameters Name, DisplayName, *Custom'

Clearly, you have to arrive at a balance to capture the required auditing data but not so much as to make it difficult to find an instance when necessary. It is likely that some trial and error will be required to settle on the right list of cmdlets and parameters to audit.

The audit mailbox

On Exchange 2010 RTM servers, you have to create and configure a mailbox to act as the repository for the audit reports that Exchange creates every time that one of the cmdlets within the audit scope is run. Exchange 2010 SP1 removes the requirement to configure an audit mailbox. Instead, SP1 uses a folder called AdminAuditLogs in the special arbitration mailbox with the display name “Microsoft Exchange” as the repository for audit reports. This is a more secure location because administrators can’t simply grant themselves access to the audit mailbox and log on to remove any audit reports that they don’t want others to see. On the other hand, the change in audit mailbox location means that any audit reports collected in the audit mailbox that you define for Exchange 2010 are ignored for the purposes of the audit reports that you can view through ECP. This shouldn’t be a real problem in practice and you can delete the original audit mailbox after you have deployed Exchange 2010 SP1 throughout the organization.

In addition to the change of audit mailbox, SP1 introduces an aging mechanism for audit reports to prevent an unwanted accumulation of data. By default, audit reports are held for 90 days and the MFA removes audit logs after their retention period expires. If you want to change the retention period, you can update it with the Set-AdminAuditLogConfig cmdlet. This command sets the audit log retention period to 182 days (approximately six months):

Set-AdminAuditLogConfig -AdminAuditLogAgeLimit 182.00:00:00

The audit configuration applies to administrator activity on an organization-wide basis so all of the reports generated across the entire organization go to the one mailbox. As you can imagine, it is all too easy to fill this mailbox with audit reports if you use settings that enable auditing of an extensive set of cmdlets and keep the reports for extended periods.

How administrator auditing happens

Auditing is performed by the Admin Audit Log agent, which evaluates cmdlets as they are run against the audit configuration to decide whether the use of the cmdlet needs to be logged. If so, the agent creates an item containing details of the cmdlet in the Inbox of the audit mailbox. Table 15-8 lists the data that are captured in the audit reports.

Table 15-8. Data captured in audit reports

The audit agent creates separate reports for each object if you execute an action that is performed against several objects. For example, if you use Get-Mailbox to fetch a list of mailboxes from a database and then use Set-Mailbox to set a new storage quota for each mailbox, the audit agent creates a separate report for each mailbox as it is updated.

You can also write your own entries into the audit log. For example, if you wanted to document a script being run or to take note of a particular administrative operation that you performed to solve a problem, you can capture it with the Write-AdminAuditLog cmdlet as shown here. You can insert up to 500 characters of text into the comment parameter, which is captured in the CmdletParameters property of the log entry:

Write-AdminAuditLog -Comment 'Server acting up; cleared by increasing HeapSize to
30000'

Only one audit mailbox is used for the organization. This can pose some difficulties in widely distributed organizations where actions performed in one part of the network might have difficulty being registered in the arbitration mailbox. Even in highly centralized environments where a small set of administrators perform all actions for the organization, it is still possible to see errors caused by the unavailability of the database that hosts the arbitration mailbox. For example, Figure 15-34 shows what happens when the database containing the audit mailbox is unavailable. Exchange is unable to capture audit entries until the database becomes available again. While the database containing the audit mailbox is unavailable, Exchange writes event 5000 from the msExchange Management Application into the application event for each instance when it is unable to log an audit entry.

Figure 15-34 EMS flags an error accessing the audit mailbox.

Exchange 2010 doesn’t provide facilities to interrogate the audit reports and create analysis of the management activity within an organization. Exchange 2010 SP1 addresses the lack in two ways.

• A set of precanned audit reports that cover the most common needs for an organization (as determined by the Exchange developers) are available through ECP (Figure 15-35). The reports cover both mailbox audit data and administrator audit data.

• The new Search-AdminAuditLog cmdlet is provided to allow administrators to create their own analysis of the administrator audit logs.

The reports provided through ECP depend on the Search-AdminAuditLog and other cmdlets to generate their data. For example, the litigation hold report is created by examining the ligitation hold property set on mailboxes that are on hold and the role groups report examines changes made to role groups to grant permission to users to perform different administrative operations. I’ll discuss what happens with mailbox audits and how you can search audit data in the next section.

Figure 15-35 Audit reports available in ECP.

Interrogating the audit reports with the Search-AdminAuditLog cmdlet is straightforward. Here are a few examples that illustrate the possibilities that exist to discover just what administrators are doing within the organization:

1. Search for actions performed by one or more users. Each of the users that you want to look for is identified by alias, email address, display name, or distinguished name. Separate the names with commas:

   Search-AdminAuditLog -UserIds Administrator, 'Tony.Redmond@contoso.com' |
   Format-Table Rundate, Caller, CmdletName

   RunDate              Caller                             CmdletName
   ------------         --------                           ----------------
   4/5/2010 7:45:56 PM  contoso.com/Users/Administrator    Set-Group
   4/5/2010 10:18:11 PM contoso.com/Users/Administrator    Set-OrganizationConfig
   4/6/2010 1:50:38 AM  contoso.com/Users/Administrator    Set-Mailbox
   4/6/2010 1:55:07 AM  contoso.com/Users/Administrator    New-MailboxImportRequest
   4/6/2010 1:55:55 AM  contoso.com/Exchange               Users/Redmond, Tony Set-CalendarProcessing
   4/6/2010 2:22:21 AM  contoso.com/Users/Administrator    Set-Mailbox
   4/6/2010 2:56:57 AM  contoso.com/Users/Administrator    Start-ManagedFolderAssistant
   4/8/2010 3:10:16 PM  contoso.com/Users/Administrator    New-Mailbox
   4/8/2010 3:10:17 PM  contoso.com/Users/Administrator    Set-User
   4/8/2010 4:23:17 PM  contoso.com/Exchange               Users/Redmond, Tony Remove-MailboxSearch

2. Search for specific actions. In this example we 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. The ObjectModified property returned in each audit log tells you the name of the database that was operated on.

   Search-AdminAuditLog -Cmdlets Dismount-Database, Mount-Database | Format-Table
   RunDate, Caller, CmdletName, ObjectModified -AutoSize

   RunDate                 Caller                             CmdletName           ObjectModified
   ------------            --------                           ----------------     --------------
   3/19/2010 6:06:47 PM    contoso.com/Users/Administrator    Mount-Database       Managers
   3/19/2010 6:07:49 PM    contoso.com/Users/Administrator    Dismount-Database    Managers
   3/19/2010 6:07:58 PM    contoso.com/Users/Administrator    Mount-Database       VIP Data

3. Search for audit records within a particular date range. In this case we want to find out who has been creating new mailboxes over a specified period. Note that we include the Succeeded property in the output because it is possible that some attempts to run the New-Mailbox cmdlet were unsuccessful, which is, in fact, what we can see in the results.

   Search-AdminAuditLog -StartDate "04/01/2010 00:00" -EndDate "04/15/2010 23:59"
   -Cmdlets New-Mailbox | Format-Table RunDate, Caller, ObjectModified, Succeeded

   RunDate              Caller                           ObjectModified                      Succeeded
   -----------          -------                          --------------------                ---------
   4/8/2010 3:10:16 PM  contoso.com/Users/Administrator  contoso.com/Users/extest_3a8609984  True
   4/8/2010 4:24:20 PM  contoso.com/Users/Administrator  contoso.com/Users/Legal Searches    True
   4/9/2010 9:47:33 AM  contoso.com/Users/Administrator  contoso.com/Users/Leitrim Room      False
   4/9/2010 9:47:58 AM  contoso.com/Users/Administrator  contoso.com/Users/Leitrim Room      False
   4/9/2010 9:48:21 AM  contoso.com/Users/Administrator  contoso.com/Users/Leitrim Room      False
   4/9/2010 9:48:34 AM  contoso.com/Users/Administrator  contoso.com/Users/Leitrim Room      True
   4/9/2010 3:58:16 PM  contoso.com/Users/Administrator  contoso.com/EMEA/Pelton, David      True
   4/9/2010 3:59:01 PM  contoso.com/Users/Administrator  contoso.com/EMEA/Ruth, Andy         True

4. Analyze the cmdlets that are being run by administrators. These data are really just for interest’s sake, but they do reveal what are the most commonly used cmdlets.

   Search-AdminAuditLog | Sort CmdletName | Group CmdletName | Format-Table Count,
   Name -AutoSize

   Count             Name
   --------          -------
   26                Add-DistributionGroupMember
   2                 Add-MailboxPermission
   1                 Dismount-Database
   1                 Enable-Mailbox
   2                 Mount-Database
   1                 Move-DatabasePath
   1                 Move-OfflineAddressBook
   4                 New-ActiveSyncDeviceAccessRule
   1                 New-ActiveSyncMailboxPolicy
   9                 New-DistributionGroup

$AuditArray = Search-AdminAuditLog -StartDate '11/1/2010 00:00'
-EndDate '11/1/2010 23:59'
$AuditArray[1].cmdletparameters

Capturing audit data for administrator actions does not replace the need for operational discipline in the careful recording of changes made to server and organization configuration, including the following:

• Hotfixes and roll-up updates tested and applied, including any updates for add-on products

• Service packs for Windows and Exchange tested and applied

• Major network updates (for example, the introduction of a new DNS server)

• Installation of new Windows and Exchange servers

• Installation of any software on an Exchange server

• Changes to transport configuration such as the addition of a new connector or a change to transport settings

In this context, audit reports are helpful to record administrator actions, but they are not a complete solution.