Ce module a été conçu dans le but d'améliorer les performances des sites web s'appuyant sur des connexions en arrière-plan vers des serveurs LDAP. Il ajoute aux fonctions fournies par les bibliothèques standards LDAP la conservation des connexions LDAP ainsi qu'un cache LDAP partagé en mémoire.
Pour activer ce module, le support LDAP doit être compilé dans
apr-util. Pour ce faire, on ajoute l'option --with-ldap
au script
Le support SSL/TLS est conditionné par le kit de développement
LDAP qui a été lié à
Ce qui suit est un exemple de configuration qui utilise
Les connexions LDAP sont conservées de requête en requête. Ceci permet de rester connecté et identifié au serveur LDAP, ce dernier étant ainsi prêt pour la prochaine requête, sans avoir à se déconnecter, reconnecter et réidentifier. Le gain en performances est similaire à celui des connexions persistantes (keepalives) HTTP.
Sur un serveur très sollicité, il est possible que de nombreuses requêtes tentent d'accéder simultanément à la même connexion au serveur LDAP. Lorsqu'une connexion LDAP est utilisée, Apache en crée une deuxième en parallèle à la première, ce qui permet d'éviter que le système de conservation des connexions ne devienne un goulot d'étranglement.
Il n'est pas nécessaire d'activer explicitement la conservation des connexions dans la configuration d'Apache. Tout module utilisant le module ldap pour accéder aux services LDAP partagera le jeu de connexions.
Les connexions LDAP peuvent garder la trace des données
d'identification du client ldap utilisées pour l'identification
auprès du serveur LDAP. Ces données peuvent être fournies aux
serveurs LDAP qui ne permettent pas les connexions anonymes au cours
lors des tentatives de sauts vers des serveurs alternatifs. Pour
contrôler cette fonctionnalité, voir les directives
Pour améliorer les performances,
Les processus de recherche et d'identification sont les opérations LDAP les plus consommatrices en temps, en particulier si l'annuaire est de grande taille. Le cache de recherche/identification met en cache toutes les recherches qui ont abouti à une identification positive. Les résultats négatifs (c'est à dire les recherches sans succès, ou les recherches qui n'ont pas abouti à une identification positive) ne sont pas mis en cache. La raison de cette décision réside dans le fait que les connexions avec des données d'identification invalides ne représentent qu'un faible pourcentage du nombre total de connexions, et ainsi, le fait de ne pas mettre en cache les données d'identification invalides réduira d'autant la taille du cache.
Le cache de recherche/identification est contrôlé par les
directives
Au cours des opérations de comparaison d'attributs et de noms
distinctifs (DN),
Notez que, lorsque l'appartenance à un groupe est vérifiée, toute comparaison de sous-groupes est mise en cache afin d'accélérer les comparaisons de sous-groupes ultérieures.
Le comportement de ces deux caches est contrôlé par les
directives
ldap-status, et on peut utiliser les directives
suivantes pour accéder aux informations du cache de
En se connectant à l'URL
http://nom-serveur/infos-cache, l'administrateur peut
obtenir un rapport sur le statut de chaque cache qu'utilise
La possibilité de créer des connexions SSL et TLS avec un serveur
LDAP est définie par les directives
Les différents SDKs LDAP disposent de nombreuses méthodes pour définir et gérer les certificats des clients et des autorités de certification (CA).
Si vous avez l'intention d'utiliser SSL ou TLS, lisez cette section ATTENTIVEMENT de façon à bien comprendre les différences de configurations entre les différents SDKs LDAP supportés.
Les certificat de CA sont enregistrés dans un fichier nommé cert7.db. Le SDK ne dialoguera avec aucun serveur LDAP dont le certificat n'a pas été signé par une CA spécifiée dans ce fichier. Si des certificats clients sont requis, un fichier key3.db ainsi qu'un mot de passe optionnels peuvent être spécifiés. On peut aussi spécifier le fichier secmod si nécessaire. Ces fichiers sont du même format que celui utilisé par les navigateurs web Netscape Communicator ou Mozilla. Le moyen le plus simple pour obtenir ces fichiers consiste à les extraire de l'installation de votre navigateur.
Les certificats clients sont spécifiés pour chaque connexion en utilisant la directive LDAPTrustedClientCert et en se référant au certificat "nickname". On peut éventuellement spécifier un mot de passe pour déverrouiller la clé privée du certificat.
Le SDK supporte seulement SSL. Toute tentative d'utilisation de STARTTLS engendrera une erreur lors des tentatives de contacter le serveur LDAP pendant l'exécution.
Un ou plusieurs certificats de CA doivent être spécifiés pour que le SDK Novell fonctionne correctement. Ces certificats peuvent être spécifiés sous forme de fichiers au format binaire DER ou codés en Base64 (PEM).
Note: Les certificats clients sont spécifiés globalement plutôt qu'à chaque connexion, et doivent être spécifiés à l'aide de la directive LDAPTrustedGlobalCert comme ci-dessous. Définir des certificats clients via la directive LDAPTrustedClientCert engendrera une erreur qui sera journalisée, au moment de la tentative de connexion avec le serveur LDAP.
Le SDK supporte SSL et STARTTLS, le choix étant défini par le paramètre de la directive LDAPTrustedMode. Si une URL de type ldaps:// est spécifiée, le mode SSL est forcé, et l'emporte sur cette directive.
Un ou plusieurs certificats de CA doivent être spécifiés pour que le SDK OpenLDAP fonctionne correctement. Ces certificats peuvent être spécifiés sous forme de fichiers au format binaire DER ou codés en Base64 (PEM).
Les certificats clients sont spécifiés pour chaque connexion à l'aide de la directive LDAPTrustedClientCert.
La documentation du SDK prétend que SSL et STARTTLS sont supportés ; cependant, STARTTLS semble ne pas fonctionner avec toutes les versions du SDK. Le mode SSL/TLS peut être défini en utilisant le paramètre de la directive LDAPTrustedMode. Si une URL de type ldaps:// est spécifiée, le mode SSL est forcé. La documentation OpenLDAP indique que le support SSL (ldaps://) tend à être remplacé par TLS, bien que le mode SSL fonctionne toujours.
SSL/TLS pour les bibliothèques LDAP propres à Solaris n'est pas encore supporté. Si nécessaire, installez et utilisez plutôt les bibliothèques OpenLDAP.
La configuration des certificats SSL/TLS pour les bibliothèques LDAP propres à Microsoft s'effectue à l'intérieur du registre système, et aucune directive de configuration n'est requise.
SSL et TLS sont tous deux supportés en utilisant des URLs de type ldaps://, ou en définissant la directive LDAPTrustedMode à cet effet.
Note: L'état du support des certificats clients n'est pas encore connu pour ce SDK.
Cette directive permet de spécifier le nombre d'octets à allouer pour le cache en mémoire partagée. La valeur par défaut est 500kb. Si elle est définie à 0, le cache en mémoire partagée ne sera pas utilisé et chaque processus HTTPD va créer son propre cache.
Cette directive permet de spécifier le chemin du fichier du cache en mémoire partagée. Si elle n'est pas définie, la mémoire partagée anonyme sera utilisée si la plate-forme la supporte.
Si chemin-fichier n'est pas un chemin absolu, il sera
relatif au répertoire défini via la directive
Cette directive permet de spécifier la taille maximale du cache LDAP primaire. Ce cache contient les résultats de recherche/identification positifs. Définissez-la à 0 pour désactiver la mise en cache des résultats de recherche/identification positifs. La taille par défaut est de 1024 recherches en cache.
Cette directive permet de spécifier la durée (en secondes) pendant laquelle une entrée du cache de recherche/identification reste valide. La valeur par défaut est de 600 secondes (10 minutes).
Cette directive permet de spécifier le nombre d'entrées que
Cette directive permet de spécifier la durée (en secondes) pendant laquelle les entrées du cache d'opérations restent valides. La valeur par défaut est de 600 secondes.
Si elle est activée par la directive
L'ajustement de ce paramètre n'est pas commun à tous les SDKs LDAP.
Certains serveurs LDAP partagent leur annuaire en plusieurs domaines et utilisent le système des redirections (referrals) pour aiguiller un client lorsque les limites d'un domaine doivent être franchies. Ce processus est similaire à une redirection HTTP. Les bibliothèques client LDAP ne respectent pas forcément ces redirections par défaut. Cette directive permet de configurer explicitement les redirections LDAP dans le SDK sous-jacent.
La directive
Avec la valeur "on", la prise en compte des redirections
LDAP par le SDK sous-jacent est activée, la directive
Avec la valeur "off", la prise en compte des redirections LDAP par le SDK sous-jacent est complètement désactivée.
Avec la valeur "default", la prise en compte des redirections
LDAP par le SDK sous-jacent n'est pas modifiée, la directive
La directive
Si la directive
Il est possible d'effectuer une autre tentative de connexion en cas d'erreurs LDAP du type délai dépassé ou connexion refusée.
Suite à des échecs de connexion au serveur LDAP, le serveur
tentera de se connecter autant de fois qu'indiqué par la directive
Il est possible d'effectuer une autre tentative de connexion en cas d'erreurs LDAP du type délai dépassé ou connexion refusée.
Cette directive permet de spécifier le chemin et le nom du
fichier contenant les certificats des CA de confiance et/ou les
certificats clients du système global que
Cette directive permet de spécifier le chemin et le nom de fichier ou l'alias d'un certificat client par connexion utilisé lors de l'établissement d'une connexion SSL ou TLS avec un serveur LDAP. Les sections directory ou location peuvent posséder leurs propres configurations de certificats clients. Certains SDK LDAP (en particulier Novell) ne supportent pas les certificats clients par connexion, et renvoient une erreur lors de la connexion au serveur LDAP si vous tenter d'utiliser cette directive (Utilisez à la place la directive LDAPTrustedGlobalCert pour les certificats clients sous Novell - Voir plus haut le guide des certificats SSL/TLS pour plus de détails). Le paramètre type spécifie le type du certificat en cours de définition, en fonction du SDK LDAP utilisé. Les types supportés sont :
Les modes suivants sont supportés :
Les modes ci-dessus ne sont pas supportés par tous les SDK LDAP. Un message d'erreur sera généré à l'exécution si un mode n'est pas supporté, et la connexion au serveur LDAP échouera.
Si une URL de type ldaps:// est spécifiée, le mode est forcé à SSL et la définition de LDAPTrustedMode est ignorée.
Cette directive configure l'option LDAP_OPT_NETWORK_TIMEOUT (ou LDAP_OPT_CONNECT_TIMEOUT) dans la bibliothèque client LDAP sous-jacente, si elle est disponible. Cette valeur représente la durée pendant laquelle la bibliothèque client LDAP va attendre que le processus de connexion TCP au serveur LDAP soit achevé.
Si la connexion n'a pas réussi avant ce délai, une erreur sera
renvoyée, ou la bibliothèque client LDAP tentera de se connecter à
un second serveur LDAP, s'il en a été défini un (via une liste de
noms d'hôtes séparés par des espaces dans la directive
La valeur par défaut est 10 secondes, si la bibliothèque client LDAP liée avec le serveur supporte l'option LDAP_OPT_NETWORK_TIMEOUT.
Cette directive permet de spécifier le délai d'attente pour les opérations de recherche et d'identification, ainsi que l'option LDAP_OPT_TIMEOUT dans la bibliothèque LDAP client sous-jacente, lorsqu'elle est disponible.
Lorsque le délai est atteint, httpd va refaire un essai dans le cas où une connexion existante a été silencieusement fermée par un pare-feu. Les performances seront cependant bien meilleures si le pare-feu est configuré pour envoyer des paquets TCP RST au lieu de rejeter silencieusement les paquets.
Les délais pour les opérations de comparaison LDAP nécessitent un SDK avec LDAP_OPT_TIMEOUT, comme OpenLDAP >= 2.4.4.
Cette directive permet de spécifier s'il faut forcer la vérification d'un certificat de serveur lors de l'établissement d'une connexion SSL avec un serveur LDAP.
Cette directive permet de spécifier la durée maximale, en secondes, pendant laquelle une connexion LDAP du jeu de connexions peut demeurer inactive, mais rester quand-même disponible pour une utilisation éventuelle. Le jeu de connexions est nettoyé au fur et à mesure des besoins, de manière non asynchrone.
Si cette directive est définie à 0, les connexions ne sont jamais sauvegardées dans le jeu de connexions d'arrière-plan. Avec la valeur par défaut -1, ou toute autre valeur négative, les connexions peuvent être réutilisées sans limite de durée.
Dans le but d'améliorer les performances, le temps de référence qu'utilise cette directive correspond au moment où la connexion LDAP est enregistrée ou remise dans le jeu de connexions, et non au moment du dernier échange réussi avec le serveur LDAP.
La version 2.4.10 a introduit de nouvelles mesures permettant d'éviter une augmentation excessive du temps de référence due à des correspondances positives dans le cache ou des requêtes lentes. A cet effet, le temps de référence n'est pas réactualisé si aucune connexion LDAP d'arrière-plan n'est requise ; d'autre part, le temps de référence se base sur le moment où la requête HTTP est reçue, et non sur le moment où la requête a été traitée.
Cette durée de vie s'exprime par défaut en secondes, mais il est possible d'utiliser d'autres unités en ajoutant un suffixe : millisecondes (ms), minutes (min), ou heures (h).
Active les options de débogage LDAP spécifiques au SDK, qui entraînent en général une journalisation d'informations verbeuses du SDK LDAP dans le journal principal des erreurs d'Apache. Les messages de traces en provenance du SDK LDAP fournissent des informations très détaillées qui peuvent s'avérer utiles lors du débogage des problèmes de connexion avec des serveurs LDAP d'arrière-plan.
Cette option n'est configurable que lorsque le serveur HTTP
Apache est lié avec un SDK LDAP qui implémente
LDAP_OPT_DEBUG ou LDAP_OPT_DEBUG_LEVEL,
comme OpenLDAP (une valeur de 7 est verbeuse) ou Tivoli Directory
Server (une valeur de 65535 est verbeuse).
Les informations journalisées peuvent contenir des données d'authentification en clair utilisées ou validées lors de l'authentification LDAP ; vous devez donc prendre soin de protéger et de purger le journal des erreurs lorsque cette directive est utilisée.