LDAP et LDAPS : comprendre les protocoles et leur usage en entreprise

Dans une entreprise, un compte désactivé trop tard ou un mot de passe transmis sans protection peut ouvrir une brèche bien réelle. LDAP centralise les identités et les ressources ; LDAPS protège les échanges grâce au chiffrement TLS. Comprendre leur différence aide à relier les applications à un annuaire d’entreprise sans négliger la sécurité des accès.

LDAP et LDAPS : le rôle de l’annuaire d’entreprise

Sans annuaire central, chaque application peut conserver ses propres comptes. Les équipes doivent alors gérer plusieurs mots de passe et désactiver les accès un à un lorsqu’un salarié quitte l’organisation. Un annuaire d’entreprise réduit ces doublons en fournissant aux services une source commune d’informations sur les utilisateurs, les groupes et certains équipements.

LDAP, pour Lightweight Directory Access Protocol, est un protocole standard d’accès à ces annuaires, défini notamment par la RFC 4511. Ce n’est pas un logiciel en soi : différents produits peuvent l’implémenter. Par exemple, une entreprise fictive, Atelier Nord, peut relier son outil de gestion des postes à un annuaire central plutôt que d’y recréer les profils de chaque salarié.

Entrées, attributs et DN : lire la structure LDAP

Un annuaire LDAP classe les informations dans une arborescence appelée Directory Information Tree. Chaque entrée possède un nom distinctif, ou DN, qui indique son emplacement et l’identifie de manière unique. Ainsi, uid=alice,ou=People,dc=example,dc=com désigne l’entrée de l’utilisatrice Alice dans l’unité People du domaine example.com.

Une entrée comprend une ou plusieurs classes d’objets, qui définissent les attributs possibles, puis les valeurs correspondantes : nom, adresse électronique ou identifiant de groupe. Cette organisation permet à un service de rechercher précisément un compte, plutôt que de parcourir des informations sans structure.

Élément	Rôle	Exemple
DN	Identifie une entrée dans l’arborescence	uid=alice,ou=People,dc=example,dc=com
OU	Regroupe logiquement des entrées	ou=People
Attribut	Décrit une caractéristique de l’entrée	mail=alice@example.com
objectClass	Détermine le type de données autorisées	inetOrgPerson

LDAP, Active Directory et les solutions d’annuaire

Plusieurs solutions savent communiquer avec LDAP, mais elles ne remplissent pas toutes le même rôle. Active Directory (AD) est un service d’identité de Microsoft pour les environnements Windows. Il utilise LDAP, mais comprend aussi d’autres composants, notamment Kerberos, DNS et les stratégies de groupe, qui facilitent l’administration des postes et des comptes.

OpenLDAP, FreeIPA et 389 Directory Server répondent à d’autres besoins, souvent dans des environnements Linux ou mixtes. Le choix dépend des systèmes déjà en place, des compétences disponibles et des fonctions attendues. Un annuaire isolé ne fournit pas automatiquement toutes les fonctions d’un service d’identité complet.

Solution	Contexte courant	À retenir
Active Directory Domain Services	Environnements Windows	Associe LDAP à des services comme Kerberos et aux stratégies de groupe
OpenLDAP	Linux et infrastructures auto-hébergées	Implémentation LDAP open source à administrer selon les besoins
FreeIPA	Parcs Linux	Associe annuaire, gestion des identités et fonctions liées à Kerberos
389 Directory Server	Infrastructures Linux	Serveur d’annuaire LDAP utilisé notamment dans l’écosystème Red Hat

LDAP, Kerberos et les fournisseurs d’identité

LDAP sert à consulter ou modifier des entrées ; il ne remplace pas tous les mécanismes d’authentification. Dans un domaine Active Directory, Kerberos permet notamment l’authentification par tickets et le SSO : après une connexion initiale, un utilisateur peut accéder à des services sans ressaisir son mot de passe à chaque étape.

Un fournisseur d’identité moderne, comme Keycloak ou Okta, peut s’appuyer sur un annuaire LDAP ou AD pour récupérer les comptes, puis exposer l’authentification aux applications web par OIDC ou SAML. Cette séparation est utile : l’annuaire conserve les identités de référence, tandis que l’IdP facilite la connexion aux services numériques.

LDAPS et chiffrement TLS : protéger les échanges LDAP

Le point essentiel n’est pas seulement de savoir où se trouve un annuaire, mais aussi de protéger les informations qui circulent entre lui et ses clients. Une connexion LDAP classique utilise généralement le port 389. Sans chiffrement, les identifiants et certaines données échangées peuvent être exposés sur le réseau, selon la méthode d’authentification et la configuration.

LDAPS établit une connexion protégée par TLS dès le début de l’échange, habituellement sur le port 636. Une autre possibilité consiste à démarrer une connexion LDAP sur le port 389, puis à négocier le chiffrement avec StartTLS. Dans les deux cas, les certificats doivent être correctement configurés et vérifiés par les clients.

Mode de connexion	Port habituel	Protection
LDAP sans TLS	389	Échanges non chiffrés : à éviter pour les identifiants
LDAP avec StartTLS	389	La connexion passe à TLS après négociation
LDAPS	636	TLS est établi dès l’ouverture de la connexion

Le nom LDAPS désigne donc une manière d’établir une connexion LDAP protégée, et non un annuaire différent. Le port ne suffit pas à garantir la sécurité : il faut aussi vérifier la validité du certificat, les versions de TLS autorisées et la configuration des applications clientes.

Configurer LDAP et LDAPS sans perturber les services

La mise en place commence par le choix d’un serveur adapté à l’infrastructure, puis par la définition des schémas et de l’arborescence. Il faut déterminer quels attributs seront stockés, comment les groupes seront organisés et quelles applications devront interroger l’annuaire. Une structure lisible dès le départ évite de multiplier les exceptions à mesure que le parc grandit.

Avant un déploiement général, Atelier Nord peut tester la configuration sur un environnement de préproduction. Les essais doivent couvrir les recherches, l’authentification, les changements de mot de passe et la désactivation d’un compte. Cette étape permet également de repérer les dépendances oubliées, par exemple une imprimante ou une application métier qui interroge encore l’ancien serveur.

• Cartographier les usages : recenser les applications et appareils qui consultent l’annuaire.
• Définir les entrées : organiser utilisateurs, groupes et unités selon des règles documentées.
• Configurer TLS : installer un certificat valide et vérifier la confiance des clients.
• Limiter les permissions : séparer les comptes d’administration des comptes utilisés par les applications.
• Tester avant production : simuler les connexions, les erreurs et la révocation des accès.

Opérations LDAP et comptes de service

Les clients LDAP réalisent plusieurs opérations : Bind pour s’authentifier, Search pour rechercher des entrées, puis Add, Modify ou Delete pour créer, modifier ou supprimer des données. En production, les modifications doivent être limitées aux rôles qui en ont réellement besoin et consignées dans des journaux exploitables.

Les comptes de service utilisés par les applications méritent une attention particulière. Ils ne devraient pas disposer de droits d’administration généraux : un service chargé de lire le nom et le groupe d’un utilisateur n’a pas besoin de pouvoir supprimer des entrées. Des identifiants dédiés et une rotation maîtrisée réduisent l’impact d’une fuite.

Sécurité des accès et bonnes pratiques LDAP

Le chiffrement TLS protège les échanges en transit, mais ne suffit pas à sécuriser l’ensemble du système. Une configuration robuste associe contrôle des permissions, surveillance des connexions et authentification forte lorsque le contexte le permet. Les comptes inutilisés doivent être désactivés rapidement, et les droits doivent être réévalués lorsque les missions changent.

Pour les services compatibles, des mécanismes comme Kerberos et les keytabs peuvent éviter de stocker un mot de passe réutilisable dans un fichier de configuration. Les équipes doivent aussi synchroniser l’heure des machines : un décalage important peut faire échouer l’authentification Kerberos. Enfin, les journaux doivent aider à repérer les connexions inhabituelles sans exposer inutilement des données personnelles.

RADIUS et TACACS+ autour de l’annuaire

Dans un réseau d’entreprise, RADIUS peut vérifier les accès au Wi-Fi professionnel, au VPN ou à un réseau filaire 802.1X, en s’appuyant parfois sur LDAP ou Active Directory pour valider les comptes. TACACS+ est davantage utilisé pour contrôler l’accès administratif aux équipements réseau et séparer plus finement l’authentification des autorisations.

Ces protocoles complètent l’annuaire sans le remplacer. Pour Atelier Nord, par exemple, RADIUS peut décider si un ordinateur rejoint le Wi-Fi interne, tandis que les groupes de l’annuaire déterminent les ressources accessibles ensuite. La cohérence entre ces systèmes évite qu’un compte supprimé conserve un accès réseau.

Questions fréquentes sur LDAP et LDAPS

Quelle est la différence entre LDAP et LDAPS ?

LDAP est le protocole utilisé pour accéder à un annuaire. LDAPS désigne une connexion LDAP protégée par TLS, généralement établie sur le port 636. StartTLS permet également de chiffrer une connexion commencée sur le port 389.

Le port 389 est-il forcément non sécurisé ?

Non. Le port 389 peut transporter LDAP sans chiffrement, mais il peut aussi être utilisé avec StartTLS. Il faut vérifier que le chiffrement est effectivement négocié et que les certificats sont validés.

Active Directory est-il la même chose que LDAP ?

Non. LDAP est un protocole d’accès aux annuaires. Active Directory Domain Services est un service d’identité qui prend notamment en charge LDAP, Kerberos, DNS et les stratégies de groupe.

LDAP peut-il fonctionner avec un fournisseur d’identité moderne ?

Oui. Un fournisseur d’identité peut lire les comptes depuis LDAP ou Active Directory, puis gérer l’accès aux applications web avec des protocoles comme OIDC ou SAML.