How to configure the Active Directory connector: every authentication method explained
The Active Directory connector is the foundation of an AdGUARD audit. It gives the application read-only access to your Microsoft Active Directory domain so it can evaluate identities, conditional access, privileged roles and more. This guide walks through every way to connect a domain and helps you pick the right method.
What the connector actually does
AdGUARD does not store your credentials or act on your behalf beyond reading configuration. The connector registers an application in your domain, grants it a small set of read-only LDAP permissions, and authenticates using a certificate or secret. Every audit then queries the LDAP to collect the current configuration — nothing is ever written back.
Read-only by design. The permissions requested are all of the .Read.All family (for example Directory.Read.All, Policy.Read.All). No write permission is ever requested or granted, so an audit cannot modify your environment.
Method 1 — Automatic provisioning (recommended)
The fastest path. From the Connectors screen, create a company, then choose Connect Active Directory. AdGUARD guides you through an interactive sign-in with a Global Administrator account, then automatically creates the application registration, generates a self-signed certificate stored locally, requests admin consent for the read-only Graph permissions, and records the domain ID, client ID and certificate thumbprint.
You authenticate once. After that, audits run non-interactively using the certificate. This is the option most teams should use: no manual work in the Entra admin center, and the least room for error.
Method 2 — Certificate authentication (app-only)
If your organisation registers applications centrally, your Entra administrator can create the app registration ahead of time and hand you the details. You then configure the connector manually with the Tenant ID, the Client ID, and a certificate whose public key is uploaded to the app registration and whose private key is available on the machine running AdGUARD.
Certificate authentication is the most secure app-only method because no shared secret is transmitted or stored in clear text. It is the recommended choice for production audits and environments with strict security requirements.
Which permissions to grant
Whichever route you take, the app registration needs read-only application permissions. The core set:
| Permission | Why it is needed |
|---|---|
Directory.Read.All | Users, groups, roles, directory settings |
Policy.Read.All | Conditional access and authentication policies |
RoleManagement.Read.All | Privileged role assignments (PIM) |
AuditLog.Read.All | Sign-in and audit log retention checks |
Reports.Read.All | Usage and security reports |
Method 3 — Client secret
A client secret (a generated string) is supported for quick tests, but it is the least recommended method: secrets expire, must be rotated, and are riskier to store than certificates. If you use one, keep its lifetime short and treat it like a password. For anything beyond a one-off trial, prefer certificate authentication.
Verifying the connection
Once configured, the connector card shows a Configured badge. Run a small audit scoped to Active Directory only: if controls return real results (compliant, warning, non-compliant) rather than errors, the connection and permissions are correct. If you see permission errors, confirm that admin consent was granted for every permission in the table above.
Troubleshooting
- "Insufficient privileges" — admin consent is missing for one or more permissions. Re-grant consent or re-run automatic provisioning.
- Certificate not found — the private key is not present on the machine, or the thumbprint does not match. Re-import or regenerate it via provisioning.
- Authentication failed — check the domain ID and client ID for typos, and confirm the app registration still exists.