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:
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:
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.
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:
SACL Entries
Activity to Audit - Create and Delete Organizational Units (OUs)
Activity to Audit - Create and Delete Computer Accounts (including a Move)
Activity to Audit - Create and Delete Group Policy Objects (GPOs)
Activity to Audit - Link and unlink GPOs to OUs
Activity to Audit – Edit Group Memberships and/or Delete Groups
SUMMARY SACL LIST TABLE
SACL list for the Domain - After the changes to my lab
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.
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.
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.
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.
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.
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.
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.
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.
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)
Forest Functional Level Changed (two events)
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/
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
Advanced Auditing FAQ - http://technet.microsoft.com/en-us/library/ff182311(WS.10).aspx
Related Ask PFE blog post – Part One of a two-part series on a real-world forensics scenario –
Go-Dos
KNOW what's happening in your AD!
Additional Screenshot - showing actual User ID
Great post! Hopefully something similar can be provided for bad passwords, account lockout.
another probably obvious consequence here: if you still have multiple folks sharing the same account for admin tasks (like you have "Administrator" on every screenshot) no auditing can ever help you, no matter how detailed or well-thought of it is.
CypherBit - thanks. We'll see if I, or someone else, picks up the bad password/account lockout and other auditing situations for a post.
Pronichkin - indeed, shared accounts are poor practice and make auditing less useful. I should have re-named the Administrator account prior to all the lab work (I can't believe I didn't do that) - HOWEVER - unlike in days past, where the Event detail would not show the actual ID, these Events DO show the actual login ID of the user who made the change. So, in my screenshots, the ID of the account used was actually "Administrator."
To illustrate that we actually capture the login ID that made the change, I've added a screenshot to the bottom of the post showing that ALTMHILDE was the account that actually made the change (deleted an OU in this case).
Cheers!
great post
Relevant and detailed post .