Administrator Audit Logging in Exchange Server 2010

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2010/compliance-policies-archiving/administrator-audit-logging-part1.html

PART-1


Introduction

As administrators of Exchange organizations that contain multiple administrators already know, it can sometimes be difficult to trace changes that have been made to any Exchange configuration objects or indeed user, distribution group or contact objects. Knowing what changes have been made and when they have been made can be extremely beneficial when troubleshooting various issues. For example, it will be very useful to understand if any Send or Receive connectors have been recently reconfigured when troubleshooting message routing issues. Recording configuration changes is also useful for documentation and may also be required for legal reasons.
Consider Figure 1, which shows the properties of a mailbox. You can see from here that this mailbox was last modified on 25th February 2010 at 21:18. However, it is not immediately clear exactly what was modified and, more importantly, who made the modification.

Figure 1: The Modified Property of a User Object
In this two-part article series we will be examining the new Exchange 2010 feature known as Administrator Audit Logging that allows you to record the various Exchange Management Shell cmdlets that have been run to make configuration changes across the Exchange organization. Administrator audit logging logs the fact that a cmdlet has been run in the Exchange Management Shell and of course the Exchange Management Console which itself actually runs Exchange Management Shell cmdlets. Additionally, cmdlets that are run via the Exchange Control Panel are also recorded.
However, cmdlets that start with Get- are not logged. Examples of such cmdlets include Get-AcceptedDomain, Get-CASMailbox and so on. Get- cmdlets are not logged because these cmdlets do not actually make any configuration changes.
The actual logged cmdlet actions are stored as email messages in a mailbox chosen by the Exchange administrator. It is therefore important that access to this mailbox is restricted to only those people who actually need access. We shall be covering this element of administrator audit logging later in this article.
Administrator Audit Logging Configuration Parameters

The configuration of administrator audit logging can be achieved using the Set-AdminAuditLogConfig cmdlet and viewed using the Get-AdminAuditLogConfig cmdlet. The Set-AdminAuditLogConfig cmdlet has a number of parameters associated with it but the most important parameters to discuss in this article all contain the string “log” in their names. Therefore, we can use the Get-AdminAuditLogConfig cmdlet and pipe the results to the format-list cmdlet choosing only to show cmdlet parameters that contain the string log in their names. To do this, the following cmdlet would need to be run:
Get-AdminAuditLogConfig | fl *log*
You can see the results of running this cmdlet in Figure 2. Note that this cmdlet has been run on a default installation of Exchange 2010 which therefore means that the parameter values shown below are default settings.

Figure 2: Results of Get-AdminAuditLogConfig
Let’s now examine these 6 cmdlet parameters in more detail.

• AdminAuditLogEnabled - Here you can see that by default this parameter is set to false, meaning that administrator audit logging is disabled by default. Setting this parameter to true will therefore enable administrator audit logging.
• TestCmdletLoggingEnabled -This parameter controls whether the logging of Test- cmdlets is enabled or not. By default, Test- cmdlets will not be logged. Examples of Test- cmdlets include Test-OutlookWebServices, Test-ReplicationHealth and so on.
• AdminAuditLogCmdlets -The AdminAuditLogCmdlets parameter shows you which cmdlets are going to be logged when administrator audit logging is enabled. By default, this parameter is set to log all cmdlets via the use of the * wildcard character. This can be changed as you will see later in this article.
• AdminAuditLogParameters - Cmdlets have associated parameters that can be used with them and this particular parameter controls whether administrator audit logging will also log cmdlet parameters. By default, this parameter is set to log all cmdlet parameters via the use of the * wildcard character. Like the AdminAuditLogCmdlets parameter this can be changed as you will see later in this article.
• AdminAuditLogAgeLimit -This parameter is not currently functional in Exchange 2010 but it is expected that this parameter will control how long a log entry should be kept. This will be a useful feature if it is implemented since, as log entries are stored as email messages, it is possible that many log entries could be generated in large Exchange organizations resulting in many email messages being generated. Again, we will cover this later on.
• AdminAuditLogMailbox - This parameter controls which mailbox is used to store the logged results. As you can see from Figure 2 this parameter is blank by default but will need to be enabled as part of the overall configuration process.

Configuring Administrator Audit Logging


Before administrator audit logging is enabled, it makes sense to first configure the required settings such as the name of the audit logging mailbox that will be used to store the results of the logging and also the list of cmdlets and associated parameters that will be logged. After all, what we do not want is a configuration where administrator audit logging is enabled but there is no corresponding mailbox configured to accept the logging results or the wrong cmdlets are logged.
Let’s look at the administrator audit logging mailbox configuration option first. To configure the audit logging mailbox we can use the Set-AdminAuditLogConfig cmdlet with the AdminAuditLogMailbox parameter. In the example below, the SMTP address auditlog@neilhobson.com is the address of a mailbox that has been created specifically to house the results of administrator audit logging. Note that the mailbox selected for this purpose must exist within the Exchange organization. The cmdlet to perform this configuration will be similar to this:
Set-AdminAuditLogConfig –AdminAuditLogMailbox auditlog@neilhobson.com
If successful, running this cmdlet does not produce any direct feedback from the Exchange Management Shell. Therefore, after running this cmdlet, you might want to re-run the Get-AdminAuditLogConfig cmdlet to check the configuration as you can see from Figure 3.

Figure 3: Checking Configuration Success
Logging Cmdlet Names


As we’ve already discussed earlier in this article, by default all cmdlets will be logged with the exception of any Get- cmdlets. To modify this configuration, the AdminAuditLogCmdlets parameter can be changed. For the AdminAuditLogCmdlets parameter, individual cmdlets can be specified as well as cmdlets with wildcard characters. For example, to log just the Set-TransportConfig cmdlet the following cmdlet would need to be run:
Set-AdminAuditLogConfig –AdminAuditLogCmdlets Set-TransportConfig
Similarly, as an example of wildcard use, it is possible to log any cmdlets that end with ReceiveConnector in their names by using the following cmdlet:
Set-AdminAuditLogConfig –AdminAuditLogCmdlets *ReceiveConnector
This cmdlet would therefore log the New-ReceiveConnector, Set-ReceiveConnector and Remove-ReceiveConnector cmdlets. Or, to log any cmdlet that has Config in its name, the following cmdlet would need to be run:
Set-AdminAuditLogConfig –AdminAuditLogCmdlets *Config*
Of course, it is more likely that several different types of cmdlets will need to be logged. Therefore, each different type of cmdlet can be specified in the AdminAuditLogCmdlets parameter when they are separated by commas. For example, to log both cmdlets that end with ReceiveConnector in their names as well as cmdlets that have Config in their names the following cmdlet would need to be run:
Set-AdminAuditLogConfig –AdminAuditLogCmdlets *ReceiveConnector, *Config*
Having said all of this, it is also quite likely that all cmdlets will need to be logged which can be achieved by running the following cmdlet if the default configuration has already been modified:
Set-AdminAuditLogConfig –AdminAuditLogCmdlets *
However, logging all cmdlets in large Exchange environments will obviously create many log entries and therefore this should be carefully monitored when first implemented.
Summary


That completes part one of this two-part article series on administrator audit logging in Exchange 2010. In this article we have covered what administrator audit logging actually is and began to look at the various configuration parameters available. In part two we will complete our look at the configuration options and then proceed to look at a working example of this feature in action

---

موضوعات مشابه:

• Exchange Management Console: New features in Exchange Server 2010
• Administrator Audit Logging in Exchange 2010
• preview of the upcoming Exchange Server 2010 Administrator's

---

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2010/compliance-policies-archiving/administrator-audit-logging-part2.html

PART-2


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 auditlog@neilhobson.com 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 auditlog@neilhobson.com
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