Sécurité Active Directory – Comment configurer la signature LDAP (LDAP Signing) ?
Sommaire
I. Présentation
Dans ce tutoriel, nous allons apprendre à activer et configurer le LDAP Signing dans un environnement Active Directory. Nous parlerons tout d'abord de la sécurité apportée par le LDAP Signing avant d'évoquer sa mise en œuvre à l'aide de stratégie de groupe (GPO).
Pour suivre ce tutoriel, vous avez besoin à minima d'un contrôleur de domaine Active Directory et d'une machine Windows pour jouer le rôle de client (Windows 10, Windows 11, Windows Server).
II. Qu'est-ce que le LDAP Signing ?
A. Quelques mots sur le LDAP et SASL
Le protocole LDAP est un protocole vulnérable à plusieurs attaques, et est susceptible de laisser fuiter en clair des identifiants sur le réseau (nom d'utilisateur et mot de passe au format texte). C'est notamment le cas avec une connexion LDAP Simple bind. Fort heureusement, il existe des solutions pour l'utiliser de façon sécurisée, dont le LDAPS (LDAP over SSL/TLS) et le LDAP SASL bind, qui peut être signé ou non signé (en lien direct avec ce que nous allons étudier dans cet article !).
Le protocole SASL (Simple Authentication and Security Layer) permet la prise en charge de plusieurs mécanismes d'authentification (GSS-SPNEGO, GSSAPI, EXTERNAL, DIGEST-MD5) qui eux-mêmes supportent des protocoles d'authentification (Kerberos, NTLM, DIGEST) pour sécuriser les connexions LDAP.
La sécurité apportée est plus ou moins robuste selon le protocole d'authentification utilisé. Microsoft l'explique sur son site : "Il ne faut pas croire que le SASL avec signature est moins sûr que le TLS. Cependant, toutes les méthodes d'authentification SASL ne se valent pas. Dans la mesure du possible, essayez d'éliminer l'utilisation de protocoles faibles tels que NTLM."
B. L'intérêt du LDAP Signing
Le LDAP Signing ou la Signature LDAP en français, est un mécanisme de sécurité qui exige que les clients signent les requêtes LDAP. La signature LDAP garantit que la demande reçue par le contrôleur de domaine (serveur LDAP) a bien été envoyée par le client dont le message LDAP est censé provenir. Cette signature va permettre de sécuriser les connexions LDAP via SASL Bind.
Dans les faits, ceci assure une protection contre certaines attaques puisque l'on s'assure que les requêtes LDAP n'ont pas été modifiés ou altérés entre la source et la destination. Sans la signature, le LDAP est vulnérable aux attaques de type man-in-the-middle.
Ce mécanisme de sécurité n'est pas nouveau puisque Windows XP et Windows Server 2003 supporte le LDAP signing.
III. Configuration du LDAP Signing
Par défaut, vous devez savoir que les contrôleurs de domaine Active Directory et les clients Windows vont tenter de négocier une connexion LDAP avec signature : si le client demande la signature des données, le serveur pourra le prendre en charge et la connexion sera sécurisée.
Néanmoins, ce n'est pas obligatoire, pour des raisons de compatibilité avec certaines applications et les OS obsolètes. De ce fait, le LDAP Signing est possible, mais il est facultatif : nous allons le rendre obligatoire pour renforcer la sécurité de notre environnement AD.
A. Activation sur les contrôleurs de domaine
Sachez que des effets de bord sont possibles avec la configuration que nous allons mettre en place. Avant de mettre en œuvre cette configuration sur vos contrôleurs de domaine, vérifiez d'abord qu'aucun client (OS ou applications) n'est configuré pour s'authentifier via un protocole LDAP non signé. Sinon, l'application ne pourra plus s'authentifier auprès de l'Active Directory. En fin d'article, une section aborde l'audit de ces événements.
Vous devez donc vous assurer de configurer ces applications pour utiliser le LDAP avec signature, le LDAPS ou le LDAP protégé par IPsec.
Commençons par créer la GPO pour les contrôleurs de domaine, à partir de la console de gestion de stratégies de groupe. Pour ma part, je crée une nouvelle GPO nommée "Sécurité - LDAP Signing - DC" et elle est liée à l'OU "Domain Controllers".
Puis, modifiez la GPO et parcourez l'arborescence de cette façon :
- Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité.
Modifiez le paramètre "Contrôleur de domaine : conditions requises pour la signature de serveur LDAP" afin de le configurer sur l'option "Exiger la signature". Ainsi, la signature LDAP sera obligatoire pour les connexions sur les DC de ce domaine.
Le paramètre contient les explications suivantes : "Nécessiter une signature : sauf si TLS\SSL est utilisé, l’option de signature des données LDAP doit être négociée.", ce qui signifie que nous pouvons aussi utiliser LDAPS.
Validez et fermez la GPO, car c'est le seul paramètre que nous devons configurer.
B. Activation sur les machines Windows
Dans le même esprit que pour les contrôleurs de domaine, nous allons créer une seconde GPO pour forcer l'utilisation de la signature LDAP du côté des clients (postes de travail, serveurs). L'impact est moindre puisqu'ils sont en mode "Négociation" par défaut, donc ils sont susceptibles de déjà l'utiliser.
Passons à la création de la seconde GPO, toujours à partir de la console de gestion de stratégies de groupe. Pour ma part, je crée une nouvelle GPO nommée "Sécurité - LDAP Signing - Client" et elle est liée sur la racine du domaine.
Puis, modifiez la GPO et parcourez l'arborescence de cette façon :
- Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité.
Modifiez le paramètre "Sécurité réseau : conditions requises pour la signature de client LDAP" afin de le configurer sur l'option "Exiger la signature". Ainsi, le client LDAP va automatiquement chercher à utiliser la signature LDAP : ce qui répondra aux attentes du serveur LDAP.
La précision suivante présente dans l'onglet "Expliquer" justifie d'autant plus la configuration de ce paramètre : "Si vous définissez le serveur de sorte qu’il exige des signatures LDAP, vous devez également définir le client. Si vous ne définissez pas le client, celui-ci ne pourra plus communiquer avec le serveur."
Validez et fermez la GPO, car c'est le seul paramètre que nous devons configurer.
IV. Tests de bon fonctionnement
Maintenant que la configuration est en place, la première chose à faire avant d'initier un test, c'est d'actualiser les GPO sur les DC et sur une machine qui sera utilisée pour le test.
gpupdate /forceEnsuite, nous allons pouvoir valider la configuration à l'aide de l'outil "ldp.exe", disponible par défaut sur Windows Server. L'objectif sera de tenter une connexion non sécurisée en Simple Bind : elle devrait être refusée.
Lancez l'outil, cliquez sur "Connexion", puis "Se connecter". Indiquez le nom FQDN du contrôleur de domaine et validez avec le bouton "OK", sans modifier les autres options.
Ensuite, cliquez sur "Connexion" puis "Lier..." (bind). Sélectionnez "Liaison simple", indiquez un compte utilisateur valide puis cliquez sur "OK".
Si la connexion réussie, vous devriez avoir le message "Authenticated as" dans la sortie. Dans ce cas, c'est que votre configuration n'est pas opérationnelle ! En effet, elle doit être refusée.
res = ldap_simple_bind_s(ld, 'IT-Connect\guy.mauve', <unavailable>); // v.3
Authenticated as: 'IT-CONNECT\guy.mauve'.Si le LDAP Signing est bien requis, la connexion doit échouer et le message "Authentification ferme requise" doit apparaître. Voici un exemple :
-----------
res = ldap_simple_bind_s(ld, 'IT-Connect\guy.mauve', <unavailable>); // v.3
Error <8>: ldap_simple_bind_s() failed: Authentification ferme requise
Server error: 00002028: LdapErr: DSID-0C09032E, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v4f7c
Error 0x2028 Une méthode d’authentification plus sécurisée est nécessaire pour ce serveur.
-----------
Si vous n'obtenez pas le résultat attendu, ouvrez l'éditeur de Registre sur votre DC et vérifiez la valeur suivante :
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity
Elle doit être égale à "2". Si elle est égale à "1", c'est que le LDAP Signing n'est pas obligatoire sur le serveur.
ans ce cas, vérifiez votre GPO : elle doit prendre le dessus sur la GPO "Default Domain Controllers Policy". En effet, cette GPO par défaut configure sur "Aucun" le paramètre "Contrôleur de domaine : conditions requises pour la signature de serveur LDAP". Ainsi, dans l'ordre des liens de GPO, votre GPO doit être au-dessus de cette GPO.
V. Auditer les connexions LDAP non sécurisées
Les journaux Windows sont précieux pour identifier quelles sont les machines à l'origine de connexions LDAP non sécurisées : connexion avec une liaison SASL sans signature ou un Bind simple avec les informations en texte clair. À chaque fois qu'une machine est à l'origine d'une connexion non sécurisée, un événement avec l'ID "2889" sera généré dans le journal "Directory Service" du contrôleur de domaine. Malheureusement, ces logs ne sont pas générés par défaut.
Remarque : par défaut, un événement avec l'ID 2887 est généré par les DC, une fois par période de 24 heures, lorsqu'une connexion non sécurisée a été détectée. Néanmoins, cet événement ne donne pas d'informations sur la source.
Pour changer le niveau de log de l'interface LDAP, il convient de modifier une clé de Registre sur chaque DC.
Voici la commande à exécuter. Vous pouvez aussi pousser ce changement par GPO.
reg add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2 Vous devez confirmer avec "Oui", afin de faire passer le niveau de 0 à 2. L'image ci-dessous illustre ce changement.
Si une connexion LDAP non sécurisée est effectuée, un nouvel événement sera bien enregistré sur le DC.
Cet événement avec l'ID 2889 est accessible via l'Observateur d'événements, via PowerShell ou encore avec Windows Admin Center (comme sur l'image ci-dessous). L'avantage, c'est qu'il indique l'adresse IP du client LDAP, ce qui doit vous permettre d'identifier l'appareil à l'origine de cette connexion (et ainsi l'application associée).
En PowerShell, voici la commande à exécuter :
Get-WinEvent -FilterHashtable @{LogName="Directory Service";Id=2889}À titre d'information, cette tentative de connexion non sécurisée a été effectuée avec l'outil "ldp.exe" via une connexion Simple Bind. Ainsi, la capture Wireshark effectuée au même moment met bien en évidence le problème : l'identifiant et le mot de passe de l'utilisateur sont visibles en clair ! Si un attaquant parvient à capturer le trafic en transit sur votre réseau, il peut alors mettre la main sur des identifiants valides.
VI. Conclusion
En suivant ce tutoriel, vous devriez être en mesure de forcer l'activation du LDAP Signing sur votre environnement Active Directory, tout en passant par la phase d'audit, grâce à la génération des événements avec l'ID 2889. Ainsi, la signature pourra améliorer la sécurité des échanges LDAP effectués via SASL Bind.
En complément de l'obligation d'utiliser la signature LDAP, il est recommandé de prioriser le protocole d'authentification Kerberos. Si vous pouvez, vous devez désactiver le protocole NTLM (au moins la version 1).
De plus, vous pouvez vous intéresser à la mise en œuvre du LDAPS et du "LDAP Channel Binding" pour lier le tunnel TLS à la couche applicative (LDAP), et ainsi éviter les attaques par rejeu d'un jeton de session (man-in-the-middle). Ce sera l'occasion de sécuriser les connexions via un LDAPS Bind à la place du Simple Bind.
Pour information, la configuration du LDAP Signing est prise en charge par l'outil HardenAD que nous avions évoqué dans un précédent article. Voici des liens utiles à ce sujet :
Qu’en est-il d’un client qui utilise Entra.ID pour la gestion des utilisateurs et de ses postes de travail, mais qui possède toujours un Azure ADConnect on premise ? Merci