Traditionally, neither the industry nor administrators care much about learning how to monitor changes in the Microsoft Exchange Server directory, even though Exchange Server 5.5 provides an assortment of useful auditing tools for tracking user activity. Exchange Server automatically tracks several low-level security events involving such changes. But by taking advantage of Exchange Server's built-in diagnostics logging options, you can easily bump up your security-auditing power to track and report the use of permissions to access, modify, or delete objects in the directory.
You might think, "My organization's Windows NT event logs are already bursting with events. Why add more?" If your organization has multiple Exchange Server administrators, you might want a tracking mechanism that lets you determine who made certain changes. (To provide the most secure system possible, each administrator should have a separate logon account.) Logging is also an important administrative component that can provide an easy-to-store documented history of activity, help you understand how users interact with Exchange Server, and—depending on your organization—help you meet government, industry, or internal compliance regulations.
Enabling Diagnostics Logging
The Exchange Server 5.5 directory comprises objects such as mailboxes, distribution lists (DLs), connectors, and servers. Exchange Server 5.5 diagnostics logging monitors changes to these objects. By default, Exchange Server 5.5 logs a minimal number of low-level security events but logs important security-related events only after you enable advanced diagnostics logging. Although you might expect such events to appear in the NT Security log, Exchange Server 5.5 logs these events to the Application log. (Exchange Server is an application, after all.) Therefore, before you set up diagnostics logging, you need to review and possibly modify your NT event-log configuration. (See the sidebar "Managing NT Event Logs," page 80, for suggested modifications.)
To enable diagnostics logging, you can choose between two methods. The first method provides access to logging configuration for the Directory Service (DS), the private store, and the public store. To use this method, open Microsoft Exchange Administrator, select an Exchange Server system, click Properties (or select File, Properties from the menu bar), and go to the Diagnostics Logging tab. The second method is similar to the first but lets you configure logging for only one of the three components (e.g., the private store only). To use this method, open Exchange Administrator, select a component (i.e., the DS, public store, or private store), open the Properties dialog box, and go to the Diagnostics Logging tab.
The Diagnostics Logging tab's options offer an extremely powerful way to report Exchange Server activity. (Some of the options are verbose and might require an increase in event-log size.) Four logging levels are available: None, Minimum, Medium, and Maximum. By default, Exchange Server turns off security diagnostics logging (i.e., the default Logging level is None). To zero in on object security, use the second method to go to the DS's Diagnostics Logging tab, which Figure 1 shows, and select Security from the Category list. In the Logging level box, select Maximum and click OK. To effectively log security changes, you must set the Logging level to Maximum; a lesser setting can cause missed events. You don't need to restart the DS after you enable logging.
As Figure 2 shows, Exchange Server diagnostics-logging categories also appear in the registry under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\%servicename%\Diagnostics subkey. A specific value reflects the selected logging level: 0 for None, 1 for Minimum, 3 for Medium, or 5 for Maximum.
Tracking Basic Events
Even if you don't enable Exchange Server diagnostics logging, you can view certain security-related events and track changes to Exchange Server objects in the DS. Exchange Server 5.5 can track logon-related events (when a user accesses another user's mailbox) and permissions-related events (when permissions to an object change).
Logon-related events. When a user initially opens a new Microsoft Outlook session and connects to another user's mailbox, Exchange Server logs event ID 1016. Event ID 1016's source is the Directory Store.
Event ID 1016 isn't always a cause for concern; users can have legitimate permissions to another mailbox (e.g., administrative assistants often have access to their managers' mailboxes). The event also flags many day-to-day Exchange Server occurrences. Messaging API (MAPI) agents, the Microsoft Mailbox Cleanup Agent, failed attempts to open mailboxes, and attempts to view other users' calendar information all generate event ID 1016, for example. However, if you see this event for a mailbox that no one else should have access to, you might want to investigate.
Permissions-related events. When permissions to an object change, knowing who made the change and when the change occurred can be helpful. For example, suppose you receive a call from the company CEO, who tells you that she's found messages that she didn't send in her Sent folder and that messages in her Inbox have disappeared. You know that no one else should have permissions for her mailbox. You open Exchange Administrator, select the CEO's mailbox, click Properties, go to the Permissions tab—and discover that another account now has User permission for the mailbox. To determine who altered the permissions on the CEO's mailbox, you can search the Application log for event ID 1175, which Exchange Server logs when permissions change on Exchange Server objects or on containers such as the site or organization. (Figure 3 shows an example of the event.) The event's source appears as MSExchangeDS, which is the DS reference in the registry under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services subkey. The event's User field lists the user who generated the event (i.e., the user who changed the permissions—avoid granting permission to modify Exchange Server to generically named accounts so that you can track down listed users). The Description field contains the modified object's distinguished name (DN) so that you can determine which object changed.
Although you can track the previous security-related events without enabling diagnostics logging, such basic tracking offers limited details (e.g., Exchange Server logs event ID 1175 only when existing permissions change). Security auditing is naturally more robust when you enable diagnostics logging. For example, when you enable advanced logging, the change to the CEO's mailbox also causes Exchange Server to log event ID 1053. This event is similar to event ID 1175, but event ID 1053 tracks the use of permissions rather than only changes to existing permissions.
Tracking Advanced Events
Administrators often grant users (or other administrators) various roles depending on what the user needs to administer. Roles can embody several permissions to Exchange Server objects. For example, the Exchange Admin role has the following permissions: Add Child, Modify User Attributes, Modify Admin Attributes, Delete, and Logon Rights. (For more information about Exchange Server roles, rights, and permissions, see the Microsoft article "XADM: Microsoft Exchange Roles, Rights, and Permissions" at http://support.microsoft.com/support/kb/articles/q168/ 7/53.asp.) By logging the use of these permissions, diagnostics logging lets you proactively track additions, modifications, and deletions of Exchange Server objects in the directory.
Added objects. The Add Child permission grants users the right to add Exchange Server objects. For example, suppose a user adds a mailbox pauln to the directory. When you've enabled diagnostics logging, this action causes Exchange Server to log event ID 1053 with the following description: The security descriptor granted 0x1 access on object /o=Corporation X/ou= CORP/cn=Recipients. The event's User field lists the user who added the mailbox. An event ID 1053 with a description containing the text 0x1 also appears when a user adds a DL or a connector.
This occurrence of event ID 1053 doesn't reveal the name of the created object—only that the creation occurred. However, Exchange Server stores the date and time of the object's creation in the object's When-Created attribute. You can use this information to determine who created the object. For example, suppose you discover an event ID 1053 that records the creation of a Recipient object. To find which Recipient the event refers to, open Exchange Administrator, view the Recipients container, and select View, Columns from the menu bar. Search the Created column for a date and time that match the date and time when Exchange Server logged event ID 1053.
Modified objects. An object, such as a mailbox, contains user attributes and admin attributes. Specific permissions control who can modify user or admin attributes in the directory. For example, if the Help Desk NT group has the Modify User Attributes permission in the Recipients container, that group can make changes to user-based attributes for any Recipient object. To determine the required permission to modify an object's attribute, you need to view the object's raw properties. Open Exchange Administrator in raw mode (i.e., run admin.exe with the /r switch). Select the object, then select File, Raw Properties from the menu bar. Choose an attribute from the Object attributes list. Each attribute maintains a separate access category; as Figure 4 shows, the Access category field will specify User or Admin. (This field might also include System or Security Admin.) The event ID's description lists the modified object's DN. However, the event doesn't specify how the user modified the attribute.
When a user successfully modifies a user attribute, Exchange Server logs event ID 1053; the description will contain the text 0x2. When a user successfully modifies an Admin attribute, Exchange Server logs event ID 1053 with a description containing the text 0x4. When a user successfully modifies an object's Permissions tab, Exchange Server logs event ID 1053 with a description containing the text 0x80.
Deleted objects. When a user with the Delete permission deletes an object, Exchange Server logs an event ID 1053. In this instance, the event's description contains the text 0x10000.
Directory access. You might also notice event ID 1053 when someone opens Exchange Administrator. This instance of the event's description contains the text 0x20. Such an occurrence records the Logon Rights permission.
All these events can help you determine who created, modified, or deleted specific objects. Enabling security diagnostics logging can also help you determine who made changes to DLs. Suppose a senior executive has ownership of a DL that he or she wants to solely main-tain, but an administrator accidentally modifies the list. If you've enabled diagnostics logging, you can track down the administrator who modified the object.
Beyond enabling diagnostics logging to track user activity, you can audit the use of Outlook's Send As and Send on Behalf features. To do so, enable diagnostics logging for the Private Send On Behalf Of and Private Send As categories for the MSExchangeIS Service.
Reporting and Notification of Changes
Regardless of your organization's size, I recommend that you create a daily report of changed user objects. This report can alert you to inappropriate changes—to a mailbox, for example.
One method to create such a report is to combine Dumpel from the Microsoft Windows NT Server 4.0 Resource Kit and Qgrep from the Microsoft Windows 2000 Server Resource Kit. (Qgrep also works in NT.) Dumpel is a command-line tool that outputs event logs to the screen or a file. Qgrep is based on the UNIX Grep command and matches patterns in text strings. (As an alternative, check out Mortice Kern Systems' MKS Toolkit for System Administrators. This tool provides Grep, as well as several other UNIX-based utilities, for use with Windows OSs.) You can then add a command to email the report results to the appropriate administrators or to a public folder.
For example, to create a report that lists changes made to the alias BobCEO, you can create the following batch file, permrept.bat:
This batch file first uses Dumpel to search the Application log for any event ID 1053 entries with a source of MSExchangeDS that occurred over the past day and to output the information to a text file. The batch file then uses Qgrep to search that text file for any references to BobCEO (the y switch tells the tool to ignore letter case) and output any results to another text file. Next, the batch file uses Infradig Systems' Postie to mail the Qgrep results file to the Exchange Server administrators. You can use the At command to schedule the batch file to run at 11:59 p.m. each night so that the d 1 switch will capture exactly 1 day. For this example, you might see the following reported results:
Only the Beginning
Diagnostics logging opens up a whole new world of understanding how Exchange Server performs. Monitoring security-related events on your Exchange Server machines is one of the best ways to keep up with activity within your Exchange Server directory. To get the best results, review your event-log configuration, enable diagnostics logging, and create and review daily reports.
