What Is signature LDAP désactivée?
Une signature LDAP désactivée signifie qu’un contrôleur de domaine Active Directory accepte encore du trafic LDAP sans protection d’intégrité sur le chemin de liaison utilisé par le client. La documentation Microsoft est explicite : les liaisons LDAP SASL non signées et les liaisons simples LDAP sur une connexion non chiffrée doivent être refusées, car elles exposent l’annuaire aux attaques de rejeu et aux manipulations en homme du milieu. Dans le cas d’une liaison simple en clair, elles peuvent aussi exposer directement des identifiants sur le réseau.
En pratique, la faiblesse apparaît quand l’équipe laisse la stratégie du contrôleur de domaine dans un état permissif parce qu’une ancienne application, un script, un équipement ou une intégration annuaire s’appuie encore sur un comportement LDAP faible. L’annuaire reste disponible, mais la confiance accordée à ce trafic est trop large. Ce point est important, car LDAP n’est pas un canal secondaire dans Active Directory. C’est l’un des principaux plans de contrôle pour interroger utilisateurs, groupes, ordinateurs et objets sensibles qui structurent les privilèges.
La signature LDAP désactivée ressort souvent lors d’une revue plus large comme Comment auditer la sécurité Active Directory : checklist pratique pour les équipes internes, mais elle mérite sa propre piste de remédiation, car la correction dépend souvent des propriétaires applicatifs autant que des équipes annuaire.
How signature LDAP désactivée Works
Microsoft documente deux comportements risqués que la signature LDAP doit empêcher sur les contrôleurs de domaine :
- des liaisons LDAP SASL qui ne demandent pas la signature
- des liaisons simples LDAP effectuées en clair au lieu de passer par SSL/TLS
Quand la signature est exigée, le client et le serveur signent cryptographiquement la session LDAP pour empêcher un intermédiaire de modifier silencieusement le flux. Quand une liaison simple reste nécessaire, la recommandation Microsoft est de la protéger par SSL/TLS au lieu de l’autoriser en clair.
Il est aussi important de ne pas confondre signature LDAP et channel binding LDAP. La signature protège l’intégrité de la session LDAP. Le channel binding est une mesure distincte pour les sessions LDAP protégées par TLS et relève d’un autre flux de détection et de stratégie. Dans les environnements réels, les deux sont souvent corrigés ensemble, mais ce ne sont pas les mêmes contrôles.
| Modèle LDAP | Accepté si la signature LDAP est désactivée | Risque principal |
|---|---|---|
| Liaison SASL sans signature | Oui, si le DC reste permissif | Rejeu et altération du trafic LDAP |
| Liaison simple sur LDAP en clair | Oui, si le DC reste permissif | Exposition d’identifiants sur le réseau |
| Liaison simple sur LDAPS | Parfois encore requise par un vieux logiciel | Transport chiffré, mais conception applicative à revoir |
| Liaison SASL signée | État cible sécurisé | Trafic LDAP protégé en intégrité |
Microsoft note aussi une évolution importante : Windows Server 2025 active la signature LDAP par défaut pour les nouveaux déploiements Active Directory. Cela confirme que le contrôle n’est plus un durcissement optionnel, mais un attendu de base pour les nouveaux environnements.
The Attack Chain
Étape 1 - Identifier le chemin hérité qui parle encore LDAP faible
Les attaquants n’ont pas besoin de commencer avec un compte Domain Admin. Ils cherchent d’abord l’application, le script, l’équipement ou le poste d’administration qui effectue encore des liaisons LDAP faibles vers un contrôleur de domaine. Dans les audits internes, ce chemin ressort souvent avec le même travail que Supervision sécurité Active Directory : événements qui comptent : identifier quels clients utilisent encore des liaisons SASL non signées ou des liaisons simples en clair, et quel propriétaire en dépend.
# Exemple de liaison simple LDAP en clair
ldapsearch -x -H ldap://dc01.corp.local -D 'CORP\svc_legacyapp' -W -b 'DC=corp,DC=local' '(objectClass=user)'
Si un chemin applicatif dépend encore d’une liaison simple en clair, le vrai problème n’est pas seulement la commande. C’est le fait que le contrôleur de domaine est resté assez permissif pour l’accepter.
Étape 2 - Intercepter ou altérer le trafic LDAP faible
La documentation Microsoft sur la signature LDAP évoque explicitement le risque de rejeu et d’homme du milieu sur le trafic non signé. Si le chemin de liaison n’est pas protégé en intégrité, un attaquant bien positionné sur le réseau peut altérer des requêtes LDAP ou réutiliser des éléments d’authentification d’une manière qui ne devrait plus être possible.
C’est pour cela que la signature LDAP désactivée recoupe souvent, sur le plan opérationnel, Attaques NTLM Relay : détournement de l’authentification dans AD. Les deux faiblesses ne sont pas identiques, mais elles réduisent la confiance que l’on peut accorder au trafic d’authentification et d’annuaire sur le réseau.
Étape 3 - Transformer l’accès annuaire en élargissement de privilèges
Une fois que l’attaquant peut s’appuyer sur ce chemin LDAP faible, l’étape suivante n’est pas toujours la compromission immédiate du domaine. Il s’agit plus souvent de reconnaissance annuaire et de cartographie des privilèges :
- énumérer des groupes sensibles et des délégations
- localiser des comptes de service et des objets applicatifs critiques
- repérer les chemins qui serviront ensuite à des abus ACL, GPO ou comptes trop exposés
C’est exactement la logique décrite dans Chemins d’attaque Active Directory vers Domain Admin : une faiblesse sur le plan de contrôle annuaire devient plus grave lorsqu’elle aide l’attaquant à cartographier la route la plus courte vers des objets privilégiés.
Detection
Le chemin de détection le plus propre passe par les événements Directory Service documentés par Microsoft pour la signature LDAP.
| Indicateur | Event ID | Source | Ce qu’il indique |
|---|---|---|---|
| Le DC reste permissif | 2886 | Journal Directory Service | Rappel que le serveur devrait être durci pour refuser les liaisons faibles |
| Des liaisons faibles ont été vues sur 24 h | 2887 | Journal Directory Service | Compte agrégé des liaisons SASL non signées et des liaisons simples en clair |
| Les liaisons faibles sont refusées | 2888 | Journal Directory Service | Confirme l’application de la stratégie et la présence de clients encore non conformes |
| Détail par client | 2889 | Journal Directory Service | Donne l’IP source et l’identité utilisée |
| Audit du channel binding LDAP | 3039, 3040, 3041, 3074, 3075 | Journal Directory Service | Utile si vous durcissez en parallèle le channel binding |
Pour le triage, commencez par l’Event 2887 afin de vérifier si le problème est encore actif. S’il l’est, augmentez le niveau de journalisation LDAP Interface Events pour obtenir l’Event 2889 avec l’IP client et l’identité. Cela permet d’assigner la remédiation au bon propriétaire applicatif plutôt que de laisser le sujet au niveau d’un constat AD générique.
# Lire les principaux événements liés à la signature LDAP sur un DC
Get-WinEvent -LogName 'Directory Service' |
Where-Object { $_.Id -in 2886,2887,2888,2889,3039,3040,3041,3074,3075 } |
Select-Object TimeCreated, Id, LevelDisplayName, Message
Pendant la remédiation, il est utile de rapprocher ces événements d’une revue de conformité plus large comme Conformité AD et Azure : NIS2, ISO 27001, CIS Controls. La signature LDAP fait partie de ces réglages qui existent depuis longtemps dans les politiques écrites, tout en restant mal appliqués en production.
Remediation
💡 Quick Win: utilisez d’abord les événements 2887 et 2889. Identifiez tous les clients qui dépendent encore de liaisons SASL non signées ou de liaisons simples en clair avant d’obliger les DC à les refuser.
Une remédiation durable suit en général cet ordre :
- Inventorier les clients faibles. Analysez les résumés 2887 et activez la journalisation détaillée pour que 2889 identifie précisément les systèmes sources.
- Corriger le comportement côté client. Mettez à jour l’application, le driver, l’équipement ou le script pour demander la signature sur les liaisons SASL ou utiliser SSL/TLS pour les liaisons simples.
- Exiger la signature sur les DC. Dans la stratégie, passez Domain controller: LDAP server signing requirements à Require signing.
- Revoir la stratégie côté client. Utilisez Network security: LDAP client signing requirements pour éviter que des postes gérés n’initient encore des sessions LDAP faibles.
- Retester les applications dépendantes. Validez le comportement de liaison dans un chemin réellement utilisé en production.
- Surveiller les tentatives résiduelles. Après activation du refus, surveillez 2888 et 2889 pour repérer les systèmes qui nécessitent encore une action.
# Exemple de vérification de stratégie sur un hôte Windows
secedit /export /cfg C:\Temp\secpol.cfg
Select-String -Path C:\Temp\secpol.cfg -Pattern 'LDAP'
Le piège opérationnel consiste à forcer le paramètre sans coordination avec les propriétaires applicatifs. La signature LDAP doit être imposée, mais le chemin le plus sûr consiste à inventorier d’abord les dépendances et à les faire migrer. C’est d’autant plus important quand l’environnement cumule déjà Mauvaises configurations GPO : vecteur d’attaque AD ou d’autres écarts d’hygiène qui compliquent le changement.
Validate Before You Close the Finding
La validation finale doit prouver plus qu’un simple changement de GPO. Relancez le même scénario qui a révélé le client faible, confirmez que la liaison utilise désormais la signature ou LDAPS selon le cas, et faites valider le workflow par le propriétaire applicatif. Ce point est important, car les écarts de signature LDAP survivent souvent via des exceptions oubliées, des comptes de service non revus ou des équipements jamais retestés après mise à jour de la stratégie.
Si l’environnement montre aussi une exposition au relais sur des services voisins, documentez-le explicitement. Dans beaucoup d’audits internes, le même système qui parle encore LDAP faible présente aussi des conditions favorables à NTLM_RELAY_OPPORTUNITY. Capturer cette relation aide les équipes à supprimer durablement la dépendance au lieu de demander une nouvelle exception longue durée.
How EtcSec Detects This
EtcSec relie ce sujet directement à LDAP_SIGNING_DISABLED, et il est souvent pertinent de l’examiner à côté de NTLM_RELAY_OPPORTUNITY quand du trafic annuaire faible et des chemins réseau relayables apparaissent ensemble. La vraie valeur n’est pas seulement de signaler que « le paramètre est faible », mais de savoir si la stratégie DC reste permissive, si des clients faibles sont encore actifs et si la remédiation relève de l’équipe annuaire ou d’un propriétaire applicatif.
ℹ️ Note: EtcSec vérifie automatiquement les faiblesses de signature LDAP pendant chaque audit Active Directory afin de distinguer une règle écrite d’un contrôle réellement appliqué sur les contrôleurs de domaine.
Official References
- Microsoft Learn: LDAP signing for Active Directory Domain Services on Windows Server
- Microsoft Learn: Manage LDAP signing using Group Policy for Active Directory Domain Service
- Microsoft Learn: How to enable LDAP signing in Windows Server
- Microsoft Support KB4520412: LDAP channel binding and LDAP signing requirements for Windows
Related Reading
Si vous traitez la signature LDAP, regardez aussi Attaques NTLM Relay : détournement de l’authentification dans AD, Supervision sécurité Active Directory : événements qui comptent, Chemins d’attaque Active Directory vers Domain Admin, Mauvaises configurations GPO : vecteur d’attaque AD et Sécurité des mots de passe AD : erreurs de configuration qui comptent. Le durcissement LDAP est plus solide quand confiance réseau, confiance annuaire et chemins de privilèges sont revus ensemble.
