Estou trabalhando em um aplicativo Java de terceiros para o qual preciso autenticar seus usuários usando o Active Directory.
Este aplicativo está hospedado no RHEL 6.5 e usa LDAP para autenticar com o Windows Active Directory. O servidor AD foi configurado e está funcionando bem com uma versão anterior do aplicativo (que foi configurada para permitir a integração).
Para a versão mais recente, o fornecedor estabeleceu algumas etapas para modificar/configurar os arquivos do aplicativo para se conectar ao servidor AD e que devem nos ajudar na autenticação.
A aplicação possui um de seus componentes como CAS, que atualmente está configurado para usar o banco de dados como seu manipulador de autenticação. Quando inserimos as credenciais - nome de usuário: abcd, senha: samplepswd, conseguimos fazer o login com sucesso.
Como o requisito de negócio é a autenticação com Active Directory usando LDAP, temos que modificar o arquivo de propriedades CAS. De acordo com as instruções do fornecedor do produto, alteramos as seguintes propriedades para usar o 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
Também precisamos fazer alterações no arquivo xml casAuthConfig para as seguintes propriedades (já que a pesquisa anônima não é suportada): 1. anônimaReadOnly, o valor é definido como falso 2. java.naming.security.authentication, o valor é definido como simples
Também existe a possibilidade de usar ldap sobre SSL, mas atualmente não estamos usando isso. No entanto, se usarmos SSL, alterações adicionais deverão ser feitas nas seguintes propriedades:
ldapSSLConfig.enabled=true
ldapSSLConfig.trustStorePath=/home/dir1/subdir1/subdir2/keystorename.keystore
ldapSSLConfig.trustStoreType=jceks
Estas são as únicas alterações de configuração feitas no nosso lado (cliente); e de fato as únicas alterações feitas. Nada foi adicionado/modificado no servidor (servidor AD), exceto outro usuário, mas isso não tem impacto na configuração existente.
Após reiniciar o cas para refletir as alterações, encontramos o erro de credenciais incorretas, embora os valores inseridos estejam corretos:
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)
Alguém pode ajudar com esse problema? Ou possivelmente apontar na direção certa? Qualquer ajuda seria muito apreciada.
Obrigado.
Responder1
Vejo alguns problemas potenciais em sua configuração.
ldapContextSource.userDn e .password devem ser as credenciais de uma conta no AD que tenha acesso para ler todas as contas de usuário que estariam efetuando login no aplicativo. Eles pretendem que o valor .userDn seja na verdade uma string DN LDAP (semelhante ao que você tem para .searchBase), mas para o Active Directory você pode usar o atributo userPrincipalName (UPN) (geralmente é[e-mail protegido]). Portanto, o erro de credenciais incorretas pode ser simplesmente porque você não está qualificando o nome de usuário com nada. Eu sempre prefiro usar UPN para integrações LDAP porque a conta pode ser movida dentro do AD e o aplicativo não se importa (ao contrário de um DN que mudaria).
Supondo que isso seja resolvido, seu valor .filter provavelmente também será um problema. Embora o atributo uid exista no Active Directory, geralmente ele não é preenchido por padrão. Você deve alterá-lo para sAMAccountName se quiser que os usuários façam login apenas com o nome de usuário.
Ao ativar o LDAP sobre SSL (LDAPS), você precisará ter um certificado TLS em seu(s) controlador(es) de domínio em que o aplicativo Java confie. Se for um certificado autoassinado, esse certificado precisará entrar no armazenamento de chaves referenciado pelos documentos. Se for um certificado gerado a partir de uma infraestrutura PKI pública ou interna, você deverá adicionar a cadeia de certificados CA para essa infraestrutura. Você também precisará alterar o URI do servidor LDAP para ldapé:// e porta 636 (ou 3269 para pesquisas de catálogo global).