Tip

Exchange 2010 auditing tools to track admin, end-user behavior

Compliance rules make tracking admin and email users a necessary evil. Thankfully, audit logging tools in Exchange 2010 can help.

I read your email. Well, I don’t really read your email but how would you know? IT finds this statement funny, but it makes non-tech folks a little nervous.

A lot of business occurs via email and companies rely on Exchange Server for critical business processes. So, CEOs are concerned with what’s actually happening on email servers and who can access them.

As an Exchange administrator, where do you turn when the CEO comes to you for answers? You turn to auditing. And Exchange Server 2010 has two levels of auditing that administrators can use: administrator audit logging and mailbox auditing logging. Each tool differs slightly in functionality and setup, so let’s take a look at what each one means and why users shouldn’t fear administrator-based audits.     

What is administrator audit logging?

Administrator audit logging (AAL) in Exchange 2010 Service Pack 1 (SP1) gives administrators a way to log commands that have been executed on the server. Enabled by default in Exchange 2010 SP1, AAL stores all commands (except Get- and Search-) in an arbitration mailbox.

Whether an admin executes the commands in the Exchange Management Console (EMC), Exchange Management Shell (EMS) or the Exchange Control Panel> (ECP), AAL records the actual EMS commands that ran.

AAL creates a record of all changes admins make to the environment, so you can use it to troubleshoot bugs and review administrative actions. The tool also provides a record of actions to help meet regulatory compliance or discovery orders. And because it records detailed information on any changes, the Exchange team can use AAL as documentation and to review any environment changes when they’re troubleshooting a problem.

Instead of having to track down the administrator who made the change and hoping he remembers what change he made, you can view who did what in the AAL and see what EMS commands he used to implement any changes. You can then reconstruct or reverse any changes, if necessary.

Inside the AAL: Exchange 2010 RTM vs. SP1

AAL is enabled by default in Exchange 2010 SP1; however, you’ll need to enable it in Exchange 2010 RTM and specify which mailbox will store the logs. To do this, open the EMS and run the following commands. This example uses the domain example.com and the user account edfisher.

Set-AdminAuditLogConfig –AdminAuditLogMailbox [email protected]

Add-MailboxPermission [email protected] –user [email protected] –AccessRights fullaccess

Repeat the AddMailboxPermission command for each admin who should have rights to the log mailbox; you can access this mailbox using Outlook or Outlook Web App 2010 (OWA).

AAL underwent some significant changes in Exchange 2010 SP1. Instead of requiring an admin to specify a mailbox to store AAL files, Exchange features a default arbitration mailbox for logs (Figure 1). The arbitration mailbox does not appear in the global address list (GAL) and you can’t add it to Outlook. However, administrators can use the ECP to report on logs in this hidden mailbox.

Exchange 2010 has a default arbitration mailbox for logs
Figure 1. Exchange 2010 SP1 includes a default arbitration mailbox.

If you apply SP1 to an Exchange server running RTM, or build a new server using Exchange 2010 SP1, AAL is enabled by default. When AAL is enabled, the default is to log all cmdlets except Test-, Get-, and Search- and to log all parameters. The retention period is set to 90 days as well.

In the EMS, you can use the Set-AdministratorAuditLog and either the full command name, or a valid wildcard, to specify which parameters to log and the length of time the audit log should retain data. I recommend that you use all default values except the retention period setting. Consult your document retention specialist or legal counsel to determine how long you should retain data for; the command below sets the period to retain data to 180 days. 

Set-AdminAuditLogConfig –AdminAuditLogAgeLimit 180.00:00:00:00

Admins must use the ECP to access the information in the AAL. To do so, visit https://CASserver/ecp and click on the Roles and Auditing link, then click Auditing.

In the Exchange Control Panel, administrators can run reports on non-owner mailbox access, litigation hold and administrator role groups (Figure 2). They can also export mailbox audit logs and administrator audit logs as an XML file, which they can send via email to any address.

Use the Exchange Control Panel to run various reports
Figure 2. Use Exchange Control Panel to run reports on non-owner mailbox access.

Reports allow you to obtain usage data; external auditors can export logs when seeking data for compliance reviews. In both instances, you select a date range for which to filter data -- from the maximum retention period to today.

What is mailbox audit logging?

Mailbox audit logging gives administrators a way to determine and record (or log) actions a mailbox owner, a user with delegated rights or the admin has performed within a mailbox or to any of its contents. Possible actions a user could make include deleting or forwarding a message. Someone with delegated rights could also edit a calendar entry.

When used with the ECP, mailbox audit logging allows you to run reports and export logs for mailbox access. If you need to review actions performed by users with delegated access to another user’s mailbox, Exchange admins can view reports about email sent and received within a specified time range, designated mailboxes or all mailboxes in the environment. Admins can then export this data to a file to review or reporting on at a later time.

To log any of this information, you must enable logging on a per-mailbox basis. To do so, use the Set-Mailbox cmdlet to specify that you want to enable auditing on a mailbox and the actions you want to audit. The command may look like this:  

Set-Mailbox –identity “Ed Fisher” –AuditEnabled $true

In Figure 3, you can see that the retention period for audit logs is set at 90 days. You can also view what actions administrators might perform in a user’s mailbox, what delegate actions could be logged and that the owner won’t be logged at all. This lets you keep a record of what actions users (other than the mailbox owner) have permission to do in a specific mailbox -- without flooding the log with actions the owner will do throughout the day.

Set the retention period for Exchange 2010 audit logging
Figure 3. The retention period for Exchange 2010 audit logging is set at 90 days.

You can enable actions for the owner by specifying that you want to audit the owner and a list of actions that will be logged, as shown in the following command:

Set-Mailbox –identity “Ed Fisher” –AuditOwner {SoftDelete, HardDelete}

A user will generate a large volume of log entries on his mailbox, so use restraint when setting up this capability. It’s helpful to log deleted email if you want to see what messages might be deleted before you run backups. However, this will only show you the deleted actions and the message ID. The log won’t capture message content. For that, you’ll need to look at message archives.

The value of proper auditing

For organizations in which users store sensitive information in their email, there are several advantages to enabling Exchange 2010 SP1 mailbox auditing. It allows you to oversee email activities that occur within the Exchange infrastructure. Auditing also enables you to review administrative actions, check on the appropriateness of delegated access and provide information for compliance reviews, external audits and discovery requests. 

However, to comply with any regulations, contractual obligations or other legal requirements, work with the human resources department and legal counsel to set up a policy stating whom and what data you will audit -- then document that plan and follow it without exception. Auditing is valuable, but its value is lost if it’s improperly configured or abused.

About the author:
An aficionado of capsaicin and Coffea canephora -- but not together -- Ed Fisher has been getting his geek on full-time since 1993 and has worked with information technology in some capacity since 1986. Stated simply, if you need to get information securely from point A to point B, he's your guy. He's like "The Transporter," but for data … and without the car … and with a little more hair. You can read more of his stuff at retrohack.com. Fisher recently took a position with Microsoft.

Dig Deeper on Microsoft identity and access management

Cloud Computing
Enterprise Desktop
Virtual Desktop
Close