I still find new implementations proceeding without directory service access auditing enabled. For me, auditing of who does what, where and when in your directory is crucial information. I can’t fully fathom why Microsoft doesn’t have it enabled with some sensible defaults out of the box, but maybe that’s just me. If you download and install Microsoft’s Security Compliance Manager 3.0, the Domain Controller baseline contains good auditing defaults. Anyway, here is a quick “how to” guide for enabling basic directory service access auditing in Windows Server 2012 R2 Active Directory.
Getting auditing going is done in two key steps.
- Configuring Group Policy with the appropriate auditing settings
- Configuring the System Access Control List (SACL) at the appropriate level(s) in the directory
Ok, let’s get started with the first item (Group Policy). For this, you will need a GPO linked to the Domain Controllers OU. You can either use the Default Domain Controllers Policy or create a new one specifically for auditing. My preference is to leave the DDCP at its defaults and create a new GPO with the settings.
Before the days of granular auditing settings you would configure your directory service access auditing under:
Computer Configuration->Policies->Windows Settings->Security Settings->Local Policies->Audit Policy
These settings belong to the dark days of pre-Windows Server 2008 when only the 9 auditing categories were available. You don’t want to use this setting. Instead you want to use the more granular auditing sub-categories introduced first in Windows Server 2008.
The first thing you need to do is enforce the use of the sub-categories in case someone unwittingly turns on the legacy auditing mentioned above. To do this, enable the following setting:
Computer Configuration->Policies->Windows Settings->Security Settings->Local Policies->Security Options->Audit: Force audit policy subcategory settings….[it goes on a bit, but you get the picture]
Now we need to enable auditing for the specific sub-categories we are interested in. To do this go to:
Computer Configuration->Policies->Windows Settings->Security Settings->Advanced Audit Policy Configuration->Audit Policies->DS Access
… and enable Audit Directory Service Access. I would also enable Audit Directory Service Changes as that can provide you with complementary audit events, including before and after information for changed attribute values (really very useful). Success and Failure? Perhaps, but unless you have firm requirements to capture failure events then just choosing Success can save the reduce the number of events generated.
Right, remember to link your new GPO to the Domain Controllers OU and that’s it for the GPO side of things. You might be thinking that’s all you need to do, but unless you’ve done part 2 you won’t see the required events generated.
Now you might be interested in just certain parts of your directory, but if you don’t have an obvious place to begin, consider turning on audit records from the top of your domain partition. To do this, open the Active Directory Administrative Centre (dsac). Yes, yes, you could use dsa.msc or adsiedit.msc too.
Right-click the top of the domain tree (“contoso” in my case) and bring up the properties. Under Extensions you will see the Security tab. From there select Advanced and then choose the Auditing tab. If you want to be comprehensive, I would select the Everyone security principal, set Type to Success and Applies to: This object and all descendant objects. For the permissions, again if you want to be comprehensive, set the following:
- Write all properties
- Delete subtree
- Modify permissions
- Modify owner
- All validated writes
- All extended writes
- Create all child objects
- Delete all child objects
Once you have applied the changes you’re pretty much ready to go. You should now start to see comprehensive directory access events as well as the before and after values for changed objects.
One thing you might not be aware of is that there was a bug in the RTM version of Windows Server 2012 R2 which meant that the directory service change information events did not get captured. Of course, by now you will have your R2 servers fully patched, but just in case you are still running RTM be aware that you will need the download from KB2887595 for the change information to be available.
Bear in mind that, if you have a lot of auditing going on in your security logs on your DCs, the events are going to be overwritten pretty regularly even if you beef up the size of your security event log. As part of defining your audit strategy you should work out your requirements for storing key events. There are a number of ways to do that, including leveraging some kind of centralised audit collection system (or SIEM), but that’s beyond the scope of this article.