Configuring the Active Directory connector: LDAP, LDAPS and Negotiate
Auditing a directory does not require a privileged account, an agent, or a maintenance window. It requires an LDAP read and the right expectations. Here is how the Active Directory connector works, what it asks for, and what it deliberately does not.
What the connector actually does
The Active Directory connector opens a read-only LDAP session against a domain controller and queries the directory the way any domain-joined workstation does. No agent is installed, no schema extension is applied, nothing is written. Every operation is a search: users, groups, group policy objects, trusts, certificate templates, delegations, password policies.
That matters for the conversation you will have with the client's team. “We need to install something on a domain controller” is a request that takes three weeks to approve. “We need to read the directory from a workstation, with an account that has no more rights than a standard user” is a request that takes an afternoon.
Port 389 or port 636
| Port | Protocol | When to use it |
|---|---|---|
| 389 | LDAP with Negotiate | The default. The traffic is signed and sealed by the Negotiate layer, so credentials never cross the wire in clear. |
| 636 | LDAPS | When the client's policy requires TLS on the wire, or when a network appliance sits between the workstation and the controller. Requires a valid certificate on the domain controller. |
LDAPS is not selected in the interface: it is a setting in the client's settings.json. That is deliberate — it is a decision taken once with the client's network team, not a toggle to flip mid-audit.
Which account to use
Two options, and the choice is usually made by the client's policy rather than by preference.
- Integrated authentication — the session runs under the Windows account already logged on to the auditing workstation. Nothing to transmit, nothing to store. Ideal for an internal audit, or when the auditor is given a temporary domain account.
- A dedicated account — entered as
DOMAIN\userwith its password, which is encrypted on the workstation by DPAPI at machine scope. Ideal when the audit runs from a machine outside the domain, or when the client wants a nominative, revocable account they can watch in their logs.
No privileged rights are required. A standard domain user can read the directory. Some controls read security descriptors, which a standard user can also read. If a control comes back “not evaluated” for an access reason, the report says so rather than concluding — you do not draw conclusions from what you could not read.
What to check before you start
- Network reach — the workstation must reach a domain controller on 389 or 636. A VPN split-tunnel that excludes the DC subnet is the classic silent failure.
- Name resolution — the domain name must resolve. Auditing from a machine using a public DNS resolver will fail before authentication does.
- The account — a standard user, but an enabled one, with a password that is not expired.
- The scope — one domain per audit. A multi-domain forest is audited one domain at a time, which is also how the findings will be discussed.
Test before you trust
Saving the connector settings does not activate the connector. That only happens after a successful connection test, and the distinction is not cosmetic: an audit resting on an unreachable directory would produce a falsely reassuring score. The test opens the session, reads the domain naming context and reports what it found. If it fails, the error is shown as returned — which is what lets you tell a network problem from a credentials problem from a certificate problem.
Learning the tool without a domain
You do not need an Active Directory to explore the product. Entering simulation as the domain name activates an offline mode that replays a complete fictitious directory: privileged groups populated, service accounts with old passwords, ACL delegations, four contrasted trusts, a certificate authority with two templates. Every control actually runs, against pre-recorded responses. It is the right way to prepare a demonstration, produce screenshots, or train a consultant before their first engagement.
One limitation to know: the simulated directory is frozen, so two successive audits produce the same result. Drift detection and the trend curve have nothing to show there.
What the connector does not do
- It does not write. No remediation, no group modification, no GPO change. The remediation scripts it can generate ship with every modifying command commented out.
- It does not read file contents. The directory is configuration, not data. Shares, mailboxes and documents are outside the perimeter.
- It does not monitor. An audit is a photograph, taken deliberately, not a continuous detection service.
- It does not audit Entra ID. A hybrid estate needs both connectors — the directory and the tenant — because a compromise rarely respects the boundary between them.