Active Directory users (WIP)

Imports user objects from Active Directory, with the account-hygiene attributes that make a directory export worth having — delegation flags, password policy state and lockouts.

Type name	active_directory_users
Creates	Users
Runs on	A sensor, or as an isolated integration with an uploaded CSV
Presence flag	active_directory_user_exits
Field prefix	active_directory_user_

What it contributes

• Identity — name, display name, given name, surname, SAM account name, UPN, distinguished name, object GUID, SID, SID history, email address
• Organisation — department, title, description, member of
• Account state — enabled, locked out, account expiration date, user account control, created
• Password state — password last set, password never expires, password not required, last bad password attempt
• Delegation — trusted for delegation, trusted to auth for delegation, does not require pre-auth

It writes the shared user fields user_full_name, user_email, user_department, user_title and updated_at, and keeps the source row in _meta_active_directory_users_scan_result.

The delegation and pre-auth flags are the interesting ones

trusted_for_delegation, trusted_to_auth_for_delegation and does_not_require_pre_auth are the attributes attackers look for, and they are rarely set deliberately. Filtering users on them is a five-second hygiene check that most estates fail somewhere.

Data collection

Like Active Directory, the sensor-side implementation reads a CSV export. Produce it with the RSAT ActiveDirectory module:

Import-Module ActiveDirectory

$props = @(
  'AccountExpirationDate','Created','Department','Description','DisplayName',
  'DistinguishedName','DoesNotRequirePreAuth','EmailAddress','Enabled','GivenName',
  'LastBadPasswordAttempt','LastLogonDate','LockedOut','MemberOf','Name',
  'ObjectClass','ObjectGUID','PasswordLastSet','PasswordNeverExpires',
  'PasswordNotRequired','SamAccountName','SID','SIDHistory','Surname','Title',
  'TrustedForDelegation','TrustedToAuthForDelegation','userAccountControl',
  'UserPrincipalName'
)

Get-ADUser -Filter * -Properties $props |
  Select-Object $props |
  Export-Csv -NoTypeInformation -Encoding UTF8 .\ad-users.csv

Headers must match those property names; unknown ones are skipped without error.

MemberOf is multi-valued

Exported to CSV, a multi-valued attribute serialises as a single string. Group membership therefore arrives as text rather than as a list — usable for search, but not as a structured relationship.

Requirements

As for Active Directory, collection is from a CSV export you supply — here of Get-ADUser — so the requirements fall mostly on whoever produces that export.

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. The reach that is needed belongs to the machine where you run Get-ADUser — an already domain-joined administrative host, using whatever access it normally has.

TODO

As for the computer-object type, the sensor-driven path is unsettled: the URL, Username and Password fields imply direct collection while the collection performed today is CSV parsing. See the same TODO in Active Directory.

Access in Active Directory

Need	Why
An account that can run Get-ADUser 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-ADUser 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
A registered, healthy sensor, for the non-isolated mode	Non-isolated instances are started via a sensor — see Sensors

Configuration

Identical to Active Directory: name, URL, username, password, optional cookies, sensor, ignore SSL, and the Isolated integration checkbox that switches the instance to operator-supplied CSV upload.

TODO

Document the sensor-driven collection path for this type, as for the computer object integration.

Permissions in Active Directory

Reading user objects needs no privilege beyond Authenticated Users in a default domain. Use a dedicated read-only service account so the reads are attributable.

See also

• Active Directory — computer objects from the same domain
• Azure users — the Entra ID equivalent, including sync state back to on-premises accounts
• Integrations overview — the shared configuration model