Delegating the Administration of Windows Server 2008 Active Directory Domain Services
- 3/5/2008
Auditing the Use of Administrative Permissions
Delegating administrative tasks in AD DS results in the need to be able to monitor and audit the use of administrative permissions throughout the directory structure. Auditing serves at least two primary purposes. First of all, it provides evidence for changes that have been made to the directory. If a change has been made to the directory, you may need to track down who has made the change. This is especially important if an incorrect or malicious change has been made to the domain information. A second purpose for auditing is to provide an additional check on the administrative permissions being exercised throughout the domain. By examining audit logs occasionally, you can determine if someone who should not have administrative rights is in fact exercising such rights.
When AD DS events are audited, entries are written to the Security log on the domain controller. You can then use the Event Viewer to view events that Windows Server 2008 logs in the Security log. You can also save events to an event file that can be used to archive and track trends over time.
There are two steps involved in enabling auditing of changes made to Active Directory objects—configuring the audit policy for domain controllers and configuring the SACL on specific Active Directory objects which are to be audited. These two steps are discussed in the following sections.
Configuring the Audit Policy for the Domain Controllers
Your first step for enabling auditing is to configure the audit policy for the domain controllers. This can be configured on the Default Domain Controllers Policy found within the Group Policy Management console. When you open the Group Policy Management console, browse to the Group Policy Objects container. In the details pane, you can right-click Default Domain Controllers Policy and then click Edit to open the Group Policy Management Editor. From the Group Policy Management Editor, you can browse to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies and then click Audit Policy. Figure 9-16 shows the default auditing configuration in Windows Server 2008 AD DS.
Figure 9-16 Configuring auditing on the Default Domain Controllers OU.
To audit changes to Active Directory objects, you need to enable and configure the Audit Directory Service Access policy. When this policy is enabled and configured, all modifications made to Active Directory objects are reported in the Security log. You can audit both successful changes to Active Directory objects and failed attempts at modifying Active Directory objects.
In Windows 2000 Server and Windows Server 2003, the Audit Directory Service Access policy was the primary option used to audit directory service events. Windows Server 2008 divides this policy into four subcategories:
Directory Service Access
Directory Service Changes
Directory Service Replication
Detailed Directory Service Replication
Dividing the Audit Directory Service Access policy into four subcategories provides more granular control on what is or is not audited in relation to directory service events. Enabling the Audit Directory Service Access policy enables all the directory service policy subcategories. To modify the subcategories, you cannot use the Group Policy Object Editor. You can only view and modify the subcategories with the command-line tool Auditpol.exe. For example, if you want to view all of the possible categories and subcategories, type the following line at the command prompt, and then press Enter:
auditpol /list /subcategory:*
Configuring Auditing on Active Directory Objects
The second step to configuring Active Directory object auditing is to enable auditing directly on the SACL of each Active Directory object to be audited. To enable Active Directory object auditing, access the object’s Properties sheet through the appropriate Active Directory administrative tool. Then, click the Security page, click Advanced, and click the Auditing page. Figure 9-17 shows the interface for the Active Directory Users And Computers administrative console and the default audit setting for an OU in Active Directory.
To add additional auditing entries, click Add and select which users or groups and what actions you want to audit. In most cases, you should select the Everyone group so that modifications made by anyone can be audited. Then you can select which activities you want to audit. You can audit all modifications made to any object in the container, to specific types of objects, or to specific properties. You can enable the auditing of all successful modifications, of all failed attempts to make modifications, or both. If you audit all successful modifications, you will have an audit trail for all changes made to the directory. If you enable failed attempts, you will be able to monitor any illicit attempts to modify directory information. After auditing is enabled, all of the audit events are recorded in the Security log accessible through the Event Viewer.
Figure 9-17 Configuring auditing on Active Directory objects.
Enabling auditing is easy. Managing auditing is much more difficult. If you enable the auditing of all directory modifications at the domain controller OU level, the Security log will grow very rapidly. Almost all of the events will be legitimate changes and thus of no interest to you except as an audit trail. However, interspersed among the legitimate changes may be a small number of changes that you need to be aware of. The problem is finding the few interesting audit events among the large number of routine events. In some companies, one administrator may be given the task of reviewing the event logs every day. A better way to deal with this is to create some automated way of centralizing and analyzing the event logs. Another way is to use a tool such as Microsoft System Center Operations Manager (a separate product available for purchase) to filter the events and raise alerts only on the interesting events.