tracking logs for shared mailbox

Is it possible with 2010 exchange tracking logs to prove the following

We have a mailbox which has been made accesible in terms of permissions so a number of users havve access and control over the mailbox. We need to prove which of those users has sent/forwarded information from that mailbox elsewhere. Can the logs prove who did these actions? Or will they just show the mailbox itself sent/forwarded them on?
LVL 3
pma111Asked:
Who is Participating?
 
Guy LidbetterCommented:
Hi pma111

Your best bet is to enable auditing on that mailbox using the set-mailbox command, this has to be manually done (2010 SP1 and higher)... i.e.

Set-Mailbox -Identity SharedMailbox -AuditDelegate SendAs,SendOnBehalf -AuditEnabled $true

Open in new window


You could then search the audit log

Search-MailboxAuditLog -Identity SharedMailbox -LogonTypes Admin,Delegate -StartDate 1/1/2010 -EndDate 12/31/2010 -ResultSize 2000

Open in new window


Other than that, you could run a search-mailbox for the specific sent item, as the sender may have it in their Sent Items as well.

Or

In Manage Diagnostic Logging Properties of a mailbox server,  set to High logging level for "MSExchange\9000 Private\Send As" service. After that, needed SendAs information will be in Event 1032 in the Application Log of the mailbox server.

Last stop, message tracking can help,

The sendr will be in the RECEIVE event and the SharedMailbox will be in the associated DELIVER event.

HTH

Guy
0
 
pma111Author Commented:
Thanks Guy, I suspect the audit logging is yet to be enabled so it was looking at anything that could still be proven in the tracking logs which are turned on for 30 days..
0
 
tigermattCommented:
If the user used "Send-As" rights (rather than Send on Behalf) then the message tracking logs will typically show the shared mailbox as the sender, not the actual user who sent the mail. These logs are purely concerned with documenting mail transactions for later mail flow troubleshooting, rather than Windows logon accounts and activity auditing.

The message tracking logs do include the client IP sending the message, but you would need logs from other systems to determine the client using a given IP at a given time (DHCP) and to prove which account was logged in to that machine. See https://technet.microsoft.com/en-us/library/cc539064.aspx for details. This could very well be another server listed in this IP, though; depends on your topology, how the client submitted the message, etc.

If the client used OWA, and authenticated with their own credentials, IIS log files on the Client Access Server(s) or any reverse proxy system you use may be able to help.

Auditing is not retrospective as you indicated, so if that was not previously enabled, there is no way to use that to determine who completed this action.

A final thought: depending upon the configuration of a shared mailbox in the user's client (assuming they used Outlook), the sent mail may be committed to the user's personal "Sent Items" folder, rather than the Sent Items folder of the shared mailbox. That may be a further avenue to explore, although it is not guaranteed this will show up results, and investigating would require accessing the relevant user mailboxes, which can have privacy and legal implications. Although, of course, if a user has shared their mailbox with other users, it would be possible for collusion to "frame" somebody else, so as with all technical solutions, this (nor auditing, nor anything is) is not guaranteed to be 100% accurate.
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
Guy LidbetterCommented:
tigermat is correct in saying that messagetracking is hit and miss, which is why I listed it last.

In an example where I work, a user sent an email from a shared mailbox. The user was located on a terminal server with 40 other users. So the source IP was useless. However, if the user was on a desktop, a reverse lookup on the IP can easily identify the culprit.

Also, the users have full access permissions to the mailbox and have the mailbox open within outlook, in this case, the user in effect actually sent the item from the shared mailbox so the sent item was not located in their own sent items.

Whereas, if a user doesn't have full access and simply uses the drop down on the from field to "Send As", the email may well go into their own sent items as well. This is where the Search-Mailbox feature I mentioned becomes useful.

You've fallen into the age old dilemma of "who dunnit?" we all land up in at some time... Hence, I now always enable auditing on shared mailboxes.

Good luck!
0
 
tigermattCommented:
You've fallen into the age old dilemma of "who dunnit?" we all land up in at some time... Hence, I now always enable auditing on shared mailboxes.
Great advice from Guy for future reference.

*tigermatt goes to double-check shared mailbox auditing is enabled...* :-)
0
 
pma111Author Commented:
I did notice on the tracking logs, in the custom-data field, the logs show the sender address as the named indivudal, whereas the puported sender shows the shared mailbox name, which is interesting..
0
 
pma111Author Commented:
i.e. sender-address says user A, whereas in the custom data column shows S:PurportedSender=sharedmailbox@ourcompany.com for the same record
0
 
Guy LidbetterCommented:
You're lucky on that one...

The Purported sender is the alleged sender... i.e. who the "from" will be on the receiving end. As you can se ethe transport logs have noted the actual sender. This is not always the case though...

If a user has full access to a shared mailbox,has the mailbox open in Outlook, Selects the mailbox and then sends an email the from field will automatically be prepopulated with the Shared Mailbox and the logs will see it as sent directly from the shared mailbox. In this case, the sender will be the shared mailbox and there will be no purportedSender in the custom-data field.

Hit and miss as it were....
0
 
pma111Author Commented:
Thanks for your help and pointers..
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.