If you would like to read the first part in this article series please go to Administrator Audit Logging (Part 1).
Introduction
This is the second and final part of an article series on the administrator audit logging feature of Exchange 2010, which allows you to audit the running of cmdlets within the Exchange organization. In part one we started to look in detail at the parameters that can be used to configure this feature and therefore in part two we will complete this area and then move on to see the administrator audit logging feature in action.
Logging Cmdlet Parameters
Similarly to the way you would configure the names of which cmdlets will be logged, it is also possible to configure which cmdlet parameters will be logged. For example, the New-ReceiveConnector and Set-ReceiveConnector cmdlets both have the RemoteIPRanges cmdlet parameter. Therefore, to log all cmdlets that have the RemoteIPRanges cmdlet parameter, the following cmdlet would need to be run:
Set-AdminAuditLogConfig –AdminAuditLogParameters RemoteIPRanges
To log any cmdlet parameters that have Database in their names, the following cmdlet would need to be run:
Set-AdminAuditLogConfig –AdminAuditLogParameters *Database*
In the same manner as we have seen with the AdminAuditLogCmdlets parameter, it is also possible to specify several different types of parameters to log by specifying each one with a comma separating them. For example, to log both cmdlet parameters that are either called RemoteIPRanges or have Database in their names, the following cmdlet would need to be run:
Set-AdminAuditLogConfig –AdminAuditLogParameters RemoteIPRanges, *Database*
Of course, it is also quite likely that all cmdlet parameters will need to be logged and therefore the following cmdlet would need to be run if the default configuration has already been modified:
Set-AdminAuditLogConfig –AdminAuditLogParameters *
The interaction between the AdminAuditLogCmdlets parameter and the AdminAuditLogParameters parameter is easy to understand. If the administrator runs a cmdlet that matches one of those cmdlets listed in the AdminAuditLogCmdlets parameter, then the list of parameters listed in the AdminAuditLogParameters parameter is checked. If one or more parameters are matched, then the cmdlet execution is logged. We will look at the format of the logged cmdlet later in this article.
Logging Test Cmdlets
To log or not log cmdlets that start with Test-, such as Test-OutlookWebServices and Test-ReplicationHealth, it is simply a case of setting the TestCmdletLoggingEnabled parameter of the Set-AdminAuditLogConfig cmdlet to true or false as appropriate. The following two examples show both of these cmdlets:
Set-AdminAuditLogConfig –TestCmdletLoggingEnabled $true
Set-AdminAuditLogConfig –TestCmdletLoggingEnabled $false
A Working Example
Let us start by examining what happens if we configure the Exchange environment to log all cmdlets and all parameters. In this example, we will configure a single user, Neil, with the ability to open the AuditLog mailbox that will be configured to receive the contents of the administrator audit logging. First, you could create an Exchange Management Shell configuration script similar to the one listed below. Obviously you will need to change the name of the audit logging mailbox from [email protected] to match the SMTP address of the audit logging mailbox within your own Exchange organization.
# ConfigAuditLog.ps1
# Configures administrator audit logging settings – log all cmdlets and cmdlet parameters
Set-AdminAuditLogConfig –AdminAuditLogCmdlets *
Set-AdminAuditLogConfig –AdminAuditLogParameters *
Set-AdminAuditLogConfig –AdminAuditLogMailbox [email protected]
Set-AdminAuditLogConfig –AdminAuditLogEnabled $true
Set-AdminAuditLogConfig –TestCmdletLoggingEnabled $true
The next step is to give Neil access permissions such that he is able to open the AuditLog mailbox. Although this can be achieved by using the Exchange Management Console, this article will focus on continuing to use the Exchange Management Shell since the administrator audit logging feature can only be configured using the Exchange Management Shell. To grant the user Neil full access permissions to the AuditLog mailbox, the following cmdlet can be used:
Add-MailboxPermission –Identity AuditLog –User Neil –AccessRights FullAccess –InheritanceType all
With the Add-MailboxPermission cmdlet, the –Identity parameter is used to identify the name of the mailbox that you want to grant access to, whilst the –User parameter is used to identify the name of the user that is to receive the access. The –AccessRights parameter specifies the rights that are to be granted to the user which in this case is the FullAccess right. Finally, the –InheritanceType parameter specifies whether permissions are inherited or not.
You can see the results of running this cmdlet in Figure 4.
Figure 4: Granting Full Access to the AuditLog Mailbox
Once the Add-MailboxPermission has been run, the user Neil now has access to the AuditLog mailbox. In Figure 5 you can see that this mailbox has been opened in Outlook Web App. Note how the running of the Add-MailboxPermission cmdlet has been logged since this cmdlet was run after the enabling of administrator audit logging.
Figure 5: Accessing the AuditLog Mailbox
Audit Log Contents
Let us now look at the scenario where an Exchange administrator called Rob makes a change to the mailbox settings of a user called Mark. Using the Exchange Management Console, Rob decides to alter Mark’s mailbox storage quotas from the default setting of Use mailbox database defaults to custom settings that are designed to issue a warning message at 10240KB and prohibit sending new messages at 20480KB. These settings are shown in Figure 6.
Figure 6: Setting Custom Mailbox Quotas
One of the new features of the Exchange Management Console in Exchange 2010 is that the Exchange Management Shell cmdlet that will be run when the configuration change is applied can be displayed within the Exchange Management Console. As soon as Rob clicks the OK button shown in Figure 6, the properties window for Mark is displayed as you can see from Figure 7. What you will notice from Figure 7 is the management shell icon in the bottom-left corner of the window.
Figure 7: The Exchange Management Shell Icon
If Rob clicks this management shell icon, a separate Exchange Management Shell Command window appears that details the Exchange Management Shell cmdlet that will be run to configure the mailbox quotas. You can see this cmdlet in Figure 8. We can view this cmdlet now and later confirm that the same cmdlet has been logged.
Figure 8: The Set-Mailbox Cmdlet Execution
Let’s now have a closer look at the administrator audit log entry that occurs in the AuditLog mailbox as a result of Rob’s configuration change. You can see the email that is recorded in the AuditLog mailbox in Figure 9.
Figure 9: Set-Mailbox Cmdlet Audit Log Entry
You can see from Figure 9 that the message subject is NEILHOBSON\rob : Set-Mailbox which clearly shows the name of the user that created the audit log entry as a result of running the cmdlet, as well as the name of the cmdlet that was run. Let’s look at each parameter presented within the body of the email.
- Cmdlet Name. Obviously this is the name of the cmdlet that has been run by the user.
- Object Modified. Here you can see the details of the object that has been modified by the cmdlet, which in this case is a user object.
- Parameter. You already saw in Figure 8 that the Set-Mailbox cmdlet was being run with 4 different parameters, namely the Identity, UseDatabaseQuotaDefaults, IssueWarningQuota and ProhibitSendQuota parameters. These 4 parameters are recorded here in the log entry.
- Property Modified. These fields show which object properties have been modified and are therefore similar to the parameter fields. Additionally, one of the Property Modified fields reveals that the object has been changed.
- Caller. The Caller field reveals the name of the user that actually ran the cmdlet.
- Succeeded. Here you can see whether the cmdlet completed successfully, which returns a value of true, or unsuccessfully in which case the value here will be false.
- Error. If the cmdlet being run by the administrator failed, the error message will be shown here.
- Run Date. This field shows, in Coordinated Universal Time (UTC) format, the date and time that the cmdlet was run by the administrator.
Summary
That completes both parts of this article series on administrator audit logging in Exchange 2010. There is no doubt that this will be a welcome feature for those organizations that need to track when configuration changes are made to the Exchange 2010 infrastructure, perhaps for documentation, change control or legal reasons.
If you would like to read the first part in this article series please go to Administrator Audit Logging (Part 1).
