Auditing Mailbox Access Using Exchange System Manager and Event Viewer

Introduction

Sometimes it may be necessary to track who is accessing other mailboxes and when they are doing it. You can determine a certain amount of basic information via Exchange System Manager and the Event Viewer and that’s what I’ll cover in this article. I’ll also show you how to use PFDAVAdmin to determine which folders have been accessed.

In Exchange System Manager, the Mailboxes and Logons objects are found under each mailbox store that you create on an Exchange 2000 or Exchange 2003 server. Both of these objects can be used to display the Last Logged on By column, which shows you which account last accessed a particular mailbox. A sample screen of this scenario is shown in Figure 1, where the Mailboxes object underneath the default mailbox store has been selected. In the right-hand pane, you can see a list of mailboxes that are contained on this mailbox store, together with the Last Logged on By and Size columns. For the highlighted mailbox belonging to User1, you can clearly see that User1’s mailbox was last logged onto by User3 from the domain NGH.


Figure 1: Last Logged on By Column

It’s very common for anxious administrators to post security-related queries to newsgroups, forums or mailing lists when they see that the Last Logged on By column references a Windows account different to the one that actually owns the mailbox. For example, Figure 1 above may prompt questions such as “Why is User3 logging onto User1’s account?” or “Is User3 reading User1’s email?”

Logging What’s Going On

Typically, there is no need to worry here. The Last Logged on By column can be updated in several different ways during normal Exchange operations. It’s important to note that this column will update frequently because it can update when a user queries one of the folders belonging to another user. Perhaps the most common event of this variety is where someone’s calendar folder is queried, perhaps to see what appointments they have or when their free/busy information is accessed when scheduling an appointment.

In the case highlighted above, unless User1 has granted User3 specific access to their mailbox, or for example the administrator has specifically given User3 the Full Mailbox Access right to User1’s mailbox, it’s unlikely that User3 has managed to gain access to User1’s mailbox. A lot of administrators assume that, if they are members of groups such as Domain Admins, they will be able to open anyone’s mailbox. However, this isn’t the case as Administrators are explicitly denied access to all mailboxes by default in Exchange 2000 and Exchange 2003. For more information on this, please see Microsoft Knowledgebase article 821897.

Of course, unless you manage all aspects of Exchange by yourself, you are going to have to delegate some administrative tasks and therefore trust those responsible for these tasks. However, if access rights are giving you cause for concern, one thing you can do is to temporarily increase diagnostics logging for the Logons and Access Control categories for mailboxes. To do this, run Exchange System Manager and keep expanding the tree until you locate your server object. Once you’ve located the server object, right-click it and bring up the properties. On the Diagnostics Logging tab, expand MSExchangeIS and then click the Mailboxes object. Select the Logons and Access Control categories and set them to Maximum. This is shown in Figure 2. You can then scan the application event log for more detailed logon information as and when logon events occur.


Figure 2: Diagnostics Logging for Logons and Access Control

Take the case where User3 successfully accesses User1’s calendar, perhaps because User1 has the calendar default permission set to the Reviewer role. Scanning the event log, we’ll see an event ID of 1016 with a category of Logons. It will look similar to the one shown in Figure 3:

Image
Figure 3: Event ID 1016

Event ID 1016 is essentially self-explanatory when you read the description, in that it means that the specified Windows NT account accessed the specified mailbox but is not the primary account for that mailbox. As I said earlier, the classic case here is when someone accesses someone else’s calendar. Exchange 5.5 used to log the 1016 event ID regardless of what the diagnostic logging level was set to. However, in Exchange 2000 and Exchange 2003, you need to set the diagnostics logging levels as I’ve previously described in order to see this event.

What about automated processes, like antivirus or backup applications? Or perhaps Exchange’s Mailbox Manager feature? Sure enough, these will also produce logon events like the 1016 event ID as shown below in Figure 4. Note that the logon account here is NT AUTHORITY\SYSTEM.

Image
Figure 4: Event ID 1016 From Mailbox Manager

So we’ve now seen that event ID 1016 is a key event to scan for when reviewing who is accessing other mailboxes. Let’s now take a look at the other event IDs that you may see whilst reviewing the event log.

Other Event Log Entries

Event ID 1013 is very much a companion event for event ID 1016. Event ID 1013 informs you that the specified user account has opened an additional mailbox. Take Figure 5 below as an example. Here you can see that the domain user NGH\User1 was validated as the user whose legacyExchangeDN is listed as /o=NGH/ou=First Administrative Group/cn=Recipients/cn=User1 but then logged into the mailbox whose legacyExchangeDN is listed as /o=NGH/ou=First Administrative Group/cn=Recipients/cn=User2. In this case, it’s because User1 opened User2’s calendar folder. You’ll notice, though, that this event does not tell you what folders or messages User1 has opened. In other words, you may need to supplement your investigation with additional documentation of exactly what permissions are set on individual mailboxes.


Figure 5: Event ID 1013

Event ID 1009 is an indication that the specified user account logged into the specified mailbox. Take the example shown below in Figure 6, where it can be clearly seen that the domain user NGH\User1 successfully logged into the mailbox whose legacyExchangeDN is listed as /o=NGH/ou=First Administrative Group/cn=Recipients/cn=User1. In other words, this is normal mailbox logon activity for a user. Note that event ID 1009 also has a category of Logons.


Figure 6: Event ID 1009

Finally, if you’ve ramped up the diagnostics logging for the Access Control category as I covered earlier, you will probably be getting quite a few event ID 1029 entries logged. This particular event log entry tells you that the specified user/mailbox was unsuccessful in its attempt to access a particular folder from another mailbox. An example of this is shown in Figure 7.

Image
Figure 7: Event 1029

In this case, User1 has failed to access a folder belonging to the Administrator mailbox. The very last piece of text within the description field, which has just started to disappear off screen in the picture above, tells you that the folder ID is included within the data section of the event; this folder ID is the highlighted text in Figure 7. We therefore know from Figure 7 that the folder ID is effectively 1-4C. How can we determine exactly which folder User1 has tried, unsuccessfully, to access? To do this, we can use the PFDAVAdmin tool. If you’re not familiar with this tool, check out my two-part article here – this will tell you where to download it.

I’ll now assume that you’ve read the PFDAVAdmin article mentioned above as it contains full details on how to connect the tool to your mailboxes. Here’s how to use PFDAVAdmin to find this folder ID:

  1. Run PFDAVAdmin and choose to connect to All Mailboxes. Obviously you can also connect to the single mailbox that you are investigating if you so desire.
  2. From the list of mailboxes now presented in the left-hand pane, expand the Administrator mailbox.
  3. Right-click the Top of Information Store object and choose Property Editor from the context menu.
  4. In the Property Editor window, choose ptagFID : 0x67480014 from the Property options field, ensure that the Display radio button is selected, and then finally ensure that the Perform this action on all subfolders of the selected folder check box is selected. This is shown in Figure 8. When you’re happy, click the Execute button.

Image
Figure 8: Property Editor

  1. Once the Execute button has been clicked, a separate window should appear containing a list of the folders within the mailbox together with their associated folder ID. An example of this is shown in Figure 9, where you can see that I’ve highlighted the folder that has a folder ID of 1-4C. You can therefore see that it was the Administrator’s calendar folder to which access was attempted.


Figure 9: PFDAVAdmin Folder IDs

Summary

Auditing mailbox access with Exchange System Manager and the Event Viewer can give you basic information on what’s going on when it comes to seeing who is accessing other mailboxes. It’s not a perfect solution by any means but it’s another combination of tools in your toolkit when you need to track down permission issues. Using PFDAVAdmin to determine which folder has had failed access attempts could prove very useful.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top