no puedo entender por qué falla la autenticación LDAP de apache

De repente, ayer, uno de mis servidores apache no pudo conectarse a mi servidor LDAP (AD). Tengo dos sitios que se ejecutan en ese servidor, los cuales usan LDAP para autenticarse en mi servidor AD cuando un usuario inicia sesión en cualquiera de los sitios. Había estado funcionando bien hace dos días. Por razones desconocidas, hasta ayer, dejó de funcionar. El registro de errores solo dice esto:

auth_ldap authenticate: user foo authentication failed; URI /FrontPage [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server], referer: http://mysite.com/

Pensé que tal vez mi certificado SSL autofirmado había expirado, así que creé uno nuevo para mysite.com, pero no para el nombre de host del servidor en sí, y el problema persistió. Habilité el registro de nivel de depuración. Muestra la transacción SSL completa con el servidor LDAP, y parece completarse sin errores hasta el final cuando recibo el mensaje "No se puede contactar con el servidor LDAP". Puedo ejecutar ldapsearch desde la línea de comandos en este servidor, y puedo iniciar sesión en él, que también usa LDAP, por lo que sé que el servidor puede conectarse y consultar el servidor LDAP / AD. Es solo apache que no puede conectarse.

Buscar una respuesta en Google no ha resultado nada, así que pregunto aquí. ¿Alguien puede dar una idea de este problema?

Aquí está la sección LDAP de la configuración de apache:

<Directory "/web/wiki/">
    Order allow,deny
    Allow from all
    AuthType Basic
    AuthName "Login"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    #AuthBasicAuthoritative off
    AuthLDAPUrl ldaps://domain.server.ip/dc=full,dc=context,dc=server,dc=name?sAMAccountName?sub
    AuthLDAPBindDN cn=ldapbinduser,cn=Users,dc=full,dc=context,dc=server,dc=name
    AuthLDAPBindPassword password
    require valid-user
</Directory>

Un rastreo de paquetes desde el servidor httpd / cliente LDAP reveló un mensaje sobre la CA desconocida.

Alerta TLSv1 (Nivel: Fatal, Descripción: CA desconocido)

Encontré y agregué la siguiente opción a mi httpd.conf:

  LDAPVerifyServerCert          off

Eso solucionó mi problema con CentOS 6. Los servidores httpd de CentOS 5 no requerían ninguna modificación y habían funcionado todo el tiempo sin la opción.

He tenido un problema similar a este antes con AD en Windows 2003: la solución que encontré fue no enlazar usando el DN completo sino usar la sintaxis de usuario @ dominio:

AuthLDAPBindDN [email protected]

¿Tiene acceso a los registros desde su servidor LDAP? Pueden ser útiles para solucionar este problema.

He visto esto cuando una actualización del paquete provoca cambios en el cliente ldap.conf (generalmente /etc/ldap.conf o /etc/openldap/ldap.conf) y restablece la opción TLS_REQCERT a una configuración más estricta. Puede negociar el SSL correctamente, pero seguirá fallando al final ya que no puede validar la cadena de certificados desde una raíz confiable.

Es posible que desee consultar el reloj de los servidores. Si la diferencia horaria es más de un par de minutos, el ticket de autenticación no será válido.

Aunque este no es exactamente el mensaje de error, la parte "el otro servidor de repente tiene el mismo problema" podría indicar tal problema.

Necesita imponer el certificado de CA LDAP para trabajar con LDAPS

Tengo un problema similar, que he identificado ejecutando este comando:

openssl s_client -connect $ldap_host:636 -state -nbio 2>&1. Creo que mod_ldap usa openssl debajo, por lo que esto debería ser bastante consistente para la depuración.

Lo comparé con otro servidor cifrado SSL que sabía que funcionaba. Una conexión SSL debidamente verificada mostrará una cadena que va a una CA raíz y devuelve 0. Una falla en la verificación SSL dará un número y una razón. Puede usar la salida para determinar qué está yendo mal.

En mi caso, los certificados del servidor LDAP están firmados por Verisign, que utiliza certificados CA intermedios . OpenSSL no puede verificar el certificado y se rechaza la conexión ("la conexión rechazada por el servidor" no es útil).

Tuve un problema similar. Podría obtener el certificado con openssl, podría consultar Active Directory sobre SSL con ldapsearch en los mismos puertos. Finalmente cambié a los puertos 3268 o 3269 del Catálogo global de Microsoft y ambos funcionaron. Los servidores de Microsoft Windows 2003 habían sido parcheados, pero eso sucedió días antes de que los problemas comenzaran a ocurrir.

Estaba implementando LDAPS en todos nuestros servidores y también me encontré con este problema. Desaparece si vuelve a LDAP de texto sin formato (no es ideal, pero es útil para conocer el origen del problema). Si es así, todavía tengo que encontrar una solución, pero quizás juntos podamos aislar un error en authnz_ldap.

Supongo que sus experimentos de línea de comandos estaban usando el mismo "usuario de enlace" que en sus configuraciones de apache. De lo contrario, debe verificar que tiene la contraseña actual correcta.

En el pasado, una vez tuve que usar el puerto del catálogo global en lugar del puerto LDAP estándar para el dominio AD. No puedo recordar el motivo. Para ldaps como en su url anterior, este sería el puerto 3269.

La forma en que esto funciona es que su sitio web necesita conectarse a AD utilizando primero las credenciales de su usuario de enlace , y luego, una vez que se realiza esta conexión, utiliza este acceso para validar las credenciales del usuario que intenta acceder a su sitio web.

Según su mensaje de error, parece que el proceso no puede conectarse a AD como su usuario de enlace (AuthLDAPBindDN).

Asegúrese de que la cuenta de usuario de enlace no esté deshabilitada en Active Directory y que la contraseña que ha especificado como (AuthLDAPBindPassword) sea correcta . Además, asegúrese de que su usuario de enlace tenga los permisos necesarios para buscar otros usuarios (en nuestro caso, debe ser miembro de Usuarios de dominio)

Acabo de tener este problema ("no puedo contactar con el servidor ldap") en RHEL6, y fue el resultado de cambios en openldap. yum había actualizado el archivo de configuración /etc/openldap/ldap.conf pero en lugar de sobrescribirlo (en caso de que estuviera personalizado; en mi caso no lo estaba) creó un archivo ldap.conf.rpmnew.

Copiar la versión .rpmnew sobre ldap.conf solucionó el problema.

(No puedo aceptar que desactivar la verificación del certificado sea una respuesta a esto. Evita el problema de una manera potencialmente peligrosa).

Logré solucionar este problema instalando los paquetes berkelydby openldapque se encuentran aquí .

La diferencia es que RedHat ha comenzado a vincular cosas en nsslugar de opensslsoporte SSL. En este caso, eso rompe todas las cosas. La instalación de estos paquetes (que están vinculados con openssl) soluciona el problema. Solo obtén los paquetes y ejecuta:

yum install berkeleydb-ltb* openldap-ltb*

Luego reinicie apache, y debería estar en el negocio.

Tuve un problema idéntico después de actualizar de rhel6.6 a rhel7.5. Cuando me quedé sin ideas, concluí que mod_ssl en apache 2.2.32 puede no ser 100% compatible en rhel7.4. Actualicé de Apache 2.2.32 a Apache2.4, habilité SSL y sldap funcionó.