La plupart des organisations gèrent l'identité des utilisateurs sur un répertoire LDAP ou AD. Lorsqu'une nouvelle application est mise en service, la même question revient : comment cette application va-t-elle se connecter au répertoire, comment va-t-elle vérifier l'utilisateur, quelles informations de groupe va-t-elle lire et où va-t-elle prendre la décision d'accès ? Si cette connexion est faite séparément dans chaque application, l'architecture d'identité se disperse rapidement.
L'intégration LDAP par application produit une dette opérationnelle. Chaque application porte son propre compte de service, son adresse de connexion, son filtre de recherche, sa valeur de timeout et son paramètre de vérification de certificat. Lorsque le schéma du répertoire change, que la structure des OU est déplacée, que le mot de passe du compte de service est tourné ou qu'une migration de domaine est effectuée, ce changement se propage à de nombreuses applications.
Du côté de la sécurité, le risque grandit également. L'utilisation de LDAP non chiffré peut entraîner le transport non protégé des mots de passe sur le réseau. Les mots de passe des comptes de service sont stockés dans les configurations des applications. L'autorisation basée sur les groupes, quant à elle, se disperse dans le code propre des applications ; l'authentification et la politique d'accès sont appliquées dans différents systèmes avec différentes règles.
L'audit et la visibilité se fragmentent aussi. L'information de savoir quelle application s'est connectée au répertoire avec quel compte de service, quel utilisateur a été vérifié, quel groupe a été interrogé, quel accès a été refusé reste souvent enfouie dans les journaux des applications. Les équipes SOC et d'audit sont contraintes de rassembler des journaux dispersés au lieu d'un flux d'identité centralisé.
TR7 LDAP / AD Bind résout ce problème sur la plateforme d'accès : les méthodes direct-bind et search-bind, le transport sécurisé LDAPS, la requête d'appartenance aux groupes, le filtre de restriction de bind, le failover multi-serveurs et la politique d'accès conditionnel AAM s'unifient dans une seule architecture.
TR7 AAM traite la connexion LDAP/AD non pas seulement comme une vérification de mot de passe, mais comme un flux de recherche d'utilisateur, d'interrogation de groupe, de transport sécurisé et de production de politique d'accès.
Le direct-bind convertit le nom d'utilisateur en valeur de bind principal via UPN, NetBIOS, UID, CN ou un modèle personnalisé. Le search-bind, lui, recherche l'information de DN de l'utilisateur avec un compte de service, puis effectue la vérification de bind avec le mot de passe propre de l'utilisateur.
En mode search-bind, la recherche de groupes peut être activée et les appartenances aux groupes de l'utilisateur sont ajoutées à la session AAM. Cette information de groupe peut être utilisée dans les décisions d'accès aux applications, d'obligation de MFA ou d'autorisation basée sur le backend.
TR7 peut établir une connexion protégée par TLS via LDAPS. En configurant la vérification de certificat et la politique de certificat self-signed, le niveau de sécurité de la connexion au répertoire est déterminé selon les standards de l'organisation.
Plusieurs serveurs LDAP/AD peuvent être définis dans une seule configuration. Les connexions sont distribuées par les méthodes roundrobin, weighted ou failover ; lorsque le serveur de répertoire principal est inaccessible, un serveur alternatif peut être mis en service.
LDAP / AD Bind relie la vérification par répertoire d'entreprise au flux AAM avec des modèles de bind, des filtres de recherche, l'appartenance aux groupes, un transport sécurisé et la gestion multi-serveurs.
En mode direct-bind, le nom d'utilisateur est converti en valeur de bind principal via l'un des modèles UPN, NetBIOS, UID, CN ou custom. Dans les environnements AD, les formats UPN et NetBIOS sont courants ; dans les répertoires OpenLDAP ou POSIX, les modèles UID et CN peuvent être plus appropriés. Avec un modèle custom, une structure spécifique à l'organisation comme uid={{username}},ou=people,dc=company,dc=com peut être établie. Cette flexibilité facilite la connexion de différents schémas de répertoire à un seul flux de vérification AAM.
En mode search-bind, TR7 se connecte d'abord au répertoire avec un compte de service et recherche l'information de DN de l'utilisateur. Lorsque l'utilisateur est trouvé, une deuxième étape effectue l'opération de bind avec le DN et le mot de passe propres de l'utilisateur. Ce modèle est utile dans les environnements où les utilisateurs se trouvent dans différentes OU, où l'information de DN ne peut pas être produite directement à partir du nom d'utilisateur ou où un filtre de recherche plus contrôlé est nécessaire. L'information du compte de service et du base DN de recherche est gérée de manière centralisée.
En mode automatique, le filtre de search-bind peut évaluer ensemble les champs userPrincipalName, sAMAccountName et cn. En mode custom, l'opérateur définit son propre filtre LDAP ; par exemple, une recherche plus étroite comme (sAMAccountName={{username}}) peut être effectuée. Cette approche s'adapte à différents schémas de répertoire et formats de nom d'utilisateur. Pour réduire les correspondances d'utilisateur erronées, le filtre doit être défini aussi précisément que possible.
Même si le mot de passe de l'utilisateur est correct, il peut ne pas être souhaitable que chaque utilisateur du répertoire accède à chaque application. Avec le bind restriction filter, seuls les utilisateurs satisfaisant une condition d'OU, de groupe ou d'attribut spécifique passent le flux de vérification. Par exemple, seuls les utilisateurs du groupe VPN Users peuvent être admis à un backend spécifique. Ce filtre évalue l'authentification conjointement avec la portée d'accès.
Lorsque ldapEnableGroupSearch est actif, TR7 peut interroger les appartenances aux groupes en utilisant la valeur de DN de l'utilisateur. Avec ldapGroupSearchBase et ldapGroupFilter, on détermine dans quelle zone du répertoire et avec quel filtre les groupes seront recherchés. La liste de groupes retournée est ajoutée à la session AAM. Les flux d'accès conditionnel peuvent prendre des décisions d'application, de MFA, d'autorisation ou de refus différentes selon cette information de groupe.
Lorsque LDAPS est utilisé, la connexion LDAP est protégée par TLS et fonctionne typiquement via le port 636. Le comportement de vérification du certificat du serveur peut être configuré avec des paramètres comme sslValidateCertificate et sslAllowSelfSigned. En environnement de production, LDAP non chiffré ne doit pas être privilégié. La sécurité de la connexion au répertoire est une exigence fondamentale pour la protection des données sensibles comme le mot de passe de l'utilisateur et le compte de service.
Les valeurs de timeout de connexion et d'opération LDAP sont configurables. Si la connexion ne peut pas être établie ou si le serveur de répertoire répond lentement, le flux AAM n'attend pas indéfiniment. Le comportement d'un domain controller lent aux heures de pointe ou la latence d'un segment réseau peuvent être maîtrisés avec ces valeurs. Les paramètres de timeout doivent être planifiés conjointement avec l'expérience utilisateur et le comportement de failover.
TR7 peut transférer vers le profil utilisateur local AAM des valeurs d'attributs comme le mail et le téléphone en récupérant les utilisateurs sous un base de recherche spécifique. Des champs comme queryMailField et queryPhoneField peuvent être ajustés selon le schéma de l'organisation. Cette fonctionnalité aide à la gestion de la liste des utilisateurs et des coordonnées. En environnement cluster, la récupération de la liste des utilisateurs est limitée pour ne s'exécuter que sur le node primary.
Plusieurs serveurs LDAP/AD peuvent être définis dans le tableau hosts. lbMethod peut être choisi comme roundrobin, weighted ou failover. En mode failover, lorsque le serveur principal est inaccessible, le basculement vers un serveur alternatif est effectué. L'approche du pool de connexions et du circuit breaker réduit le risque que des serveurs en échec permanent perturbent le flux.
On peut configurer par quel namespace réseau accéder au serveur LDAP. Ceci est important pour les domain controllers d'un segment distinct ou les structures de répertoire spécifiques à un tenant. Le trafic de gestion des accès est transporté via la bonne table de routage et l'isolation réseau. Cela offre un contrôle réseau plus clair dans les architectures multi-tenant ou de data centers segmentés.
LDAP / AD Bind est exploité conjointement avec le cycle de vie de la connexion, la sécurité des filtres, le nettoyage des connexions, le comportement du search-bind, la contrainte de cluster et la sélection d'attributs.
Lorsque les paramètres LDAP sont mis à jour, l'information de connexion est repréparée et le flux de vérification fonctionne avec les nouveaux paramètres. L'information de connexion est produite à partir des paramètres protocol, host, port, TLS et timeout. L'application des modifications de paramètres au sein d'un cycle de vie centralisé assure la cohérence de la configuration.
Avant que les saisies de l'utilisateur ne soient placées dans le filtre LDAP, les caractères spéciaux sont échappés. Des valeurs comme la barre oblique inverse, l'astérisque, les parenthèses et le caractère null sont échappées pour réduire le risque d'injection LDAP. Ce comportement est particulièrement critique dans les structures utilisant un filtre custom.
Après utilisation de la connexion LDAP, le client est nettoyé et les listeners sont supprimés. Cette approche réduit les connexions zombies et l'usage mémoire inutile. Le comportement keep-alive de longue durée ne doit être utilisé que dans des modes spéciaux comme la récupération de la liste des utilisateurs.
Le filtre de search-bind automatique peut évaluer ensemble les champs userPrincipalName, sAMAccountName et cn. En mode filtre custom, l'opérateur définit son propre filtre LDAP. Le filtre custom est puissant ; mais comme des filtres trop larges et erronés peuvent conduire à des correspondances d'utilisateur inattendues, il doit être conçu avec soin.
La structure de pool de backend LDAP de nouvelle génération peut gérer les connexions du client LDAP avec une logique de pool. Lorsque LDAPS est choisi, les options TLS sont ajoutées à l'établissement de la connexion. Une durée de lookup DNS personnalisée et des valeurs de timeout de connexion prennent de l'importance dans les réseaux lents ou segmentés.
La récupération de la liste des utilisateurs est limitée pour ne s'exécuter que sur le node primary en environnement cluster. Ce comportement empêche que la même liste d'utilisateurs soit récupérée simultanément par plusieurs nœuds et produise une charge inutile. Le flux de bind d'authentification, lui, continue de fonctionner selon le modèle de connexion défini.
Le tableau ldapAttributes détermine quels champs sont retournés depuis le répertoire. Les champs par défaut peuvent couvrir des valeurs comme dn, cn, userPrincipalName, displayName, mail et téléphone. Des champs supplémentaires comme department, employeeID ou un attribut personnalisé peuvent être ajoutés à la liste selon les besoins de l'organisation.
Dans une grande organisation, les employés accèdent aux applications via AAM avec leur nom d'utilisateur et mot de passe AD existants. Les appartenances aux groupes sont transportées vers la politique AAM ; les groupes finance, RH et IT peuvent être dirigés vers des flux d'application ou de MFA différents. Lorsque la politique de mot de passe AD change, les applications ne sont pas mises à jour une par une.
Dans une structure avec deux domain controllers dans deux data centers, TR7 peut établir la connexion via la méthode failover. Lorsque le serveur de répertoire principal est inaccessible, le basculement vers un serveur alternatif est effectué. Le flux de vérification des utilisateurs ne dépend pas de la panne d'un seul DC.
Un backend spécifique ne peut être ouvert qu'aux utilisateurs du groupe VPN Users. Même si le bind réussit, un utilisateur qui ne passe pas la condition bindRestrictionFilter est refusé. Ainsi, la vérification du mot de passe et le droit d'accès à l'application ne sont pas considérés comme la même chose.
Les organisations utilisant OpenLDAP au lieu d'AD peuvent vérifier les utilisateurs avec les modèles de bind UID ou CN. Dans les répertoires basés sur posixAccount, le mapping du mail, du téléphone et des attributs personnalisés peut être transporté vers le profil AAM. En établissant une connexion sécurisée via LDAPS, les répertoires LDAP classiques sont intégrés au flux d'accès moderne.
Connexion LDAP/AD, politique basée sur les groupes, transport sécurisé LDAPS et audit centralisé sur une seule plateforme. Laissez-nous vous guider dans une installation en direct dans votre propre environnement.