LDAP port TCP : le port 389 et les communications sécurisées expliquées

Dans les réseaux informatiques d’entreprise, le LDAP port TCP désigne avant tout le port 389. C’est là que les clients se connectent par défaut pour parler à un annuaire. Le protocole Lightweight Directory Access Protocol a besoin d’un transport fiable, et TCP remplit parfaitement ce rôle : livraison ordonnée, retransmission automatique, gestion des paquets volumineux. UDP existe aussi sur ce même port, mais dans la vraie vie on le voit très peu pour les opérations LDAP complètes.

Le truc c’est que beaucoup de monde confond encore les deux. On voit des captures Wireshark qui montrent parfois du UDP, surtout chez Microsoft avec CLDAP pour des requêtes ultra-légères. Mais dès qu’il s’agit d’une recherche un peu sérieuse, d’une authentification ou d’une modification dans l’annuaire, tout le monde bascule sur TCP. Les RFC le disent clairement : le port par défaut est TCP 389 et les clients doivent le supporter.

Pourquoi TCP plutôt qu’UDP pour LDAP ?

TCP apporte la fiabilité dont LDAP a besoin. Une requête LDAP peut renvoyer des milliers d’entrées, des attributs binaires, des certificats… Si un paquet se perd, il faut le renvoyer sans tout recommencer. UDP, lui, reste en mode « envoie et prie ». Ça va pour des trucs simples et stateless, mais pas pour un protocole qui gère des sessions, des contrôles étendus et des pages de résultats.

En fait, l’IANA enregistre bien le service « ldap » sur 389 en TCP et en UDP. Mais la quasi-totalité des implémentations modernes (OpenLDAP, Active Directory, 389 Directory Server…) écoutent et parlent prioritairement en TCP. Sur le terrain, quand je configure un pare-feu, je mets systématiquement TCP 389 en premier.

Le port 389 : le standard non sécurisé (et toujours indispensable)

C’est le port historique. Un client LDAP s’y connecte en clair, fait son bind (souvent avec des identifiants), puis lance des recherches ou des modifications. Dans Active Directory, ce port sert à presque tout : authentification des postes, application des GPO, replication entre contrôleurs de domaine, trusts, etc.

Le point important : même en 2026, on ne peut pas simplement désactiver le 389 sur un domaine Active Directory. Les spécifications, les enregistrements DNS SRV, les anciens clients et une bonne partie du code Microsoft sont encore écrits autour de ce port. Du coup on le garde… mais on le protège.

Honnêtement, laisser le 389 exposé sur internet sans rien autour, c’est jouer avec le feu. Les credentials circulent en clair, les données d’annuaire aussi. C’est pour ça que tout le monde parle maintenant de LDAPS.

LDAPS sur le port 636 : la version chiffrée en TCP

Quand on veut du LDAP sécurisé dès le début de la connexion, on passe sur le port 636 en TCP. Le handshake TLS se fait avant même la première requête LDAP. Plus de texte en clair sur le réseau.

Active Directory supporte ça depuis longtemps, à condition d’installer un certificat valide sur les contrôleurs de domaine (avec le bon OID d’authentification serveur et le FQDN dans le Subject ou le SAN). Une fois le certificat en place, le service LDAP écoute automatiquement sur 636.

Beaucoup d’administrateurs activent aussi StartTLS sur le port 389 : le client se connecte en clair, puis négocie le chiffrement via une requête étendue. C’est plus flexible, mais certains outils et pare-feu préfèrent le port dédié 636. Les deux approches coexistent, et c’est tant mieux.

Les ports supplémentaires dans Active Directory : 3268 et 3269

Quand on travaille dans un domaine Microsoft, il y a deux autres ports TCP à connaître :

• 3268 : LDAP sur le Global Catalog. Il permet des recherches forest-wide sans avoir à connaître le domaine exact de l’objet.
• 3269 : la version chiffrée du Global Catalog (LDAPS GC).

Ces ports sont purement TCP. Pas de UDP ici. Un poste Windows membre du domaine utilise massivement le 389 et le 3268 pour ses opérations courantes. Si vous bloquez ces ports entre les VLAN ou entre sites, vous allez avoir des surprises au niveau de l’authentification et des stratégies de groupe.

Ce qu’il faut vraiment ouvrir dans le pare-feu

Sur un contrôleur de domaine, les flux entrants typiques à autoriser depuis les clients et les autres DC :

• TCP 389 (et UDP 389 si vous avez encore des outils qui l’utilisent)
• TCP 636 pour LDAPS
• TCP 3268 et 3269 pour le Global Catalog

N’oubliez pas les ports éphémères en sortie (généralement 49152-65535 ou la plage configurée). Et côté client, c’est souvent le contraire : autoriser les connexions sortantes vers ces ports sur les DC.

En pratique, je vois encore trop de règles « tout autoriser vers le DC » qui datent de 2012. Avec un peu de segmentation réseau et du zero-trust, on peut restreindre sérieusement sans tout casser.

Dépannage rapide quand ça ne marche pas

Le plus fréquent : le pare-feu bloque le 389 ou le 636. Testez avec ldp.exe sur Windows ou ldapsearch sur Linux en forçant le port. Si la connexion timeout, c’est presque toujours réseau. Si elle se connecte mais que le bind échoue, regardez les credentials ou les permissions.

Pour LDAPS, les erreurs de certificat sont classiques : nom DNS qui ne correspond pas, certificat non approuvé par le client, ou chaîne incomplète. Vérifiez avec certlm.msc sur le DC et testez la connectivité TLS avec OpenSSL (openssl s_client -connect dc01:636).

Un autre classique : le service n’écoute plus sur 636 après un renouvellement de certificat. Un redémarrage du service NTDS ou du serveur règle souvent le problème.

En résumé, ce que je recommande sur le terrain

Le LDAP port TCP 389 reste le port de référence et il ne disparaîtra pas demain. Mais dans n’importe quel réseau un peu sérieux, on active LDAPS sur 636 (et 3269 pour le GC) et on limite l’exposition du port 389. StartTLS sur 389 est un bon compromis quand on ne peut pas tout basculer.

Si vous gérez un domaine Active Directory aujourd’hui, la question n’est plus « est-ce qu’on utilise le 389 ? » mais « comment on le sécurise et comment on restreint son exposition ? ». Le reste, c’est de la configuration réseau classique : règles de pare-feu précises, supervision des flux, et tests réguliers avec les vrais outils des utilisateurs.

Ça fait partie des bases qu’on vérifie systématiquement quand on audite ou qu’on monte une infra propre. Et franchement, une fois que c’est bien fait, on n’y pense plus… jusqu’à la prochaine migration ou le prochain audit de sécurité.