Auditing and Logging
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.
| Tip | You never know when you are going to need historical information from logs. Plan to have a few weeks' worth when configuring logs and designing the capacity of your Exchange servers. |
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
| Tip | Event log sizes and overwrite behavior can be set centrally using a group policy object (GPO). |
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.
 |
| Event Log | Exchange Server | Domain Controller |
|---|---|---|
| Application | 147,456KB | 49,152KB |
| Security | 49,152KB | 147,456KB |
| System | 49,152KB | 49,152KB |
| PowerShell | 16,384KB | N/A |
| Directory Service | N/A | 16,384KB |
| File Replication Service | N/A | 16,384KB |
| DNS Server | N/A | 16,384KB |
Open table as spreadsheet |
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.
| Tip | Event log sizes and overwrite settings can be configured using Event Viewer on a server-by-server basis or by using an Active Directory group policy object. If you have more than one or two servers, using a GPO is much simpler. |
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.
|
| Policy | Settings |
|---|---|
| Audit Account Logon Events | Success and Failure |
| Audit Account Management | Success and Failure |
| Audit Directory Service Access | No auditing |
| Audit Logon Events | Success and Failure |
| Audit Object Access | No auditing |
| Audit Policy Change | Success and Failure |
| Audit Privilege Use | Success and Failure |
| Audit Process Tracking | Failure |
| Audit System Events | Success and Failure |
|
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
| Note | Exchange diagnostics logging information appears in the Application event log. |
Table 21.3 lists event log services and categories that you should consider enabling.
|
| Event Category | Description |
|---|---|
| MSExchangeIS\9000 Private\Logons | Audit events relating to mailbox access |
| MSExchangeIS\9000 Private\Send As | Audit events relating to the use of the Send As permission |
| MSExchangeIS\9000 Private\Send On Behalf Of | Audit events relating to a user using the Send on Behalf Of permission |
| MSExchangeIS\9000 Private\Storage Limits | Audit events indicating that mailboxes are exceeding storage limits |
| MSExchangeIS\9002 System\Move Mailbox | Audit events indicating that a mailbox has been moved |
| MSExchangeIS\9002 System\Virus Scanning | Audit events relating to virus scanning |
| MSExchangeMailboxAssistants\Email_Lifecyle_Assistants | Audit events relating to processing message records management settings |
| MSExchangeMailboxAssistants\Resource Booking Assistant | Audit events relating to the use of the resource booking assistant |
|
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:
| Get-EventLogLevel | Reports on the level of logging of the specified event category or all categories if no category is specified |
| Set-EventLogLevel | Configures the diagnostics logging level of the specified logging category |
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
EAN: 2147483647
Pages: 198