Estoy trabajando en una aplicación Java de terceros para la cual necesito autenticar a sus usuarios mediante Active Directory.
Esta aplicación está alojada en RHEL 6.5 y utiliza LDAP para autenticarse con Windows Active Directory. El servidor AD se configuró y funciona bien con una versión anterior de la aplicación (que se configuró para habilitar la integración).
Para la versión más reciente, el proveedor ha establecido algunos pasos para modificar/configurar los archivos de la aplicación para conectarse con el servidor AD, y que se espera que nos ayuden a autenticarnos.
La aplicación tiene uno de sus componentes como CAS, que actualmente está configurado para utilizar la base de datos como controlador de autenticación. Cuando ingresamos las credenciales: nombre de usuario: abcd, contraseña: samplepswd, podemos iniciar sesión correctamente.
Como el requisito comercial es el de autenticación con Active Directory usando LDAP, tenemos que modificar el archivo de propiedades CAS. Según las instrucciones del proveedor del producto, hemos cambiado las siguientes propiedades para usar ldap:
authenticationHandler.type=ldap
ldapSSLConfig.enabled=false
ldapContextSource.url=ldap://sample.ADserver.example.net:389
ldapContextSource.userDn=abcd
ldapContextSource.password=samplepswd
ldapAuthenticationHandler.filter=uid=%u
ldapAuthenticationHandler.searchBase=OU=DEF,OU=PQR,OU=XYZ,DC=ADserver,DC=example,DC=net
También necesitamos realizar cambios en el archivo xml casAuthConfig para las siguientes propiedades (ya que no se admite la búsqueda anónima): 1. anonymReadOnly, el valor se establece en falso 2. java.naming.security.authentication, el valor se establece en simple
También existe la posibilidad de usar ldap sobre SSL, pero actualmente no lo estamos usando. Sin embargo, si utilizamos SSL, se deben realizar cambios adicionales en las siguientes propiedades:
ldapSSLConfig.enabled=true
ldapSSLConfig.trustStorePath=/home/dir1/subdir1/subdir2/keystorename.keystore
ldapSSLConfig.trustStoreType=jceks
Estos son los únicos cambios de configuración realizados por nuestra parte (cliente); y de hecho los únicos cambios realizados. No se ha agregado/modificado nada en el servidor (servidor AD), excepto otro usuario, pero eso no tiene ningún impacto en la configuración existente.
Luego de reiniciar cas para reflejar los cambios, nos encontramos con el error de credenciales incorrectas, aunque los valores ingresados son correctos:
2015-09-16 12:12:30,558 INFO [com.pqr.cas.authentication.support.DelegatingAuthenticationHandler] - Authenticating credential using handler
com.pqr.cas.adaptors.ldappwd.BindLdapAuthenticationHandler
2015-09-16 12:12:30,558 DEBUG [com.pqr.cas.authentication.support.DelegatingAuthenticationHandler] - credentials.getUsername() = abcd
2015-09-16 12:12:30,672 INFO [com.pqr.cas.adaptors.ldappwd.BindLdapAuthenticationHandler] - Search for cn=abcd returned 0 results.
2015-09-16 12:12:30,672 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - AuthenticationHandler:
com.pqr.cas.authentication.support.DelegatingAuthenticationHandler failed to authenticate the user which provided the following credentials:
[username: abcd]
2015-09-16 12:12:30,676 ERROR [org.jasig.cas.integration.restlet.TicketResource] - error.authentication.credentials.bad
org.jasig.cas.ticket.TicketCreationException: error.authentication.credentials.bad
at org.jasig.cas.CentralAuthenticationServiceImpl.createTicketGrantingTicket_aroundBody10(CentralAuthenticationServiceImpl.java:423)
¿Alguien puede ayudar con este problema? ¿O posiblemente apuntar en la dirección correcta? Cualquier ayuda sería muy apreciada.
Gracias.
Respuesta1
Veo algunos problemas potenciales en su configuración.
ldapContextSource.userDn y .password deben ser las credenciales de una cuenta en AD que tenga acceso para leer todas las cuentas de usuario que iniciarían sesión en la aplicación. Su intención es que el valor .userDn sea en realidad una cadena LDAP DN (similar a la que tiene para .searchBase), pero para Active Directory puede usar el atributo userPrincipalName (UPN) en su lugar (generalmente esto es[correo electrónico protegido]). Entonces, el error de credenciales incorrectas puede deberse simplemente a que no estás calificando el nombre de usuario con nada. Siempre prefiero usar UPN para integraciones LDAP porque la cuenta se puede mover dentro de AD y a la aplicación no le importa (a diferencia de un DN que cambiaría).
Suponiendo que eso se resuelva, su valor .filter probablemente también será un problema. Si bien el atributo uid existe en Active Directory, generalmente no se completa de forma predeterminada. En su lugar, debe cambiarlo a sAMAccountName si desea que los usuarios inicien sesión solo con su nombre de usuario.
Cuando empiece a habilitar LDAP sobre SSL (LDAPS), necesitará tener un certificado TLS en su(s) controlador(es) de dominio en el que confíe la aplicación Java. Si se trata de un certificado autofirmado, ese certificado deberá ingresar al almacén de claves al que hacen referencia sus documentos. Si se trata de un certificado generado a partir de una infraestructura PKI pública o interna, debe agregar la cadena de certificados de CA para esa infraestructura. También necesitarás cambiar el URI del servidor LDAP a ldap.s:// y el puerto 636 (o 3269 para búsquedas de catálogos globales).