Skip to main content
Question

Bindplane File source slow/delayed ingestion for Windows AD (Active Directory) export to Google SecOps

  • July 28, 2026
  • 1 reply
  • 48 views

Omskirt
Forum|alt.badge.img+7

We're forwarding Active Directory user/computer object data from a Windows AD server to Google SecOps via Bindplane, using a scheduled PowerShell script that exports Get-ADUser/Get-ADComputer data to a JSON file, which Bindplane picks up via a File source (WINDOWS_AD log type).

Problem: After setting up the Bindplane File source on the client's AD server, we're experiencing significant delay in logs reaching Bindplane / SecOps - sometimes logs don't show up at all until much later, even though the export file is being generated on schedule.

What we've tried so far:

1. Original script - full -Properties * dump via a double Get-ADUser/Get-ADComputer query (list first, then re-query each object individually):

Get-ADUser -Filter * -Properties samAccountName | ForEach-Object { 
    Get-ADUser $_.SamAccountName -Properties * | ConvertTo-Json -Compress 
} | Out-File -Encoding utf8 -FilePath $TEMP_FILENAME

This produced very large files (3GB+) and was slow to generate.

2. Trimmed-down version - selecting only a specific subset of properties (SamAccountName, DisplayName, DNSHostName, OperatingSystem, whenCreated, etc.) instead of -Properties *:

$userProps = @("SamAccountName","Enabled","DisplayName","DistinguishedName","LastLogonDate","PasswordLastSet","whenCreated","whenChanged","Description","EmailAddress")
Get-ADUser -Filter * -Properties $userProps | Select-Object $userProps | ForEach-Object {
    $_ | ConvertTo-Json -Compress -Depth 2
}

This produced a much smaller file, but a lot of expected entity fields (SID, ObjectGUID, MemberOf, ObjectClass, etc.) end up missing, which breaks the UDM entity mapping (USER/ASSET entity_type detection) in SecOps - the parser relies on ObjectClass and several other AD attributes we excluded to correctly populate entity.user / entity.asset fields.

Questions:
1. Is there a recommended way to configure a Bindplane File source specifically for large/high-volume JSON exports like this, to reduce ingestion latency (batch size, polling interval, fingerprint settings, etc.)?
2. Should we be doing incremental exports (e.g., filtering on whenChanged) instead of a full snapshot every run, to avoid Bindplane re-reading the entire file each cycle?
3. Is there a way to keep full -Properties * output (for correct UDM/entity mapping) while still keeping ingestion fast - e.g., excluding only known-bloated fields like nTSecurityDescriptor and msExchMailboxSecurityDescriptor rather than restricting to a small property list?
4. Any guidance on Multiline Parsing settings for the File source when each line is already a single compressed JSON object (no multiline records)?

Any guidance from those who've set up similar Windows AD → Bindplane → SecOps pipelines would be much appreciated. Happy to share more config/screenshots if needed.

1 reply

a_aleinikov
Forum|alt.badge.img+8
  • Bronze 2
  • July 29, 2026

The main issue is likely the repeated full-file replacement rather than Bindplane polling. The File source tracks offsets and works best with append-only or uniquely named rotated files, so I would export incremental changes using whenChanged, write one compressed JSON object per line, and periodically send a separate full snapshot for reconciliation. Include the specific attributes required by the WINDOWS_AD parser, such as ObjectClassObjectGUIDSID and MemberOf, instead of using -Properties *. Multiline parsing should be disabled because each line is already a complete JSON record. Also write to a temporary file and rename it atomically after completion so Bindplane never reads a partially generated export.