Active Directory

One source, Active Directory (On-Prem), covers directory reads over LDAP and Windows event log collection over WinRM. The rights the service account needs for each operation are on the Active Directory account page; this page is about connecting and what happens once you do.

The source form

The three authentication modes

• Password (default). The LDAP bind is NTLM when the username is written DOMAIN\user, and a simple bind otherwise (user@domain, or a bare name which CICADA completes with the Domain field). WinRM uses NTLM. As in every mode, the domain controller's LDAP certificate is checked before the password is sent (see CA certificate above). Over HTTPS (5986) the WinRM certificate is checked too; see WinRM over HTTPS.
• Kerberos with password. CICADA obtains a ticket for the principal and uses it for LDAP (SASL/GSSAPI) and WinRM. No NTLM anywhere. Enter the account as svc-cicada@CORP.EXAMPLE or a bare name plus the Domain field. DOMAIN\user is refused in this mode with the message In Kerberos mode enter the account as user@REALM or a bare name; DOMAIN\user is an NTLM form. The source is still saved, with status Error and that message.
• Kerberos with keytab. As above, but the ticket comes from a keytab you upload, so no password is stored on the appliance.

Rules in the Kerberos modes

• The Domain Controller field must be the DC's DNS name, not an IP address. The service ticket is issued for ldap/<name>, so an IP is refused when the source signs in: the source is saved with status Error and the message In Kerberos mode the Domain Controller must be its DNS name ... not an IP address. Additional servers given as IP addresses are accepted silently (the only warning is a line in the appliance's own log), but WinRM to them will fail in the Kerberos modes; enter names.
• The appliance's DNS must resolve those names. Set DNS in the console network wizard.
• The appliance clock must be within five minutes of the domain. The error you get otherwise is The appliance clock differs from the domain by more than five minutes; check NTP on the appliance and on the domain controller.
• The account must allow AES. Tick This account supports Kerberos AES 128/256 bit encryption. A keytab that holds only RC4 keys is refused.
• Port 88 to the domain controllers must be open. The appliance's Kerberos library makes that connection, so allow both TCP and UDP, as Network Requirements lists.

Making the keytab

On a domain controller, as a domain admin:

ktpass -princ svc-cicada@CORP.EXAMPLE -mapuser CORP\svc-cicada -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass * -out cicada.keytab

ktpass sets a new password on the account. If the password changes later the keytab stops working until it is issued again and uploaded again. Before storing the file CICADA checks that it is a version 2 keytab, that it holds an AES key, and that the principal you typed is in it; the error names the principals it did find. The file is capped at 64 KiB; a service-account keytab is a few hundred bytes.

Ports

The full list is on Network Requirements.

WinRM on domain controllers and member servers

On each host CICADA will collect from, in an elevated PowerShell:

# Turn on the WinRM service and the HTTP listener on 5985
Enable-PSRemoting -Force

# Let the service account connect over WinRM
Add-LocalGroupMember -Group "Remote Management Users" -Member "CORP\svc-cicada"

# Let it read the Security log (and the other channels)
Add-LocalGroupMember -Group "Event Log Readers" -Member "CORP\svc-cicada"

On a domain controller the two groups are domain groups, so add the account once in Active Directory Users and Computers instead. Member servers can get the same two group memberships through Group Policy (Restricted Groups).

• CICADA runs wevtutil, tzutil, gpupdate, repadmin and short PowerShell scripts through WinRM. It does not install anything on the host.
• Remote Management Users and Event Log Readers are enough for log collection. gpupdate /force needs local administrator on the target; see the rights table.
• A host that does not answer on 5985 or 5986 is reported as WinRM unreachable and its event logs are not collected; for that host, whether a domain controller or a member server, CICADA falls back to the LDAP queries below, which always run against the domain controller it is bound to.
• The Sysmon channel is not collected: on some domain controllers its absence breaks the WinRM session for the channels after it.

WinRM over HTTPS

Over HTTPS (port 5986) CICADA checks the host's certificate before it sends any credential or command. The certificate must be issued by the CA in the source's CA certificate field (or, when that is blank, a CA the appliance already trusts), be in date, and carry the host's name as you entered it in its Subject Alternative Name. A host entered as an IP address needs that address in the Subject Alternative Name. A refused certificate gives The WinRM certificate presented by …:5986 was not accepted (…). No credentials or commands were sent. CICADA does not then retry over HTTP.

Over HTTP (5985) the traffic is encrypted by NTLM or Kerberos, not TLS. NTLM, used in Password mode, does not prove the host is genuine. To never use HTTP, tick WinRM over HTTPS only on the source; every host CICADA runs commands on then needs an HTTPS listener with such a certificate:

# On the host: an HTTPS listener with the computer certificate AD CS issued
$cert = Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.Subject -eq "CN=$env:COMPUTERNAME.$env:USERDNSDOMAIN" } |
  Select-Object -First 1
New-Item -Path WSMan:\localhost\Listener -Transport HTTPS -Address * `
  -CertificateThumbPrint $cert.Thumbprint -Force
New-NetFirewallRule -DisplayName "WinRM HTTPS" -Direction Inbound -Protocol TCP -LocalPort 5986 -Action Allow

What CICADA collects over WinRM

For each host, for each channel, one wevtutil qe query with an absolute time range in UTC (TimeCreated[@SystemTime >= ... and @SystemTime <= ...]), newest first, in text format, capped per channel. A channel that does not exist on a host is skipped, not failed. Before the first query CICADA asks the configured domain controller, once per run, for its time zone: first the TimeZoneKeyName registry value through PowerShell, then tzutil /g, then a PowerShell UTC offset as a last resort. That zone is applied to every host in the run, so the local times wevtutil prints can be turned back into UTC; if the zone cannot be read the run carries a warning.

That is the full list of twenty channels. A host other than the configured domain controller whose name does not resolve is skipped with a warning rather than costing one timeout per channel. Warnings from a run (a skipped host, a time zone that could not be read, timestamps that could not be resolved across a daylight-saving change) are shown on the Sources page against the source.

What CICADA collects over LDAP

• Users, groups and computers, with their membership, for target resolution and for blast-radius and access-rights analysis.
• Other domain controllers, discovered after the first bind, so a collection can cover them.
• When a host is unreachable over WinRM, a fallback query against the bound domain controller lists objects whose whenChanged falls in the collection window: modified users (including userAccountControl, lockoutTime, pwdLastSet, adminCount), modified groups and their members, modified computers, and modified Group Policy objects. This gives account and group changes even without event logs. It is the only place GPOs are read.

What Test Connection tells you

The result is one line per protocol, for example:

LDAP: connected via Kerberos as svc-cicada@CORP.EXAMPLE (dc01.corp.example:636)
WinRM: connected (dc01.corp.example)

In password mode the first line reads connected via NTLM or connected via simple bind. If only one of the two works the source is still marked connected and the message ends with collection will use LDAP or collection will use WinRM. A WinRM line of timed out after 60s is the network or the listener. A WinRM line of unreachable is any failure to open a session on 5985 or 5986, a rejected credential included; the underlying error follows the dash. A Kerberos failure is explained in plain words (unreadable keytab file, principal not found in the domain, wrong password or stale keytab, clock skew, KDC not found, no service principal for that name, AES not enabled, password expired) followed by the raw Kerberos text.

Response actions and the rights each needs

Approving an action needs Approve or deny actions, and running it needs Execute actions on customer systems. IR lead and Admin have both by default.

The exact rights, and which of them have been confirmed in a lab, are on the Active Directory account page.

Next

• CrowdStrike Falcon
• Troubleshooting: Active Directory connection fails
• Back to the onboarding overview