Service Pack 2 Highlight: Mailbox Access Auditing


In today’s installment of “Microsoft Exchange Server 2007 Service Pack 2 Highlight”, I bring you a brief overview of how we have made auditing mailbox access easier (in the aforementioned service pack 2 – yes, for Exchange Server 2007).

Auditing access to mailboxes (Who opened what) has always been difficult with Exchange Server. I first made my acquaintance with this code in Exchange 4.0 – and it hasn’t changed much – until now. With Service Pack 2 we made a set of changes that will meet the needs of some organizations. Not everyone will be happy with our design decisions. Not everyone will be able to utilize Access Auditing for their needs. Those of you who can use these features, will be pleased to find that Service Pack 2 offers granularity, detail, and clarity for auditing mailbox access.

Decisions, Decisions

To start with, we had to decide what to log. One thing you will notice right away is the thing we decided not to log: Logons. Traditional auditing has involved turning up diagnostic logging on private logons and filtering through a lot of data. The problem with this is that a logon (in and of itself) doesn’t really represent anything malicious. If I put Kurt Phillips on the recipient list of a meeting invite with Outlook, you might see my client attempt to logon. Not because I decided to try and read Kurt’s mail) but because Outlook wants to check his free/busy. Get out the pitch forks or calmly pass over? It’s hard to tell. On the other hand, if I opened user A’s inbox – that would be valuable information. So Access Auditing is focused on actual access to data, not mailbox logons.

Success is what counts

We also decided to focus on access success, not failure. If you fail to open an inbox, Access Auditing does not record this. Again, focusing on actual access to actual data.

Location, Location, Location

The biggest change you will notice from Access Auditing is where it places the audit events. It is in essence a set of diagnostic logging categories for the Exchange Information Store. In studying the last five years worth of auditing cases, and every escalation where auditing was used to gather data, we realized that because of the volume of data, customers using private logon diagnostics often had to make a hard choice when confronted with an issue that required diagnostic logging:

  1. Have the data necessary to audit access.
  2. Have enough room for the other logging to troubleshoot.

Every version of Exchange has used the Application log as its dumping ground since Exchange 4.0. Until now. Exchange 2007, Service Pack 2 creates a new application log: Exchange Auditing. It is not the security log (and we’ve gotten a bunch of feedback for and against this). It is not the application log. It is the location where Exchange 2007 can output events related to mailbox access (and more.).

So what do we get?

You get a lot of information. All audited events associated with a user logon carry the same sort of information:

Object specific information, information about which NT Account was used, what mailbox was acted upon, and if you are running at least Outlook 2003 SP2, information about the machine the access was made from. You also get a great deal of choice about what is logged. Log only administrators using administrative rights, log only access from one user to another user’s mailbox, or log access to any mailbox. The choice is yours to enable the amount of information you need to fit your needs.

Let’s look at a sample access event:

Accessing user, mailbox being accessed, windows account, and information about what was accessed. That’s not a bad set of data for customers who have to answer who did what and when.

You have the Right to Remain Invisible

One of the most controversial issues will, without a doubt, be the addition of a new extended right. For organizations with trusted service accounts (such as voice mail, brick backup, or device software) these applications generate anywhere from two to eight times as many events as a normal user. These trusted accounts can be granted an extended right that effectively drops them from the audit log.

This is very valuable to customers who use this software.

This is very worrisome to people who must record every access, everywhere, by everyone.

Some customers will not be able to use SP2’s extended auditing specifically because of this. For those customers, the existing Windows Auditing plus diagnostic logging will still function.

Making sense of all of this

Auditing mailbox access is actually the last step in a process that begins with understanding what your company’s needs and requirements are. You need to understand what data you need, what degree of granularity is required. Then you need to decide how you are going to archive, access, and report on that data. Then you need to understand how to configure and control Exchange to produce the information that meets your needs.

We can’t help you with the first problem – there are as many customer requirements for data as there are customers using auditing. Collection is also very specific, and reporting is quite possibly one of the single biggest variants in the whole field. When it comes to configuring and controlling this, CSS Escalation Engineer Mike Lagase and Tom Di Nardo from our CXP team have produced comprehensive documentation on this subject:

Understanding Mailbox Access Auditing with Exchange Server 2007 Service Pack 2

White Paper: Configuration and Mailbox Access Auditing for Exchange 2007 Organizations

This concludes this episode of “Service Pack 2” highlight. Stay tuned for the next one, in which we look at Public Folder Quotas and how we’ve made changes to make it clear which limits are enabled, what the limits are, and how to reliably control Public Folder quotas.

Jason Nelson


Comments (15)
  1. Michael Dragone says:

    Great post. Thanks, Jason.

  2. Sitaram.Pamarthi says:

    With this logging, will I be able to know from where(IP address) user has accessed the mailbox?

  3. xC0000005 says:

    Sitaram – indeed.  As you have probably noticed from the picture above (or read in the detailed documentation linked), the "Address:" portion of the client information contains the address.  In the example above it’s an IPV6 address because that’s what my client used to connect to the server.  When the connection is via LRPC it shows the machine name, when it’s IPv4 it’s a normal dotted address.  I don’t know if it’s still possible to install and do RPC over IPX or Appletalk.  No idea what address it would show for those.  As noted in the documentation, address is part of the client info block sent by Ol2k3 Sp1 and later clients.

  4. Rob Broughall says:

    Nice feature, any plans for it to appear in 2010?  It looks like it’s absent from the RC?

  5. Amar says:

    Consider secretary has access on Manager’s mailbox. She opens her manager’s mailbox.

    How auditing will work in such case?

    Amar

  6. xC0000005 says:

    Rob – Yes, it’s in the plans, but we were delivering the code for Access Auditing extremely late the 2010 delivery cycle.  In general 2010’s auditing capabilities as is surpass 2007 but we are looking at how this (and the upcoming mailbox security descriptor auditing) complement 2010’s features.

    Amar – In this case, Secretary is user A, Manager is user B, so if you have configured auditing at any level greater than 1 (Administrative access level) you will see the events audited.  We evaluated specific options for "Not when A is a delegate of B" or ‘Optionally when A is a delegate of B" but in the four years worth of case data, every critsit ever opened where auditing was used, and every deployment plan I had access to where Auditing was designed in I could not justify adding yet another level of complexity.  

    There are great things that can be done with this information, but I expect that there’s a lot of room for our third party partners to extened and add value.  I expect that because we had to decide which areas were core features and which were "Value add but not essential", and one of these is in the "This set of actions is a false positive because A is a delegate of B" area.  The events themselves are designed to be easily consumed by programs (the identifier field was added specifically for short term correlation) but those programs don’t exist…yet.  

  7. Sean says:

    Great post!  I enabled Mailbox Audit logging but when I try to go into Event Viewer and open the ExchangeAuditing log, I get this error:

    Event Viewer cannot open the custom or saved view.  Ensure that the Event Log services is started.  Access is Denied (5)

    This is running on Windows 2008 SP2 with the default UAC settings enabled.  I get the same error if I run as local admin.  Also verified the service is running.  I am able to access other logs with no problem

  8. xC0000005 says:

    You will see this if you did not restart the server after installation.

  9. Sean says:

    No luck, rebooted the server and still get the same access denied error

  10. xC0000005 says:

    Is the EVTX being created in the auditing directory?  If it is it’s an issue of the ACL denying you access.

  11. Sean says:

    According o the ACL, Users have Resd access, Administrators have Full Control, System and LOcal Service also has full control.  I logged as the local administrator and confirmed that my effective permissions are full control.  

  12. Sean says:

    And yes,  the EVTX file is being created.  I even tried moving the file to another folder

  13. Sean says:

    According to the effective permissions on the file, I have full control with nothing listed as Deny access.

  14. xC0000005 says:

    Create a user who is only a mailbox admin and see if you can log on and read it.  The permissons assigned to the event channel are documented in the article, there are a couple of groups denied access.

  15. Sam Tudorov says:

    I have set up a logging level of 3 for Folder Access Auditing.  When  UserA on ServerA opens a folder belonging to UserB on ServerB, the 10100 MSExchangeIS Auditing event log on ServerA says that "The folder <foldername> in <UserA Mailbox> was opened by user MyDomainUserA".  I expected it to say "The folder <foldername> in <UserB Mailbox> was opened by user MyDomainUserA".

    Why is that ?

    Thanks

    Sam

Comments are closed.