Liaison de canal LDAP, contrôleur de domaine, relais NTLM, LDAPS : la moitié de l'avis de 2020 que personne n'a terminée

Liaison de canal LDAP, contrôleur de domaine, relais NTLM, LDAPS — ces quatre termes appartiennent à la même phrase, car la liaison de canal est le seul paramètre du contrôleur de domaine qui empêche un relais NTLM d'atterrir dans une session LDAPS sur le port 636. La plupart des équipes Active Directory ont lu les recommandations de durcissement de Microsoft de 2020 comme un seul et même élément, ont fermé la moitié « signature LDAP », puis sont passées à autre chose. La moitié « liaison de canal » est une valeur de registre distincte qui, sur Windows Server 2022 et les versions antérieures, n'existe pas tant qu'un administrateur ne l'a pas créée — et Windows Server 2025 n'a changé cela que pour les tout nouveaux déploiements.

Liaison de canal LDAP, contrôleur de domaine, relais NTLM, LDAPS : comment les pièces s'assemblent

La liaison de canal LDAP utilise un jeton de liaison de canal (Channel Binding Token, CBT) pour lier l'authentification qui se produit à l'intérieur d'une session TLS au canal TLS qui la transporte. Microsoft explique que les CBT servent « à lier cryptographiquement la sécurité de la couche application (telle qu'une session SSL/TLS) à la connexion réseau sous-jacente », afin qu'un attaquant qui intercepte la session chiffrée ne puisse ni la détourner ni la rétrograder.

Le jeton n'existe qu'à un seul endroit. La référence de stratégie Windows pour Contrôleur de domaine : exigences du jeton de liaison de canal du serveur LDAP est explicite : « Le CBT ou l'EPA est utilisé avec les sessions TLS lorsqu'une méthode d'authentification SASL est utilisée pour authentifier l'utilisateur. SASL signifie que vous utilisez NTLM ou Kerberos pour l'authentification de l'utilisateur. La liaison simple LDAP (Simple Bind) sur TLS n'offre pas de protection par jeton de liaison de canal et n'est donc pas recommandée. »

Deux ports comptent ici. Le LDAP en clair écoute sur le port 389 — le port où vivent les problèmes d'énumération non authentifiée tels que l'accès LDAP anonyme via dsHeuristics. LDAPS utilise le port 636 et établit une session SSL/TLS dès qu'un client se connecte. La liaison de canal est un contrôle pour ce second port.

La capacité elle-même n'est pas nouvelle. Selon la KB4520412, « la prise en charge de la liaison de canal LDAP a été ajoutée par le CVE-2017-8563 sur Windows Server 2008 et les versions ultérieures », et les jetons de liaison de canal sont pris en charge sur Windows 10 version 1709 et ultérieure. Ce que le CVE-2017-8563 a livré, c'est la prise en charge d'Extended Protection for Authentication (EPA) plus une entrée de registre qu'un administrateur doit créer — pas un changement de valeur par défaut.

Pourquoi la signature LDAP ne couvre pas votre trafic LDAPS

C'est la partie qu'on saute généralement, et le texte de vulnérabilité de Microsoft lui-même le dit clairement. La description MSRC du CVE-2017-8563 indique :

Une vulnérabilité d'élévation de privilèges existe dans Microsoft Windows lorsqu'un attaquant de type « homme du milieu » (man-in-the-middle) parvient à transférer avec succès une demande d'authentification vers un serveur LDAP Windows, tel qu'un système exécutant Active Directory Domain Services (AD DS) ou Active Directory Lightweight Directory Services (AD LDS), qui a été configuré pour exiger la signature ou le scellement sur les connexions entrantes.

Relisez cette dernière proposition deux fois. Le contrôleur de domaine de cette phrase exige déjà la signature. Il reste pourtant relayable. Le correctif livré par Microsoft était l'EPA, et la FAQ du même avis indique aux administrateurs qu'installer la mise à jour ne suffit pas — ils doivent en plus créer le paramètre de registre LdapEnforceChannelBinding.

La portée du contrôle de signature explique pourquoi. Lorsque la signature LDAP est appliquée, un contrôleur de domaine « rejette les liaisons simples LDAP sur des connexions non SSL/TLS et les liaisons SASL qui ne demandent pas de signature ». Les deux moitiés de cette règle concernent un trafic qui n'est pas déjà à l'intérieur de TLS. Une liaison simple transportée sur LDAPS n'est pas ce que le contrôle de signature rejette, et selon la référence de stratégie ci-dessus, elle ne bénéficie pas non plus de la protection par jeton de liaison de canal : le CBT s'applique lorsqu'une méthode SASL — NTLM ou Kerberos — effectue l'authentification, ce qui explique pourquoi Microsoft signale la liaison simple LDAP sur TLS comme « non recommandée » plutôt que comme quelque chose que la liaison de canal corrige.

Si vous travaillez encore sur le volet signature, ce contrôle est traité séparément dans Signature LDAP désactivée : comment les liaisons non signées exposent Active Directory. Cet article traite de l'autre valeur, sur l'autre port.

La valeur par défaut qui n'a jamais bougé

L'avis ADV190023 de Microsoft, Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing, est inhabituellement direct sur le point de départ : « Un ensemble de configurations par défaut non sécurisées pour la liaison de canal LDAP et la signature LDAP existe sur les contrôleurs de domaine Active Directory, qui permettent aux clients LDAP de communiquer avec eux sans appliquer la liaison de canal LDAP ni la signature LDAP. »

Les mises à jour du March 10, 2020 dont tout le monde se souvient ont ajouté le paramètre de stratégie de groupe et les ID d'événements. Elles n'ont rien basculé du tout. La KB4520412 répète l'avertissement quatre fois — dans son introduction et une fois dans chaque section de mise à jour : « Les mises à jour du March 10, 2020, et les mises à jour dans un avenir prévisible, ne modifieront pas les stratégies par défaut de signature LDAP ou de liaison de canal LDAP, ni leur équivalent de registre, sur les contrôleurs de domaine Active Directory nouveaux ou existants. » Les mises à jour d'audit du August 8, 2023 et du October 10, 2023 le répètent chacune pour leur propre version.

Côté registre, la KB4034879 est tout aussi directe : « Par défaut, ce paramètre est désactivé » et « L'entrée de registre LdapEnforceChannelBindings doit être créée explicitement ».

C'est avec Windows Server 2025 que l'histoire change enfin — partiellement.

La documentation de Microsoft indique que Windows Server 2025 et les versions ultérieures configurent la liaison de canal sur « When supported » par défaut, avec l'audit de la liaison de canal activé par défaut, et que ces valeurs par défaut renforcées s'appliquent aux nouveaux déploiements Active Directory — tandis que « les installations mises à niveau conservent leurs paramètres de sécurité LDAP actuels afin d'éviter toute interruption ». Un contrôleur de domaine Server 2025 qui rejoint un domaine que vous avez construit en 2016 n'est donc pas automatiquement celui, durci, vanté dans les points marketing. Si un renouvellement de contrôleur de domaine est déjà à votre programme, cette distinction compte : voir Fin de support de Windows Server 2016 : mise à niveau des contrôleurs de domaine Active Directory.

Et « When supported » n'est pas non plus la ligne d'arrivée. Selon la propre définition de Microsoft, à ce niveau « seules les liaisons de canal incorrectes seront bloquées, et les clients qui ne prennent pas en charge la liaison de canal peuvent continuer à se connecter via LDAP sur TLS ». La meilleure pratique documentée est Always.

La chaîne d'attaque

Étape 1 - Obtenir une authentification à relayer

L'attaquant a besoin qu'une machine Windows ou un compte utilisateur s'authentifie vers un hôte sous son contrôle. Les mécanismes de cette étape — coercition, empoisonnement de la résolution de noms, chemin de partage malveillant — sont les mêmes que ceux traités dans Attaques par relais NTLM : détournement de l'authentification dans AD, et ne sont modifiés par rien de ce qui se passe sur le contrôleur de domaine.

Étape 2 - Le relayer vers LDAPS sur le port 636

Plutôt que de terminer l'authentification, l'attaquant ouvre sa propre session TLS vers un contrôleur de domaine sur le port 636 et y transfère les messages d'authentification de la victime. C'est exactement le scénario que décrit l'ADV190023 : « un attaquant de type homme du milieu parvient à transférer avec succès une demande d'authentification vers un serveur LDAP Windows ... qui n'a pas été configuré pour exiger la liaison de canal, ni la signature ou le scellement sur les connexions entrantes. »

Étape 3 - Se lier et agir en tant que principal relayé

Avec LdapEnforceChannelBinding absent ou réglé sur 0, le contrôleur de domaine n'a aucun moyen de remarquer que l'authentification a été forgée pour un canal TLS différent de celui par lequel elle est arrivée, et la liaison réussit. L'attaquant détient désormais une session LDAP authentifiée portant les droits d'annuaire du compte relayé — ce qui, si le principal relayé est un compte ordinateur de contrôleur de domaine ou un utilisateur privilégié, constitue un chemin très court vers le reste du domaine. Une session LDAP authentifiée est aussi l'endroit où les objets d'annuaire sont écrits, et des valeurs par défaut telles que le quota de comptes machine déterminent ce qu'un compte faiblement privilégié peut encore faire.

Avec l'application du CBT réglée sur Always, la même authentification relayée ne porte aucune liaison valide pour le canal de l'attaquant, et le contrôleur de domaine la rejette.

Détection

Commencez par ce que chaque contrôleur de domaine fait réellement aujourd'hui, pas par ce que prétend l'éditeur de GPO.

$dcs = (Get-ADDomainController -Filter *).HostName

Invoke-Command -ComputerName $dcs -ScriptBlock {
    $params = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
    $diag   = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics'
    [pscustomobject]@{
        DC          = $env:COMPUTERNAME
        OS          = (Get-CimInstance Win32_OperatingSystem).Caption
        CBT         = (Get-ItemProperty $params -Name LdapEnforceChannelBinding -ErrorAction SilentlyContinue).LdapEnforceChannelBinding
        Signing     = (Get-ItemProperty $params -Name LDAPServerIntegrity -ErrorAction SilentlyContinue).LDAPServerIntegrity
        LdapLogging = (Get-ItemProperty $diag -Name '16 LDAP Interface Events' -ErrorAction SilentlyContinue).'16 LDAP Interface Events'
    }
} | Format-Table -AutoSize

Une colonne CBT vide signifie que la valeur n'a jamais été créée. Sur Windows Server 2022 et les versions antérieures, cela équivaut à 0 — Never.

Les deux paramètres se trouvent sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, et la KB4520412 les associe aux noms de stratégie comme suit.

Ensuite, les événements. Ils atterrissent tous dans le journal Directory Service avec la source Microsoft-Windows-ActiveDirectory_DomainService.

🚨 Danger : ce tableau cache un piège. La KB4520412 indique que « les événements 3039, 3074 et 3075 ne peuvent être générés que lorsque la liaison de canal est réglée sur When Supported ou Always ». Un contrôleur de domaine resté à la valeur par défaut ne produit donc aucun inventaire client — les événements d'audit qui vous indiquent quels clients casseraient n'existent pas tant que vous n'avez pas déjà quitté Never. Le réflexe habituel « auditer d'abord, activer ensuite » est ici inversé : passer à 1 est l'étape d'audit.

Les événements 3040 et 3041 font exception, et constituent votre oracle de référence. Ils se déclenchent au niveau de journalisation 0 sans aucune configuration, et uniquement lorsque la stratégie est Never. Si un contrôleur de domaine journalise le 3041, la liaison de canal y est désactivée — quoi qu'en dise la page de propriétés.

Get-WinEvent -FilterHashtable @{
    LogName   = 'Directory Service'
    Id        = 3039, 3040, 3041, 3074, 3075
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Select-Object Name, Count |
    Sort-Object Name

Pour collecter le détail des clients, augmentez le niveau de diagnostic LDAP. La KB4520412 donne la commande textuellement :

Reg Add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

Au niveau 2, les événements 3074 et 3075 transportent les champs nécessaires pour retrouver un client : l'adresse IP et le port du client, l'identité que le client a tenté d'utiliser pour s'authentifier, si le client prend en charge la liaison de canal, s'il a été autorisé en mode when-supported, et une valeur d'indicateur de résultat d'audit.

Get-WinEvent -FilterHashtable @{ LogName = 'Directory Service'; Id = 3074, 3075 } -ErrorAction SilentlyContinue |
    ForEach-Object {
        if ($_.Message -match 'Client IP address:\s*(\d{1,3}(?:\.\d{1,3}){3}):\d+') { $Matches[1] }
    } |
    Group-Object |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Adaptez le motif si certains de vos clients atteignent le contrôleur de domaine via IPv6.

Les indicateurs de résultat d'audit se décodent comme suit, selon la KB4520412.

Les bits dans 0x30 indiquent un CBT valide ; les bits dans 0x0C indiquent un CBT en échec.

Les événements d'audit nécessitent également un socle de mise à jour minimal : selon l'ADV190023, les événements d'audit de liaison de canal 3074 et 3075 sont devenus disponibles sans étape d'activation manuelle avec les mises à jour du November 14, 2023 sur Windows Server 2022 et les mises à jour du January 9, 2024 sur Windows Server 2019.

Remediation

1. Assainissez d'abord la plomberie. La liaison de canal est un contrôle sur LDAPS, donc LDAPS doit être sain avant d'appliquer quoi que ce soit : un certificat valide sur chaque contrôleur de domaine et une configuration TLS moderne. Si ce terrain n'est pas vérifié, commencez par Audit TLS faible LDAPS, spouleur d'impression, synchronisation horaire du contrôleur de domaine.

2. Passez à When Supported (valeur 1).

$params = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
New-ItemProperty -Path $params -Name 'LdapEnforceChannelBinding' -PropertyType DWord -Value 1 -Force

La KB4034879 confirme que le coût opérationnel est proche de zéro : « Le serveur LDAP répond dynamiquement aux modifications de cette entrée de registre. Vous n'avez donc pas besoin de redémarrer l'ordinateur après avoir appliqué la modification du registre. » Microsoft recommande également spécifiquement la valeur 1 pour maximiser la compatibilité avec les systèmes d'exploitation plus anciens.

3. Lisez l'inventaire sur un cycle métier complet. Avec la journalisation de diagnostic à 2, collectez les 3074 et 3075 sur tous les contrôleurs de domaine, assez longtemps pour capturer les tâches mensuelles et trimestrielles. La KB4520412 recommande de répartir chaque IP source en trois catégories : appliance ou routeur (contactez le fournisseur), périphérique non Windows (confirmez auprès de l'éditeur de l'OS et de l'application que la signature et la liaison de canal sont toutes deux prises en charge), et périphérique Windows (vérifiez que l'application utilise réellement la liaison de canal).

4. Attendez-vous à des catégories de casse spécifiques. La FAQ LDAP de Microsoft signale que les clients se connectant via SSL/TLS sans CBT échoueront dès que le serveur l'exigera, et que « les connexions SSL/TLS terminées par un serveur intermédiaire qui émet à son tour une nouvelle connexion vers un contrôleur de domaine Active Directory échoueront » — un répartiteur de charge (load balancer) effectuant la terminaison TLS devant vos contrôleurs de domaine est une victime garantie. La même FAQ note que « la prise en charge de la liaison de canal peut être moins courante sur les systèmes d'exploitation et applications tiers qu'elle ne l'est pour la signature LDAP », ce qui explique précisément pourquoi tant d'environnements ont terminé la signature et se sont arrêtés ici. La KB4520412 ajoute deux autres modes d'échec. Windows XP « ne prend pas en charge la liaison de canal LDAP et échouerait si la liaison de canal LDAP est configurée avec une valeur Always, mais interopérerait avec des DC configurés avec le paramètre de liaison de canal LDAP plus permissif When supported » — il survit à l'étape 2 et échoue à l'étape 5. Et un client peut avoir l'EPA désactivé localement via le paramètre de registre SuppressExtendedProtection ; puisque la KB4520412 définit un client compatible liaison de canal comme un client où l'EPA est « installé ou disponible dans l'OS et non désactivé via le paramètre de registre SuppressExtendedProtection », un tel client n'apparaît jamais non plus dans votre inventaire 3075.

5. Appliquez avec Always (valeur 2), par stratégie. Une fois l'inventaire propre, réglez la stratégie de groupe Contrôleur de domaine : exigences du jeton de liaison de canal du serveur LDAP sur Always sous Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options dans la Default Domain Controllers Policy, afin que les nouveaux contrôleurs de domaine en héritent au lieu de dépendre de la mémoire de quelqu'un pour la valeur de registre. La meilleure pratique énoncée par Microsoft pour ce paramètre est Always ; l'effet de bord documenté est que les clients qui ne prennent pas en charge la liaison de canal ne peuvent plus exécuter de requêtes LDAP contre les contrôleurs de domaine.

6. Vérifiez par l'absence. L'événement 3041 ne se déclenche que tant que la stratégie est Never. Quand un contrôleur de domaine cesse de journaliser les 3040 et 3041, et commence à journaliser des 3039 pour de véritables échecs, l'application est active sur cet hôte. Relancez l'inventaire de registre de la section Détection sur tous les contrôleurs de domaine — y compris ceux promus après le changement.

7. Fermez les chemins de relais voisins. La liaison de canal ferme une destination de relais. Les identifiants relayés proviennent généralement d'un endroit où le SMB n'est pas signé, associez donc ce travail à Signature SMB désactivée : pourquoi elle permet encore le relais NTLM — et les points de terminaison d'inscription de certificats constituent une destination distincte qu'il vaut la peine d'auditer dans la même campagne, traitée dans Chemins d'attaque ADCS expliqués.

Comment EtcSec détecte cela

EtcSec lit la configuration LDAP effective de chaque contrôleur de domaine lors d'un audit Active Directory. LDAP_CHANNEL_BINDING_DISABLED signale les contrôleurs de domaine qui n'exigent pas de jetons de liaison de canal, et LDAP_SIGNING_DISABLED signale la moitié « signature » du même avis — délibérément sous forme de deux constats distincts, car fermer l'un ne ferme pas l'autre. NTLM_RELAY_OPPORTUNITY rapporte l'exposition au relais que ces valeurs par défaut créent, et DC_LDAPS_WEAK_TLS vérifie que la couche TLS dont dépend la liaison de canal est elle-même saine.

Références officielles

• KB4520412 : 2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for Windows — correspondances de registre, tableaux d'événements complets et déclencheurs, indicateurs de résultat d'audit
• KB4034879 : Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure — sémantique des valeurs, état par défaut, aucun redémarrage requis
• ADV190023 : Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing — la déclaration sur les valeurs par défaut non sécurisées et le calendrier de mise à jour
• CVE-2017-8563 — Windows Elevation of Privilege Vulnerability — le relais contre un serveur LDAP avec signature appliquée, score de base CVSS 3.0 de 7.5
• Domain controller: LDAP server channel binding token requirements — définitions des valeurs, valeurs par défaut effectives par version de Windows, meilleure pratique
• LDAP signing for Active Directory Domain Services on Windows Server — valeurs par défaut de Windows Server 2025 et comportement lors de la mise à niveau
• Manage LDAP signing using Group Policy — la stratégie d'application de la signature de Server 2025 et les étapes de journalisation de diagnostic
• KB4546509 : Frequently asked questions about changes to Lightweight Directory Access Protocol — modes d'échec de compatibilité

Lectures connexes

• Signature LDAP désactivée : comment les liaisons non signées exposent Active Directory
• Attaques par relais NTLM : détournement de l'authentification dans AD
• Signature SMB désactivée : pourquoi elle permet encore le relais NTLM
• Audit TLS faible LDAPS, spouleur d'impression, synchronisation horaire du contrôleur de domaine : une checklist d'hygiène réseau
• Accès LDAP anonyme dsHeuristics : énumération Active Directory
• Quota de comptes machine Active Directory (ms-DS-MachineAccountQuota)
• Chemins d'attaque ADCS expliqués : comment les mauvaises configurations de certificats deviennent des chemins d'escalade Active Directory
• Fin de support de Windows Server 2016 : mise à niveau des contrôleurs de domaine Active Directory