Module Apache mod_ldap

Exemple de configuration

Ce qui suit est un exemple de configuration qui utilise mod_ldap pour améliorer les performances de l'authentification HTTP de base fournie par mod_authnz_ldap.

Conservation des connexions LDAP

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 LDAPReferrals et LDAPReferralHopLimit. Cette fonctionnalité est activée par défaut.

Cache LDAP

Pour améliorer les performances, mod_ldap met en oeuvre une stratégie de mise en cache agressive visant à minimiser le nombre de fois que le serveur LDAP doit être contacté. La mise en cache peut facilement doubler et même tripler le débit d'Apache lorsqu'il sert des pages protégées par mod_authnz_ldap. De plus, le serveur LDAP verra lui-même sa charge sensiblement diminuée.

mod_ldap supporte deux types de mise en cache LDAP : un cache recherche/identification durant la phase de recherche/identification et deux caches d'opérations durant la phase de comparaison. Chaque URL LDAP utilisée par le serveur a son propre jeu d'instances dans ces trois caches.

Le cache recherche/identification

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.

mod_ldap met en cache le nom d'utilisateur, le DN extrait, le mot de passe utilisé pour l'identification, ainsi que l'heure de l'identification. Chaque fois qu'une nouvelle connexion est initialisée avec le même nom d'utilisateur, mod_ldap compare le mot de passe de la nouvelle connexion avec le mot de passe enregistré dans le cache. Si les mots de passe correspondent, et si l'entrée du cache n'est pas trop ancienne, mod_ldap court-circuite la phase de recherche/identification.

Le cache de recherche/identification est contrôlé par les directives LDAPCacheEntries et LDAPCacheTTL.

Les caches d'opérations

Au cours des opérations de comparaison d'attributs et de noms distinctifs (DN), mod_ldap utilise deux caches d'opérations pour mettre en cache les opérations de comparaison. Le premier cache de comparaison sert à mettre en cache les résultats de comparaisons effectuées pour vérifier l'appartenance à un groupe LDAP. Le second cache de comparaison sert à mettre en cache les résultats de comparaisons entre DNs.

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 LDAPOpCacheEntries et LDAPOpCacheTTL.

Superviser le cache

mod_ldap possède un gestionnaire de contenu qui permet aux administrateurs de superviser les performances du cache. Le nom du gestionnaire de contenu est ldap-status, et on peut utiliser les directives suivantes pour accéder aux informations du cache de mod_ldap :

En se connectant à l'URL http://nom-serveur/infos-cache, l'administrateur peut obtenir un rapport sur le statut de chaque cache qu'utilise mod_ldap. Notez que si Apache ne supporte pas la mémoire partagée, chaque instance de httpd possèdera son propre cache, et chaque fois que l'URL sera rechargée, un résultat différent pourra être affiché, en fonction de l'instance de httpd qui traitera la requête.

Utiliser SSL/TLS

La possibilité de créer des connexions SSL et TLS avec un serveur LDAP est définie par les directives LDAPTrustedGlobalCert, LDAPTrustedClientCert et LDAPTrustedMode. Ces directives permettent de spécifier l'autorité de certification (CA), les certificats clients éventuels, ainsi que le type de chiffrement à utiliser pour la connexion (none, SSL ou TLS/STARTTLS).

Certificats SSL/TLS

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.

SDK Netscape/Mozilla/iPlanet

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.

SDK Novell

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.

SDK OpenLDAP

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.

SDK Solaris

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.

SDK Microsoft

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.