Mastering Microsoft Exchange Server 2007 SP1

Both Windows and Exchange Server present you with a lot of options for recording activity that occur on an Exchange server. Some auditing and logging options are on by default, while others must be enabled manually. We will break these up in to two broad categories. The first is Windows auditing, which reports on security- and operational-related events that affect the Windows operating system. The second is auditing and logs related to Exchange; within this category we can break these up further in to audit events relating to security and operations and events relating to message transport.

We are going to examine a number of different types of logging and auditing. We will often recommend that you turn on logging and auditing that is not turned on by default. Our reasoning behind this is that when you must start troubleshooting a problem or looking in to a possible security issue, you will need these logs available to you.

However, keep in mind that each time you increase the amount of logging or auditing that a system is doing, you increase the system overhead (CPU, disk, and memory).

Windows Auditing

Windows auditing can be applied to each server by using the Local Security Policy Editor or by applying the settings centrally using a group policy object (GPO) via Active Directory. In our example, we will use the Local Security Policy Editor. By default, Windows 2003 enables success auditing for some event logging categories, but we recommend enabling additional auditing of both success and failures.

When choosing to enable success, failure, or both types of auditing, there are two different philosophies at work. Those that recommend enabling mostly success auditing are usually interested in auditing things that actually happened or things that were successfully done by authorized users. This seems to be the mindset of the people that set the original Windows default auditing values.

Those that recommend enabling mostly failure auditing are usually interested in auditing things that were attempted but failed, such as logon failures or someone trying to run a program that they do not have permissions to run.

Finally, there is the third category of event logging that can best be described as logging done by paranoid control freaks. That is the category into which we place ourselves. We not only want an audit history of successful events, we also want to be able to audit failures that might help us track down intrusion or unauthorized access attempts.

As you increase the amount of logging that you are doing on any server, you will increase the load that is placed on it. The larger the event logs grow, the more challenging it will become to disseminate any useful information from them. So keep this in mind. Security-minded organizations with more than a few servers and a few hundred users should consider investing in an event log management system that can collect and analyze event logs centrally.

Increasing the Size of Event Logs

If you plan on keeping more than a few hours worth of information in your security and application logs, you will probably need to increase the overall size of the logs. The default event log file sizes are not sufficient for larger servers. You can configure the size of the event log sizes using the Event Viewer (right-click on each event log and select Properties from the pop-up menu). The Application event log properties are shown in Figure 21.8. The size of the event log is set in the Maximum Log Size box and must be in multiples of 64KB.

Figure 21.8: Changing the Application event log properties

We recommend that you increase the size of your event logs on both your Exchange servers and your domain controllers. Table 21.1 shows the recommended event logs sizes for Exchange servers and domain controllers.

The recommended sizes shown in Table 21.1 are just estimates and you can tweak them in whatever direction you see necessary. However, for the best performance and accuracy with event logs, we recommend that the combined size of all event logs not exceed 300MB.

Notice also in Figure 21.8 that there is a setting for controlling the behavior of event logging when the maximum log size is reached. The default is Overwrite Events as Needed. In a security-conscious environment, you may want to set this to either Overwrite Events Older Than 7 Days (you can change the number of days) or Do Not Overwrite Events (Clear Log Manually). If you set either of these two settings and the event log fills up before it is either cleared or the maximum number of days is reached, then event logging will stop. That is considered a feature and is designed to prevent an intruder or evildoer from covering their tracks by generating additional event logging and thus removing evidence of their evil deed.

Defining an Audit Policy

Defining an auditing policy for a member server is really simple. Open the Local Security Policy management console program and drill down to the Local Policies à Audit Policies container (shown in Figure 21.9).

Figure 21.9: Configuring events to be audited

Table 21.2 shows the audit settings that we recommend enabling for a Windows 2003 machine that is functioning as a member server. Anything that is logged by these settings will be logged to the Security event log.

To select an audit level, double-click on the policy to see the dialog box that allows you to select whether to audit the success or failure of events.

Exchange Diagnostics Logging

Exchange Server has a lot of possible categories for diagnostics logging and troubleshooting. Most of this report information is much more advanced and detailed than we typically need on a day-to-day basis when monitoring Exchange, but there are some diagnostics logging events that we recommend you enable. They help you to monitor some of the common events that you might need to be aware of for either security reasons or operational purposes. Figure 21.10 shows an example of one of these events; in this event we see that a user is logging on to their own mailbox.

Figure 21.10: An application event indicating that a user is logging in to their own mailbox

Table 21.3 lists event log services and categories that you should consider enabling.

If you are familiar with Exchange 2000/2003, then you probably already know that diagnostics logging was set using the Exchange System Manager. However, Exchange 2007 does not include a graphical user interface for managing diagnostics logging. These must be enabled using the Exchange Management Shell (EMS). There are two EMS cmdlets that are used to retrieve event logging levels and to set them. They are as follows:

If you use the Get-EventLogLevel cmdlet with no parameters, the output will show you all of the diagnostics logging levels relating to Exchange. The following is the output of the Get-EventLogLevel cmdlet. We are listing these here as a reference.

Get-EventLogLevel Identity EventLevel -------- ---------- MSExchange ActiveSync\Requests Lowest MSExchange ActiveSync\Configuration Lowest MSExchange Antispam\General Lowest MSExchange Autodiscover\Core Lowest MSExchange Autodiscover\Web Lowest MSExchange Autodiscover\Provider Lowest MSExchange Availability\Availability Service Lowest MSExchange Availability\Availability Service General Lowest MSExchange Availability\Availability Service Authentication Lowest MSExchange Availability\Availability Service Authorization Lowest MSExchange Cluster\Move Lowest MSExchange Cluster\Upgrade Lowest MSExchange Cluster\Action Lowest MSExchange Common\General Lowest MSExchange Common\Configuration Lowest MSExchange Common\Logging Lowest MSExchange Extensibility\Transport Address Book Lowest MSExchange Extensibility\MExRuntime Lowest MSExchange EdgeSync\Synchronization Lowest MSExchange EdgeSync\Topology Lowest MSExchange EdgeSync\SyncNow Lowest MSExchange TransportService\TransportService Lowest MSExchange Web Services\Core Lowest MSExchange IMAP4\General Lowest MSExchange Messaging Policies\Journaling Lowest MSExchange Messaging Policies\AttachFilter Lowest MSExchange Messaging Policies\AddressRewrite Lowest MSExchange Messaging Policies\Rules Lowest MSExchange Messaging Policies\Prelicensing Lowest MSExchange Anti-spam Update\HygieneUpdate Lowest MSExchange Management Application\Shell Lowest MSExchange Management Application\Console Lowest MSExchange OWA\FormsRegistry Lowest MSExchange OWA\Core Lowest MSExchange OWA\Configuration Lowest MSExchange OWA\Themes Lowest MSExchange OWA\SmallIcons Lowest MSExchange OWA\Proxy Lowest MSExchange OWA\Transcoding Lowest MSExchange OWA\ADNotifications Lowest MSExchange POP3\General Lowest MSExchange Process Manager\ProcessManager Lowest MSExchange Repl\Service Lowest MSExchange Repl\Exchange VSS Writer Lowest MSExchange System Attendant Mailbox\General Lowest MSExchange ADAccess\General Lowest MSExchange ADAccess\Cache Lowest MSExchange ADAccess\Topology Low M