Enabling Auditing in Exchange 2007 SP2

One of great improvements made in Exchange 2007 SP2 is the ability to perform better auditing a feature missing in previous versions of Exchange and this could be performed using the GUI of Exchange Management Console. Before the release of SP2, we had to use shell cmdlets for getting and setting diagnostic logging for various exchange parameters.

Although we can still use these cmdlets for doing the same in SP2, it is now available in the exchange console, which is good news from many admins who are not that comfortable with exchange shell.

In order to increase the logging level for an exchange attribute, launch EMC and navigate to Server Configuration. Right click the server and select “Manage Diagnostic Logging Properties”. You can get the same option by right clicking the server from any nodes under Server Configuration.

Drill down and select the property that you want and set the logging level. The different levels of logging available are lowest, low, medium, high and expert. Once the logging is enabled, detailed information is available in the event viewer.

Once you have finished with increased logging, right click the server and select "Manage Diagnostic Logging Properties” and select “Reset all services to default logging level” to switch logging to the default level.

Access Auditing is controlled by diagnostic categories for Exchange Information Store (MSExchangeIS). We cannot use this feature to audit message deletions, only access is possible. Following are the four actions on which auditing is possible.

• Folder Access - Lets you log events that correspond to opening folders, such as the Inbox, Outbox, or 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.

How To Enable Mailbox Access Auditing?

Launch EMC & navigate to Server Configuration -> Mailbox. Select your mailbox server, right click & select “Manage Diagnostic Logging Properties”. Drill down to MSExchangeIS -> 9000 Private.

Expand the tree to see all the options & you will find the four options mentioned above.

Increase the logging level, depending upon the level of information you need & click Configure. That’s it!

How To Access The Audited Info?

Now that mailbox access auditing is enabled, we need to be able to get the information logged. SP2 creates a separate area for logging information related to mailbox access & it is named Exchange Auditing. Navigate to Event Viewer -> Applications & Services Log -> Exchange Auditing.


How To Change The Default Properties?

By default, the location for storing the the logs is in the exchange server installation directory, Drive\Program Files\Microsoft\Exchange Server\Logging\AuditLogs to be precise. The default behaviour is to archive the logs when it gets full. Hence, the location of the logs should be changed to a drive that has enough free space. You can achieve this by selecting the properties of Exchange Audting & changing the options.

What About Service Accounts?

Any organization will have service accounts which have full access to the mailboxes, like accounts used to run backups. As this type of accounts will be used on a daily basis, we don’t need information about these accounts to fill up our mailbox access log. To overcome this issue, SP2 extends the schema with a new right named “Bypass Auditing”. Run the following command to exclude service accounts from being audited.

Get-MailboxDatabase –identity “server\sg\dbname”
Add-ADPermission –User “service account” –ExtendedRights ms-Exch-Store-Bypass-Access-Auditing –InheritanceType All



Configure Auditing to Track Exchange Server Usage

Auditing lets you track what’s happening with Exchange Server. You can use auditing to collect information related to information logons and logoffs, permission use, and much more. Any time an action that you’ve configured for auditing occurs, this action is written to the system’s security log. You can then access the security log from Event Viewer. You enable auditing in the domain through Group Policy.

To enable Exchange auditing, follow these steps:

1. Start the Group Policy Management Console by clicking Start, All Programs, Administrative Tools, Group Policy Management. You can now navigate through the forest and domains in the organization to view individual Group Policy Objects.

2. To specifically audit users’ actions on Exchange Server, you should consider creating an organizational unit (OU) for Exchange servers and then define auditing policy for a Group Policy Object applied to the OU. After you’ve created the OU or if you have an existing OU for Exchange servers, right-click the related policy object, and then select Edit to open the policy object for editing in Group Policy Management Editor.

3. Access the Audit Policy node by working your way down through the console tree. Expand Computer Configuration, Policies, Windows Settings, Security Settings, and Local Policies. Then select Audit Policy.

4. You should now see the following auditing options:

• Audit Account Logon Events Tracks user account authentication during logon. Account logon events are generated on the authenticating computer when a user is authenticated.

• Audit Account Management Tracks account management by means of Active Directory Users And Computers. Events are generated any time user, computer, or group accounts are created, modified, or deleted.

• Audit Directory Service Access Tracks access to Active Directory. Events are generated any time users or computers access the directory.

• Audit Logon Events Tracks local logon events for a server or workstation.

• Audit Object Access Tracks system resource usage for mailboxes, information stores, and other types of objects.

• Audit Policy Change Tracks changes to user rights, auditing, and trust relationships.

• Audit Privilege Use Tracks the use of user rights and privileges, such as the right to create mailboxes.

• Audit Process Tracking Tracks system processes and the resources they use.

• Audit System Events Tracks system startup, shutdown, and restart, as well as actions that affect system security or the security log.

5. To configure an auditing policy, double-click or right-click its entry, and then select Security. This opens a Properties dialog box for the policy.

6. Select the Define These Policy Settings check box, and then select the Success check box, the Failure check box, or both. Success logs successful events, such as successful logon attempts. Failure logs failed events, such as failed logon attempts.

7. Repeat steps 5 and 6 to enable other auditing policies. The policy changes won’t be applied until the next time you start the Exchange server.

Auditing in Exchange 2003

Can we audit mailbox access?
Yes we can, but only to a certain extent.

Auditing on Exchange server is performed by increasing 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 does impact the performance on the server to a certain extent and make sure you have a bigger application log size in event viewer)

Some more info:
Event 1016 indicates that a Windows account that is not the primary account for a mailbox has logged on to the mailbox. Logging on to a mailbox does not indicate that the contents of the mailbox can actually be accessed. Additional permissions are required to access mailbox contents. Thus, a 1016 event indicates only that an attempt was made to access mailbox contents, and that the username and password presented were valid within the Windows directory.

Event 1016 will not be raised merely by scheduling an appointment with a mailbox owner (this may cause event 1013 to be logged) or by configuring a profile that includes another user's mailbox.

Event 1016 will be generated if:
You are a delegate for a mailbox and you perform an action on a mailbox item sent to you as a delegate (such as declining or accepting an appointment).
You have configured another person's mailbox in your Outlook profile, and you try to access the mailbox in the Outlook folder tree (the 1016 will be logged regardless of success in actually accessing mailbox items).
You open or try to open a particular folder in another user's mailbox, regardless of your delegate status.

In short, event 1016 indicates an attempt to access a mailbox, but does not indicate whether a user was successful in accessing folders within the mailbox. Logging on to a mailbox must be distinguished from being able to access mailbox contents. Almost any user can log on to a mailbox, but that does not grant access, but rather access to determine whether further access should be granted.

Event 1029 indicates only denial of access to a folder. It does not indicate successful access. Therefore, a 1016 with no succeeding 1029's may indicate either that the logged on account had extensive or full rights in the mailbox, and thus no failures were logged, or that no further access was attempted after the initial logon.

In summary, generation of a 1016 indicates that person A has logged on to person B's mailbox. It does not mean that person A has been able to access any of the mailbox contents of person B. The presence of an event 1029 (or multiple 1029 events) indicates that A was denied access to at least some parts of B's mailbox. This may be because A is a legitimate delegate of B, with limited permissions, or A may have no permissions at all to access mailbox folders.


References:
How to monitor mailbox access by auditing or by viewing Mailbox Resources in Exchange Server
http://support.microsoft.com/kb/867640/en-us

Exchange Records Event 1016 in the Event Log For Both Valid and Invalid Mailbox Access
http://support.microsoft.com/?id=812007


Can we audit permission changes (if someone changes the permissions on their mailbox/folders)?
Once again we need to remember that Exchange and Outlook is not designed for auditing.

An Exchange mailbox is only an attribute of an AD user object. The only way we can audit mailbox access is by auditing the AD object access on the msexchmailboxsecuritydescriptor attribute on users. This would give us limited information on who made the changes, but it would not tell us what kind of changes was made or what rights were given. This functionality is very limited in Exchange 2003.


How to turn on auditing for the msexchmailboxsecuritydescriptor:

1. Open up the Default Domain Controller Policy and enable success auditing for “Audit Directory service access” and “Audit object access”
2. Open up adsiedit.msc (Windows Support Tools) and select the properties of the OU where the users exists.
3. Select the Properties of the OU, Select Advanced, Select the Auditing Tab, Click on Add, Select Everyone
4. Select the Properties Tab, In the apply onto pull down menu, select User Objects
5. Check the option Successful for both Read msExchMailboxSecurityDescriptor and Write msExchMailboxSecurityDescriptor

We should see events (565 or 566) coming up on the Domain Controller where the Exchange server was connected when the change was made. Unfortunately you will not be able to see what was done to the particular account. These events will not give you the level of information you are looking for and could at best be used to verify a suspected “permission change”.

The events (565-566) may be logged in circumstances where no security breach has occurred. For example, this event may be logged when a service or an add-in has to use an account that has access to all mailboxes. Examples of accounts that have access to all mailboxes are service accounts or administrator accounts. Examples of services or add-ins that have to use these kinds of accounts include antivirus software, backup agents, or Microsoft Exchange Mailbox Manager.


Getting the permissions list on the Exchange server using PFDAVADMIN
Use PFDavAdmin to dump out the folder permissions and compare the permissions before and after. You could download the PFDAVADMIN tool from the below link
http://www.microsoft.com/downloads/details.aspx?FamilyID=635BE792-D8AD-49E3-ADA4-E2422C0AB424&displaylang=en

Open PFDAVadmin
Click on File connect
Enter the name of the Exchange server and the Global Catalogue server and under connection click on all Mailboxes.
It will generate the list of mailboxes on that Exchange server.
Now click on Tools  Export permissions
Select the scope and in the format select the desired format

Information about PublicDelegate ( this is the attribute that gets stored on the mailbox when we add delegates to Outlook)
PublicDelegate Will be populated with the delegate (on the user that has granted permissions).
publicDelegatesBL: The back link will be populated with the "granting user" on the delegates user object.
If you grant someone delegate permissions through Outlook, that user will be seen in the Publicdelgates attribute of your user.
The user that you granted the delegate permission will get the publicDelegatesBL populated.


It is also possible to possible get mailbox permission list using ADMODIFY on the Exchange server.
If you want to dump these permissions to a file, you can use the admodify.net tool, which you can download at http://www.codeplex.com/admodify. This tool has two main purposes: It can dump out the mailbox permissions, and it can bulk change multiple accounts.
1. After you download admodify.net, extract the file to a folder and run the ADModify.exe image. On the main application
window, click the Modify Attributes button (even though you're not modifying anything).

2. Select the domain and domain controller (DC) and click the green arrow button to display a domain tree list. Expand the list and select the container or organizational unit (OU) you want to export and click Add To List. In the right pane, select all the users. Click Next.
3. Select the Mailbox Rights tab and select the "Export Mailbox Rights" box, as the figure shows. Click Go. You'll notice on this screen that you can bulk change information on multiple users at once, but in this case we're changing nothing and instead just listing mailbox rights.

4. Click OK and open the newly created mbxrights.xml file (it will be in the same folder as the admodify.net tool).


Is there a best practice for Exchange Auditing?:
No, we don’t have best practices for Exchange Auditing. As the need for auditing is different for all organizations and the ability to audit on Exchange specific task is difficult there is no Best Practices for Exchange Auditing.


Links you would like to read:-

Audit Active Directory Objects in Windows Server 2003
http://support.microsoft.com/kb/814595

813229 XADM: Failure Audit Security Event ID Messages Are Logged When You Open a Mailbox That You Have Delegate Access To
http://support.microsoft.com/default.aspx?scid=kb;EN-US;813229

How to View Windows NT Accounts that Access Mailboxes in Exchange Server
http://support.microsoft.com/kb/274317/en-us

How to monitor mailbox access by auditing or by viewing Mailbox Resources in
Exchange Server
http://support.microsoft.com/kb/867640/en-us

Exchange Records Event 1016 in the Event Log For Both Valid and Invalid Mailbox
Access
http://support.microsoft.com/?id=812007

System Event Viewer Tips
http://www.microsoft.com/technet/prodtechnol/exchange/2003/insider/eventviewer.mspx

175062 - How To Determine from Which Computer a User Logged On
http://support.microsoft.com/kb/175062

260835 - XADM: How to Log Mailbox Access by Computer Name
http://support.microsoft.com/kb/260835

173692 - Event 1016 Generated When You Open Mailbox or Schedule of Another User
http://support.microsoft.com/kb/173692