How to Add Active Directory Logs to Microsoft Sentinel

When setting up your SIEM, ingesting Active Directory logs is essential. Active Directory (AD) remains the ‘crown jewel’ for on-premises or hybrid organizations because a breached AD environment means that the entire environment is vulnerable. Monitoring Active Directory is thus of paramount importance. When using Microsoft Sentinel as a SIEM, multiple ways exist to ingest Active Directory logs. The two major options are to use Microsoft Defender for Identity (MDI) or harvest the raw Windows security logs from the Domain Controllers with an agent. This blog dives into the two options to compare their strengths and weaknesses.

Defender for Identity

Microsoft Defender for Identity is the only Microsoft product in the Defender stack that focuses on Active Directory security. Installing a sensor on all Domain Controllers will send data to the cloud. The data is then available through advanced hunting within the Microsoft Defender portal and analyzed in the backend by Microsoft. When potential suspicious activities are identified by MDI (such as Pass-The-Ticket, Golden Ticket, or Account Enumeration), an incident is created for the security team to investigate. These incidents can be investigated through the Microsoft Defender portal.

While the main benefit of MDI is in its ability to detect potential issues, it’s not always clear how much raw data MDI collects and provides to you. If we navigate to the Advanced Hunting blade within the Microsoft 365 portal, we see four tables containing information related to AD:

• IdentityInfo: This table contains information about AD and Azure AD user objects, including properties such as SIDs, Names, and Status.
• IdentityLogonEvents: Contains all logon events captured by AD and Azure AD.
• IdentityDirectoryEvents: Events happening on the Domain Controllers for user and group objects, including password resets and user and group updates.
• IdentityQueryEvents: This table holds AD queries made by users and devices to the Domain Controllers, this could be LDAP or SAMR queries requesting information. These kinds of queries are often used during reconnaissance by an adversary.

By using the Microsoft 365 Defender connector within Microsoft Sentinel, we can ingest those tables mentioned above. Do this by opening the Sentinel environment, selecting Data Connectors, and choosing Microsoft 365 Defender. If you scroll down on the data connector configuration page, you can see the available MDI tables. Select the three tables shown in Figure 1 and click Apply changes to start synchronizing the data into Sentinel.

The keen-eyed among you may have noticed that the IdentityInfo table is missing from Figure 1. This is because Sentinel has a native solution called User Entity Behavior Analytics, which automatically pulls the MDI data.

Another important note is the cost of this solution; ingesting raw advanced hunting logs into Sentinel is not free and comes at a price. The cost of this solution is difficult to estimate; one potential is to use the queries created by Microsoft Rod Trent.

Windows Security Events

Every Domain Controller collects security events generated by activity on DCs and saves them in the Event Viewer. How much data is gathered depends on the auditing configuration for the domain. Security event data collected by domain controllers can be transmitted to Microsoft Sentinel. To do this, an agent must be installed on the Domain Controllers. Two agents are currently available: Microsoft Monitoring Agent (MMA) and Azure Monitor Agent (AMA). Both agents send security event data to Log Analytics, but only the AMA agent should be considered. There are two reasons why:

• Microsoft considers MMA to be a legacy solution and won’t support it after 2022.
• MMA does not provide adequate filtering for events.

The Azure Monitoring Agent can only be installed on servers hosted on Azure or onboarded into Azure Arc. After it is installed we must configure a Data Collection Rule that utilizes an xPath query. An xPath query is a filter specific to the Windows Event Viewer, to tell the agent what events to transmit

An example of an xPath Query is:

‘”Security!*[System[EventID=4728]]”’.

This query retrieves Event ID 4278 (Member add to security-enabled group) from the Security Event log. To collect multiple events from Domain Controllers, you must create various (complex) xPath queries to retrieve the logs and send them to Microsoft Sentinel.

An end-to-end manual on how to set up these rules and install the Azure Monitoring Agent is covered in Microsoft’s documentation.

Note: This solution requires Domain Controllers to be connected to the internet; this can be avoided by using Windows Event Forwarding.

Comparing both options

While both options achieve the same goal, significant differences exist. The main ones are the license requirements and setup complexity.

Defender for Identity is the easiest to integrate as you can start synchronizing tables without additional infrastructure, but MDI is only available with a Microsoft 365 E5 Security license. This means it’s not an option for every organization. If a customer is starting out with Sentinel and has access to an E5 license, this is the path I advise them to follow. It allows them to get the most value without much effort.

While ingesting the raw security events is more challenging to set up, this method is my preference. With raw security events, you have complete control over what you ingest and, thus, your cost. It is up to you whether you want to ingest specific Event IDs or all security events. This also means that this method can go much further in your data gathering and ingesting events that MDI does not even collect.