Configurer le connecteur Active Directory : toutes les méthodes d'authentification expliquées
Le connecteur Active Directory est la fondation d'un audit AdGUARD. Il donne à l'application un accès en lecture seule à votre domaine Microsoft Active Directory pour évaluer les identités, l'accès conditionnel, les rôles privilégiés et plus encore. Ce guide passe en revue toutes les façons de connecter un domaine et vous aide à choisir la bonne méthode.
Ce que fait réellement le connecteur
AdGUARD ne stocke pas vos identifiants et n'agit pas en votre nom au-delà de la lecture de la configuration. Le connecteur enregistre une application dans votre domaine, lui accorde un petit ensemble de permissions LDAP en lecture seule, et s'authentifie par certificat ou secret. Chaque audit interroge ensuite l'API Graph pour collecter la configuration courante — rien n'est jamais réécrit.
Lecture seule par conception. Les permissions demandées appartiennent toutes à la famille .Read.All (par exemple Directory.Read.All, Policy.Read.All). Aucune permission d'écriture n'est jamais demandée ni accordée : un audit ne peut pas modifier votre environnement.
Méthode 1 — Provisionnement automatique (recommandé)
Le chemin le plus rapide. Depuis l'écran Connecteurs, créez une entreprise, puis choisissez Connecter Active Directory. AdGUARD vous guide dans une connexion interactive avec un compte Administrateur général, puis crée automatiquement l'enregistrement d'application, génère un certificat auto-signé stocké localement, demande le consentement administrateur pour les permissions Graph en lecture seule, et enregistre l'ID du domaine, l'ID client et l'empreinte du certificat.
Vous vous authentifiez une seule fois. Ensuite, les audits s'exécutent de façon non interactive avec le certificat. C'est l'option que la plupart des équipes devraient utiliser : aucun travail manuel dans le centre d'administration Entra, et le moins de place pour l'erreur.
Méthode 2 — Authentification par certificat (app-only)
Si votre organisation enregistre les applications de façon centralisée, votre administrateur Entra peut créer l'enregistrement d'application à l'avance et vous en remettre les détails. Vous configurez alors le connecteur manuellement avec le Tenant ID, le Client ID, et un certificat dont la clé publique est téléversée dans l'enregistrement d'application et dont la clé privée est disponible sur la machine qui exécute AdGUARD.
L'authentification par certificat est la méthode app-only la plus sûre, car aucun secret partagé n'est transmis ni stocké en clair. C'est le choix recommandé pour les audits de production et les environnements aux exigences de sécurité strictes.
Quelles permissions accorder
Quelle que soit la voie choisie, l'enregistrement d'application a besoin de permissions applicatives en lecture seule. Le socle :
| Permission | Pourquoi elle est nécessaire |
|---|---|
Directory.Read.All | Utilisateurs, groupes, rôles, paramètres d'annuaire |
Policy.Read.All | Accès conditionnel et stratégies d'authentification |
RoleManagement.Read.All | Affectations de rôles privilégiés (PIM) |
AuditLog.Read.All | Vérifications de rétention des journaux de connexion et d'audit |
Reports.Read.All | Rapports d'usage et de sécurité |
Méthode 3 — Secret client
Un secret client (une chaîne générée) est pris en charge pour des tests rapides, mais c'est la méthode la moins recommandée : les secrets expirent, doivent être renouvelés, et sont plus risqués à stocker que des certificats. Si vous en utilisez un, gardez sa durée de vie courte et traitez-le comme un mot de passe. Au-delà d'un essai ponctuel, préférez l'authentification par certificat.
Vérifier la connexion
Une fois configurée, la carte du connecteur affiche un badge Configuré. Lancez un petit audit limité à Active Directory : si les contrôles renvoient de vrais résultats (conforme, avertissement, non conforme) plutôt que des erreurs, la connexion et les permissions sont correctes. Si vous voyez des erreurs de permission, confirmez que le consentement administrateur a été accordé pour chaque permission du tableau ci-dessus.
Dépannage
- « Insufficient privileges » — le consentement administrateur manque pour une ou plusieurs permissions. Ré-accordez le consentement ou relancez le provisionnement automatique.
- Certificat introuvable — la clé privée n'est pas présente sur la machine, ou l'empreinte ne correspond pas. Réimportez-la ou régénérez-la via le provisionnement.
- Échec d'authentification — vérifiez le domaine ID et le client ID (fautes de frappe), et confirmez que l'enregistrement d'application existe toujours.