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.
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.
.gif) 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.