Imposer la signature et la liaison de canal LDAP

Relayer une authentification NTLM vers LDAP sur un contrôleur de domaine est le chemin le plus direct entre « je peux forcer une machine à s'authentifier auprès de moi » et la compromission du domaine. Un attaquant qui relaie un compte d'ordinateur vers LDAP peut configurer une délégation contrainte basée sur les ressources sur cet ordinateur. Un utilisateur privilégié relayé peut ajouter des comptes à des groupes ou accorder des droits DCSync. Des outils comme ntlmrelayx et KrbRelayUp automatisent exactement cela, et c'est pourquoi la protection de LDAP est généralement la première chose que réclame un rapport de test d'intrusion.

Le pilier NTLM et protocoles hérités liste les deux valeurs de registre qui corrigent le problème. Ce guide couvre le déploiement : comment collecter les preuves sur chaque DC, comment lire les événements 2886 à 2889 et 3039 à 3041, quoi modifier sur chaque type de client, et comment passer de l'audit à l'application stricte sans panne un lundi matin.

En quoi les deux contrôles diffèrent

Les deux paramètres se trouvent sous :

Computer Configuration > Policies > Windows Settings > Security Settings >
  Local Policies > Security Options

La liaison de canal n'existe que pour les sessions protégées par TLS : elle suppose donc que vos DC disposent d'un certificat LDAPS valide, généralement émis à partir du modèle Domain Controller Authentication ou Kerberos Authentication. Si LDAPS n'a jamais fonctionné dans votre domaine, corrigez cela d'abord ; le guide de durcissement AD CS couvre les modèles.

Les valeurs par défaut dépendent de la version. Les anciens DC sont livrés avec une signature non exigée et une liaison de canal réglée sur « jamais ». Windows Server 2025 a introduit des valeurs par défaut plus strictes pour les nouveaux déploiements et un paramètre d'application supplémentaire dans les Security Options, mais les environnements mis à niveau ou migrés sur place conservent la configuration antérieure. Lisez toujours les valeurs de registre effectives au lieu de les supposer.

Mesurer : activer la télémétrie

Chaque DC journalise des événements de synthèse dans le journal Directory Service sans aucune modification :

Les événements par client 2889 et 3039 sont ceux dont vous avez besoin, et ils nécessitent la journalisation de diagnostic de l'interface LDAP au niveau 2. Activez-la sur chaque DC. Le volume reste faible dans la plupart des domaines, mais augmentez la taille du journal Directory Service pour qu'il contienne une semaine de données.

$dcs = (Get-ADDomainController -Filter *).HostName
Invoke-Command -ComputerName $dcs -ScriptBlock {
    Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' `
        -Name '16 LDAP Interface Events' -Value 2 -Type DWord
    Limit-EventLog -LogName 'Directory Service' -MaximumSize 512MB
}

Auditer : établir la liste de remédiation

Collectez les événements 2889 et 3039 sur tous les DC pendant au moins deux semaines, en incluant une fin de mois si des systèmes financiers se lient à AD. L'événement 2889 stocke l'adresse du client, l'identité et le type de liaison à des positions fixes : le type 0 correspond à une liaison SASL non signée, le type 1 à une liaison simple sans TLS.

$results = foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{ LogName = 'Directory Service'; Id = 2889 } -ErrorAction SilentlyContinue |
        ForEach-Object {
            [PSCustomObject]@{
                DC       = $dc
                Client   = ($_.Properties[0].Value -split ':')[0]
                Identity = $_.Properties[1].Value
                BindType = @{ '0' = 'Unsigned SASL'; '1' = 'Simple (cleartext)' }[[string]$_.Properties[2].Value]
            }
        }
}
$results | Group-Object Client, Identity, BindType | Sort-Object Count -Descending |
    Select-Object Count, Name | Export-Csv .\ldap-unsigned-clients.csv -NoTypeInformation

# Liaison de canal : lister les messages 3039 bruts par DC
foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{ LogName = 'Directory Service'; Id = 3039 } -MaxEvents 200 -ErrorAction SilentlyContinue |
        Select-Object @{n='DC';e={$dc}}, TimeCreated, Message
}

Si vous centralisez les événements (voir Windows Event Forwarding), ajoutez plutôt les deux ID à l'abonnement des DC et interrogez le collecteur.

Associez chaque IP cliente à un responsable. D'expérience, la liste contient presque toujours les mêmes catégories :

• Imprimantes et multifonctions qui interrogent le carnet d'adresses avec une liaison simple sur le port 389.
• Intégrations Linux et appliances (concentrateurs VPN, pare-feu, wikis et outils de ticketing, NAS) configurées avec un DN de liaison et un mot de passe en LDAP non chiffré.
• Applications Java utilisant JNDI avec une authentification simple.
• Scripts utilisant System.DirectoryServices avec AuthenticationTypes.None ou une authentification basique explicite.
• Clients Windows : ils posent rarement problème, car ils négocient la signature par défaut (« Network security: LDAP client signing requirements » = Negotiate signing) et prennent en charge la liaison de canal depuis des années.

Corriger les clients

Pour chaque source, choisissez l'une de ces options, par ordre de préférence :

1. Utiliser Kerberos ou SASL Negotiate si la bibliothèque le permet. La signature est alors gérée par le protocole.
2. Utiliser LDAPS (636) ou StartTLS avec la chaîne de l'AC d'entreprise approuvée sur le client. Cela satisfait l'exigence de signature. Pour la liaison de canal, la bibliothèque cliente doit aussi envoyer un jeton de liaison ; les versions récentes de Java le prennent en charge via une propriété JNDI, et le comportement des clients basés sur OpenLDAP varie selon la version : testez chacun d'eux.
3. Retirer ou remplacer l'équipement s'il ne sait faire ni l'un ni l'autre. Un multifonction qui ne sait se lier qu'en clair expose aussi le mot de passe de son compte de liaison à quiconque se trouve sur le réseau.

Changez le mot de passe de chaque compte apparu dans une liaison simple en clair : il a circulé sur le réseau sans protection depuis que l'intégration existe. Dans la mesure du possible, faites passer ces intégrations sur des comptes dédiés à faibles privilèges plutôt que sur des comptes de service réutilisés.

Configurez également la stratégie côté client sur les machines Windows pour exiger la signature une fois que vos DC l'imposent, afin qu'un serveur LDAP malveillant ne puisse pas les rétrograder :

Network security: LDAP client signing requirements = Require signing
HKLM\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity (DWORD) = 2

Imposer par étapes

1. Liaison de canal à 1 (si prise en charge) sur tous les DC. Cela protège tous les clients qui envoient déjà des jetons, ce qui couvre les Windows modernes, pratiquement sans risque.
2. Signature exigée (LDAPServerIntegrity = 2) lorsque l'événement 2889 est silencieux ou ne montre plus que des sources acceptées dont le retrait est planifié. Commencez par un seul DC si vous pouvez y orienter les clients restants, puis traitez les autres.
3. Liaison de canal à 2 (toujours) lorsque l'événement 3039 est silencieux.

Déployez ces paramètres via une GPO liée à l'UO Domain Controllers afin qu'un DC nouvellement promu en hérite. Les deux prennent effet sans redémarrage sur les versions actuelles de Windows Server, mais prévoyez un redémarrage progressif du service NTDS ou des DC dans une fenêtre de maintenance si vous voulez une certitude.

Vérifier

Invoke-Command -ComputerName $dcs -ScriptBlock {
    $p = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
    [PSCustomObject]@{
        DC                  = $env:COMPUTERNAME
        LDAPServerIntegrity = $p.LDAPServerIntegrity
        ChannelBinding      = $p.LdapEnforceChannelBinding
    }
} | Format-Table DC, LDAPServerIntegrity, ChannelBinding

Chaque DC doit afficher 2 et 2. Les événements 2886 et 3041 doivent disparaître après le cycle de 24 heures suivant, et l'événement 2888 doit apparaître avec le nombre de liaisons rejetées, idéalement zéro. Un décompte 2888 non nul après l'application stricte signifie qu'un client oublié est en échec : les événements de diagnostic l'identifieront. Une fois l'application stricte stabilisée, ramenez le niveau de diagnostic à 0, ou conservez-le à 2 si vous souhaitez une alerte permanente en cas de régression.

Enfin, relancez vos outils de test d'intrusion ou demandez à votre red team de rejouer le test de relais vers LDAP. Le relais doit échouer au moment de la liaison.

Ce qui casse

• Les liaisons simples sur le port 389 sans TLS sont rejetées dès que la signature est exigée : carnets d'adresses des multifonctions, anciennes appliances VPN, certains connecteurs SIEM et IAM, et scripts maison. Ils doivent passer à LDAPS ou StartTLS.
• Les clients LDAPS sans prise en charge de la liaison de canal échouent lorsque la valeur passe à 2 : anciens runtimes Java, certaines piles LDAP embarquées et certaines passerelles d'identité tierces. La valeur 1 les laisse fonctionner, d'où son rôle d'étape intermédiaire.
• L'inspection TLS ou les répartiteurs de charge placés devant les DC qui terminent TLS cassent la liaison de canal par conception, car le canal du client n'est pas celui du DC. Ne placez pas de DC derrière des équipements qui terminent TLS.
• Les problèmes de certificats deviennent des pannes : dès que des intégrations dépendent de LDAPS, un certificat de DC expiré les arrête. Surveillez l'expiration des certificats des DC et l'inscription automatique.

Pour aller plus loin : le thème NTLM & protocoles hérités, l'entrée de glossaire Liaison de canal LDAP, bloquer la coercition d'authentification pour supprimer les déclencheurs que les attaquants relaient, et délégation contrainte et RBCD pour l'écriture de délégation que vise généralement le relais vers LDAP.