Active Directory service account
CICADA IR connects to your domain with one service account. This page says how to create it, the least rights each CICADA operation needs, and how to use Kerberos with a password or a keytab instead of NTLM. Domain Admin is not required.
1. Create the account
- A standard user account, for example
svc-cicada, in an OU of your choice. - Tick This account supports Kerberos AES 128 bit encryption and AES 256 bit encryption. CICADA refuses an RC4-only keytab.
- Tick Account is sensitive and cannot be delegated.
- Deny interactive and Remote Desktop logon by Group Policy ("Deny log on locally" and "Deny log on through Remote Desktop Services"). CICADA never logs on interactively.
- A long random password, or a keytab (section 4). Not a member of Domain Admins.
2. Rights per operation
Each row names the protocol CICADA uses and the minimum right. The Verified column records what was confirmed in our lab against a Windows Server domain; a row marked "not yet" is published with the broader right until it is.
| Operation | Protocol | Minimum right | Verified |
|---|---|---|---|
| User, group, computer and GPO reads; domain controller discovery | LDAP | Default Authenticated Users read | not yet |
| Disable, enable, unlock an account | LDAP | Write userAccountControl and lockoutTime on the user objects in scope (Delegation of Control, custom task) | not yet |
| Reset a password | LDAPS | "Reset password" extended right and write pwdLastSet on the users in scope | not yet |
Event log collection (wevtutil qe per channel), tzutil | WinRM | Member of Event Log Readers and Remote Management Users on each target (the Security channel is readable only through Event Log Readers) | not yet |
| Share enumeration, directory listing, file hashes | WinRM | Remote Management Users plus share and NTFS read on the paths | not yet |
gpupdate /force on a target | WinRM | Local Administrators on the target | not yet |
repadmin /showrepl | WinRM | Published as Domain Admins or delegated replication read until confirmed | not yet |
3. Network
- 636 (LDAPS, default) or 389 (LDAP) to the domain controllers.
- 5985 or 5986 (WinRM) to every host CICADA collects from.
- 88 TCP and UDP (Kerberos) to the domain controllers, in the Kerberos modes.
- DNS from the appliance that resolves the domain controllers by name.
- The appliance clock within five minutes of the domain (NTP).
The full port list is on Network Requirements.
4. Password, Kerberos with password, or keytab
- Password (default). NTLM for
DOMAIN\user, a simple bind otherwise. Works everywhere. As in every mode, the domain controller's LDAP certificate is checked before the password is sent. - Kerberos with password. Mutual authentication with the domain controller and WinRM targets; no NTLM. Enter the Domain Controller by DNS name and the account as
svc-cicada@CORP.EXAMPLEor a bare name plus the Domain field. - Kerberos with keytab. As above, with no password stored on the appliance: upload the keytab the domain controller issued. On a domain controller:
ktpass -princ svc-cicada@CORP.EXAMPLE -mapuser CORP\svc-cicada -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass * -out cicada.keytabktpasssets a new password on the account. If the password is changed afterwards the keytab stops working until it is re-issued and uploaded again.
5. What CICADA does not do
- It does not need Domain Admin for any operation except, until the lab confirms otherwise,
repadmin /showrepl. Whatever account you give it is stored encrypted on the appliance. - It does not need a service principal name of its own.
- It does not join the domain. The keytab or password is the only domain secret it holds, encrypted on the appliance.