LDAP signing et channel binding : sécuriser Active Directory sans interruption

Pourquoi ce durcissement est important

Active Directory accepte encore, dans plusieurs environnements existants, des liaisons LDAP qui n’offrent pas toutes les garanties attendues contre l’interception ou la modification du trafic. Un attaquant placé sur le chemin réseau peut tenter de relayer une authentification ou d’altérer une requête lorsque la signature, le chiffrement ou la liaison au canal TLS ne sont pas correctement appliqués.

La cible n’est pas de fermer le port 389 ni d’activer aveuglément une stratégie. Il faut découvrir les imprimantes, NAS, pare-feu, applications Java, outils de supervision et logiciels métiers qui interrogent les contrôleurs de domaine, corriger leurs paramètres, puis imposer les protections par étapes.

Windows Server 2025 et les versions suivantes exigent la signature LDAP par défaut pour les nouveaux déploiements Active Directory. Une mise à niveau depuis une version antérieure conserve toutefois les stratégies existantes afin d’éviter une interruption. Il faut donc vérifier le résultat effectif plutôt que de déduire la posture à partir de la version du système d’exploitation.

• Microsoft — Gérer la signature LDAP avec les stratégies de groupe ↗

Signature LDAP, LDAPS et channel binding : trois mécanismes distincts

LDAPS n’est pas un synonyme de signature LDAP. Une application peut utiliser un simple bind à l’intérieur d’un canal TLS, tandis qu’un client Windows peut utiliser SASL avec signature sur le port 389. De même, chiffrer la connexion ne garantit pas que le client fournit un CBT valide.

Documentez pour chaque intégration le port, l’usage de StartTLS ou LDAPS, la méthode de bind, le compte utilisé, la validation du certificat, la prise en charge de la signature et celle du CBT. Cette matrice évite les raccourcis dangereux.

1. Établir l’inventaire avant de modifier les GPO

Un événement indique une connexion, pas son importance opérationnelle. Associez chaque adresse IP à un actif, un processus et un propriétaire. Les pools NAT, répartiteurs, proxys LDAP et grappes applicatives peuvent masquer l’origine réelle et nécessiter des journaux supplémentaires ou une capture ciblée.

• Recenser chaque application ou équipement qui utilise LDAP et son propriétaire métier.
• Identifier tous les contrôleurs de domaine ciblés, y compris les adresses IP codées en dur et les anciens noms DNS.
• Noter le compte de bind, la méthode d’authentification, le port, TLS, le fournisseur et la version du client.
• Inclure les tâches mensuelles, les systèmes de relève et les équipements rarement utilisés.
• Prévoir un test d’authentification, de recherche et d’autorisation pour chaque intégration critique.

2. Activer l’audit LDAP sur tous les contrôleurs de domaine

L’événement 2887 résume chaque jour les liaisons non protégées qui ont été acceptées. Pour obtenir l’adresse IP et l’identité, définissez le niveau de diagnostic 16 LDAP Interface Events à 2 sur chaque contrôleur de domaine. Microsoft recommande de surveiller 2889 pour la signature ainsi que 3039, 3074 et 3075 pour le channel binding.

La journalisation détaillée augmente le volume du journal Directory Service. Dimensionnez sa taille, centralisez les événements et retirez ou réduisez le diagnostic après la période d’analyse si votre politique d’exploitation l’exige.

$path = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics'
New-ItemProperty -Path $path -Name '16 LDAP Interface Events' `
  -PropertyType DWord -Value 2 -Force

Get-ItemProperty -Path $path -Name '16 LDAP Interface Events'

Import-Module ActiveDirectory
$start = (Get-Date).AddDays(-30)
$ids = 2886,2887,2888,2889,3039,3040,3041,3074,3075

$events = foreach ($dc in Get-ADDomainController -Filter *) {
  try {
    Get-WinEvent -ComputerName $dc.HostName -FilterHashtable @{
      LogName='Directory Service'; Id=$ids; StartTime=$start
    } -ErrorAction Stop | Select-Object @{n='DC';e={$dc.HostName}},
      TimeCreated,Id,LevelDisplayName,Message
  } catch {
    [pscustomobject]@{DC=$dc.HostName;TimeCreated=Get-Date;Id='ERROR';
      LevelDisplayName='Error';Message=$_.Exception.Message}
  }
}
$events | Export-Csv .\LDAP-Audit.csv -NoTypeInformation -Encoding UTF8

• Microsoft — Journalisation diagnostique AD DS et AD LDS ↗
• Microsoft — Exigences LDAP signing et channel binding (KB4520412) ↗

Comprendre les événements à surveiller

Les événements 3074 et 3075 nécessitent les mises à jour prises en charge et le niveau de journalisation approprié. Microsoft précise aussi que les événements 3039, 3074 et 3075 sont générés lorsque le channel binding est configuré à When Supported ou Always.

N’interprétez pas une journée calme comme une preuve de compatibilité. Observez au moins un cycle métier représentatif et validez manuellement les applications critiques.

3. Corriger les clients plutôt que créer des exceptions permanentes

Pour les clients Windows, utilisez SASL avec Negotiate ou Kerberos et demandez la signature. Pour un simple bind, exigez TLS, validez le certificat du contrôleur de domaine et évitez les comptes trop privilégiés. Pour les appliances et applications tierces, confirmez la prise en charge auprès de l’éditeur; une case « SSL » ne documente ni la validation du certificat ni le CBT.

Éliminez les connexions vers une adresse IP lorsque la validation TLS repose sur un nom DNS, remplacez les certificats expirés ou incomplets et évitez de désactiver globalement la validation de certificat. Si un produit ne peut pas être corrigé, traitez-le comme une dette avec propriétaire, segmentation, échéance et plan de remplacement. Il n’existe pas d’exception LDAP signing propre à un seul client sur un contrôleur de domaine.

• Microsoft — Activer LDAP sur SSL avec une autorité tierce ↗

4. Déployer d’abord la stratégie côté client

Dans une GPO dédiée appliquée aux postes et serveurs pilotes, configurez Network security: LDAP client signing requirements à Negotiate signing. Cette étape demande la signature lorsque le serveur la prend en charge tout en facilitant un déploiement graduel. Passez ensuite à Require signing pour les groupes validés.

Cette stratégie Windows ne répare pas automatiquement une bibliothèque Java, un NAS ou une appliance. Les événements des contrôleurs de domaine restent la source de vérité pour savoir ce qui arrive réellement.

gpupdate /force
gpresult /h C:\Temp\gpresult-ldap.html

5. Imposer la signature sur les contrôleurs de domaine

Créez une GPO dédiée et versionnée, liée à l’OU Domain Controllers. Configurez Domain controller: LDAP server signing requirements à Require signing. Une GPO séparée simplifie l’attribution, la revue et le retour arrière par rapport à une modification difficile à retracer dans la Default Domain Controllers Policy.

Un pilote sur un DC demande de la prudence : les clients découvrent normalement plusieurs contrôleurs de domaine et une incompatibilité peut sembler intermittente. Pointez explicitement les tests vers le DC pilote ou utilisez un environnement de laboratoire représentatif avant l’application générale.

Sur Windows Server 2025, vérifiez également Domain controller: LDAP server signing requirements enforcement. Pour un nouveau déploiement, cette stratégie applique la signature par défaut et a priorité sur l’ancienne stratégie. Une forêt mise à niveau conserve son comportement existant.

$ntds = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
Get-ItemProperty $ntds | Select-Object LDAPServerIntegrity,LdapEnforceChannelBinding

# Compléter par RSOP/gpresult : Windows Server 2025 ajoute une stratégie
# d'enforcement qui peut prendre priorité sur la stratégie classique.

6. Passer le channel binding de When Supported à Always

La stratégie Domain controller: LDAP server channel binding token requirements offre Never, When Supported et Always. When Supported constitue une étape de compatibilité utile : elle valide le CBT fourni et permet l’audit, tout en acceptant certains clients qui ne l’envoient pas. Always rejette les authentifications concernées lorsque le CBT est absent ou invalide.

Ne passez à Always qu’après la disparition ou l’acceptation formelle de chaque événement 3039, 3074 et 3075, des tests sur les applications critiques et une fenêtre de changement. La pertinence du CBT dépend de la méthode de bind; validez le comportement réel plutôt que de supposer que tout trafic LDAPS est conforme.

7. Tester autre chose que l’ouverture des ports

Test-NetConnection vers 389 ou 636 ne valide que la connectivité TCP. Ldp.exe peut confirmer qu’un simple bind non protégé reçoit Strong Authentication Required, mais la recette complète doit être exécutée depuis chaque application.

• Tester une authentification réelle avec un compte de service à privilèges minimaux.
• Tester les recherches, les groupes imbriqués et les attributs réellement utilisés.
• Vérifier le basculement vers un autre contrôleur de domaine.
• Valider la chaîne TLS, le nom DNS, l’EKU Server Authentication et le renouvellement du certificat.
• Confirmer qu’un simple bind en clair sur 389 est rejeté après enforcement.
• Surveiller 2888 et 3039 après le changement et suivre les erreurs applicatives.

• Microsoft — Activer et vérifier la signature LDAP ↗

8. Préparer un retour arrière contrôlé

Avant la fenêtre, exportez les GPO, documentez les valeurs effectives et confirmez qui peut rétablir la stratégie. En cas d’incident, retirez temporairement la GPO d’enforcement dédiée ou ramenez le channel binding de Always à When Supported. Conservez la journalisation afin d’identifier le client responsable.

Un retour arrière doit être limité dans le temps. Il ne faut pas supprimer les certificats LDAPS, désactiver la validation TLS partout ou laisser une stratégie assouplie sans propriétaire. Corrigez l’intégration, répétez le pilote et rétablissez la cible sécurisée.

Checklist de déploiement

• Tous les DC sont corrigés et synchronisés.
• Le niveau LDAP Interface Events est défini et les journaux sont centralisés.
• Les événements 2889, 3039, 3074 et 3075 sont associés à un actif et un propriétaire.
• Chaque intégration critique possède une recette de test et un plan de retour arrière.
• Les clients Windows passent de Negotiate signing à Require signing par anneaux.
• Les DC exigent LDAP signing après validation du pilote.
• Le passage de CBT à Always est une décision séparée fondée sur les données.
• Les résultats, exceptions temporaires et échéances sont documentés.

Le bon objectif : une transition mesurée

LDAP signing et channel binding ferment des chemins de relais et de manipulation importants, mais leur valeur dépend d’un inventaire fiable. Le travail le plus long est rarement la GPO : il consiste à retrouver le propriétaire d’une vieille intégration, confirmer son comportement et coordonner sa correction.

Ce guide permet de structurer la transition; il ne remplace pas un audit Active Directory complet. Un audit met aussi en contexte délégations, comptes de service, protocoles hérités, AD CS, chemins privilégiés, sauvegarde et capacité de récupération.

• Service — Audit de sécurité Active Directory →
• Article — Sécuriser les comptes de service AD →
• Article — Migrer Kerberos de RC4 vers AES →