Ese error de contraseña LDAP puede que no sea la contraseña del usuario

Restablecer la contraseña de un usuario es el primer movimiento equivocado cuando el registro solo dice que se rechazó un bind. Con un complemento de directorio hay más de un bind en un solo inicio de sesión, y el rechazo puede pertenecer a la cuenta de servicio que realiza la búsqueda. Restablecer las credenciales del usuario en ese caso no cambia nada. También deja fuera a alguien que nunca fue el problema.

Un inicio de sesión, varios bind

Una configuración con una cuenta de directorio dedicada suele realizar cuatro pasos en orden, y cualquiera de ellos puede terminar el inicio de sesión.

connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groups

El complemento crea su conexión de autenticación de usuario mediante el mismo auxiliar que gestiona la primera conexión, por lo que ese auxiliar puede fallar al conectar, al negociar TLS o al hacer bind como la cuenta de servicio. El mensaje de alto nivel sobre una contraseña se genera después y no indica qué identidad estaba implicada. Por eso el texto del error por sí solo no puede decirle si se rechazó al usuario o a la cuenta de servicio.

Lea las líneas anteriores al mensaje y anote el momento en que se produjo el fallo. Un rechazo al arrancar, antes de que llegue ningún usuario, apunta a la cuenta configurada o al punto de conexión. Un rechazo que aparece solo para una persona, tras una búsqueda correcta, apunta a la entrada o al estado de cuenta de esa persona.

Empareje el error con una identidad

La regla práctica es registrar tres cosas juntas: cuándo falló, qué operación se estaba ejecutando y qué identidad se presentó. Sin ese triple, dos fallos muy distintos parecen idénticos en un registro que solo conserva la frase final.

Si falla la cuenta configurada, inspeccione esa cuenta y la conexión antes de tocar cualquier registro de usuario. Si falla el bind del usuario tras una búsqueda correcta, examine la entrada que devolvió la búsqueda en lugar de la que supuso que devolvería. Los dos caminos comparten un mensaje y nada más. Anote cuál descartó, porque la siguiente persona preguntará exactamente eso.

El nombre distinguido es un dato, no una suposición

Cambiar un componente del nombre porque parece poco familiar es una forma habitual de romper una configuración que funciona. La ubicación predeterminada de los objetos de usuario en Active Directory es un contenedor llamado Users, y un contenedor no es el mismo tipo de objeto que una unidad organizativa con un nombre similar.

Pida al administrador del directorio el nombre distinguido real de la cuenta, o léalo del propio objeto. Ambos de los siguientes pueden ser correctos en su propio directorio, por lo que ninguno debería escribirse de memoria.

CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example

Un movimiento o un cambio de nombre modifica ese valor mientras la cuenta y la contraseña siguen siendo válidas, así que una configuración que funcionaba el trimestre pasado puede fallar este sin que nadie toque una credencial. Compare la cadena configurada con el atributo actual del directorio después de cualquier reorganización. Hágalo también tras una migración silenciosa, no solo después de una caída reportada.

Una base de búsqueda no es una cuenta de servicio

La identidad de bind y la base de búsqueda responden a preguntas distintas: como quién se autentica el complemento y dónde busca personas. Un bind correcto seguido de ningún usuario coincidente es un problema de ámbito, filtro o permiso de lectura, y sustituir el nombre distinguido de la cuenta por la base de los usuarios no cambia nada en eso.

Confirme que el servicio cargó la configuración que editó y que su punto de conexión, confianza TLS y modo de autenticación coinciden con una prueba administrativa que funcione. Una consulta manual con otra cuenta, o contra otro controlador de dominio, no es un experimento equivalente.

Compruebe el secreto almacenado y compruebe si la cuenta está habilitada, caducada o bloqueada, sin imprimir la contraseña en ningún sitio. La caducidad es fácil de pasar por alto porque la cuenta sigue funcionando hasta el día en que deja de hacerlo. Un bloqueo heredado de un servicio no relacionado es igual de silencioso. Ninguna de las dos condiciones produce un mensaje que nombre la cuenta de servicio.

Las reglas de grupo van al final

La autorización se ejecuta después de que los bind tengan éxito, así que una comprobación de grupo no puede ser la causa de un fallo de bind, y eliminar el requisito de grupo no puede repararlo. Si el inicio de sesión llega ahora a la etapa de grupo, el problema restante es la pertenencia, no las credenciales.

Conceder a la cuenta de servicio amplios derechos de directorio para hacer desaparecer el error cambia la política de acceso de todo el despliegue. Trátelo como una decisión de seguridad con su propia revisión, no como una solución para un mensaje que aún no ha atribuido a una identidad.