Active Directory (AD) is a popular technology used in many organizations to handle their user management, authentication, and authorization. The fact that it’s so dominant and so central to the IT infrastructure makes it a key component for security monitoring. It’s also a popular target for malicious actors, as compromising Active Directory accounts gives them access to many resources.
Security information and event management (SIEM) tools, therefore, need to “speak” Active Directory. We’ll go through the different aspects of monitoring an Active Directory for security and compliance purposes and we’ll provide several examples about how LogSentinel SIEM handles certain use cases.
Active Directory Log Ingestion Ways
The first step is ingesting the logs from domain controllers. There are three ways to do that depending on the setup:
- On-premise Active Directory with remote log collection – domain controller logs are using the standard windows event log, so ingesting them is achieved through a standard windows event log connector. In order to get access from a remote machine, you need to follow several non-straightforward configuration steps, which we have documented here. LogSentinel SIEM reads logs remotely through the LogSentinel Collector component. Username, password and domain for the read-only service account should be configured in the collector and then it subscribes to the domain controller windows event logs to stream them to the SIEM
- On-premise Active Directory with the local collection – there is an option to use an agent (or our collector) on the domain controller machine to read and forward logs – directly to the SIEM or to an intermediate component (forwarder). We natively support the OSSEC/Wazuh agents which can send data to a LogSentinel Collector instance which in turn forwards them to the SIEM.
- Azure Active Directory – AzureAD is the cloud identity and access management platform by Microsoft and its logs can be ingested via integration with the Microsoft365 logging facility. LogSentinel SIEM supports one-click integration (followed by the necessary authorization by an account admin) and then all logs are ingested automatically without the need for an intermediate component.
SIEM Data Visualization And Search for Active Directory
Once collected, data should be visualized and searchable. The search must be available via each of the extracted parameters, most importantly the user ID (or display name) and the action/event code. Detailed queries supporting boolean logic and other parameters are typically also available (e.g. “show me authentication for user X from computer Y in the past three days”, or “show me all authentication failures outside of working hours”.
LogSentinel SIEM supports all of the above with a simple query language and visualizes the results on a timeline chart (histogram). Additionally, custom charts can be defined with “top active users in AD”, “users with most authentication failures”, etc.
SIEM Reporting for Active Directory
SIEM provides flexible reporting for compliance and other reasons. Most compliance requirements involve the need for collecting and presenting authentication logs, so it’s important to be able to easily generate these reports. Additionally, ad-hoc and scheduled aggregation reports are very useful – e.g. “show me the top active users and their most typical AD events” or “show me the computers”. Built-in reports are also very useful and save time.
LogSentinel SIEM supports three types of scheduled reports, all of which can be sent on configurable intervals in many supported formats (PDF, XLS, CSV, JSON, HTML):
- Overview – general statistics and charts for all monitored systems or for an individual source, like Active Directory. Useful for management review.
- Saved search – report all records that match criteria for the reporting period. Ad-hoc exports of data that matches certain criteria are also supported.
- Group by reports – aggregation reports, grouped by one or several fields, as in the example above – top actors by a number of events, top actions (event codes) by a number of events, top actors and their respective top actions (a 2nd level aggregation), etc.
SIEM Alerting for Active Directory Protection
The most important functionality of SIEM is not log aggregation and search, but detecting malicious behaviour in a large volume of data. Multiple ways of defining alerts are often needed in order to allow an adequate response:
- Monitoring Microsoft-recommended events – Microsoft recommends multiple event codes to be monitored and alerted for (with varying criticality). These are simple rules that match an event code and generate an alert.
- Correlation rules – defining a sequence of steps that may constitute malicious behaviour – e.g. “more than 20 failed logins within 10 minutes for the same user” or “more than 10 failed logins within 10 minutes followed by a successful login”, “more than 2 logins with different usernames from the same computer ” or “more than 5 failed logins outside of working hours”.
- Statistical monitoring and baselining – the SIEM can allow you to define a monitored period and then get alerted if a deviation from the normal behaviour is observed, e.g. “alert if there are more than 2 standard deviations about the typically observed activity in the last 4 hours, rolling”. These rules should be filterable by event code (e.g. monitor only authentication failures) and other parameters.
- Machine learning – a SIEM can allow training an unsupervised model with historical data and then generate alerts if anomalies are detected.
- Threat Intelligence – for cloud AD events, the IP address of the authenticating user can be matched against a list of known malicious IPs (for on-premise AD the IP is typically one from the local network and the IP threat intelligence match is done on the device/appliance/server that terminates VPN connections).
LogSentinel SIEM supports all of the above through intuitive interfaces. It also has built-in templates for the Microsoft recommended events as well as other typical use cases. Alerts can be sent via email, SMS, or trigger other activities, as outlined in the next section.
SIEM Incident Response for Active Directory Security
After an alert is triggered, the security (or general IT) team is expected to react. Apart from sending simple messages, SIEM (alone or via a SOAR integration) would normally support:
- Invoking 3rd party APIs
- Creating tickets in ticketing systems
- Sending messages to messaging platforms (e.g. Slack)
- Executing scripted response (e.g. disable an Active Directory user)
LogSentinel supports all of that, either directly or through integration with IFTTT/Zapier (for cloud-based ticketing systems and messaging platforms). The active response actions – e.g. disabling a user – need a LogSentinel Collector that would receive the alert and act as configured.
Conclusion:Do We Have to Integrate the Active Directory With a SIEM Software?
Active Directory is at the centre of many organizations’ IT infrastructure and special attention has to be paid to its security monitoring. While SIEM is expected to aggregate all log sources, usually the Active Directory is integrated with high priority and the proper parsing and alerting is especially critical from the get-go. While other sources may be tweaked and improved over time, SIEM has to offer great automatic support for the AD.
Bozhidar Bozhanov is a senior software engineer and solution architect with 15 years of experience in the software industry. Bozhidar has been a speaker at numerous conferences and is among the popular bloggers and influencers in the technical field. He’s also a former government advisor on e-government, transparency, and information security.
