Tuesday, February 2, 2010

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.

How to monitor mailbox access by auditing or by viewing Mailbox Resources in Exchange Server

Exchange Records Event 1016 in the Event Log For Both Valid and Invalid Mailbox Access

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

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

813229 XADM: Failure Audit Security Event ID Messages Are Logged When You Open a Mailbox That You Have Delegate Access To

How to View Windows NT Accounts that Access Mailboxes in Exchange Server

How to monitor mailbox access by auditing or by viewing Mailbox Resources in
Exchange Server

Exchange Records Event 1016 in the Event Log For Both Valid and Invalid Mailbox

System Event Viewer Tips

175062 - How To Determine from Which Computer a User Logged On

260835 - XADM: How to Log Mailbox Access by Computer Name

173692 - Event 1016 Generated When You Open Mailbox or Schedule of Another User

No comments:

Post a Comment