[AIX Solaris HP-UX Linux Windows]

Autenticación con LDAP en IBM HTTP Server utilizando mod_ibm_ldap (sistemas distribuidos)

En este apartado se describe cómo configurar LDAP para proteger los archivos de IBM® HTTP Server.

Antes de empezar

Característica en desuso 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

  1. Edite el archivo de configuración httpd.conf de IBM HTTP Server.
  2. Determine el recurso al que desea limitar el acceso. Por ejemplo: <Directory "/secure_info">.
  3. 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
  4. 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.

  5. 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.
    1. Entre la información de conexión del servidor web.
    2. Cuando utilice SSL, LDAPS, o LDAP a través de SSL:
      • Cambie ldap.transport a un valor SSL
      • Cambie ldap.URL para incluir el protocolo LDAPS y el valor de puerto correcto, por ejemplo, 636.
      • Configure la base de datos de claves SSL que se va a utilizar, por ejemplo:
        ldap.key.fileName=/vía_acceso_a/key.kdb
        ldap.key.file.password.stashFile=/vía_acceso_a/stashfile
        Donde archivostash se crea mediante el mandato bin/ldapstash.
        ldap.key.label=etiqueta
        Donde etiqueta es el valor que aparece en IKEYMAN para el key.kdb referenciado.

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:

Tema de tarea    

Términos y condiciones para centros de información | Comentarios

Última actualización: October 10, 2014 03:11 AM EDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=ihs-dist&topic=tihs_ldapconfig
Nombre de archivo: tihs_ldapconfig.html