Monitoring Active Directory Changes with Cribl Edge Windows Event Logs (Splunk ADmon Migration)

Objective

Monitor Active Directory (AD) object changes (user and group create, update, delete, move) in Cribl in a way that is functionally similar to Splunk ADmon. You tested the cribl-ldap-source pack, but it only returned directory entries (for example, objects with objectClass=person) instead of emitting add/update/delete change events. This article explains how to collect AD change events using the Cribl Edge Windows Event Logs source and Windows Security auditing instead of the LDAP pack.

Environment

• Cribl Edge running on Windows Server
• Windows domain controller(s) providing Active Directory Domain Services (AD DS)
• Windows Security event log on the domain controller
• Directory Service Changes auditing enabled for AD objects (users/groups)
• Optional: Cribl Stream or another downstream destination receiving Windows Security events from Cribl Edge

Procedure

1. Confirm the role of the LDAP pack
   1. Verify that the cribl-ldap-source pack is currently being used only to run LDAP queries against AD (for example, to list objects with objectClass=person).
   2. Note that LDAP search queries return point-in-time directory entries, not a continuous change feed, so they will not produce add/update/delete events like Splunk ADmon.
2. Decide to collect from the Windows Security event log instead of LDAP
   1. Plan to collect AD change information from the Security log on a domain controller using the Windows Event Logs source in Cribl Edge.
   2. Understand that this approach uses Windows auditing to record AD object changes as Security events, then streams those events through Cribl, rather than querying AD directly via LDAP for changes.
3. Ensure Cribl Edge is installed on a suitable Windows host
   1. Install or verify Cribl Edge on a Windows domain controller, or on a Windows host that has access to the domain controller’s Security log.
   2. Confirm that the Edge node is connected and visible under the appropriate Fleet in the Edge leader UI.
4. Enable Directory Service Changes auditing in Active Directory
   1. Ask your AD administrator to enable Directory Service Changes auditing for the OUs or scopes that contain the users and groups you want to monitor.
   2. Configure auditing so that the domain controller’s Security log records events for AD object changes, including:
      • 5136 – object modified
      • 5137 – object created
      • 5138 – object undeleted
      • 5139 – object moved
      • 5141 – object deleted
   3. Verify on the domain controller (for example, with Event Viewer) that the Security log is now receiving these event IDs when AD objects change.
5. Configure the Windows Event Logs source in Cribl Edge
   1. In the Edge leader UI, go to Edge > Fleets, select the fleet that includes your Windows domain controller, and open Sources.
   2. Create or edit a Windows Event Logs (win_event_logs) source for that fleet.
   3. Under the source configuration, set:
      1. Log name (or equivalent) to Security.
      2. Read mode (or equivalent) to From last entry if you want only new change events going forward, or to Entire log if you need a historical backfill.
   4. In Advanced Settings, prefer the native Windows Event Log API path (disable any Use Windows Tools or similar toggle that forces PowerShell collection) to avoid performance and data-loss issues.
   5. Save the source, then Commit & Deploy the change to the fleet so the source starts reading the Security log.
6. Filter to only the AD change events you care about
   1. Create a pipeline (pre-processing or processing) attached to the Windows Event Logs source or its route.
   2. In the pipeline, add a filter function or rule to keep only Security events whose event ID matches the AD object change events you need (for example, 5136, 5137, 5138, 5139, 5141).
   3. Optionally add additional filters (for example, by target OU, object type, or operation) to reduce noise and control downstream ingestion costs.
   4. Save the pipeline and commit/deploy any configuration changes.
7. Validate that AD changes are flowing through Cribl
   1. Trigger a simple AD change in a test OU (for example, create, modify, move, or delete a test user or group).
   2. In the Edge leader UI, preview events from the Windows Event Logs source or use your downstream destination (for example, Cribl Stream, SIEM, or data lake) to search for new Security events with the expected event IDs.
   3. Confirm that the events contain the AD object details you require (such as user or group identifiers and the type of operation performed).

Additional Information

Why the LDAP pack does not behave like ADmon

• The cribl-ldap-source pack issues LDAP search queries that return matching directory entries (for example, objects matching objectClass=person) as snapshots; LDAP itself does not provide a built-in change feed of add/update/delete operations.
• Splunk admon uses Windows AD change-notification APIs and emits its own events independent of the Security log; it is not an LDAP search job.

How the Cribl approach compares to Splunk ADmon

• Collecting AD object changes via the domain controller’s Windows Security log with Directory Service Changes auditing enabled yields equivalent change data (who/what/when) but through a different mechanism than admon (audited events instead of AD change-notification calls).
• Cribl Edge does not currently provide a native admon-style AD API source; the supported patterns are:
  • Windows Security event collection via the Windows Event Logs source, with Directory Service Changes auditing enabled.
  • An Exec source that runs PowerShell/AD scripts if a custom or more specialized AD monitoring approach is required.

Documentation references

• See the Windows Event Logs source documentation for full details and advanced options, including performance tuning and API-based collection guidance.