Exchange 2007 Mailbox Access Auditing

[LEFT][CODE]http://www.msexchange.org/articles_tutorials/exchange-server-2007/compliance-policies-archiving/exchange-2007-mailbox-access-auditing-part1.html[/CODE]

[IMG]http://www.msexchange.org/img/upl/neil-20081231491807209.jpg[/IMG]
[B][B]Neil Hobson[/B][/B]

[B][SIZE=3]PART-1[/SIZE][/B]

[B]Important:[/B]
Before you read this article any further, please read this blog post on the Exchange Team Blog:
[URL="http://msexchangeteam.com/archive/2010/01/11/453755.aspx"]Raising diagnostic logging for Message Access might cause calendar issues with Exchange 2007 SP2[/URL]
In a previous article [URL="http://www.msexchange.org/tutorials/Auditing-Mailbox-Access-Exchange-System-Manager-Event-Viewer.html"]here[/URL] on MSExchange.org, I covered how to perform basic auditing of mailbox access in Exchange 2003 using the Exchange System Manager and the event viewer. If you have already read that article, you may well remember that several limitations of this auditing process were exposed. For example, the [I]Last Logged On By[/I] column in Exchange System Manager often references a Windows account that is different to the account that actually owns the mailbox. Furthermore, if the diagnostics logging level for access control is increased, event log entries will often be recorded that show one particular user accessing a mailbox for which they are not the primary Active Directory account. Although all of this may initially sound suspicious, it was often the case that someone had merely accessed someone else’s calendar folder, thereby triggering the event log entry to be created or the Last Logged On By column to update accordingly. This issue was often compounded by service accounts for applications such as antivirus and backup that had the need to log into all mailboxes. Auditing Exchange in a full and deep manner was therefore quite difficult.
Enter Exchange 2007 Service Pack 2 and the new mailbox access auditing feature. This is a brand new feature that allows the administrator of an Exchange organization to implement a new set of diagnostics logging categories that allow for detailed auditing event log entries to be recorded when various resources are accessed. The resources accessed that can be logged include messages, folders and the ability for users to send as another user, either directly or using the [I]send on behalf of[/I] feature. In this two-part article series we will look at how to enable this new feature and give examples of what to expect to see in the event log.
[B]The Exchange Auditing Event Log
[/B]

Rather than record these new event log entries into the application event log, the mailbox access auditing feature writes these event log entries into a new event log called the Exchange Auditing event log. You can see this new event log in Figure 1 although it is currently empty; we will see how the new events look as we go through this article. In my lab environment running Exchange 2007 SP2, the new event log file called [I]ExchangeAuditing.evtx[/I] is stored in the [I]\Program Files\Exchange Server\Logs\AuditLogs[/I] folder.
[IMG]http://www.msexchange.org/img/upl/image0021264797543152.jpg[/IMG]
[B]Figure 1:[/B] Exchange Auditing Event Log
[B]Enabling Mailbox Access Auditing
[/B]

Let us look at how we can access the configuration area for mailbox access auditing. We will use the Exchange Management Console first and then move on to using the Exchange Management Shell later in part two of this article series. If you run the Exchange Management Console after applying Exchange 2007 Service Pack 2, you will likely notice a few subtle changes that let you know that Service Pack 2 has been applied. The first is the fact that you can see an additional action pane menu item when highlighting one of your Exchange 2007 servers. In Figure 2, you can see the new [I]Manage Diagnostic Logging Properties[/I] menu option.
[IMG]http://www.msexchange.org/img/upl/image0041264797543183.jpg[/IMG]
[B]Figure 2:[/B] Manage Diagnostics Logging Properties Menu Option
To configure mailbox access auditing on a particular mailbox server, first select that server in the Exchange Management Console and then choose the [B]Manage Diagnostics Logging Properties[/B] menu option from the action pane. Doing so will bring up the [I]Manage Diagnostics Logging Properties[/I] screen as you can see in Figure 3. In this screen, expand the [B]MSExchangeIS[/B] category and then expand the [B]9000 Private[/B] category.
[IMG]http://www.msexchange.org/img/upl/image0061264797543183.jpg[/IMG]
[B]Figure 3:[/B] Manage Diagnostics Logging Properties Configuration Screen
Under the [B]MSExchangeIS\9000 Private[/B] category you will see many different areas for which you can configure the diagnostics logging level. As this article is focused on the mailbox access auditing feature, the particular categories that we are interested in are, in order that they are presented in the configuration screen, [I]Extended Send As[/I], [I]Extended Send On Behalf Of[/I], [I]Folder Access[/I] and [I]Message Access[/I]. Let’s first look at the Folder Access category to see what happens when one user accesses the inbox folder of another user. First, select the [B]Folder Access[/B] category in the configuration screen and then choose the relevant diagnostics logging level that you want to set this to. We’ll set this to the [B]Medium[/B] level as you can see in Figure 4. We’ll discuss what all the various diagnostics logging levels mean later in this article but for the moment you should understand that setting the level to medium will log basic events when a user accesses folders of their own mailbox or someone else’s mailbox. Once the configuration level has been chosen, click the [B]Configure[/B] button.
[IMG]http://www.msexchange.org/img/upl/image0081264797644277.jpg[/IMG]
[B]Figure 4:[/B] Folder Access Diagnostics Logging Level Modification
If all goes well, you should be presented with a completion screen indicating that the event log level has been successfully set. However, the configuration is not complete yet as you must restart the Microsoft Exchange Information Store service before the changes will take effect.
[B]Auditing Folder Access
[/B]

Let us now look at a situation where one user called Mark first logs into his own mailbox and then proceeds to open the inbox folder of another user called Rob. In this particular example, Mark has already been allowed by the administrator to open Rob’s mailbox and therefore has been granted [I]Full Access[/I] permission against Rob’s mailbox. Consequently, access by Mark to Rob’s mailbox is to be expected but nevertheless access is also to be recorded. Now that we have configured the Folder Access category in the Manage Diagnostics Logging Properties configuration screen, let us see what information is logged into the Exchange Auditing event log. The moment Mark logs into his own mailbox, you will see many new event log entries added to the Exchange Auditing log as you can see from Figure 5. In Figure 5, you can see that these new event log entries have an event ID of [I]10100[/I], a source of [I]MSExchangeIS Auditing[/I] and a category of [I]Mailbox Access Auditing[/I].
[IMG]http://www.msexchange.org/img/upl/image0101264797644293.jpg[/IMG]
[B]Figure 5:[/B] Exchange Auditing Event Log Entries
An example of one of these event log entries is shown below in Figure 6 where you can see that the description of the event log reveals that Mark has accessed his own inbox folder. Other fields that you can see included within the event description include the display name of the folder as it appears in Outlook or OWA, the distinguished name of the accessing user, whether the access was performed with administrative rights and at the bottom the start of additional client information. We’ll have a closer look at the additional client information in part two of this article.
[IMG]http://www.msexchange.org/img/upl/image0111264797644293.jpg[/IMG]
[B]Figure 6:[/B] Event ID 10100 – Own Mailbox Access
When Mark accesses Rob’s inbox folder a new event log entry is recorded and obviously this has the same event ID, source and category as the entry recorded when Mark accessed his own mailbox. You can see this additional event log entry in Figure 7. Of course, with Full Mailbox Access permissions against Rob’s mailbox, Mark is free to access any folder he likes and as you might expect the auditing will log access to any folder, including any custom folders that Rob has created.
[IMG]http://www.msexchange.org/img/upl/image0121264797644308.jpg[/IMG]
[B]Figure 7:[/B] Event ID 10100 – Different Mailbox Access
[B]Summary
[/B]

That completes part one of this two-part article series where we have seen which Exchange auditing categories are available for us to record as well as sample event log entries that are recorded when a user accesses their own mailbox or the mailbox of another user. In part two we will complete our look at this new feature of Exchange 2007 Service Pack 2 by looking at controlling the feature using the Exchange Management Shell as well as the event logs recorded by the Message Access and Send As logging categories
[/LEFT]

[LEFT][CODE]http://www.msexchange.org/articles_tutorials/exchange-server-2007/compliance-policies-archiving/exchange-2007-mailbox-access-auditing-part2.html[/CODE]

[B][SIZE=3]PART-2[/SIZE][/B]

[B]Introduction[/B]

This is the second and final part of an article series on the new mailbox access auditing feature introduced in Exchange 2007 Service Pack 2. In part one we looked at enabling the feature using the Exchange Management Shell and then went on to looking at the events recorded when a user accesses their own mailbox as well as the mailbox of a different user. Here, in part two, we will complete our look at this new feature by covering how to use the Exchange Management Shell to enable auditing as well as looking at the events recorded by the Message Access and Send As logging categories. However, we will start part two by looking at how we can bypass auditing for specific accounts.
[B]Bypassing Auditing
[/B]

In part one of this two-part article series we saw how a new Exchange auditing event log entry was created when one user accessed the mailbox of another user. After reading this, you may have wondered what happens in those cases where the service account of an application, such as a backup application, accesses all mailboxes as part of its normal operations. Surely in such cases many Exchange auditing event log entries will be created as the application does it work? Fortunately, this situation has been catered for via the [I]Bypass Auditing[/I] right which is an extension to the schema performed during the installation of Exchange 2007 Service Pack 2. In the aforementioned situation, the Bypass Auditing right is granted to the account used by the backup application. By granting the Bypass Auditing right to an account, no logging events will occur for this account.
The Bypass Auditing right needs to be granted to an account against each relevant mailbox database. If you have spread your users’ mailboxes randomly across all databases then clearly you will need to ensure that this right is granted against all mailbox databases. To grant the Bypass Auditing right you can use the [I]Add-ADPermission[/I] cmdlet. In the example cmdlet below, the service account [I]neilhobson\svc-backup[/I] has been granted the Bypass Auditing right against all mailbox databases because the results of the [I]Get-MailboxDatabase[/I] cmdlet, which will return all databases, has been piped into the cmdlet to add the necessary rights. Here is the example cmdlet:
[I]Get-MailboxDatabase | Add-ADPermission -User neilhobson\svc-backup –ExtendedRights ms-exch-store-bypass-access-auditing –InheritanceType all[/I]
You can see the results of running this cmdlet in Figure 8 where the right has been granted against all four mailbox databases on the server called E2K7.
[IMG]http://www.msexchange.org/img/upl/image0021265382414445.jpg[/IMG]
[B]Figure 8:[/B] Adding The Bypass Auditing Right
[B]Management Shell Configuration
[/B]

Also in part one of this article we saw how to use the Exchange Management Console to configure the diagnostics logging level. Obviously it is also possible to use the Exchange Management Shell to do this and so here we will take a look at how to do this.
In Figure 4 in part one of this article, we saw how to set the [I]Folder Access[/I] diagnostics logging category that is found under the [I]MSExchangeIS\9000 Private[/I] category. To do the same thing in the Exchange Management Shell, you must first use the [I]Set-Location[/I] cmdlet to point to the registry location that is used to alter the diagnostics logging level. In PowerShell, the Set-Location cmdlet is used to navigate through not only the file system, but also the registry. The full registry path required to set the diagnostics logging level is:
[I]HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\Diagnostics\9000 Private[/I]
In Figure 9 below you can see the various values that are present in this registry key; we will refer back to these a little later in this article.
[IMG]http://www.msexchange.org/img/upl/image0041265382414742.jpg[/IMG]
[B]Figure 9:[/B] The 9000 Private Registry Key
The first cmdlet you need to run is shown immediately below. This sets the Exchange Management Shell so that it’s now working in the specified registry location.
[I]Set-Location “HKLM:\System\CurrentControlSet\Services\MSExchangeIS\Diagnostics\9000 Private”[/I]
Once you have executed this cmdlet, your cursor should change from the regular folder prompt to be the registry location prompt. In Figure 9 above you can see that the [I]Folder Access[/I] category has a full value name of [I]9074 Folder Access[/I], with a specified [I]Data[/I] value of 0. The value name is important as this is the name we now need to specify when changing the data value. To alter the value of this registry setting we need to use the [I]Set-ItemProperty[/I] cmdlet with the [I]Path[/I], [I]Name[/I] and [I]Value[/I] parameters. For the path, we just need to use the local path which is specified as a period (.). For the name, we need to use the value name of [I]9074 Folder Access[/I] as discussed previously. Finally, for the value we need to specify our required diagnostics logging level which in part one of this article was specified as [I]Medium[/I].
To set the diagnostics logging level to a value of [B]Lowest[/B], use a value of [B]0[/B].
[I]For a level of [B]Low[/B], use [B]1[/B].[/I]
[I]For the [B]Medium[/B] level, use [B]3[/B].[/I]
[I]Finally, for the [B]High[/B] level, use [B]5[/B].[/I]
[I]Therefore, the cmdlet that we now require to run is as follows:[/I]
[I]Set-ItemProperty –Path . –Name “9074 Folder Access” –Value 3[/I]
If all goes well, the cursor should simply move straight to the next line. To prove that the setting has been made, simply run the [I]Get-ItemProperty[/I] cmdlet with the [I]Path[/I] parameter specified as a period (.) as shown here:
[I]Get-ItemProperty –Path .[/I]
The results will look similar to that shown in Figure 10 below. The cmdlets used above may not necessarily be the most intuitive to use if you’re not too familiar with PowerShell but if you plan on scripting the build of your Exchange 2007 servers these cmdlets can easily be added to any PowerShell script.
[IMG]http://www.msexchange.org/img/upl/image0061265382414929.jpg[/IMG]
[B]Figure 10:[/B] Registry Set Via Exchange Management Shell
[B]Additional Client Information
[/B]

As I stated in part one of this article series, you can begin to see additional client information within the event log description text of the event log entry recorded when a folder is accessed by another user. The full client information displayed in the event log entry shown in Figure 6 in part one of this article series is as follows:
[I]Machine Name: CCR-SRV1[/I]
[I]Address: 192.168.50.50[/I]
[I]Process Name: w3wp.exe[/I]
[I]Process Id: 0[/I]
[I]Application Id: Client=OWA[/I]
As you can see, it is fairly clear from this information that Mark has accessed Rob’s folder from Outlook Web Access running on the server CCR-SRV1 that has an IP address of 192.168.50.50. If Outlook is used as the client application, expect the process name to be [I]OUTLOOK.EXE[/I] rather than w3wp.exe as shown above.
[B]Event Log Levels[/B]

In part one of this article series we saw how the event log level was set to [I]Medium[/I] for folder access. We saw how this was set in the Manage Diagnostics Logging Properties wizard, a reminder of which is pictured in Figure 11 below.
[IMG]http://www.msexchange.org/img/upl/image0081265382415133.jpg[/IMG]
[B]Figure 11:[/B] Manage Diagnostics Logging Properties
You can also see in Figure 11 that there are five different event log levels starting at [I]Lowest[/I] and ending at [I]Expert[/I]. The different event log levels will naturally record differing amounts of information into the event log. The medium level is sufficient to capture access to normal user mailbox folders; it’s really not necessary to select any level higher than this unless you want to capture access to information in the non-IPM subtree or folders such as the mailbox root folder that is also known as the [I]Top of Information Store[/I] as you can see in Figure 12.
[IMG]http://www.msexchange.org/img/upl/image0091265382501039.jpg[/IMG]
[B]Figure 12:[/B] Event ID 10100 – Mailbox Root Folder
[B]Auditing Other Areas
[/B]

Similar event log entries are recorded for the other categories of [I]Message Access[/I], [I]Extended Send As[/I] and [I]Extended Send On Behalf Of[/I]. For example, if the Message Access category is set to a level of [I]Medium[/I] and Mark accesses a message in Rob’s mailbox, event ID 10102 is recorded as you can see in Figure 13. You will notice from Figure 13 that the message ID of the message that was accessed is revealed, along with other important information such as the folder that contained the message, the distinguished name of the accessing user as well as the distinguished name of the owning mailbox. The event log entry also includes the same client information that you saw earlier in this article.
[IMG]http://www.msexchange.org/img/upl/image0101265382501179.jpg[/IMG]
[B]Figure 13:[/B] Event ID 10102 – Message Access
When auditing the [I]Extended Send As[/I] category, the event log event ID changes to 10106 and the category changes to [I]Send As[/I] as you can see from the example entry in Figure 14. Here you can see that the event log description reveals the distinguished names of the users involved in the transaction and that Mark has sent a message as if it came from Rob.
[IMG]http://www.msexchange.org/img/upl/image0111265382501211.jpg[/IMG]
[B]Figure 14:[/B] Event ID 10106 – Send As
[B]Summary
[/B]

That completes our two-part look at the new mailbox access auditing feature of Exchange 2007 Service Pack 2. This is a very powerful feature that can quickly fill your event logs with a lot of information, so clearly planning how you are going to enable this feature is important. What is also important is planning on how long you are going to retain the event logs once you’ve captured this information
[/LEFT]