AD DS: Auditing
Applies To: Windows Server 2008
In the Windows Server® 2008 operating system, you can now set up Active Directory® Domain Services (AD DS) auditing with a new audit policy subcategory (Directory Service Changes) to log old and new values when changes are made to AD DS objects and their attributes.
Note
This new auditing feature also applies to Active Directory Lightweight Directory Services (AD LDS). However, this discussion refers only to AD DS.
What does AD DS auditing do?
The global audit policy Audit directory service access controls whether auditing for directory service events is enabled or disabled. This security setting determines whether events are logged in the Security log when certain operations are carried out on objects in the directory. You can control what operations to audit by modifying the system access control list (SACL) on an object. In Windows Server 2008, this global audit policy is not enabled by default. Although the subcategory Directory Service Access is enabled for success events by default, the other subcategories are not enabled by default.
If you define this policy setting (by modifying the default Domain Controllers Policy), you can specify whether to audit successes, audit failures, or not audit at all. Success audits generate an audit entry when a user successfully accesses an AD DS object that has a SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an AD DS object that has a SACL specified.
You can set a SACL on an AD DS object on the Security tab in that object's properties dialog box. Audit directory service access is applied in the same manner as Audit object access; however, it applies only to AD DS objects and not to file system objects and registry objects.
Who will be interested in this feature?
This feature applies to AD DS administrators who are responsible for setting up auditing in the directory. Administrators set appropriate SACLs on the objects that they want to audit.
In general, permissions to modify SACLs and view the Security log are assigned only to members of the Administrators groups, including Domain Admins, Builtin\Administrators, and Enterprise Admins.
What existing functionality is changing?
Windows Server 2008 is adding the capability of AD DS auditing to log old and new values of an attribute when a successful change is made to that attribute. Previously, AD DS auditing only logged the name of the attribute that was changed; it did not log the previous and current values of the attribute.
Auditing AD DS access
In Windows 2000 Server and Windows Server 2003, there was one audit policy, Audit directory service access, that controlled whether auditing for directory service events was enabled or disabled. In Windows Server 2008, this policy is divided into four subcategories:
Directory Service Access
Directory Service Changes
Directory Service Replication
Detailed Directory Service Replication
The ability to audit changes to objects in AD DS is enabled with the new audit subcategory Directory Service Changes. The types of changes that you can audit are create, modify, move, and undelete operations that are performed on an object. The events that are generated by these operations appear in the Security log.
This new policy subcategory adds the following capabilities to auditing in AD DS:
When a successful modify operation is performed on an attribute of an object, AD DS logs the previous and current values of the attribute. If the attribute has more than one value, only the values that change as a result of the modify operation are logged.
If a new object is created, values of the attributes that are populated at the time of creation are logged. If attributes are added during the create operation, those new attribute values are logged. In most cases, AD DS assigns default values to attributes (such as sAMAccountName). The values of such system attributes are not logged.
If an object is moved within a domain, the previous and new location (in the form of the distinguished name) is logged. When an object is moved to a different domain, a create event is generated on the domain controller in the target domain.
If an object is undeleted, the location to which the object is moved is logged. In addition, if attributes are added, modified, or deleted during an undelete operation, the values of those attributes are logged.
Note
If an object is deleted, no change auditing events are generated. However, an audit event is generated if the Directory Service Access subcategory is enabled.
After Directory Service Changes is enabled, AD DS logs events in the Security event log when changes are made to objects that an administrator has set up for auditing. The following table describes these events.
| Event ID | Type of event | Event description |
|---|---|---|
5136 |
Modify |
This event is logged when a successful modification is made to an attribute in the directory. |
5137 |
Create |
This event is logged when a new object is created in the directory. |
5138 |
Undelete |
This event is logged when an object is undeleted in the directory. |
5139 |
Move |
This event is logged when an object is moved within the domain. |
Why is this change important?
The ability to identify how object attributes change makes the event logs more useful as a tracking mechanism for changes that occur over the lifetime of an object.
What works differently?
In Windows Server 2008, you implement the new auditing feature by using the following controls:
Global audit policy
SACL
Schema
Global audit policy
Enabling the global audit policy Audit directory service access enables all the directory service policy subcategories. You can set this global audit policy in the Default Domain Controllers Group Policy (under Security Settings\Local Policies\Audit Policy). In Windows Server 2008, this global audit policy is not enabled by default. Although the subcategory Directory Service Access is enabled for success events by default, the other subcategories are not enabled by default.
In Windows 2000 Server and Windows Server 2003, the policy Audit directory service access was the only auditing control available for Active Directory. The events that were generated by this control did not show the old and new values of any modifications. This setting generated audit events in the Security log with the ID number 566. In Windows Server 2008, the audit policy subcategory Directory Service Access still generates the same events, but the event ID number is changed to 4662.
With the new audit policy subcategory Directory Service Changes, successful changes to the directory are logged along with the previous and current attribute values. Settings for both Directory Service Access and Directory Service Changes are stored in the Local Security Authority (LSA) database. They can be queried with new LSA application programming interfaces (APIs).
The two audit subcategories are independent of each other. You can disable Directory Service Access and still be able to see change events that are generated if the subcategory Directory Service Changes is enabled. Similarly, if you disable Directory Service Changes and enable Directory Service Access, you can see Security log events with the ID number 4662.
You can use the command-line tool Auditpol.exe to view or set audit policy subcategories. There is no Windows interface tool available in Windows Server 2008 to view or set audit policy subcategories.
SACL
The SACL is the part of an object's security descriptor that specifies which operations are to be audited for a security principal. The SACL on the object is still the ultimate authority in determining whether an access check must be audited or not.
The content of the SACL is controlled by security administrators for the local system. Security administrators are users who have been assigned the Manage Auditing and Security Log (SeSecurityPrivilege) privilege. By default, this privilege is assigned to the built-in Administrators group.
If there is no access control entry (ACE) in the SACL requiring attribute modifications to be logged, even if the Directory Service Changes subcategory is enabled, no change auditing events are logged. For example, if there is no ACE in a SACL requiring Write Property access on the telephone number attribute of a user object to be audited, no auditing events are generated when the telephone number attribute is modified, even if the subcategory Directory Service Changes is enabled.
Schema
To avoid the possibility of an excessive number of events being generated, there is an additional control in the schema that you can use to create exceptions to what is audited.
For example, if you want to see changes for all attribute modifications on a user object—except for one or two attributes, you can set a flag in the schema for the attributes that you do not want audited. The searchFlags property of each attribute defines whether the attribute is indexed, replicated to the global catalog, or some other such behavior. There are seven currently defined bits for the searchFlags property.
If bit 8 (zero-based indexing; value 256) is set for an attribute, AD DS will not log change events when modifications are made to the attribute. This applies to all objects that contain that attribute.
What settings have been added or changed?
There are new registry key settings and Group Policy settings for AD DS auditing.
Registry settings
The following registry key values are used to configure AD DS auditing.
| Setting name | Location | Possible values |
|---|---|---|
MaximumStringBytesToAudit |
HKEY_LOCAL_MACHINE\ System\CurrentControlSet\ Services\NTDS\Parameters |
|
Group Policy settings
You cannot view the audit policy subcategories with the Local Group Policy Editor (GPedit.msc). You can only view them with the command-line tool Auditpol.exe. The following example auditpol command enables the audit subcategory Directory Service Changes:
auditpol /set /subcategory:"directory service changes" /success:enable