Presque toutes les évaluations de sécurité AD, tous les tests de pénétration ou toutes les discussions sur l'architecture finissent par contenir la recommandation de « passer du LDAP non sécurisé au LDAPS » pour votre Active Directory (AD). Travaillant pour un éditeur de logiciels dont les produits « font des choses avec AD », j'entends plusieurs fois par semaine la question suivante : « Votre produit XY prend-il en charge le LDAPS ? Si ce n'est pas le cas, est-ce prévu ? ». Dans la plupart des cas, la réponse correcte est « Non, et ce n'est pas un problème de sécurité ». Examinons les raisons de cette réponse.
Quel est le problème avec LDAPS ?
Internet propose littéralement des milliers d'articles, de blogs et de vidéos sur la manière de créer et d'importer des certificats TLS dans vos contrôleurs de domaine (DC) afin qu'ils puissent fournir des services LDAP sur TLS sur le port 636/TCP. Pour plus d'informations sur la méthode utilisée par les DC pour sélectionner leur certificat LDAPS lorsqu'il existe plusieurs candidats, vous pouvez lire cet article de Marc-André Moreau sur AwakeCoding, mais pour résumer, Moreau explique que :
« L'activation et l'application du protocole LDAPS constituent aujourd'hui une tâche courante de renforcement de la sécurité dans les environnements Windows Active Directory... En théorie, tout semble parfait, jusqu'à ce que vous vous rendiez compte que non seulement vous ne pouvez pas sélectionner explicitement le certificat LDAPS à utiliser, mais qu'il n'y a pas de journaux à activer et aucun moyen de diagnostiquer le problème. »
Ce que ces articles sur la « mise en œuvre de LDAPS » ne vous disent généralement pas, c'est ce qu'il faut faire avec LDAPS une fois qu'il est activé. Une chose est sûre, cependant : vos contrôleurs de domaine continueront à servir LDAP sans TLS sur le port 389, et vous ne pouvez pas le désactiver ou le bloquer sur le pare-feu sans perturber gravement vos membres AD.
Je répète : un membre AD utilisera toujours le port 389/3268 pour toutes les requêtes LDAP/GC qu'il doit effectuer en tant que membre AD. Il n'y a aucun moyen de modifier ce comportement ou d'inciter une machine membre à utiliser le protocole LDAPS basé sur TLS sur le port 636/3269, point final. Il n'existe pas non plus de moyen standardisé et universellement fiable pour que l'infrastructure annonce LDAPS aux applications.
Pourquoi les solutions de contournement LDAPS ne fonctionnent pas
Étant donné que le seul mécanisme connu pour la découverte de services LDAP est le DNS, plusieurs techniques ont été essayées :
- Ajoutez un enregistrement SRV pour LDAPS, tel que _ldaps._tcp.domain.com, ainsi que _ldap et _gc.
- Modifiez le numéro de port dans les enregistrements du service LDAP de 389 à 636 (et empêchez leur mise à jour par les contrôleurs de domaine).
- Remplacer les enregistrements SRV _ldap par _ldaps (c'est-à-dire supprimer les enregistrements _ldap et _gc ).
Voici le problème avec ces approches : elles ne fonctionnent pas.
L'ajout d'un enregistrement SRV pour LDAPS ne change rien.
Comme _ldaps n'est pas un service standard, aucune application ne le recherchera dans le DNS. Si vous créez une application qui pourrait tirer parti du protocole LDAP sur TLS, vous pouvez implémenter la découverte du service LDAPS dans votre code ; il fonctionnera alors comme n'importe quelle découverte de service personnalisée. Mais comme il ne s'agit pas et n'a jamais été d'une norme industrielle, aucune autre application ne l'utilisera.
Changer le numéro de port ne fonctionnera pas.
La modification du numéro de port n'interrompra pas les communications des membres AD, car le port 389 est codé en dur dans Windows. Cette action pourrait perturber d'autres applications utilisant LDAP, car le passage du port 389 au port 636 ne les incitera pas à établir une négociation TLS avant de tenter une liaison LDAP.
Suppression des enregistrements _ldap et _gc = Ne le faites pas
La troisième approche est un excellent moyen de perturber la découverte de services pour LDAP, y compris celle des membres du domaine. Ne faites pas cela chez vous (ni au travail... ni ailleurs, d'ailleurs).
Connexions simples vs connexions SASL
Alors, le protocole LDAP dans Active Directory est-il simplement « peu sûr de par sa conception » ? Bien au contraire.
La raison pour laquelle il vous a été conseillé de passer à LDAPS est de protéger les informations d'identification en clair utilisées par LDAP si vous effectuez une liaison simple. Le fait est que les membres AD, ainsi que la plupart des applications accédant à AD via LDAP, n'utilisent pas de liaisons simples. Ils utilisent plutôt des liaisons SASL dans lesquelles l'authentification est effectuée par GSS-SPNEGO et la couche de chiffrement LDAP est négociée avec des clés de session échangées pendant le processus d'authentification.
Ainsi, non seulement il n'y a pas d'informations d'identification en clair à protéger, mais les communications sont en fait déjà cryptées, sans avoir besoin de recourir à des certificats pour la couche TLS. Ce mécanisme n'est pas limité aux membres du domaine. N'importe quelle application peut le faire, quel que soit le système d'exploitation et l'appartenance au domaine.
Que faire pour renforcer la sécurité d'AD LDAP, si ce n'est bloquer le port 389 ?
Si vous êtes certain qu'aucune application de votre environnement n'a réellement besoin de liaisons simples avec des informations d'identification en clair, appliquez la signature LDAP sur vos contrôleurs de domaine en définissant la stratégie de groupe comme décrit ici. En plus de... eh bien, de signer les communications, ce qui empêchera diverses attaques par relais Kerberos et NTLM, les contrôleurs de domaine rejetteront également toute liaison simple sur une connexion LDAP non cryptée.
Si vous voulez être absolument certain de ne rien perturber, consultez les journaux d'événements de vos contrôleurs de domaine, comme décrit dans cet article Learn intemporel sur la signature LDAP, la liaison de canal et LDAPS.
Si vous avez des applications qui nécessitent une liaison simple, forcez ces applications à utiliser le port 636/3269 en configurant ce comportement (et la confiance dans les certificats LDAPS) au sein même des applications.
[Note de la rédaction : cet article a été adapté à partir du billet original de l'auteur.]
