Understanding Mailbox Access Auditing with Exchange Server 2007 Service Pack 3
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007 SP2
Access Auditing is implemented in the Microsoft Exchange Store.exe process, which is the access point for mail in mailbox databases. Access Auditing represents a set of Event log events that are designed to give administrators information about mailbox resources that have been opened by users. These events are new. They do not modify existing events, which may be used for other purposes.
Access Auditing is enabled by a set of Diagnostics Logging categories for the Microsoft Exchange IS resource, with each category corresponding to a different type of resource access. Each category can be enabled independently. This allows an administrator to choose the level of information (and the corresponding load from recording it) that is appropriate for the particular organization.
The Diagnostics Logging categories include the following:
Folder Access: lets you log events that correspond to opening folders, such as the Inbox, the Outbox, or the Sent Items folders
Message Access: lets you log events that correspond to explicitly opening messages
Extended Send As: lets you log events that correspond to sending a message as a mailbox-enabled user
Extended Send On Behalf Of: lets you log events that correspond to sending a message on behalf of a mailbox-enabled user
Each category supports logging levels from zero (not enabled) to five (maximum logging). Higher logging levels increase the amount and detail of logged data.
Comparing Access Auditing to Windows Auditing
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.
Exchange Auditing Event Log
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 3 (SP3), 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
Access Auditing by Event Log Level
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.
Common Audit Event Information
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 Auditing
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.
Basic Events Logging and All Events Logging
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
| Logging level | Administrator rights required | Acting user | Mailbox | Result |
|---|---|---|---|---|
0 |
Not applicable |
Not applicable |
Not applicable |
Nothing |
1 |
No |
Not applicable |
Not applicable |
Nothing |
1 |
Yes |
Not applicable |
Not applicable |
Basic events |
2 |
Not applicable |
UserA |
UserA |
Nothing |
2 |
Not applicable |
UserA |
UserB |
Basic events |
3 |
Not applicable |
UserA |
UserA |
Basic events |
3 |
Not applicable |
UserA |
UserB |
Basic events |
4 |
Not applicable |
UserA |
UserA |
Nothing |
4 |
Not applicable |
UserA |
UserB |
All events |
5 |
Not applicable |
UserA |
UserA |
All events |
5 |
Not applicable |
UserA |
UserB |
All events |
When Folder Access auditing is enabled, events that resemble the following are logged:
Event Id:10100 Severity: Informational Facility: AccessAuditing The folder %1 in Mailbox '%3' was opened by user %4 Display Name:%2 Accessing User: %5 Mailbox: %6 Administrative Rights:%7 Identifier:%8 Client Information (if Available): Machine Name: %9 Address: %10 Process Name: %11 Process Id: %12 Application Id: %13 |
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
Log name: Exchange Auditing Source: MSExchangeIS Auditing Event ID: 10100 Task Category: Mailbox Access Auditing Level: Information Keywords: Classic Description: The folder /Inbox in Mailbox 'UserA' was opened by user CONTOSO\UserB Display Name: Inbox Accessing User: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB Administrative Rights: false Identifier: 00000000318A00E0 Client Information (if Available) Machine Name: <ClientName> Address: <IP Address> Process Name: OUTLOOK.EXE Process Id: 0 Application Id: N/A |
Message Access Auditing
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
| Logging level | Administrator rights required | Acting user | Mailbox | Result |
|---|---|---|---|---|
0 |
Not applicable |
Not applicable |
Not applicable |
Nothing |
1 |
No |
Not applicable |
Not applicable |
Nothing |
1 |
Yes |
Not applicable |
Not applicable |
Basic events |
2 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
2 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
3 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
3 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
4 |
Not applicable |
UserA |
UserA |
Nothing |
4 |
Not applicable |
UserA |
UserB |
All events |
5 |
Not applicable |
UserA |
UserA |
All events |
5 |
Not applicable |
UserA |
UserB |
All events |
When Message Access auditing is enabled, events that resemble the following are logged:
Event ID:10102 Severity: Informational Facility: AccessAuditing The message %1 in Mailbox %3 was opened by user %4 Folder: %2 Accessing User: %5 Mailbox: %6 Administrative Rights:%7 Identifier:%8 Client Information (if Available): Machine Name: %9 Address: %10 Process Name: %11 Process Id: %12 Application Id: %13 |
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
Log name: Exchange Auditing Source: MSExchangeIS Auditing Date: <date> Event ID: 10102 Task Category: Mailbox Access Auditing Level: Information Keywords: Classic Description: The message <BA15978123F9C848B820A8C5C1DC29B5F06B6F@Server.Contoso.com> in Mailbox UserA was opened by user CONTOSO\UserB Folder: /Inbox Accessing User: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB Administrative Rights: false Identifier: 00000000318A00E0 Client Information (if Available) Machine Name: <ClientName> Address: <IP Address> Process Name: OUTLOOK.EXE Process Id: 0 Application Id: N/A |
Extended Send As Auditing
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
| Logging level | Administrator rights required | Acting user | Mailbox | Result |
|---|---|---|---|---|
0 |
Not applicable |
Not applicable |
Not applicable |
Nothing |
1 |
No |
UserA |
UserA |
Not applicable |
1 |
Yes |
UserA |
UserB |
All events |
2 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
2 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
3 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
3 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
4 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
4 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
5 |
Not applicable |
UserA |
UserA |
Not applicable |
5 |
Not applicable |
UserA |
UserB |
All events |
When Extended Send As auditing is enabled, events that resemble the following are logged:
Event Id:10106 Severity: Informational Facility: SendAs %1 sent a message as %2 Message Id:%3 Account Name: %4 Accessing User: %5 Mailbox: %6 Administrative Rights:%7 Identifier:%8 Client Information (if Available): Machine Name: %9 Address: %10 Process Name: %11 Process Id: %12 Application Id: %13 |
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
Log name: Exchange Auditing Source: MSExchangeIS Auditing Date: <date> Event ID: 10106 Task Category: Send As Level: Information Keywords: Classic Description: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB sent a message as /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserA Message Id: <BA15978123F9C848B820A8C5C1DC29B5038E9D50@Server.Contoso.com> Mailbox: UserB Account Name: CONTOSO\UserB Accessing User: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB Mailbox:<NULL> Administrative Rights: false Identifier: 00000000317A7130 Client Information (if Available) Machine Name: <ClientName> Address: <IP Address> Process Name: OUTLOOK.EXE Process Id: 0 Application Id: N/A |
Extended Send On Behalf Of Auditing
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
| Logging level | Administrator rights required | Acting user | Mailbox | Result |
|---|---|---|---|---|
0 |
Not applicable |
Not applicable |
Not applicable |
Nothing |
1 |
No |
UserA |
UserA |
Not applicable |
1 |
Yes |
UserA |
UserB |
All events |
2 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
2 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
3 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
3 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
4 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
4 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
5 |
Not applicable |
UserA |
UserA |
Not applicable |
5 |
Not applicable |
UserA |
UserB |
All events |
When Extended Send On Behalf Of auditing is enabled, events that resemble the following are logged:
Event Id:10104 Severity: Informational Facility: SendOnBehalfOf %1 sent a message on behalf of %2 Message Id:%3 Account Name: %4 Accessing User: %5 Mailbox: %6 Administrative Rights:%7 Identifier:%8 Client Information (if Available): Machine Name: %9 Address: %10 Process Name: %11 Process Id: %12 Application Id: %13 |
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
Log name: Exchange Auditing Source: MSExchangeIS Auditing Date: <date> Event ID: 10104 Task Category: Send On Behalf Of Level: Information Keywords: Classic Description: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB sent a message on behalf of /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserA Message Id: <BA15978123F9C848B820A8C5C1DC29B50406C46E@Server.Contoso.com> Mailbox: UserB Account Name: CONTOSO\UserB Accessing User: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB Mailbox:<NULL> Administrative Rights: false Identifier: 0000000031718B30 Client Information (if Available) Machine Name: <ClientName> Address: <IP Address> Process Name: OUTLOOK.EXE Process Id: 0 Application Id: N/A |
Bypass Auditing Rights
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:
get-mailboxdatabase -Identity "Server01\StorageGroup01\MailboxDatabase01" | Add-ADPermission -User example\ServiceAccount -ExtendedRights ms-Exch-Store-Bypass-Access-Auditing -InheritanceType All
Choosing an auditing strategy
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
At diagnostic logging level one (1), all categories log only events in which the acting users exercise administrative rights to access a mailbox. Organizations that use Exchange Access Auditing must keep in mind that by default, Exchange administrators can modify the diagnostic logging levels or clear the Exchange Access Auditing event log. Also, Exchange administrators may grant the Bypass Auditing right. Organizations that want to audit only Exchange administrators must implement a split permissions model to prevent the Exchange administrators from modifying logging levels, security descriptors or from clearing the event log.
Auditing Only Access from One Mailbox to Another
At logging levels two (2) and four (4), folder and message access auditing log events when one mail-enabled user opens another mailbox-enabled user's folder or message. This logging level does not detect all types of shared mailbox access. A shared mailbox or a resource mailbox is associated with a disabled user account, and then additional users are granted access to the mailbox. If the additional users are not mailbox-enabled, access to the shared mailbox or resource mailbox is not logged at diagnostic level two (2) or four (4).
Auditing Basic Events Versus All Events
At diagnostic levels two (2) and three (3), Folder Access auditing logs Basic events or All events. Basic events only include folders that are subfolders of the IPM subtree. Or folders that are second rank or higher subfolders of the non-IPM subtree (for applications that cache data in these locations). Enabling higher diagnostic levels means that more events will be logged. This additional logging increases the load on the server. Also, the increased logging level could log false positive events such as free/busy cache lookup operations. Free/busy cache lookup operations access the root of the mailbox. These are non-malicious lookup operations.
To decide whether an organization needs to audit Basic or extended events requires knowing what applications the organization has deployed and where sensitive user data is stored. If an application stores sensitive user data in an immediate child folder of the non-IPM subtree, only All events (diagnostic level four or five) logging will log access to the particular folders.
Limitations of Access Auditing
Extended client information
Client programs that do not send the extended client information block generate auditing events that do not populate the client information. These are versions of Outlook that are earlier than Outlook 2003.
Folder Contents Tables
Message Access Auditing cannot detect all the information that is retrieved from a mailbox. This is because access to the folder contents table which is a summary table of commonly used message properties, does not require the user to open a message. The message subject, recipient information, and many basic message properties are part of the message folder table. This information may be read without opening a message and therefore, without generating a message access event.
Security Considerations
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
If a user is granted the Bypass Auditing extended right, the user is not audited. We recommend that you monitor Active Directory ACLs to verify that a user who has Write Security Descriptor access does not grant themselves the Bypass Auditing right.
Domain Administrators
Windows grants Domain Administrators all extended rights. A domain administrator account should not be mail-enabled if all mailbox access must be audited.
Diagnostic Logging Changes
Because the diagnostic logging levels control the events that are logged to the Exchange Auditing event log, changing the diagnostic logging level for particular categories may give you unexpected results. For example, certain expected events may no longer be logged. Also, because the Store.exe process cannot identify which user changed the logging levels or even whether the logging levels were changed from an earlier session, the Store.exe process is unable to identify changes to the auditing configuration.
Local Administrators
The Exchange Auditing log contains a record of audited events and the Event Viewer has an ACL that prevents typical users from clearing the event log. If a local administrator took ownership of the appropriate registry key, reset the CustomSD value, and then restarted the server, the administrator could clear the Exchange Auditing log.
Performance Considerations
The Exchange Auditing event log may be a high traffic event log, depending on the server configuration and user actions. Therefore, we recommend that the Exchange Auditing event log be located on a dedicated hard disk drive that has sufficient space and that can support fast write operations.
For more information about how to configure Exchange Auditing event logs, see the following topics:
How to Configure Automatic Archiving of Exchange Auditing Event Logs
How to Configure the Size and Location of Exchange Auditing Event Logs
For More Information
For more information about how to modify diagnostics logging levels in Exchange, see How to Change Logging Levels for Exchange Processes.