다음을 통해 공유

AD DS Auditing Step-by-Step Guide

  • 아티클

Applies To: Windows Server 2008, Windows Server 2008 R2

This guide includes a description of the new Active Directory® Domain Services (AD DS) auditing feature in Windows Server® 2008. It also provides procedures to implement this new feature.

Note

This new auditing feature also applies to Active Directory Lightweight Directory Services (AD LDS). However, this guide refers only to AD DS.

What’s new in AD DS auditing?

In Windows Server 2008 you can now set up AD DS auditing with a new audit subcategory to log old and new values when changes are made to objects and their attributes.

In Microsoft® Windows® 2000 Server and Windows Server 2003, Active Directory audit logs can show you who made changes to what object attributes, but the events do not display the old and new values. For example, the audit log can show that Joe modified his favorite drink attribute in the directory, but it cannot show his previous favorite drinks or what the attribute was after he changed it. With the new auditing feature, you can log events that show old and new values; for example, you can show that Joe's favorite drink changed from single latte to triple-shot latte.

Auditing changes to objects in AD DS

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 policy subcategory Directory Service Changes. This guide provides instructions for implementing this audit policy subcategory.

The types of changes that you can audit include a user (or any security principal) creating, modifying, moving, or undeleting an object. The new audit policy subcategory adds the following capabilities to auditing in AD DS:

  • When a successful modify operation is performed on an attribute, 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 the user adds attributes 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, the previous and new location (distinguished name) is logged for moves within the domain. 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 where the object is moved to is logged. In addition, if the user adds, modifies, or deletes attributes while performing an undelete operation, the values of those attributes are logged.

Note

When you undelete an object, you clear the isDeleted attribute and specify a new location for the object by setting the distinguishedName attribute, in a single LDAP modify operation. For more information, see Microsoft Knowledge Base article 84001 (https://go.microsoft.com/fwlink/?LinkId=89248).

  • The events that are generated by these actions appear in the Security log in Event Viewer.

Implementing AD DS change auditing

In Windows Server 2008, you implement the new auditing feature by using the following controls:

  • Global audit policy

  • System access control list (SACL)

  • Schema

Global audit policy

Enabling the global audit policy, Audit directory service access, enables all 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 Audit directory service access policy was the only auditing control available for Active Directory. The events 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 has been changed to 4662.

Note

The new audit policy subcategory Directory Service Access functions similarly to the Audit directory service access policy in Windows 2000 Server and Windows Server 2003, which was enabled for Success events by default. No other new audit policy subcategories are enabled by default so that administrators are not overburdened by additional events that they are not prepared for.

With the new audit policy subcategory Directory Service Changes, successful changes to the directory are logged along with the previous and current values. There are new event ID numbers associated with Directory Service Changes. Settings for both Directory Service Access and Directory Service Changes are stored in the Local Security Authority (LSA) database. They can be queried by using 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 on the object is still the ultimate authority in determining whether an access check must be audited or not. The SACL is the part of an object's security descriptor that specifies which operations are to be audited for a security principal.

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 what values have changed as a result of all but a few attribute modifications on a user object, you can set a flag in the schema for the attributes that you do not want audited. The searchFlags property of each attribute defines behavior such as whether the attribute is indexed or replicated to the global catalog. The searchFlags property has seven currently-defined bits.

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.

Example modify operation and log entry

The following table shows an example of how events are logged when a user modifies a group object by adding values to two attributes (description and member) and the global audit policy Audit directory service access has been enabled. In this example, you see both events 4662 and 5136 because both subcategories Directory Service Access and Directory Service Changes are enabled. However, you do not see an event 5136 for the Description field because the searchFlag attribute for the property is set to disable auditing changes.

SACL User action Audit policy settings Audit events logged

Object:

CN=GroupX,

CN=Users, <domain DN>

ACE in SACL:

{WP; AU}

Object modified:

CN=GroupX,

CN=Users,

<domain DN>

Attribute modified: Member

Operation: Add

Value: User1

Attribute modified:

Description

Operation: Add

Value: Group of users with role 'X'

Subcategory: Directory Service Access ON

Subcategory: Directory Service Changes ON

Description attribute in schema: search flag bit 8 set to disable change auditing

Event ID: 4662

Object: CN=GroupX, CN=Users, <domain DN>

Permission: Write Property

Attributes: Member; Description

Event ID: 5136

Object: CN=Group X, CN=Users, <domain DN>

Operation: Add

Attribute: Member

Value: User1

Who should use this new feature?

Domain Admins who set up the required objects that they want to audit should use this feature. In general, permissions to modify SACLs and view the Security log are given only to Administrators, including Domain Admins, Built-in Administrators, and Enterprise Admins.

Benefits of auditing changes in AD DS

If you can identify how object attributes have changed, the event logs are more useful as a tracking mechanism for changes that occur over the lifetime of an object.

How to set up AD DS auditing

This section provides step-by-step procedures for enabling auditing of changes to objects in AD DS. This process consists of two primary steps:

  • Enabling the global audit policy in Group Policy

  • Setting up auditing in object SACLs using the Active Directory Users and Computers snap-in.

This section also includes examples of Security log entries that appear when you create, modify, or move a user object and Directory Service Changes is enabled.

Prerequisites

  • User: To perform this set of procedures, you should be familiar with editing Group Policy, using the Active Directory Users and Computers snap-in, AD DS auditing, and event logs.

  • Computer: To set up auditing for changes to objects in AD DS, you must have Windows Server 2008 with the AD DS role installed on your computer.

Steps to set up auditing

This section includes procedures for each of the primary steps for enabling change auditing:

  • Step 1: Enable audit policy.

  • Step 2: Set up auditing in object SACLs by using Active Directory Users and Computers.

Step 1: Enable audit policy.

This step includes procedures to enable change auditing with either the Windows interface or a command line:

  • By using Group Policy Management, you can turn on the global audit policy, Audit directory service access, which enables all the subcategories for AD DS auditing. If you need to install Group Policy Management, click Add Features in Server Manager. Select Group Policy Management and then click Install.

  • By using the Auditpol command-line tool, you can enable individual subcategories.

To enable the global audit policy using the Windows interface

  1. Click Start, point to Administrative Tools, and then Group Policy Management.

  2. In the console tree, double-click the name of the forest, double-click Domains, double-click the name of your domain, double-click Domain Controllers, right-click Default Domain Controllers Policy, and then click Edit.

  3. Under Computer Configuration, double-click Policies, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then click Audit Policy.

  4. In the details pane, right-click Audit directory service access, and then click Properties.

  5. Select the Define these policy settings check box.

  6. Under Audit these attempts, select the Success, check box, and then click OK.

To enable the change auditing policy using a command line

  1. Click Start, right-click Command Prompt, and then click Run as administrator.

  2. Type the following command, and then press ENTER:

    auditpol /set /subcategory:"directory service changes" /success:enable

Step 2: Set up auditing in object SACLs.

The following procedure presents an example of just one of many different types of SACLs that you can set based on the operations that you want to audit.

To set up auditing in object SACLs

  1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.

  2. Right-click the organizational unit (OU) (or any object) for which you want to enable auditing, and then click Properties.

  3. Click the Security tab, click Advanced, and then click the Auditing tab.

  4. Click Add, and under Enter the object name to select, type Authenticated Users (or any other security principal), and then click OK.

  5. In Apply onto, click Descendant User objects (or any other objects).

  6. Under Access, select the Successful check box for Write all properties.

  7. Click OK until you exit the property sheet for the OU or other object.

Example audit events

This section presents examples of the new events that appear in the Security event log when you create, modify, or move a user object and Directory Service Changes is enabled.

Create a user object

If you create a new user, you see the Security event in the following figure.

Modify a user object

When you change an attribute for a user object, you see the event in the following figure.

Move a user object

If you move a user object, you see the event in the following figure.

Summary of new AD DS auditing events

The following table describes the events for each of the operations that are audited and appear in the Security event log. The table columns provide the following information:

  • Operation: Describes the AD DS operation that has the potential of generating a change audit event.

  • Event ID: The ID that each of the new events will have in the Security event log.

  • Event description: A brief description of the parameters that are logged for the particular event.

  • ACE in SACL that triggers event: The type of ACE that must be present in the SACL for the particular event to be generated. This column also describes which object should hold the ACE.

Operation Event ID Event description ACE in SACL that triggers event

Modify

5136

<Object DN>

<Operation>: Add/Delete

<Attribute name>

<Value>

For existing objects:

<Object DN> is the distinguished name of the existing object.

For new objects:

<Object DN> is the distinguished name of the new object.

For reanimated objects:

<Object DN> is the target distinguished name of the object (after the object has moved from the deleted objects container to its new location).

ACE

{Write Property; <attribute> or <property set> or blank; Trustee}

For existing objects:

ACE should be in the SACL of the object.

For new objects:

ACE should be in the SACL of the new object. The new object Security Descriptor (including the SACL) is a sum of explicitly assigned ACEs + ACEs inherited from parent + default ACEs in the schema definition of the object.

For reanimated objects:

ACE should be in the SACL of the reanimated object. The Security Descriptor (including the SACL) of a reanimated object is a sum of the SD that persisted when the object was deleted + ACEs inherited from the new parent.

Create

5137

<New Object DN>

{Create Child; <object type> or blank; Trustee}

ACE should be on parent object

Undelete

5138

<Old Object DN>

<New Object DN>

{Create Child; <object type> or blank; Trustee}

ACE should be on target parent object (not source)

Move

5139

<Old Object DN>

<New Object DN>

{Create Child; <object type> or blank; Trustee}

ACE should be on target parent object (not source)

Delete

5141

A directory service object was deleted.

Security ID:<domain>\<account name>

<object DN>

<Object GUID>

Tree delete: Yes or No

{Delete (sometimes known as Delete Self); <object type> or blank; Trustee}

ACE should be on the source object

{Delete Child; <object type or blank>; Trustee}

ACE should be on the parent object

{Delete Tree; <object type or blank>; Trustee}

ACE should be on the root object of the tree deletion.

A Delete Tree ACE on a root object does not ensure that every object included in the tree deletion will have its deletion audited. The deletion is audited only if the Delete self ACE is also on the SACL of object that is being deleted as part of the tree deletion.

Summary of attribute syntaxes

Because change audit events log old and new values, different values may have different syntaxes. The following table shows directory service attribute syntaxes and how they are represented in the Security event log.

String values have a limit on the number of bytes that will be logged in the event log. This limit prevents logs from being overloaded with large string values that could slow down the system.

Registry setting information is as follows:

  • Location: HKLM\System\CurrentControlSet\Services\NTDS\Parameters that can be configured by the administrator to control the maximum limit for strings

  • Setting name: Maximum Audit String Length

  • Type: REG_DWORD

  • Values

    • Default registry value: 1000

    • Minimum registry value: 0

    • Maximum registry value: 20480

Binary values are stripped off completely and replaced with the term <binary> (localized to the system language). Therefore, if you have an attribute called JpegPhoto and you change the photograph in this attribute, the change is logged, but the old and new value that is logged does not show the old and new photograph. Instead, it shows the term <binary>.

Syntax Attribute syntax object identifier String limit Example Notes

Distinguished Name (DN)

2.5.5.1

-

CN=Users, DC=ntdev, DC=com

 

Object Id

2.5.5.2

-

5.77.3.7

 

String (Case Sensitive)

2.5.5.3

Yes

Hello World

 

String (Case Insensitive)

2.5.5.4

Yes

Hello World

 

String (Print Case)

String (IA5)

2.5.5.5

Yes

Hello World

 

String (Numeric)

2.5.5.6

Yes

12345

 

DN-Binary

OR Name

2.5.5.7

-

B:32:3F67…:CN=User, DC=ntdev, DC=com

Will be represented as:

B:32:<binary>:CN=User, DC=ntdev, DC=com

Boolean

2.5.5.8

-

TRUE

 

Integer

Enumeration

Enumeration (Delivery-Mechanism)

Enumeration (Export-Information-Level)

Enumeration (Preferred-Delivery-Method)

2.5.5.9

-

588

 

Octet String

Object (Replica Link)

2.5.5.10

-

x5a x74 x03 …

Will be represented as:

<binary>

Time (Generalized)

2.5.5.11

(OM ID =24)

-

20010928060000.0Z

YYYYMMDD

HHMMSS.0Z

YYYYMMDD

HHMMSS.0

[+/-]HHMM

Time (UTC)

2.5.5.11

(OM ID =23)

-

910131145503Z

YYMMDDHH

MMSSZ

YYMMDDHH

MMSS[+/-]HHMM

Unicode String

2.5.5.12

Yes

Hello World

 

Presentation-Address

2.5.5.13

Yes

Hello World

 

DN-String

Access-Point

2.5.5.14

Yes*

S:32:some string:CN=Users, DC=ntdev, DC=com

*Limit applies to the string portion, not the DN portion

NT Security Descriptor

2.5.5.15

-

O:AOG:DAD:(A;;RPWPCCDCLCSWRCWDWOGA;;;S-1-0-0)

Expressed in SDDL

Large Integer

Interval

2.5.5.16

-

75859769

 

SID

2.5.5.17

-

S-1-….

SID string format

Additional resources

The following resources can help you resolve problems that you might encounter while using auditing in AD DS: