Active Directory (WIP)
Imports computer objects from Active Directory — the domain's own record of every machine ever joined to it, including the ones that stopped reporting years ago.
| Type name | active_directory |
| Creates | Endpoints |
| Runs on | A sensor, or as an isolated integration with an uploaded CSV |
| Presence flag | active_directory_hosts_exits |
| Field prefix | active_directory_ |
What it contributes
- Identity — name, DNS host name, SAM account name, distinguished name, object GUID, SID, UPN, object class
- Network — IPv4 address, IPv6 address
- Platform — operating system, operating system version
- Lifecycle — created, modified, last logon date, last bad password attempt, enabled flag
- Organisation — managed by, location, description, last known parent, primary group and primary group ID, instance type
It writes the shared fields names, os, os_vendor, type, private_ip and
updated_at, and keeps the whole source row in
_meta_active_directory_scan_result.
Every other source lists machines that are alive. AD lists machines that were ever joined. Assets present in AD but absent from CrowdStrike or Windows Defender are either an agent-coverage gap or dead computer objects nobody cleaned up — both worth knowing.
Data collection
The sensor-side implementation reads a CSV export of computer objects. Produce it
on a domain-joined host with the RSAT ActiveDirectory PowerShell module:
Import-Module ActiveDirectory
$props = @(
'DistinguishedName','DNSHostName','Enabled','IPv4Address','IPv6Address','Name',
'ObjectClass','ObjectGUID','OperatingSystem','OperatingSystemVersion',
'SamAccountName','SID','UserPrincipalName','Created','Modified','Description',
'HomedirRequired','instanceType','LastBadPasswordAttempt','LastKnownParent',
'LastLogonDate','Location','ManagedBy','PrimaryGroup','primaryGroupID'
)
Get-ADComputer -Filter * -Properties $props |
Select-Object $props |
Export-Csv -NoTypeInformation -Encoding UTF8 .\ad-computers.csv
Column names must match the property names above — the parser looks them up by header, and any it cannot find is simply left empty rather than raising an error.
Because unknown headers are skipped silently, a truncated Select-Object produces
a successful run with sparse assets. If a field you expect is empty across every
asset, check the CSV header before suspecting the integration.
Requirements
This type is the odd one in the catalogue: collection is from a CSV export of
Get-ADComputer that you supply, so the requirements fall mostly on whoever
produces that export rather than on the platform.
Network access
| From | To | Protocol | Port |
|---|---|---|---|
| The sensor running the integration | Nothing — the run parses a CSV export | — | — |
No route from a sensor to a domain controller is needed for the CSV path, which is
what makes this type usable for management forests and air-gapped domains where the
domain is deliberately unreachable. The reach that is needed belongs to the
machine where you run Get-ADComputer — an already domain-joined administrative
host, using whatever access it normally has to the domain.
The sensor-driven path is not settled — the URL, Username and Password fields imply direct collection, but the collection this type performs today is CSV parsing. Resolve this alongside the TODO under Configuration, and document the egress a direct-collection instance would need.
Access in Active Directory
| Need | Why |
|---|---|
An account that can run Get-ADComputer against the domain | It produces the export; Authenticated Users is enough in a default domain — see Permissions in Active Directory |
The RSAT ActiveDirectory PowerShell module on that host | Get-ADComputer ships with it rather than with Windows itself — Data collection has the export command |
In this deployment
| Need | Why |
|---|---|
| Console access to upload the export | In Isolated integration mode the CSV is supplied through the console rather than collected — see Isolated integration |
| A registered, healthy sensor, for the non-isolated mode | Non-isolated instances are started via a sensor — see Sensors |
Configuration
| Field | Required | Notes |
|---|---|---|
| Name | Yes | Label for this instance |
| URL | Yes | Domain controller URL |
| Username | Yes | Account used for the connection |
| Password | Yes | Password for that account |
| Cookies | No | Extra cookies added to requests |
| Sensor | Yes | Sensor that will run the integration |
| Ignore SSL | No | Skips certificate validation |
| Isolated integration | No | See below |
Isolated integration
Ticking Isolated integration means the integration cannot be started via a sensor — you upload the CSV yourself instead. This is the mode to use when the domain is deliberately unreachable from where sensors run, which is common for management forests and air-gapped domains.
Document the sensor-driven collection path for this type: what the URL, username and password are used for versus the CSV route, and whether a non-isolated instance collects directly or still expects an operator-supplied export.
Permissions in Active Directory
Reading computer objects needs no privilege beyond Authenticated Users in a default domain. Use a dedicated read-only service account anyway, so the access is attributable in domain controller logs.
See also
- Active Directory users — user objects from the same domain
- LDAP users — for a non-AD directory
- Integrations overview — the shared configuration model