En este apartado se describe cómo configurar LDAP para proteger
los archivos de IBM® HTTP Server.
Antes de empezar
Característica en desuso: El módulo mod_ibm_ldap se proporciona con este release de
IBM HTTP Server para la
compatibilidad con releases anteriores. Si utiliza el módulo mod_ibm_ldap para la configuración de LDAP, debe
migrar las configuraciones existentes para utilizar los módulos mod_authnz_ldap y mod_ldap para asegurar el
soporte futuro de la configuración de LDAP. Consulte el tema
Autenticación con LDAP en
IBM HTTP Server utilizando
mod_ldap para obtener una descripción de cómo utilizar el módulo mod_ldap.
depfeat
El módulo LDAP no se
carga en IBM HTTP Server de forma predeterminada. Sin la directiva LoadModule, las funciones de LDAP no están disponibles para utilizarlas.
Para habilitar la función LDAP, añada una directiva LoadModule al archivo de
IBM
HTTP Server httpd.conf de la manera siguiente:
Si tiene el
cliente de LDAP instalado en la máquina, puede utilizar ldapsearch como herramienta para
probar los valores que pretenda utilizar para los distintos valores.
Acerca de esta tarea
Consulte Directivas LDAP
para obtener descripciones detalladas de las directivas LDAP
(mod_ibm_ldap).
Procedimiento
- Edite el archivo de configuración
httpd.conf de
IBM
HTTP Server.
- Determine el recurso al que desea limitar el acceso. Por ejemplo: <Directory "/secure_info">.
- Añada directivas en httpd.conf a la ubicación de directorio
(contenedor) para que se proteja con valores específicos con el entorno. Por ejemplo:
- LdapConfigFile vía_a_ldap.prop
- AuthType Basic
- AuthName"Título del reino protegido"
- Require valid-user
- Hay tres opciones sobre maneras de utilizar IBM HTTP Server
para autenticarse con la instalación de LDAP existente.
- Autorización basada en la pertenencia a grupos LDAP.
Utilice LDAP para
comprobar las contraseñas de usuario y verificar que cada usuario existe en un grupo
definido en LDAP.
Nota: La pertenencia que identifica el usuario como capacitado para
acceder al recurso es una parte del grupo, no es parte de la propia entrada LDAP del
usuario.
Por ejemplo, para restringir el acceso a un grupo, añada la directiva
siguiente:
LDAPRequire group grp1
Para esta forma
de LDAPRequire, debe tener grupos configurados en el repositorio LDAP que cumplan las reglas
siguientes (utilizando el nombre de grupo de ejemplo grp1):
- Existe una entrada en el repositorio LDAP que coincide con el siguiente filtro de
búsqueda, donde los valores groupofnames y
groupofuniquenames son valores de ejemplo especificados en
ldap.group.dnattributes.
Nota: El valor adecuado de
ldap.group.dnattributes es una lista de lo que objectclasses significa como grupo en el
esquema LDAP.
ldapsearch ... "(&(cn=grp1)(|(objectclass=groupofnames)
(objectclass=groupofuniquenames)))"
- Como parte de la entrada LDAP para "grp1", hay una serie de atributos que
coinciden con lo siguiente, donde los valores member y uniquemember son
valores de ejemplo de ldap.group.memberAttributes.
Nota: El valor adecuado de
ldap.group.memberAttributes es una lista de lo que significa objectclasses como
pertenencia a un grupo. Los valores de estas entradas son los Nombres distinguidos (DN) de los usuarios.
ldapsearch ... "(&(cn=grp1)(|(objectclass=groupofnames)
(objectclass=groupofuniquenames)))" member uniquemember
Ejemplo:
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 objeto del tipo
listado en ldap.group.dnattributes es miembro del grupo en el que se busca, se buscará
de forma repetida de la misma maenra, hasta una profundidad igual a ldap.group.search.depth
- En primer lugar, IBM HTTP Server utiliza ldap.group.name.filter y
ldap.user.cert.filter para convertir el CN proporcionado para el usuario y
el grupo en nombres distinguidos (DN). A continuación, IBM HTTP Server
busca utilizando el DN de grupo como base para las entradas cuyo valor es
el DN de usuario.
Ejemplo:
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))"
- Autorización basada en atributos LDAP de usuario. Utilice LDAP para
comprobar las contraseñas de usuario y verifique que el usuario coincide con un conjunto
de atributos (el atributo que identifica el usuario como capacitado para acceder al
recurso forma parte de la propia entrada LDAP de los usuarios).
Ejemplo:
LDAPRequire filter "(&(jobtitle=accountant)(location=newyork))"
Para utilizar esta forma de LDAPRequire, IBM HTTP Server debe utilizar
ldap.user.cert.filter para convertir el CN proporcionado para el usuario
en un DN. IBM HTTP Server también debe buscar utilizando el DN de usuario
como base y utilizar el filtro de búsqueda proporcionado en la directiva
LDAPRequire. Si se devuelven resultados, se habrá
conseguido la autorización.
Ejemplo:
ldapsearch ... -b "cn=user1,ou=otherunit,o=myorg,c=US" "(&(jobtitle=accountant)
(location=newyork))"
Algunos atributos (a veces denominados Roles
dinámicos) de LDAP se calculan de forma dinámica por el servidor LDAP y pueden tener
semánticas distintas que no sean válidas en un filtro de búsqueda. Tales
valores fallarán si se utilizan en el ejemplo previo y no pueden
utilizarse para la autorización en IBM HTTP Server.
- Sólo autenticación: utilice LDAP sólo para comprobar contraseñas de usuario.
Puede
utilizar la directiva Require para limitarla a usuarios específicos o mantener un archivo
de grupo sin formato mediante AuthGroupFile.
- Edite el archivo de configuración ldap.prop. Si aún no
tiene ninguno, puede utilizar el archivo ldap.prop.sample que se
entrega con IBM HTTP Server. Si tiene dudas sobre los valores correctos, consúltelo con el administrador del
servidor de LDAP. Actualice las directivas siguientes con los valores que sean correctos para el entorno.
- Entre la información de conexión del servidor web.
- Cuando utilice SSL, LDAPS, o LDAP a través de SSL:
Resultados
Las búsquedas que utilizan las directivas mod_ibm_ldap mantienen una
agrupación de conexiones de servidor que se autentican como el usuario
ldap.application.dn. La primera conexión se crea cuando se recibe la primera petición
protegida por LDAP. Las conexiones se mantendrán abiertas durante un número
específico de segundos (ldap.idleConnection.timeout)
para realizar búsquedas posteriores en esa conexión o conexiones para otras peticiones.
Si
está leyendo registros cronológicos o examina un rastreo IP, debería producirse la
siguiente secuencia de sucesos:
- Se inicia IBM HTTP Server.
- Si LDAP_TRACE_FILE se ha establecido, tendrá algunas entradas para
LDAP_obtain_config
- Se recibe la primera petición para el recurso protegido por LDAP.
- IBM HTTP Server se enlaza con LDAP mediante el nombre de usuario
ldap.application.dn y la contraseña almacenada en
ldap.application.password.stashFile (Conexión de aplicaciones)
- IBM HTTP Server realiza una búsqueda a través de esta conexión para
convertir el nombre de usuario escrito por el usuario, o el contenido de
su certificado de cliente, en un Nombre distinguido (DN) mediante los
valores de user.*.filter.
- IBM HTTP Server se enlaza al servidor LDAP como nombre de
usuario/contraseña proporcionado por el cliente para comprobar la
autenticación (es una "conexión de usuario" al servidor LDAP)
- Si hay directivas LDAPRequire en vigor para esta petición, IBM HTTP
Server las procesa de la manera descrita en el procedimiento anterior.
- IBM HTTP Server desenlaza la conexión de usuario
- La conexión de aplicación se mantiene para la petición siguiente