First published on TechNet on Apr 22, 2012
Sometimes, we Microsoft engineers get called into a 'forensics' type situation to help a customer try to answer the "W" questions - where someone (WHO?) did something (WHAT?) at some point (WHEN?) in Active Directory (AD) or some other aspect of a Windows infrastructure. Usually, if we get the call, the change had a big (sometimes catastrophic) negative impact on the company's business or operations.
Depending on how auditing was setup before the event, we may or may not be able to help answer those questions.
This post provides details on how I set up a Windows Server 2008 R2 Active Directory environment for effective auditing of certain AD changes. The changes I chose to audit for this post are a direct result of customer incidents and trying to answer those "W" questions. Some of the incidents resulted in massive outages such as an OU deletion executed via script that was mis-coded and deleted a root-level OU and all contents resulting in thousands of User Accounts getting deleted. Of course, there are additional items that can be audited such as:
- Creating and/or deleting objects - User Accounts, Site Links, Sites, etc
- Editing/deleting files and folders
- Users logging in and/or logging out of the Domain – this one can be tricky to pin down
- FSMO Role transfers, Directory Service Restore Mode password changes
- Domain/Forest Functional Level changes
This is a post focused on AD object auditing, so I'm not going to cover user logon/log off, file server access or other types of auditing (so little time; so many audit options).
IMPORTANT NOTES AND DISCLAIMERS:
- The event details and auditing settings in this post are specific to Windows Server 2008 R2 and are not applicable and/or different in a Windows 2000 or 2003 AD.
-
!!**WARNING**!! Improper auditing can, among other things:
- SWAMP your DCs and other servers – as with anything, vet this information out as I did - in a lab – proceed with caution .
- SWAMP your Security Event Logs on your DCs or other servers, over writing critical data required for audit compliance – proceed with caution .
- SWAMP your alerting and/or audit collection system and cause Alert storms – proceed with caution .
- Auditing is not a 'black or white' technology in Windows and there isn't always a clear answer to the "W" questions, even with auditing enabled.
- I chose not to care about failure to make changes – I only cared about successfully making changes, so I enabled SUCCESS audits but not FAILURE audits. This can help to reduce auditing noise. Some would say this reduces visibility into potential denial of service (DOS) attacks.
-
Turn on auditing at the proper levels. This, too, can help to reduce auditing noise:
-
The AD object level –
- On a partition (i.e. the configuration or domain partition object)
- On a certain OU(s) or sub OU(s)
- Other AD objects, such as a certain group or service account
-
The AD object inclusion level –
- This and every object below - "This object and all descendant objects"
- Only instances of the specific object type = "All descendant OUs"
-
-
Consider not enabling auditing for TEST/DEV objects/OUs/ PC/servers, etc
- This can help to reduce auditing noise due to frequent changes in lab environments.
- This post only brushes the surface of Auditing in Active Directory and is by no means 'all there is.'
Auditing in AD has come a long way since Windows 2000 but many customers haven't taken or had the time to set it up so that valuable data can be derived from the infrastructure. As a result, often, those WHO/WHAT/WHEN questions for sensitive and/or unexpected/unplanned changes or deletions cannot be answered with empirical evidence.
OK, let's do some stuff!!
Several things need to be addressed before AD auditing can be fruitful.
-
AD events occur on Domain Controllers; hence, we need to enable Advanced Audit Policy settings on the DCs. In my lab, I set these options in the Default Domain Controllers GPO:
Here's the relevant output of AUDITPOL /get /category: * from the DC:
Here's the setting which forces the newer granular Audit settings to prevent potential conflicts with legacy Audit settings. See the links for a further discussion of this setting: http://technet.microsoft.com/en-us/library/dd408940(v=WS.10).aspx
http://technet.microsoft.com/en-us/library/dd772710(v=WS.10).aspx
Here's one of the audit events for enabling "Success" on Directory Service Changes above (this is audited/logged by default).
Here's a screenshot of the Default Domain Controllers GPO in my lab after my changes:
-
We need to create one or more System Access Control List entries (SACLs) for what we want to audit.
- IMPORTANT – if you enable the above Audit Policy settings but don't also create SACLs, you won't get any audit events from those Audit Policies. I've seen this unpleasant 'surprise' with customers, too.
-
This is what I set in my lab for this post - adjust to meet your environment's needs/specifics:
- Open AD Users and Computers MMC (DSA.MSC)
- Right-click the Domain or the target AD Object > click Properties
- Click the Security tab > Click the Advanced button
- Click the Auditing tab
- Click Add to begin adding SACL entries
SACL Entries
Activity to Audit - Create and Delete Organizational Units (OUs)
- EVERYONE > CREATE Organizational Unit objects > DOMAIN and all descendent objects
- EVERYONE > DELETE > Descendant Organizational Unit objects
Activity to Audit - Create and Delete Computer Accounts (including a Move)
- EVERYONE > CREATE Computer objects > DOMAIN and all descendent objects
- EVERYONE > DELETE > Descendent Computer objects
Activity to Audit - Create and Delete Group Policy Objects (GPOs)
- EVERYONE > CREATE Group Policy Container objects > DOMAIN and all descendent objects
- EVERYONE > DELETE > Descendent Group Policy Container objects
Activity to Audit - Link and unlink GPOs to OUs
- EVERYONE > WRITE GPLink > DOMAIN and all descendent objects
Activity to Audit – Edit Group Memberships and/or Delete Groups
- EVERYONE > Write all properties + Delete > Descendant Group objects
SUMMARY SACL LIST TABLE
SACL list for the Domain - After the changes to my lab
- You need to consider the increased amount of data gathered as it relates to the size of the Security Event Log on your DCs. You may need to increase the size of the Security Event Log so the data doesn't roll through the Log before you even know you need it.
-
Some customers enable auditing for Everyone at the Domain level, with all descendent objects, capturing Success and Failure events on everything and think they're all set. However, when they go into the Security Event Log "looking for answers," they're stunned to realize their Security Event Logs wrap in less than 2 hours and the event data they need from the "WHAT THE &*$#@ ?!?" this morning is no longer available.
-
I'm stating the obvious here, but this depends on numerous variables such as:
-
How many objects are in the environment
- An AD with 5 users will produce a lower volume of Audit data than an AD with 50,000 users. Realize that the default Event Log sizes are the same in both cases, though.
-
How many items are being auditing
- Auditing 4 OUs for deletions will produce a lower volume of Audit data than auditing every attribute on every object in AD for success and failure.
-
-
Scenario – Linking a GPO to an OU
If someone links a GPO to an OU, it could produce dramatic results on the contents of that OU, including systems or users falling out of audit compliance. We want to be able to determine the who/what/when for the change.
- Event ID 5136 – A directory service object was modified .
-
This example lists the OU DN path and the linked-GPO's GUID
-
What OU had the link added?
- Object "DN:OU=SERVICE ACCOUNTS,OU=-PRODUCTION OU….,DC=LAB"
-
What GPO was linked to the OU?
-
Attribute:
-
LDAP Display Name "gPLink"
- Value: <GUID of the GPO>
-
-
How is this differentiated from removing a GPO Link from an OU?
- Operation Type: Value Added
-
-
NOTE: In the screenshots I've included, the relevant information to help answer the "W" questions is called out via the red boxes. I labeled this first screenshot with Who/What/When text and arrows, too, but for clarity, on the rest of the screenshots, I only used the red boxes .
You can use a DSQUERY one-liner to derive the Display Name from the GPO GUID, then use GPMC to review the new GPO, if needed.
dsquery * "cn={E83C3E6F-2864-46CD-B6C1-C29CE4D04A88},cn=policies,cn=system,DC=DOMAIN,DC=LAB" -scope base -attr displayname
SCENARIO – Deleting a GPO Link from an OU
If someone unlinks a GPO from an OU, it could produce drastic results on the contents of that OU, including systems or users falling out of audit compliance. We want to be able to determine the who/what/when for the change.
- Event ID 5136 – A directory service object was modified .
-
This example event lists the OU DN path and the un-linked-GPO's GUID
-
What OU had the link deleted?
- Object "DN:OU=SERVICE ACCOUNTS,OU=-PRODUCTION OU ….DC=LAB"
-
What GPO was unlinked from the OU?
-
Attributes to review:
-
LDAP Display Name "gPLink"
- Value: <GUID of the GPO>
- Use the same DSQUERY one-liner from the prior example.
-
-
-
How is this differentiated from linking a GPO to an OU event?
- Operation Type: Value Deleted
-
SCENARIO – Deleting a GPO
If someone deletes a GPO from AD, it could produce drastic results on the contents of the Site, Domain or OU(s) to which it is linked, including systems or users falling out of audit compliance. We want to be able to determine the who/what/when for the change.
- Event ID 5141 – A directory service object was deleted .
-
This sample event lists the DN path (which is also the GUID) for the GPO that was deleted
- I could not correlate an Event that listed the Name of the GPO that was deleted and the DSQUERY command from before won't work because the object is gone.
- I checked in the Deleted Objects Container to see if I could get the Name of the GPO from there but that attribute (along with most others) is cleared upon deletion – no luck.
- However, I was able to look in my nightly GPO Backups (you do backup your GPOs, right?) and found the GUID for the deleted GPO and got the Name from the GPOReport file that is generated during the GPO backup job.
SCENARIO – Delete an OU
If someone deletes an OU (and everything in it) can produce drastic results. We want to be able to determine who made the change.
- Event ID 5141 – A directory service object was deleted
- This example event lists the DN path of the OU deleted.
SCENARIO – Moved a computer account from one OU to another OU
This can produce drastic results on the system moved (i.e. a critical application server), including systems or users falling out of audit compliance. We want to be able to determine the who/what/when for the change.
-
Event ID 5139 – A directory service object was moved .
- This sample event lists the old and new DN path for the Computer Account.
-
How do we know it was a Computer Account move?
- Object > Class: computer
SCENARIO – An OU was moved (possibly drag-n-dropped on accident?)
Moving an OU (and its contents) can produce drastic results on the systems/users in the OU(s). This includes systems or users falling out of audit compliance. We want to be able to determine the who/what/when for the change.
-
Event ID 5139 – A directory service object was moved .
- This sample event lists the old and new DN path for the OU.
-
How do we know it was an OU move?
- Object > Class: organizationalUnit
SCENARIO – Editing a Group's membership
If someone edits membership to sensitive Groups in AD (such as Domain Admins, Enterprise Admins or others), it could produce drastic results, including systems or users falling out of audit compliance. We want to be able to determine the who/what/when for the change.
- Event ID 5136 – A directory service object was modified .
- This sample event lists who was added or removed from the group
-
Group Member Added
- Operation > Type > Value Added
-
Group Member Removed
- Operation > Type > Value Deleted
SCENARIO – Deleting a Group
If someone deletes a critical Group in AD, it could produce drastic results, including systems or users falling out of audit compliance. We want to be able to determine the who/what/when for the change.
- Event ID 5141 – A directory service object was deleted .
- This sample event lists the DN path of the group deleted.
BONUS AD Auditing nuggets
If you've stuck with me this long, you must enjoy this stuff as much as I do! So, just between us, here are a few bonus Events for AD environment 'awareness'
Domain Functional Level changed (two events)
- Directory Services Event Log Entry
- Security Event Log Entry
Forest Functional Level Changed (two events)
- Directory Services Event Log Entry
- Security Event Log Entry
Directory Services Restore Mode DC Boot-up
RID FSMO Role Transfer
From the prior FSMO Role DC – Directory Service Event Log – notice the "User"
From the new FSMO target DC – Directory Service Event Log – notice the "User"
Domain Naming Master FSMO Transfer
PDCE FSMO Transfer
Infrastructure Master FSMO Transfer
Schema FSMO Transfer
Links:
Eric Fitzgerald’s Blog - http://blogs.msdn.com/b/ericfitz/
- Minimizing audit noise -http://blogs.msdn.com/b/ericfitz/archive/2005/01/11/350848.aspx
- Auditing GPOs - http://blogs.msdn.com/b/ericfitz/archive/2005/08/04/447951.aspx
- Audit changes to Audit Policy - http://blogs.msdn.com/b/ericfitz/archive/2010/07/16/auditing-changes-to-audit-policy.aspx
- Auditing impact on system performance - http://blogs.msdn.com/b/ericfitz/archive/2009/08/10/auditing-system-impact-on-performance.aspx
TechNet
Advanced Auditing - http://technet.microsoft.com/en-us/library/cc731607(v=WS.10).aspx
AD Object Auditing - http://technet.microsoft.com/en-us/library/cc773209(v=WS.10).aspx
Advanced Security Auditing - http://technet.microsoft.com/en-us/library/dd408940(v=WS.10).aspx
Block accidental deletion of OUs – http://technet.microsoft.com/en-us/library/ee617237.aspx
- Look into the “ProtectedFromAccidentalDeletion” switch
Advanced Auditing FAQ - http://technet.microsoft.com/en-us/library/ff182311(WS.10).aspx
- Compares legacy and new Audit Policies and how they interaction
Related Ask PFE post – Part One of a two-part series on a real-world forensics scenario –
Go-Dos
- Get into a lab and run through some of this – a small lab running one DC VM is all you need.
- Once you’re comfortable with the inputs/outputs in your lab, collaborate with your IT peers/teams and consider rolling out some changes to your Production environment.
- Consider combining this information with Event Forwarding/Subscriptions for small-scale environments or a true Audit/Alerting/Monitoring solution such as Ops Manager to achieve near real-time Alerting delivered to a Console and/or a monitored mailbox and ….
KNOW what's happening in your AD!
Additional Screenshot - showing actual User ID
Updated Feb 07, 2020
Version 3.0MichaelHildebrand
Microsoft
Joined August 13, 2018
Core Infrastructure and Security Blog
Follow this blog board to get notified when there's new activity