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:
- Have the data necessary to audit access.
- 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.