LDAP - ¿Cómo verificar una combinación de nombre de usuario/contraseña?

El uso de LDAP es comprobar un nombre de usuario/contraseña tan simple como intentar enlazar como ese usuario y anotar los resultados, o ¿hay una función especial de "verificación de contraseña" de LDAP?LDAP - ¿Cómo verificar una combinación de nombre de usuario/contraseña?

Estoy tratando de entender un poco más "entre bastidores" mientras trabajo en un problema de configuración de depósito LDAP desordenado.

(Nota: Esto es para situaciones en las que la contraseña no se almacena como un hash en una propiedad personalizada; situación que es fácil de manejar)

Fuente

2010-11-01 DrStalker

LDAP admite una comparación de userPassword. Usted envía la contraseña, el servidor hace la comparación y devuelve verdadero o falso. Esta es la forma en que no se requiere iniciar sesión para autenticar usuarios.

Fuente

2010-11-02 10:21:55 geoffc

¿Cómo se "compararía" si la contraseña en el servidor LDAP está encriptada? –

@Ashwinkumar Hay una función específica para comparar las contraseñas. Proporciona la contraseña para probar, está encriptada de manera similar, luego puede comparar los dos valores. La distinción es entre intentar vincularse con estos creds o llamar explícitamente a la función ldapCompare. – geoffc

hmm .. En una pregunta reciente, publiqué http://stackoverflow.com/questions/16168293/how-to-do-password-authentication-for-a-user-using-ldap, me sugirieron utilizar bind para el resultado de búsqueda con la contraseña. Encuadernación con las últimas 'dn' obras. Sin embargo, el enlace es esencialmente un 'inicio de sesión'. haciendo un LDAP 'ldap_compare_s' falló. ¿Hay alguna manera de obtener una contraseña en comparación con la contraseña del usuario de LDAP? –

vinculante como ese usuario es suficiente. La contraseña se marca en el proceso de enlace.

Fuente

2010-11-01 11:29:02 EJP

Esto es realmente un comentario, no una respuesta a la pregunta. Utilice "agregar comentario" para dejar comentarios al autor. – Conner

@Conner Estás equivocado.En realidad, esta es realmente una respuesta directa a la pregunta "es comprobar un nombre de usuario/contraseña tan simple como intentar enlazar como ese usuario". – EJP

Espero que mi comentario no te haya ofendido. Este comentario enlatado fue generado por el sistema de revisión beta. Personalmente, creo que las respuestas "sí/no" o menores a preguntas específicas son más adecuadas como comentarios. No me refiero a nada en contra suya personalmente por esa opinión. Saludos. – Conner

Tenga cuidado al usar bind para verificar el nombre de usuario/contraseña, en algunos sistemas contará como un inicio de sesión y con restricciones de inicio de sesión podría fallar.

Usar comparar es una mejor opción para simplemente verificar la contraseña.

Fuente

2010-11-22 18:37:20 casperghst42

También un inicio de sesión con una contraseña nula cuenta como un enlace anónimo, que siempre tendrá éxito. – geoffc

Supongo que el enfoque "correcto" depende de lo que estás tratando de hacer. En el caso común de escribir una aplicación que delega la autenticación en un directorio externo, las restricciones de inicio de sesión generalmente son * deseables *, ¿no? –

No sé cuál podría ser la diferencia entre 'verificar contraseña' e 'iniciar sesión', o mejor dicho, por qué alguna vez querría hacer una sin la otra. @geoffc Un enlace anónimo solo tendrá éxito si el servidor está configurado para permitirlo. – EJP

Mire en la operación extendida WhoAmI (RFC 4532).

WhoAmI cumple realmente un propósito: validar las credenciales de enlace enviadas. No debería afectar ni provocar ninguna "restricción de inicio de sesión" (que yo sepa).

WhoAmI se puede hacer usando un binario dedicado (como "ldapwhoami"), o se puede hacer usando Net :: LDAP :: Extension :: WhoAmI (Perl) u otro lenguaje similar que admita operaciones LDAP. Tenga en cuenta que "probar una contraseña" usando alguna función de "Búsqueda" es un método de prueba poco aconsejable.

Por ejemplo, si mi DN es "uid = max, ou = usuarios, dc = compañía, dc = com" y mi contraseña es "@secret", se puede hacer esto a través del binario dedicado en una caja Linux (nota -ZZ se utiliza para la confidencialidad TLS, que es posiblemente sin soporte opcional o en su entorno):

ldapwhoami -x -w "@secret" -D uid=max,ou=users,dc=company,dc=com -ZZ -H ldap://address.of.your.ldapserver/

Si el usuario/pass combinación es correcta, la respuesta devuelta es:

dn: uid = max, ou = usuarios, dc = compañía, dc = com

Si la combinación usuario/pass no es correcta, la respuesta devuelta es (por lo general):

(49) credenciales no son válidas

Esto podría significar, como ya he dicho, la contraseña y/o el nombre de usuario es incorrecto, el usuario no existe o las LCA del servidor LDAP están rotas de tal manera que la autenticación no es posible. En la mayoría de los casos, su combinación de usuario/pase está mal escrita o el usuario no existe.

Para finalizar, la operación LDAPWhoAmI es un método muy ligero y simple de validación de credenciales. También funciona a través de otros mecanismos (por ejemplo, inicio de sesión único de Kerberos, Digest-MD5, etc., etc.).

Fuente

2013-07-20 18:30:07

El nombre de usuario y la contraseña ni siquiera se envían como parte de la solicitud 'WhoAmI'. Todo lo que hace la operación 'WhoAmi' es decirte a quién estás vinculado actualmente. Por lo tanto, no tiene sentido decir que 'valida las credenciales de enlace presentadas'. No es así Simplemente los devuelve, o mejor dicho, solo el nombre de usuario. Es el paso * bind * el que hace la validación: solo por lo tanto es suficiente. En el ejemplo dado, 'ldapwhoami' se une primero, lo que puede fallar con 'Credenciales inválidas', y luego ejecuta la operación' WhoAmI'. * Cualquier * operación LDAP habría hecho. No tenía que ser 'WhoAmi'. – EJP

LDAP - ¿Cómo verificar una combinación de nombre de usuario/contraseña?

Respuesta

Cuestiones relacionadas