La présente section décrit comment configurer LDAP pour protéger les fichiers sur IBM® HTTP
Server.
Avant de commencer
Fonction obsolète : Le module mod_ibm_ldap
est fourni avec cette édition d'IBM HTTP Server à des fins de compatibilité avec les précédentes éditions. Si vous utilisez le module
mod_ibm_ldap pour votre configuration LDAP, vous devez migrer les
configurations existantes pour utiliser les modules mod_authnz_ldap et mod_ldap pour vous assurer une prise en charge ultérieure
pour votre configuration LDAP. Voir la rubrique
Authentification avec
LDAP sur IBM HTTP Server en utilisant mod_ldap pour obtenir une description
de l'utilisation du module mod_ldap.
depfeat
Le module LDAP n'est pas chargé dans IBM HTTP Server par défaut. Sans la directive LoadModule, les fonctions LDAP ne sont pas disponibles. Pour activer la fonction LDAP, ajoutez une directive LoadModule dans le fichier httpd.conf d'IBM HTTP Server :
Si le client LDAP est installé sur votre ordinateur, vous pouvez utiliser ldapsearch en tant qu'outil pour tester les valeurs que vous envisagez d'utiliser pour les différents paramètres.
Pourquoi et quand exécuter cette tâche
Voir Directives LDAP pour obtenir des
descriptions détaillées des directives LDAP (mod_ibm_ldap).
Procédure
- Modifiez le fichier de configuration httpd.conf IBM HTTP Server.
- Déterminez la ressource dont vous souhaitez limiter l'accès. Par exemple : <Répertoire "/secure_info">.
- Ajoutez des directives dans httpd.conf à l'emplacement du répertoire (conteneur) pour qu'il soit protégé avec des valeurs spécifiques à votre environnement. Par exemple :
- LdapConfigFile chemin_d'accès_à_ldap.prop
- AuthType Basic
- AuthName "Nom de votre domaine sécurisé"
- Require valid-user
- Trois options vous sont proposées pour l'utilisation d'IBM HTTP Server pour vous authentifier avec votre installation LDAP existante.
- Autorisation reposant sur l'appartenance à un groupe LDAP.
Utilisez LDAP pour contrôler les mots de passe utilisateur et vérifier que l'utilisateur existe dans un groupe défini au sein de LDAP.
Remarque : L'appartenance indiquant que l'utilisateur est en droit d'accéder à la ressource dépend du groupe, pas de l'entrée LDAP de l'utilisateur même.
Par exemple, pour limiter l'accès à un groupe, ajoutez la directive suivante :
LDAPRequire group grp1
Pour cette forme de LDAPRequire, vous devez avoir des groupes configurés dans votre référentiel LDAP qui soient conformes aux règles suivantes (avec le nom du groupe exemple grp1):
- Il existe dans votre référentiel LDAP une entrée correspondant au filtre de recherche suivant, dans lequel les valeurs groupedenoms et groupedenomsuniques sont des exemples de valeur spécifiées dans ldap.group.dnattributes.
Remarque : La valeur propre de ldap.group.dnattributes est une liste des attributs objectclass indiquant l'appartenance à un groupe de votre schéma LDAP.
ldapsearch ... "(&(cn=grp1)(|(objectclass=groupofnames)
(objectclass=groupofuniquenames)))"
- Au sein de l'entrée LDAP de "grp1," il existe une série d'attributs correspondant aux éléments suivants, où les valeurs member et uniquemember sont des exemples de valeurs de ldap.group.memberAttributes.
Remarque : La valeur propre de ldap.group.memberAttributes est une liste des attributs objectclass indiquant l'appartenance à un groupe. Les valeurs de ces entrées correspondent aux Noms distinctifs (DN) de vos utilisateurs.
ldapsearch ... "(&(cn=grp1)(|(objectclass=groupofnames)
(objectclass=groupofuniquenames)))" member uniquemember
Exemple
:
ldapsearch -x -h myldapserver -D cn=root -w rootpw
"(&(cn=grp1)(|(objectclass=groupofnames)(objectclass=groupofuniquenames)))"
member uniquemember
dn: cn=group1,ou=myunit,o=myorg,c=US
member: cn=user1, ou=otherunit, o=myorg, c=US
member: cn=user12, ou=otherunit, o=myorg, c=US
Si un objet du type répertorié dans ldap.group.dnattributes est un membre du groupe faisant l'objet de la recherche, il sera recherché de la même façon, en mode récursif, jusqu'au niveau de ldap.group.search.depth.
- IBM HTTP
Server utilise d'abord ldap.group.name.filter et ldap.user.cert.filter
pour convertir en nom distinctif le nom usuel fourni pour l'utilisateur et le groupe. Ensuite, IBM HTTP
Server recherche, sur la base du nom distinctif de groupe, les entrées dont la valeur correspond au nom distinctif de l'utilisateur.
Exemple
:
ldapsearch ... -b "cn=grp1,ou=myunit,o=myorg,c=US"
"|((member=cn=user1,ou=otherunit,o=myorg,c=US)
(uniquemember=cn=user1,ou=otherunit,o=myorg,c=US))"
- Autorisation reposant sur les attributs LDAP de l'utilisateur. Utilisez LDAP pour contrôler les mots de passe utilisateur et vérifier que l'utilisateur correspond à un ensemble d'attributs (l'attribut indiquant que l'utilisateur est en droit d'accéder à la ressource fait partie de l'entrée LDAP propre aux utilisateurs).
Exemple
:
LDAPRequire filter "(&(jobtitle=accountant)(location=newyork))"
Pour utiliser cette forme de LDAPRequire, IBM HTTP Server doit utiliser ldap.user.cert.filter
pour convertir le nom usuel fourni par l'utilisateur en nom distinctif. IBM HTTP Server doit également effectuer la recherche en se basant sur le nom distinctif de l'utilisateur et utiliser le filtre de recherche fourni dans la directive LDAPRequire. Si des résultats sont renvoyés, l'autorisation a réussi.
Exemple :
ldapsearch ... -b "cn=user1,ou=otherunit,o=myorg,c=US" "(&(jobtitle=accountant)
(location=newyork))"
Certains attributs (parfois appelés rôles dynamiques) dans LDAP sont calculés de manière dynamique par le serveur LDAP. Il se peut que leur sémantique soit différente et par conséquent non valide dans un filtre de recherche. De telles valeurs provoquent des échecs si elles sont utilisées dans l'exemple précédent et ne peuvent pas être utilisées pour accorder une autorisation sur IBM HTTP
Server.
- Authentification uniquement : utilisez LDAP uniquement pour contrôler les mots de passe utilisateur.
Vous pouvez utiliser la directive Require pour limiter l'accès à des utilisateurs spécifiques ou pour gérer un fichier de groupe plat à l'aide d'AuthGroupFile.
- Editer le fichier de configuration ldap.prop. Si vous n'avez pas de fichier de configuration, vous pouvez utiliser le fichier ldap.prop.sample, fourni avec IBM HTTP
Server. Si vous avez des questions sur les valeurs correctes, consultez votre administrateur de serveur LDAP. Mettez à jour les directives suivantes à l'aide des valeurs appropriées à votre environnement :
- Entrez les informations de connexion relatives au serveur Web.
- Lorsque vous utilisez SSL, LDAPS ou LDAP sur SSL :
Résultats
Les recherches utilisant les directives mod_ibm_ldap gèrent un ensemble de connexions serveur authentifiées en tant qu'utilisateur ldap.application.dn. La première connexion est créée lors de la réception de la demande protégée par LDAP. Les connexions sont maintenues ouvertes pendant une nombre de secondes spécifié (ldap.idleConnection.timeout)
pour les recherches suivantes effectuées sur cette ou ces connexions dans le cadre d'autres demandes.
Si vous lisez des journaux ou consultez une trace IP, la séquence d'événements suivante doit se produire :
- IBM HTTP
Server démarre.
- Si LDAP_TRACE_FILE est défini, il comportera quelques entrées pour LDAP_obtain_config
- La première demande de ressource protégée par LDAP est reçue.
- IBM HTTP
Server se connecte à LDAP à l'aide du nom et du mot de passe d'utilisateur ldap.application.dn dissimulés dans ldap.application.password.stashFile (Connexion d'application)
- IBM HTTP
Server effectue une recherche sur cette connexion pour convertir le nom d'utilisateur entré par l'utilisateur ou le contenu de son certificat client en nom distinctif à l'aide des paramètres user.*.filter.
- IBM HTTP
Server se connecte au serveur LDAP avec le nom d'utilisateur et le mot de passe fourni par le client pour vérifier l'authentification ("connexion d'utilisateur" au serveur LDAP)
- Si des directives LDAPRequire sont applicables pour cette demande, IBM HTTP Server
les traite de la façon décrite dans la procédure précédente.
- IBM HTTP
Server interrompt la connexion utilisateur
- La connexion d'application est maintenue pour la demande suivante