The Microsoft Exchange Information Store service supports Windows NT Audit events based on system policy. These events reflect each instance of an opened object, and are recorded in the Security event log. This kind of logging is the highest auditing level that is available, and offers extensive records of object access. The goal of Access Auditing is not to replace Windows auditing. Windows auditing focuses on object open and object close events. Access Auditing implicitly ignores certain object events in favor of events that represent real user data that is being accessed.

Consider the following example:

With Windows auditing, the primary focus is "Logons to Mailbox." In Exchange, a logon event is the act of binding to data that then lets the client try to open folders. The logon object itself does not grant access to specific data. There, it represents a false focal point for auditing.

Access Auditing focuses on events that reflect a client gaining access to actual messaging data, or exercising rights that affect messaging data. For example:

• By opening a folder, the client gains access to actual data.
  
  
• By opening a message, the client gains access to actual data.
  
  

Logging on to a mailbox is an implicit operation to gain access to the folder. Access Auditing lets you disregard operations that occur below the IPM subtree, such as free/busy cache lookup operations. Also, Access Auditing ignores access by Exchange system processes. Access Auditing can also log only a particular class or classes of access. The tradeoffs between Windows auditing and Access Auditing are in the configuration process. Windows Auditing can be set by policy. Access Auditing is controlled by diagnostic categories for the Microsoft Exchange information store.

Important:
Access Auditing does not audit message deletions, only message access.

The volume of logged audit events is directly related to the load on a server together with the number of user operations of the audited type occurring at any time. Because the Application log is also a source of diagnostic and troubleshooting data, Access Auditing does not log events to the Application log. In Exchange 2007 Service Pack 2 (SP2), installing the Mailbox server role on a server creates a new event log. This is the Exchange Auditing event log. By default, the Exchange Auditing event log is located under \Exchange Server\Logs\AuditLogs. On a Windows Server 2008-based computer, this event log is located under Applications and Services Logs\Exchange Auditing. The default file location for this log file is %PROGRAMFILES%\Exchange Server\Logging\Auditlogs. The default access control list (ACL) on the Exchange Auditing log allows the following permissions:

• Exchange Recipient Administrators: Read and Clear access
  
  
• Exchange Organization Administrators: Read and Clear access
  
  
• Exchange Servers: Read and Write access
  
  
• Local Service All Access
  
  

To change the default ACL list, you have to update the CustomSD value in the registry. Update the CustomSD value to include the group or user that you want to access the Exchange Auditing Event Log. The CustomSD value is located under the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Exchange Auditing

Note:
The ACL that is stored in the CustomSD value is stored in SDDL format. For more information about how to change the permissions on Windows Event Logs and more information about SDDL formats, view the topic Event Log.

To obtain a user or group SID value, use the PsGetSid tool from Windows Sysinternals. For more information about this tool, see PsGetSid v1.43.

Or, you can use PowerShell to obtain the SID. For example, to obtain the SID for a user, use the following command:

$objUser = New-Object System.Security.Principal.NTAccount("Exchange Organization Administrators")

$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])

$strSID.Value

For events that represent access by one user to another user's mailbox, the following general guidelines describe which events are logged at each diagnostic logging level:

• At logging level zero (0), nothing is logged.
  
  
• At logging level one (1), only actions for which the acting user invoked administrative privileges are logged.
  
  
• At logging level two (2) and four (4) only access from one mailbox-enabled user to another mailbox is logged.
  
  
• At logging level three (3) and five (5) access from any user to any mailbox is logged.
  
  

Auditing events that reflect actions that are based on a user's logon expose a common set of information. Extended client data is only available when the program supports sending extended client data. Outlook 2003 and later versions of Outlook send extended client data.

Folder Access events indicate the successful opening of a folder in a mailbox. Folder Access auditing provides different events at different auditing levels. This lets an administrator select the appropriate logging level for his or her auditing requirements. The following list describes the events that are logged at each logging level:

• At level zero (0) nothing is logged. At this logging level, no events are logged in response to folder access.
  
  
• At level one (1) only access using Administrative rights is logged.
  
  
• At logging level two (2) and four (4) only access by one mailbox-enabled user to another mailbox-enabled user is logged.
  
  
• At logging level three (3) and five (5) access to folders by any user is logged.
  
  

The mailbox folder hierarchy consists of a non-IPM subtree, which houses folders for application use, such as search folders, together with an IPM subtree which houses folders that are viewed and used by users, such as the Inbox or Sent Items folders. Basic events represent typical access to the folders that the user sees. These folders are generally defined as "mail folders." Access to a folder is logged at the basic level if the folder is a child folder of the IPM subtree. All Events logging includes the folders that are not visible to the user, such as the mailbox root folder and non-IPM subtree folders. Administrators who want to audit access to "mail folders" such as the Inbox folder, Sent Items folder, or Drafts folder do not have to enable higher level event logging. The following table illustrates the events that are logged at each logging level for the Folder Access category.

Category: Folder Access

When Folder Access auditing is enabled, events that resemble the following are logged:

The parameters in this event message represent the following items:

• %1 represents the URL name of the folder. This provides you with the full path of the folder.
  
  
• %2 represents the display name of the folder. You can use the display name together with the folder path to differentiate between multiple folders that have the same name.
  
  

Common Audit Event Information:

• %3 represents the legacyDN of the opened mailbox.
  
  
• %4 represents the user name of the user who authenticated to the information store.
  
  
• %5 represents the legacyDN of the user who opened the object.
  
  
• %6 represents the legacyDN of the mailbox.
  
  
• %7 is a flag that indicates whether administrator rights were used to open the folder.
  
  
• %8 is a relatively unique identifier. You can use this parameter to correlate a series of actions over a short period.
  
  

Client Information:

• %9 represents the computer name.
  
  
• %10 represents the address as composed by the client. This value is dependent on the protocol that was used to connect to the server. Local connections (connections from the same computer) use the computer name. Exchange binary files send the IPV6 address, if possible and the IPV4 address if they cannot send the IPV6 address. If an IP address is sent, it represents the IP address as the client identifies it. For clients behind a NAT gateway, the IP address may not provide a distinguishing address.
  
  
• %11 represents the process name. This is the application binary file that made the call to access the object.
  
  
• %12 represents the process ID (PID). This is a numeric identifier for the particular process.
  
  
• %13 represents the application ID. This is a value that the client sets to allow differentiation between instances of Powershell.exe. Or, an event to allow an add-in in a process to be labeled as an add-in during operations to access the server.
  
  

Example folder access event log entry

Message Access events indicate the successful opening of a message in the Exchange information store. Messages do not support Basic Events. All message access is audited based on the logging level that is set by the administrator. The following table illustrates the events that are logged at each logging level for the Message Access category.

Category: Message Access

When Message Access auditing is enabled, events that resemble the following are logged:

The parameters in this event message represent the following items:

• %1 represents the Internet Message ID of the message being opened.
  
  
• %3 represents the mailbox where the message is saved.
  
  
• %4 represents the user who authenticated to the information store.
  
  
• %5 represents the legacyDN of the user who opened the message.
  
  
• %6 represents the legacyDN of the mailbox.
  
  
• %7 is a flag that indicates whether administrator rights were used to open the message.
  
  
• %8 is a relatively unique identifier which can be used to correlate a set of actions over a short period.
  
  

Client Information

• %9 represents the computer name.
  
  
• %10 represents the address as composed by the client. This value is dependent on the protocol that was used to connect to the server. Local connections (connections from the same computer) use the computer name. Exchange binary files send the IPV6 address, if possible and the IPV4 address if they cannot send the IPV6 address. If an IP address is sent, it represents the IP address as the client identifies it. For clients behind a NAT gateway, the IP address may not provide a distinguishing address.
  
  
• %11 represents the process name. This is the application binary file that made the call to access the object.
  
  
• %12 represents the process ID (PID). This is a numeric identifier for the particular process.
  
  
• %13 represents the application ID. This is a value that the client sets to allow differentiation between instances of Powershell.exe. Or, an event to allow an add-in in a process to be labeled as an add-in during operations to access the server.
  
  

Example message access event log entry

Extended Send As events indicate that one user sent a message as another user. Extended Send As events do not support Basic events and only apply when one user sends a message as another user. At logging level one (1), an event is only recorded if the user used administrator privileges to open the mailbox, and then sent a message as another user. At logging level five (5), an event is recorded if one user sends a message as another user. The following table illustrates the events that are logged at each logging level for the Extended Send As category.

Category: Extended Send As

When Extended Send As auditing is enabled, events that resemble the following are logged:

The parameters in this event message represent the following items:

• %1 represents the legacyDN of the sending user.
  
  
• %2 represents the legacyDN of the user who was Sent As.
  
  
• %3 represents the Internet message ID of the message.
  
  
• %4 represents the user who authenticated to the information store.
  
  
• %5 represents the legacyDN of the accessing user.
  
  
• %6 represents the legacyDN of the mailbox.
  
  
• %7 is a flag that indicates whether administrative rights were used to send the message.
  
  
• %8 is a relatively unique identifier that can be used to correlate events over a short period.
  
  

Client Information

• %9 represents the computer name.
  
  
• %10 represents the address as composed by the client. This value is dependent on the protocol that was used to connect to the server. Local connections (connections from the same computer) use the computer name. Exchange binary files send the IPV6 address, if possible and the IPV4 address if they cannot send the IPV6 address. If an IP address is sent, it represents the IP address as the client identifies it. For clients behind a NAT gateway, the IP address may not provide a distinguishing address.
  
  
• %11 represents the process name. This is the application binary file that made the call to access the object.
  
  
• %12 represents the process ID (PID). This is a numeric identifier for the particular process.
  
  
• %13 represents the application ID. This is a value that the client sets to allow differentiation between instances of Powershell.exe. Or, an event to allow an add-in in a process to be labeled as an add-in during operations to access the server.
  
  

For more information about how to grant the Send As permission, see How to Grant the Send As Permission for a Mailbox.

Example Send As event log entry

Extended Send On Behalf Of events indicate that one user sent a message on behalf of another user. Extended Send On Behalf Of events do not support Basic events and are only applicable when one user sends a message on behalf of another user. At level one (1), an event is recorded only if the user used administrator privileges to open a mailbox and then send a message on behalf of another user. At logging level five (5), an event is logged if one user sends a message on behalf of another user. The following table illustrates the events that are logged at each logging level for the Extended Send On Behalf Of category.

Category: Extended Send On Behalf Of

When Extended Send On Behalf Of auditing is enabled, events that resemble the following are logged:

The parameters in this event message represent the following items:

• %1 represents the legacyDN of the sending user.
  
  
• %2 represents the legacyDN of the user who was Sent On Behalf Of.
  
  
• %3 represents the Internet message ID of the message.
  
  
• %4 represents the user who authenticated to the information store.
  
  
• %5 represents the legacyDN of the accessing user.
  
  
• %6 represents the legacyDN of the mailbox.
  
  
• %7 is a flag that indicates whether administrative rights were used to send the message.
  
  
• %8 is a relatively unique identifier that can be used to correlate events over a short period.
  
  

Client Information

• %9 represents the computer name.
  
  
• %10 represents the address as composed by the client. This value is dependent on the protocol that was used to connect to the server. Local connections (connections from the same computer) use the computer name. Exchange binary files send the IPV6 address, if possible and the IPV4 address if they cannot send the IPV6 address. If an IP address is sent, it represents the IP address as the client identifies it. For clients behind a NAT gateway, the IP address may not provide a distinguishing address.
  
  
• %11 represents the process name. This is the application binary file that made the call to access the object.
  
  
• %12 represents the process ID (PID). This is a numeric identifier for the particular process.
  
  
• %13 represents the application ID. This is a value that the client sets to allow differentiation between instances of Powershell.exe. Or, an event to allow an add-in in a process to be labeled as an add-in during operations to access the server.
  
  

Example Send on Behalf Of event log entry

Applications that log on to multiple user mailboxes as a trusted service account generate a higher load for auditing. This is because each mailbox access operation by the service account may be logged.

In Exchange 2007 SP2, a new extended right is added to the schema. This is the Bypass Auditing right. The Bypass Auditing right prevents logging of actions by the user account to which the right is granted. Therefore, you should not grant the Bypass Auditing right to users who you want to audit.

Note:

By default, Windows grants the Domain Administrators group all extended rights. A domain administrator should not be mail-enabled if you have to audit all mailbox access. To allow the audit of domain administrators, you can deny the Bypass Auditing right at the Exchange Organization level. This allows the audit of Domain Administrator accounts that are mail-enabled. For example, to deny the bypass auditing right for the Domain Admins Group, run the following command from the Exchange Management Shell: Add-ADPermission -Identity "CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" -User "Domain\Domain Admins" -AccessRights ExtendedRight -ExtendedRights Ms-Exch-Store-Bypass-Access-Auditing -Deny:$true

You can use the Add-ADPermission cmdlet to grant the appropriate right for eachmailbox database th bypass auditing for specific service accounts. For example, to grant the Example\ServiceAccount the Bypass Access Auditing right, run the following command from the Exchange Management Shell:

	Copy Code
get-mailboxdatabase -Identity "Server01\StorageGroup01\MailboxDatabase01" | Add-ADPermission -User example\ServiceAccount -ExtendedRights ms-Exch-Store-Bypass-Access-Auditing -InheritanceType All

Auditing mailbox access in Exchange is a complex process that is dependent on the intended use of the information, the organization's particular auditing requirements, the applications that are in use, and the level of administrator trust.

Windows NT Security Auditing is the best solution for organizations that have the highest level of auditing requirements. This form of auditing logs access to all objects by all users and stores the logged information in the Security log.

Exchange Access Auditing is appropriate for organizations that do not require Windows Auditing security. Exchange Access Auditing is appropriate for organizations that want to audit the following:

• Only administrators who exercise Administrator rights to open mailboxes.
  
  
• Only cases where one user opens another user's mailbox.
  
  
• Only cases where the accessed resource is located in the IPM subtree.
  
  

Auditing Administrator access using administrator privileges

Auditing Only Access from One Mailbox to Another

Auditing Basic Events Versus All Events

Extended client information

Folder Contents Tables

When an organization selects Access Auditing for its auditing requirements, a number of security scenarios must be considered to evaluate the final cost of fully securing access to the audit logs and of protecting the log content.

Bypass Auditing

Domain Administrators

Diagnostic Logging Changes

Local Administrators

Performance Considerations

For more information about how to modify diagnostics logging levels in Exchange, see How to Change Logging Levels for Exchange Processes.