Audit your Active Directory environment to ensure the security of your company’s most valuable assets. Here are the top 10 events to audit in Active Directory to identify risks.
Active Directory provides authentication, account management, and authorization services that are critical for strong access governance. To quickly detect insider threats, organizations should audit the creation of new accounts and security groups, and any modifications to existing users and groups.
Preventing attackers from gaining access to Active Directory is crucial for the protection of data and line-of-business applications because it controls access to all your organization’s critical data, infrastructure, and applications. Failure to protect data and applications can lead to costly downtime, reputational damage, and hefty fines from regulatory bodies and government.
Depending on the auditing settings, the Event Log of a domain controller can become cumbersome to review. Generally, utilizing a product such as Semperis Directory Services Protector or Microsoft System Center Operations Manager (SCOM) is advised. Semperis can actively monitor AD changes and identify indicators of compromise.
SCOM can be configured to selectively collect specific events from the Event Viewer to limit the amount of “information overload” one can get when reviewing security logs in Windows. In both cases, integration with a SIEM (Security Information and Event Management) can greatly simplify the data you have collected. Splunk, Azure Log Analytics, and Microsoft Sentinel are just a few common options that can allow administrators to create useful dashboards to present data taken from the event logs and turn it into something that can help quickly identify, for instance, user accounts that may be failing to log in repeatedly.
Seeing an organized overview of the data makes it easier for IT Pros and managers to monitor potential configuration issues and threats, and to take appropriate action.
Because it has been around for almost 25 years, there are well-established best practices for how and what events to audit in Active Directory. I recommend reading through Microsoft’s documentation on the subject to get an idea of where you should start. For example, read through Microsoft’s Active Directory audit policy recommendations to get an idea of where you should start.
Let me start by explaining how to enable auditing in Active Directory.
The core mechanics of auditing Active Directory haven’t changed much over its long life. Starting in server 2008, new “Advanced Auditing Policy” options were added to replace the legacy Audit settings from Server 2000 and 2003. There are new domain and forest functional levels but the core process is essentially the same, a mixture of configuring the Advanced Auditing Settings and also setting the SACLS (System Access Control List) in the directory to specify specific audit settings for the domain or a specific Organizational Unit (OU) for instance. It is important to not configure both the legacy Audit settings and the newer Advanced Auditing settings at the same time.
Here are the top 10 events to audit in Active Directory.
Monitoring the creation of processes can be useful during a security incident. The auditing of Process Creation and Process termination can be “busy”. So, it is usually recommended to monitor for such things if a compromise is suspected.
In the past, using the legacy auditing settings, one would have configured monitoring of process creation in the Group Policy location I list below. However, these days, it is recommended that first you only utilize legacy or advanced auditing, not both at the same time. And it is recommended that you use Advanced Auditing settings.
To identify the legacy audit settings, use the Group Policy Management Editor (GPME) tool in the Group Policy Management Console (GPMC).
However, as mentioned before it is recommended that you only configure the audit settings from the Advanced Audit Policy located at Computer Configuration > Windows Settings > Advanced Audit Policy Configuration > Audit Policies. To monitor process creation browse further under Detailed Tracking and enable Audit Process Creation.
Auditing ‘Privilege Use’ in Active Directory means every time a user exercises a user right, such as logging on to a computer with the ‘Allow log on locally’ right or if a Windows service logs in to a computer, you’ll get a logged event. Yes, this can be very high volume. But, privilege use certainly should be audited, monitored, and aggregated into your SIEM infrastructure so you can monitor for crucial instances of these events.
Although a user logging on to a computer is not necessarily a ‘critical event’, it could be the first sign of an intrusion in your network. A user inappropriately logging on as a service could also constitute a security incident.
Be sure to utilize your SIEM solution to at least capture these events so they can be reconciled. Be warned – this can get chatty and potentially consume a good deal of CPU and memory resources on your domain controllers (DCs) if ALL the audit settings are enabled. So, be sure to audit only the privilege events that you feel would benefit your security team.
In the Advanced Audit Policy, one can find Privilege Use audit settings under the Privelege Use category.
Group Policy provides a central system for configuring your computers and servers. Some very important system-created Group Policy Objects (GPOs) should be monitored with robust alerting capabilities. Namely the ‘Default Domain Controllers Policy’, as by default this policy holds the security policy and Active Directory auditing settings.
What sounds better to you? Combing through reams of audit logs or event logs, or letting Semperis Directory Services Protector (DSP) tool do it for you? This helpful feature not only detects the changes but it also tells you who made them and what exactly was changed.
DSP allows a few different options when comparing versions of a GPO when tracking unauthorized GPO settings. Another reason a third-party tool offers a great increase in value when auditing and achieving actionable results.
The other important GPO is the root ‘Default Domain’ policy. You’ll find this at the root of your domain in the Group Policy Management Console (GPMC). And this is just me but leave this GPO alone. Resist the urge to make ANY changes to it. Instead, create a new GPO.
If you don’t have the means to procure another tool, you can audit for directory service object changes in the Group Policy “Policies” container. For example, in domain.com, the path to the container would be CN=Policies,CN=System,DC=domain, DC=com.
This one is certainly nuanced – you could even include this in the ‘advanced auditing’ section. I say this because blankly enabling the first category – Directory Service Access – will flood the Security logs on your domain controllers.
However, you can only monitor this access on events that have had an audit System Access Control List (SACL) specified. Because of this, it is best to filter this specific monitoring to critical objects in your environment. So, it may be better to focus on the second category – Directory Service Changes.
It is arguably better to do a trial run with Directory Service Changes, as opposed to Directory Service Access, to reduce the number of events your Security log will generate. Give it about a week to get a feel for how many events are logged so you can plan on using this category or not.
If you utilize Semperis’s DSP product, Directory Service Changes is enabled on all partitions monitored by the product. It provides real-time information about AD changes as they happen as well and Changed By information to inform the administrator who made the change.
Plus, if you read Microsoft’s recommended audit guidelines, you may notice both categories are NOT on the list. What does that mean in practical terms? Enable them for a short time at the beginning of your testing and make necessary changes if an event gets generated.
Now we finally get to a category that is more straightforward – the auditing of user and computer account events. You can choose to audit the creation, modification, and deletion of accounts – and I recommend you do so.
This is a category where you might export the events generated to a separate tool like Semperis Directory Services Protector. You can get daily, weekly, etc. reports emailed to you with the data aggregated in an easy-to-read format.
Enabling this setting shouldn’t put too much load on your Security event log. But it is important as it allows you to detect malicious or accidental creation or deletion of all types of accounts in your environment.
I don’t know if I can accurately describe, without being accused of hyperbole, how important it is to protect your AD schema. The main avenue for making changes to your schema is the ‘Schema Admins’ group. It is best practice to leave the Schema Admins group empty.
During day-to-day operations, there is no reason to have ANY accounts in the Schema Admins group. During a planned update to the schema, you can add protected accounts to the ‘Schema Admins’ group and then remove them when your steps are complete.
Being notified when any changes are made to the membership of AD protected groups, like Schema Admins, is much easier when you use a special tool in conjunction with basic AD Auditing. Semperis Directory Services Protector can be configured to send you emails when anything is modified in your schema AND if the membership in ‘Schema Admins’ or ‘Enterprise Admins’ occurs.
This one is particularly nuanced, too. There is often a fine line between legitimate user accounts getting locked out, due to mistyped passwords, and truly compromised accounts, due to attacks. The best course of action, to filter out the routine noise from account lockout audit events, is to modify the default settings applied by Group Policy.
If a user’s CAPS LOCK key is on, they could have repeated issues authenticating. And if they are logged in to multiple computers, they may forget about those other PCs. And if they configured a Windows Service to log on as their main account (NOT a good idea!), that service will fail to log in after the user changes their password.
One relatively safe option is to raise the default password lockout threshold from 5 to between 20 and 50. If a bad actor is attempting to hack into an account, they will still get locked out legitimately. But this prevents your users from losing their sanity when they have to call the helpdesk if they mistype their password 6 times.
Microsoft’s free Account Lockout Status tool is available for download. It will show you what accounts are locked out on each of your domain controllers.
By default, Active Directory will audit account logon and logoff events in your domain. However, failure events are what you should focus on. Failed logon events in a high number for a single user could indicate an attempt at brute force/password spray attack.
Also, while it is important to monitor failed logons, it is also important to monitor successful ones. There have been incidents in some environments where domain controllers were queuing up their ability to process requests because a poorly configured application was authenticating millions of times in a single day. There will be different events depending on whether the user is logging in with Kerberos vs the older NTLM protocol, which could be useful for those looking to cut down on NTLM usage in their environments.
If you do have confirmation from an end user that they recently changed their password, you’ll have the data to determine the precise system the change occurred on. You can then correlate the timing of these events to verify if this is legitimate or a potential security threat. But this is hard to do without a third-party tool.
Semperis Directory Services Protector, or a SIEM solution, helps to do all the data gathering and analysis for you. You’re then presented with either an ‘informational’ event, describing a common routine task your user took, or a potential threat to act on. Semperis DSP can also be integrated with a SIEM to provide unique information not captured by auditing, such as Indicators of Exposure and Indicators of Compromise.
Ownership of an AD object determines who can modify permissions on said object. Monitoring this is important, but again it needs to be balanced with how noisy the volume of events can amount to on your domain controllers.
You could conceivably use ownership monitoring with the ‘Directory Service Changes’ audit setting for robust monitoring of crucial Active Directory objects and accounts. On paper this provides an excellent feather in your cap of at least identifying unauthorized changes to your most crucial AD objects. But you need to fine-tune the individual granular options to make sure you’re not sifting through thousands of events in your SIEM or third-party software product.
A system administrator can reset a user’s account password with a single click. They don’t even need to know the old password. This should be monitored, especially when you receive reports of passwords being reset for privileged accounts.
To make sure you’re monitoring password reset events, you could combine an audit policy around Account Management with data collection in a third-party tool. Without the tool, the size of your environment (number of users, etc.) could pose an issue with managing the ingest of data.
Semperis Directory Services Protector can be set up easily to notify administrators when privileged user accounts are modified in any way.
Every organization’s needs differ, as does their environment. It is essential to tailor your auditing strategy to meet your requirements and resource needs. Acquiring an Active Directory SIEM solution, like Semperis Directory Services Protector, allows you to quickly and continuously get the information you need to identify potential security breaches in your environment.
Let Semperis handle all the data gathering, analysis, reporting, compliance reporting (PCI/GDPR/etc) and dashboard creation so you can focus on keeping your business data and apps safe.