LDAP vs. LDAPS : Sécuriser l’accès aux applications existantes

Écrit par Kate Lake le August 4, 2022

Partagez cet article

Les configurations d’applications antérieures utilisent encore le protocole LDAP pour certaines liaisons d’annuaire dans un environnement local. Bien que ces liaisons LDAP traditionnelles soient relativement inoffensives au sein des réseaux locaux fortifiés d’antan, les bases de sécurité modernes exigent le cryptage de toutes les informations d’identification des utilisateurs en transit afin de les protéger contre le reniflage de mots de passe et d’autres formes de vol de données personnelles.

Dans le cas des environnements distants et hybrides, les authentifications LDAP passent plus souvent par l’Internet public, ce qui nécessite des mécanismes de sécurité supplémentaires.

Vous avez peut-être entendu dire que vous deviez configurer les applications tierces existantes pour utiliser le protocole LDAP sécurisé (LDAPS) au lieu du protocole simple LDAP. LDAPS (LDAP sur SSL) et STARTTLS (LDAP over TLS) sont deux versions sécurisées de LDAP qui chiffrent le processus d’authentification. (Notez que “LDAPS” est souvent utilisé pour désigner LDAP sur SSL, STARTTLS et une implémentation LDAP sécurisé).

Le passage de LDAP à LDAPS implique un examen attentif du journal des événements de votre service d’annuaire, l’identification et la commutation manuelles des ports que les anciennes applications utilisent pour se lier à l’annuaire, l’extraction de certificats AC (Autorité de certification) pour créer la liaison sécurisée, et une surveillance continue.

Le processus peut être fastidieux et prendre du temps, mais il est réalisable – et, aujourd’hui plus que jamais, obligatoire. Examinons de plus près le protocole LDAP, ce qui rend LDAPS et STARTTLS sûrs, et comment mettre en œuvre un processus d’authentification sécurisé pour les applications existantes.

Qu’est-ce que LDAP ? Profil de base

LDAP (Lightweight Directory Access Protocol) est parfois utilisé comme synonyme ou abréviation de Microsoft Active Directory lui-même. Cependant, si une grande partie des fonctionnalités d’AD est basée sur LDAP, on parle de deux entités bien distinctes. En fait, AD utilise plus souvent une autre version du même protocole, celui-ci commercialisé par Kerberos, pour authentifier l’accès de ses utilisateurs. De son côté, le protocole LDAP est utilisé par de nombreuses ressources et applications sur site pour authentifier les utilisateurs à un annuaire principal comme AD ou OpenLDAP.

Voici un aperçu plus détaillé du fonctionnement de LDAP. Si vous souhaitez en savoir davantage sur ce protocole, lisez notre interview de Tim Howes, co-créateur de LDAP :

Quelle est la différence entre LDAP et LDAPS ?

LDAPS n’a rien d’un protocole fondamentalement distinct : il s’agit du même vieux LDAP, simplement conditionné différemment. LDAPS permet le cryptage des données LDAP (qui comprennent les informations d’identification des utilisateurs) en transit lors d’une communication avec le serveur LDAP (comme un annuaire lié), ce qui permet une protection contre le vol d’informations d’identification.

SSL et TLS sont des protocoles cryptographiques qui utilisent des certificats établissant une connexion sécurisée entre le client et le serveur avant tout échange de données (dans ce cas, LDAP). TLS est une version améliorée de SSL, ce qui rend STARTTLS plus sûr et recommandé par rapport à LDAP et LDAPS lorsque cela est possible.

En raison de l’augmentation des risques en matière de sécurité et du besoin croissant de cryptage en transit, LDAPS remplace LDAP comme protocole d’annuaire standard accepté. Voici comment les administrateurs informatiques peuvent mettre en œuvre ce changement.

Mise en place de LDAPS (LDAP sur SSL)

En général, LDAP et LDAPS sont activés à la base du système, ce qui rend Secure LDAP disponible pour tous les liens d’annuaire. Dans les environnements Cloud LDAP, par exemple, il est disponible dans la plateforme LDAP.

Dans AD, en revanche, vous devez l’activez sur le contrôleur de domaine ou le catalogue global. Dans ce contexte, l’activation de LDAPS n’est pas automatique, et vous devez d’abord régler les paramètres pour l’utiliser ; exiger des liens LDAPS sans modifier les paramètres pourrait rompre les liens avec des ressources utilisant toujours la version simple LDAP. Dans les deux cas, vous pouvez mettre à jour les liens existants en passant au peigne fin vos ressources liées pour trouver et modifier les liens LDAP en LDAP sécurisé.

Un contrôleur de domaine ou un autre serveur LDAP dont les certificats sont correctement configurés offrira LDAPS via le port 636 (3269 pour un serveur de catalogue global) et STARTTLS via le port 389. Vous pouvez trouver et corriger les liaisons non sécurisées individuellement en passant au peigne fin le journal des événements de votre service d’annuaire – toute application utilisant un port autre que 636 et 3269 doit être examinée.

Dans AD, la plupart des problèmes proviendront de connexions au port 2889. Pour OpenLDAP, le port est souvent le 389. Cependant, le port 389 supporte à la fois le texte brut et STARTTLS – n’utilisez le port 389 que pour les authentifications qui supportent STARTTLS ; sinon, utilisez le port 636 pour LDAPS. (Le consultant en gestion de centre de données Kurt Roggen détaille ce processus étape par étape sur son blog).

Lorsqu’elles sont liées à LDAPS, de nombreuses applications vous demandent de télécharger une autorité de certification homologue. Voici comment vous pouvez le faire dans AD, et voici comment le faire sur Mac, Windows et Linux avec JumpCloud, un service LDAP hébergé dans le cloud.

Ai-je encore besoin de LDAP/LDAPS ?

Compte tenu de certaines des solutions de contournement nécessaires à l’utilisation sécuritaire de LDAP, vous vous demandez peut-être si LDAP a encore sa place dans le paysage informatique moderne. En bref, la réponse est oui : Bien que le transfert des charges de travail vers le cloud ait entraîné l’apparition d’autres protocoles d’authentification, de nombreuses solutions matérielles et logicielles sur site et dans les centres de données utilisent toujours LDAP. Tim Howes a bien résumé la situation à la fin de notre entretien :

«On constate que le monde se déplace de plus en plus vers le cloud, mais il y a toujours un univers présent dans votre environnement local – vous avez des appareils, des imprimantes, vous avez tout. Les gens doivent également être authentifiés dans ces différents contextes. »

La question devient donc moins « Ai-je encore besoin de LDAP ? » que « Existe-t-il un meilleur moyen de gérer LDAP en toute sécurité dans l’ère moderne de l’informatique ? ».

Une approche moderne de LDAP et LDAPS

Si vous suivez le processus d’évaluation ci-dessus et découvrez bon nombre de connexions LDAP non sécurisées, c’est probablement signe que votre annuaire et vos applications ont grandement besoin d’une mise à jour. Avant de régler les coûts liés à la mise à niveau de votre serveur Windows ou OpenLDAP et de tout matériel associé, vous pouvez envisager une solution plus moderne et plus complète pour la gestion LDAP.

Et si, au lieu de doubler la mise avec Active Directory ou OpenLDAP sur site, vous pouviez migrer vos utilisateurs et vos systèmes vers un tout nouvel annuaire hébergé dans le cloud ? Et si votre nouvel annuaire pouvait gérer en toute sécurité les autorisations et les authentifications pour une grande variété de ressources dans le cloud et sur site, avec la fonctionnalité Secure LDAP incluse et toutes les données en transit automatiquement cryptées ? En savoir plus sur la gestion Cloud LDAP.

Kate Lake

Kate Lake is a Senior Content Writer at JumpCloud, where she writes about JumpCloud’s cloud directory platform and trends in IT, technology, and security. She holds a Bachelors in Linguistics from the University of Virginia and is driven by a lifelong passion for writing and learning. When she isn't writing for JumpCloud, Kate can be found traveling, exploring the outdoors, or quoting a sci-fi movie (often all at once).

Continuez à apprendre avec notre newsletter