This article is an example of a problem I might solve at work as a Microsoft Windows System Administrator/Directory Services Engineer. My goal was to use the built-in Auditing and Event Log Subscription features in Windows Server 2008 R2 to monitor when changes are made to certain Active Directory groups. The groups I wanted to track included built-in Administrators, Domain Admins, Enterprise Admins, and Schema Admins. Accomplishing this turned out to be somewhat more complicated than I expected. So, I wrote out my solution here, with references to web resources for more detail.

1. Auditing of Directory Services Changes
Reference: Advanced Security Audit Policy Settings
First, I verified that changes to Active Directory group memberships will generate events in the domain controllers’ (DC) Security log. This requires two things: an audit policy on the DCs, and a SACL on the object to be audited.

1a. Audit Policy
At an administrative command prompt on a DC, run “auditpol /get /category:*”. The output shows all audit categories and their current status. I was interested in the category “DS Access”, subcategory “Directory Service Changes”. This audit policy generates event IDs 4662 and 5136 when an Active Directory object is changed. The event 5136 includes details such as what user account made the change, and what changed.

Another option is to enable audit policy for category “Account Management”, subcategory “Security Group Management”. This audit policy generates event ID 4735 for a change to a security group. It generates event ID 4732 for member added and event ID 4733 for member removed. The events include detail of who made the change and what member was added/removed.

Audit policies can be configured on individual DCs using the auditpol.exe command line. Or, they can be configured and enforced for all DCs through Group Policy. The settings are found in the group policy editor at Computer Configuration | Policies | Windows Settings | Security Settings | Advanced Audit Policy Configuration | Audit Policies.

I chose to audit “Directory Service Changes” and monitor for event IDs 5136. I enforced the auditing through group policy, so I don’t have to set it on all DCs manually or remember to verify it on new domain controllers in the future.

1b. Audit SACL
I verified that the target groups have a System Access Control List (SACL) entry which enables auditing for the “Everyone” group for “Write all properties”/”Success”. It appears that this is a default setting.

1c. Testing
I changed membership of target groups, and verified that in fact, event ID 5136 is being logged in the Security log of the domain controller where the change was made.

The target events are just a “needle in the haystack” of all the thousands of events being logged in the DC Security log. And, there could be many DCs in a domain. In a busy Active Directory environment, security logs may be archived and/or overwritten often. Event Log Subscriptions is a tool for monitoring, filtering, capturing, and gathering the target events together.

2. Enable Windows Remote Management on Forwarder and Collector Computers
References:
Configure Computers to Forward and Collect Events
Installation and Configuration for Windows Remote Management
Enable Powershell Remoting Via Group Policy
Configuring WinRM for HTTPS
Event Log Subscriptions use the Windows Remote Management (WinRM) service to send messages between hosts. So, we must first ensure that WinRM is enabled on both the forwarder computers (DCs) and the collector computer (in my case a Win2K8R2 member server).

One method is to manually run “winrm quickconfig” at an elevated command prompt on each server. This command will enable the WinRM service with default settings and configure firewall exceptions for the default ports. Apparently, “winrm quickconfig” enables HTTP only, and does not enable the HTTPS listener. To enable HTTPS, run “winrm quickconfig -transport:https”. To see what listeners are enabled and what ports are assigned, run “winrm enumerate winrm/config/listener”.

Another method is to use group policy. In the group policy editor, browse to Computer Configuration | Policies | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service. I have not tested the WinRM GPO settings.

3. Create a Service Account and Delegate Rights
Note, this step is only required when using a “Collector Initiated” Event Log Subscription type. The “Source Computer Initiated” type does not need a service account or delegated rights. Using a service account, rather than Network Service, on the collector server helps to accomplish this task while following the principle of least privilege.

3a. Create a Service Account
This is a domain account. In my case the account name is “eventcollector”.

3b. Delegate “read” rights to the DC Security Logs
Reference: Security Descriptor Definition Language
Add “eventcollector” to the domain group “Event Log Readers”. The command “wevtutl.exe sl security” shows the current rights to the Security log in SDDL format. I think the string “(A;;CC;;;ER)” shows that the Event Log Readers group has read rights, and this is a default setting. If this is not present, the wevtutl command can add rights to the event log. I believe the Event Log Readers group has rights to view all event logs on the DCs. So, it may be possible to delegate rights even more narrowly by using wevtutl to delegate read rights only on the Security log to the service account. (That would need to be done manually on every DC, or possibly through a custom group policy security setting.)

4. Create Event Log Subscription
References:
Create a New Subscription
Security Event Log Collection From a Domain Controller
Setting up a Source Initiated Subscription
An event log subscription can be “Collector Initiated” or “Source Computer Initiated”. I prefer the “Source Computer Initiated” type for three reasons:
1. No special rights delegations are required for the collector computer. The collector does not “tell” the source computer what to do–the source reaches out to the collector to get subscription info.
2. The target subscription manager is pushed to the event source computers through group policy.
3. The source computers for the subscription can be an Active Directory group, rather than selecting individual computers.

I did have some difficulty getting the “Source Computer Initiated” method to work. I kept getting an error in the EventLog-ForwardingPlugin log of the source DCs that “A subscription policy contains invalid configuration”. It turns out I had used incorrect syntax in the GPO setting, leaving off the “Server=” keyword.

The Query Filter:
Reference: Advanced XML Filtering in the Windows Event Viewer
The basic filter settings allow filtering by event ID and source event log. But, I was still getting too many unwanted events, including all changes to all AD objects. To build a custom XML filter, go to the XML tab in the Select Events/Query Filter dialog. The XML syntax provides more flexibility and granularity, and allows one to capture only events for changes to a SPECIFIC object or objects. Now, we are talking! This example shows the XML filter syntax:

<QueryList>
  <Query Id="0">
    <Select Path="Security">
      *[System[(EventID='5136')]]
      and
      *[EventData[Data[@Name='ObjectDN']
        and
        (Data='CN=Domain Admins,CN=Users,DC=chlab,DC=net') or
        (Data='CN=Administrators,CN=Builtin,DC=chlab,DC=net') or
        (Data='CN=Enterprise Admins,CN=Users,DC=chlab,DC=net')
      ]]
    </Select>
  </Query>
</QueryList>

Caveats and Misc Notes
I realize that a knowledgeable sysadmin can circumvent this auditing method in several ways. One could disable the auditing policy, stop the event collector service, or unplug the network cable on the collector, just for starters. The groups I am auditing here are highly privileged. If a sysadmin has access and rights to modify these privileged groups, they can certainly disable and circumvent auditing if desired. If I were auditing less-privileged groups, this mechanism would have fewer such vulnerabilities.

The “Windows Event Collector” service running on the member server/event collector is set to Automatic (delayed start). The delay on system startup is about 3 minutes.

A next step could be to configure Event Log Notification to send an e-mail when these events are received by the collector.

Updated Sep. 15, 2013 to add info on enabling WinRM HTTPS listener, and to include “Source Computer Initiated” troubleshooting results.