Dans Active Directory, LDAP facilite les échanges entre les postes, les applications et les contrôleurs de domaine, mais une connexion mal protégée peut exposer des identifiants ou des requêtes à l’interception. La bonne approche consiste à auditer les usages, à imposer la signature LDAP quand elle convient et à activer LDAPS avec un certificat TLS valide. Voici comment distinguer les ports, préparer la configuration et vérifier que les échanges sont réellement protégés.
L’article en bref
LDAP est un rouage discret d’Active Directory, mais sa protection ne se règle pas au hasard. Repérez les connexions à sécuriser, choisissez la bonne méthode et testez chaque étape avant le déploiement général.
- Repérer les ports : Distinguez LDAP sur 389 et LDAPS sur 636 avant d’ouvrir les flux réseau.
- Renforcer les échanges : Imposez la signature LDAP aux connexions SASL compatibles du domaine.
- Préparer LDAPS : Installez un certificat TLS adapté et reconnu par les clients LDAP.
- Auditer avant déploiement : Exploitez les événements des contrôleurs pour identifier les clients non sécurisés.
Une configuration LDAP bien préparée renforce la sécurité des annuaires sans couper les applications légitimes.
Active Directory LDAP : comprendre les ports et les protections
Dans une entreprise fictive, l’équipe de Nora découvre qu’un ancien outil d’inventaire interroge encore l’annuaire sans protection. Ce type de connexion peut laisser passer des données sensibles sur le réseau : le premier réflexe consiste donc à savoir quel protocole est utilisé, et sur quel port.
LDAP permet aux applications de consulter et parfois de modifier les données de l’annuaire. Avec un bind simple sans TLS, les identifiants ne bénéficient pas du chiffrement du transport. Le trafic peut alors être lisible par une personne capable de l’intercepter sur le réseau.
| Protocole ou usage | Port courant | Protection et remarque |
|---|---|---|
| LDAP | 389 | Connexion LDAP classique ; le chiffrement dépend de la configuration utilisée. |
| LDAP avec StartTLS | 389 | Démarre une session TLS sur une connexion LDAP existante. |
| LDAPS | 636 | Établit TLS dès l’ouverture de la connexion LDAP. |
| Catalogue global LDAP | 3268 | Accès au catalogue global sans TLS implicite. |
| Catalogue global LDAPS | 3269 | Accès au catalogue global sous TLS. |
Ces ports sont les valeurs habituelles, mais les règles de pare-feu doivent correspondre aux services réellement utilisés. N’ouvrez que les flux nécessaires entre les clients concernés et les contrôleurs de domaine : une règle réseau trop large, c’est la porte d’entrée laissée grande ouverte.
LDAP Signing et LDAPS : deux protections différentes
La signature LDAP, ou LDAP Signing, protège l’intégrité des échanges SASL signés : elle aide à détecter une modification des requêtes en transit. Elle ne chiffre pas à elle seule toute la conversation. LDAPS, lui, établit une session TLS qui protège la confidentialité et l’intégrité du transport.
Les deux mécanismes ne s’opposent donc pas. Une connexion SASL signée peut convenir à certains usages, tandis que les applications qui utilisent un bind simple doivent s’appuyer sur TLS, par LDAPS ou StartTLS. Pour une authentification sécurisée, le choix dépend des capacités du client et des règles de l’organisation.
Le protocole SASL peut s’appuyer sur plusieurs mécanismes, notamment Kerberos ou NTLM. Leur niveau de robustesse n’est pas identique : privilégiez Kerberos lorsque c’est possible et réduisez la dépendance aux mécanismes anciens. La sécurité des annuaires se construit par couches, pas avec un seul bouton magique.
Configuration LDAP : préparer les contrôleurs de domaine
Avant de modifier une stratégie, faites l’inventaire des applications, équipements et systèmes qui interrogent Active Directory. Une imprimante multifonction oubliée ou un service historique peut encore utiliser une liaison non signée ; imposer la signature sans vérification risque alors de bloquer son authentification.
La démarche la plus sûre est progressive : activez l’audit, identifiez les clients concernés, corrigez leurs paramètres, puis rendez la signature obligatoire. Testez d’abord sur un périmètre maîtrisé et conservez une procédure de retour arrière.
Créer une GPO pour exiger la signature LDAP côté serveur
Dans la console de gestion des stratégies de groupe, créez une stratégie dédiée, par exemple « Sécurité – LDAP Signing – DC », puis liez-la à l’unité d’organisation des contrôleurs de domaine. Dans l’éditeur, ouvrez le chemin suivant :
- Configuration ordinateur > Paramètres Windows > Paramètres de sécurité ;
- Stratégies locales > Options de sécurité ;
- Contrôleur de domaine : conditions requises pour la signature de serveur LDAP ;
- Choisissez Exiger la signature.
Ce réglage impose la signature aux connexions LDAP SASL concernées. Une connexion protégée par TLS, notamment en LDAPS, reste possible. Vérifiez toutefois que la GPO s’applique effectivement et qu’aucune stratégie prioritaire ne la remplace.
Imposer la signature LDAP aux clients Windows
Pour aligner les postes et serveurs Windows sur la règle des contrôleurs de domaine, créez une seconde GPO, par exemple « Sécurité – LDAP Signing – Client ». Dans les mêmes options de sécurité, configurez Sécurité réseau : conditions requises pour la signature de client LDAP sur « Exiger la signature ».
Déployez la stratégie sur un groupe pilote avant de l’étendre au domaine. Une application qui ne sait communiquer qu’en LDAP non signé peut échouer après ce changement : l’audit préalable sert précisément à éviter la panne du lundi matin, ce classique dont personne ne raffole.
Activer LDAPS avec un certificat TLS valide
LDAPS repose sur un certificat que le contrôleur de domaine peut présenter aux clients. Pour éviter les alertes et les échecs de validation, le certificat doit être valide, contenir l’usage approprié pour l’authentification du serveur et correspondre au nom DNS utilisé par les clients.
Dans un environnement de production, une autorité de certification d’entreprise ou une autorité reconnue est généralement préférable à un certificat autosigné. Les clients doivent faire confiance à la chaîne de certification ; sinon, ils peuvent refuser la connexion même si le port 636 répond.
Émettre et installer le certificat sur le contrôleur de domaine
Si l’environnement dispose déjà d’Active Directory Certificate Services, utilisez un modèle de certificat adapté à l’authentification du serveur. Vérifiez que le nom DNS du contrôleur de domaine figure dans le certificat et que sa clé privée est installée avec celui-ci dans le magasin personnel de l’ordinateur.
Si une nouvelle autorité de certification est nécessaire, son déploiement demande une réflexion sur la confiance, la sauvegarde et la durée de validité. Évitez de créer une autorité temporaire sans plan de gestion : un certificat expiré ou une chaîne non distribuée transforme rapidement le port 636 en porte fermée.
Une fois le certificat installé, vérifiez que les clients font confiance à son autorité émettrice et qu’ils se connectent au contrôleur par son nom DNS correspondant. Les applications clientes n’ont généralement pas besoin d’une copie de la clé privée du serveur : ne l’exportez pas pour les postes clients.
Configurer le client LDAP sous Windows ou Linux
Sur un client Linux utilisant OpenLDAP, installez le certificat de l’autorité de confiance selon les règles de votre distribution, puis indiquez son emplacement dans la configuration cliente. Par exemple, la directive TLS_CACERT doit pointer vers le certificat de l’autorité qui a signé le certificat du contrôleur, et non vers une clé privée.
Pour tester StartTLS avec ldapsearch, utilisez le nom DNS du serveur et exigez la validation TLS. Selon la version de l’outil, les options peuvent différer ; vérifiez sa page d’aide et configurez le nom de serveur conformément au certificat présenté.
Sous Windows, l’outil graphique ldp.exe permet de tester une connexion : entrez le nom DNS du contrôleur, indiquez le port 636 et cochez l’option SSL. Un échec peut signaler un certificat non approuvé, un nom qui ne correspond pas ou un port bloqué.
Tester la configuration LDAP et auditer les connexions faibles
Après le déploiement des stratégies, actualisez-les sur les contrôleurs de domaine et sur le poste de test avec gpupdate /force. Validez ensuite le comportement attendu avant d’étendre la configuration à tous les systèmes.
Avec ldp.exe, une tentative de bind simple sans TLS doit être refusée lorsque le contrôleur exige la signature pour les connexions concernées. Un message indiquant qu’une authentification plus sécurisée est requise peut confirmer le refus attendu. En revanche, un bind simple réussi sans TLS montre que le scénario de test n’est pas protégé comme prévu.
Pour auditer les clients incompatibles, activez le niveau de journalisation LDAP sur chaque contrôleur de domaine. La commande suivante configure le niveau 2 pour les événements d’interface LDAP :
reg add HKLMSYSTEMCurrentControlSetServicesNTDSDiagnostics /v « 16 LDAP Interface Events » /t REG_DWORD /d 2
L’événement 2889 du journal « Directory Service » fournit des informations utiles sur les connexions LDAP non sécurisées, dont l’adresse IP du client. L’événement 2887 fournit plutôt un récapitulatif périodique et ne permet pas, à lui seul, d’identifier chaque source.
Pour consulter les événements détaillés dans PowerShell, utilisez :
Get-WinEvent -FilterHashtable @{LogName= »Directory Service »;Id=2889}
Associez chaque adresse repérée à une machine, puis à l’application qui l’utilise. Corrigez l’application pour qu’elle emploie une liaison SASL signée, LDAPS ou StartTLS selon ses capacités, avant de rendre la stratégie obligatoire partout.
Points de contrôle avant la mise en production
- Vérifier les applications et équipements qui utilisent LDAP sur le port 389.
- Confirmer que les clients font confiance à l’autorité du certificat TLS.
- Tester LDAPS par nom DNS sur le port 636 depuis les réseaux concernés.
- Examiner les événements 2889 et corriger chaque connexion non sécurisée identifiée.
- Déployer les GPO progressivement et contrôler leur application sur les postes pilotes.
Un audit bien mené transforme les journaux en plan d’action : chaque connexion repérée devient une occasion de moderniser un service sans interrompre les usages nécessaires.
Questions pratiques sur Active Directory LDAP et LDAPS
Quelle différence entre LDAP sur le port 389 et LDAPS sur le port 636 ?
LDAP utilise couramment le port 389 et peut fonctionner sans chiffrement, ou démarrer TLS avec StartTLS. LDAPS utilise généralement le port 636 et établit TLS dès le début de la connexion.
La signature LDAP remplace-t-elle LDAPS ?
Non. La signature protège l’intégrité des échanges SASL concernés, tandis que TLS chiffre le transport. Une liaison simple doit être protégée par TLS pour éviter l’exposition des identifiants.
Quel certificat faut-il pour activer LDAPS sur un contrôleur de domaine ?
Le contrôleur doit disposer d’un certificat valide pour l’authentification du serveur, avec le nom DNS utilisé par les clients et une clé privée installée. Les clients doivent faire confiance à la chaîne de certification.
Comment repérer les clients qui utilisent LDAP sans protection ?
Activez la journalisation détaillée LDAP sur les contrôleurs de domaine, puis recherchez les événements 2889 dans le journal Directory Service. Ils aident à retrouver l’adresse IP à l’origine des connexions concernées.
