Sunday, July 16, 2017

Exchange 2010 SP3 - Search-AdminAuditLog (1)

After my previous blog posts on Exchange 2016 (in French), this post marks both a return to English (probably brief) and a return to Exchange 2010. I still manage Exchange 2010 servers and recently needed to examine the auditing of changes to mailbox permissions made by administrators (a subject that I've covered in the past as well). The context? Troubleshooting a third-party auditing tool that uses the PowerShell cmdlet Search-AdminAuditLog. Pending a solution to the problem in question, I wanted to see to what extent the same results could be achieved with native Exchange tools.


***

First, I'll present the scenario.

The mission is to create a report that will list changes made to mailbox permissions with the Add-MailboxPermission cmdlet (and optionally the Remove-MailboxPermission cmdlet). We should remember that even if we make changes in the Exchange Management Console (EMC), or Exchange Admin Center (EAC) in later versions of Exchange, these interfaces use PowerShell cmdlets behind the scenes to execute the desired action. I will also point out that by default administrators are denied access to user mailboxes - unless they execute the Add-MailboxPermission cmdlet that we will audit. Once created, the report should be sent to a designated auditor.

Next, I will execute the command and observe how Exchange records the action in the Event Viewer logs.

For example, the administrator "xadmin" grants himself Full Access to the mailbox of Alex Heyne:


Note: yes, you can click on the image to enlarge it.



Such an action is recorded in the MSExchange Management log of the Event Viewer :




Almost all actions performed by administrators are recorded in this log so we might have to use the "Find" tool to locate the actions that interest us, for example:





The action is only recorded on the server where it was executed (EX13-2 in this case). If we search for the action on EX13-1, there will be no result:




However, our objective is to discover any use of the Add-MailboxPermission cmdlet rather than locating single examples of the event in the MSExchange Management log. For this, we need to use another cmdlet: Search-AdminAuditLog.

I can execute the command with the expected results on EX13-2:



I also notice that the Search-AdminAuditLog cmdlet apparently examines the logs of other servers, since I obtain the same results on EX13-1 (note that the "OriginatingServer is still EX13-2):




We still do not have our report but we are on the right track. Indeed, the reporting function of the third-party software does use the Search-AdminAuditLog to retrieve the actions to be audited.



***


We are on the right track but I already notice something missing in the results of the Search-AdminAuditLog cmdlet. We see ...

  • Object modified (Alex.Heyne)
  • CmdletName (Add-MailboxPermission)
  • Caller (XADMIN)

So XADMIN executed the command Add-MailboxPermission against the mailbox of Alex.Heyne.

But what permissions were granted and to whom? Himself? Someone else?

We should keep in mind that the entry in the Event Viewer (shown in one of the screenshots above) does indicate these details.

After some research, I discovered that the information we want is present but not displayed but default. We are supposed to observe the property "CmdletParameters" with (in braces) "Identity", "User" and "Access rights" and realize this is a hash-table containing "name-value" pairs. We need to extract these using an array.

I used this article as a reference but was not able to obtain the same results:




Next, I attempted to expand the CmdletParameters property (successfully) but the output was not what I would have liked. I will not present all the variations attempted but in the end, this was the most readable:



So, for a single action (XADMIN grants himself Full Access to the mailbox of Alex Heyne), we have three separate entries. The auditor would have to be able to see the relationship between the three items that (by default) are not united in a single entity (unlike the presentation in the Event Viewer, once again).

While I could not create an array as described in the article cited earlier...

Parsing the Admin Audit Logs with PowerShell

It did include a script by Matthew Byrd that is supposed to format the output of the Search-AdminAuditLog so it is easier to interpret. I thought I would give this a try.


***


First, we download the script from the TechNet Gallery (Script Center):

Get-SimpleAuditLogReport script

Second, we declare a variable and assign it the output of the Search-AdminAuditLog as shown in the screenshot below.

Third, we pipeline the result to the Get-SimpleAdminAuditLog.ps1 script:


Note: click to enlarge.

This is much better! In the FullCommand field, we see the exact command that was executed. The auditor still needs to understand what that command accomplishes but no longer has to determine the relationship between three separate items as before.

But can we export the content to a file?

Yes we can:



And can we send the file to the auditor? Yes! In my case, I had to create a script for this (simple text to be saved and then executed as a .ps1 file):





The operation is successful and the auditor (we'll pretend user Alan Reid holds this role) does indeed receive the .csv attachment:



However, some may consider that the presentation is not the best:




***


I thought that HTML might allow for a more attractive and perhaps even readable presentation.

First, this is what I tried:



You might want to ignore what is inside the orange frame. Without further formatting, the output is really no better than our .csv file. With the -head parameter (please observe the details in the screenshot above), we can create a document like this:



We can combine all the elements so the file is sent to the auditor:



Note: we can also configure the Task Scheduler to run the script at the interval of our choice.


 ***


With some instruction, our auditor should be able to make sense of the HTML file. We can add other events as desired after the -Cmdlets section of the script. All in all, it seems like an acceptable solution if we do not have a third-party tool (or if our third-party tool stops functioning after an insufficiently tested update...).

And giving credit where credit is due...

Besides the text already cited twice above, I also used the following resources to construct my script(s):

Windows PowerShell Tip of the Week - ConvertTo-Html

Trying to pipe Export-Csv to Send-MailMessage







No comments:

Post a Comment