Autenticação de aplicativo Java usando o Active Directory

Question

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 ativar a integração).

Para a versão mais recente, o fornecedor definiu algumas etapas para modificar / configurar os arquivos do aplicativo para conexão com o servidor do AD e que devem nos ajudar a autenticar.

O aplicativo tem um de seus componentes como CAS, que está atualmente 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 comercial é o da autenticação com o Active Directory usando o LDAP, temos que modificar o arquivo de propriedades do 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 (como a pesquisa anônima não é suportada): 1. anonymousReadOnly, o valor é definido como false 2. java.naming.security.authentication, value é definido como simples

Há provisão para usar o ldap sobre SSL também, 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 em nosso lado (cliente); e de fato as únicas mudanças feitas. Nada foi adicionado / modificado no servidor (servidor AD), exceto outro usuário, mas isso não afeta a configuração existente.

Depois de reiniciar o cas para refletir as alterações, encontramos o erro de credenciais ruins, embora os valores inseridos estejam corretos:

2015-09-16 12:12:30,558 INFO [com.emeter.cas.authentication.support.DelegatingAuthenticationHandler] - Authenticating credential using handler 
com.emeter.cas.adaptors.ldappwd.BindLdapAuthenticationHandler 
2015-09-16 12:12:30,558 DEBUG [com.emeter.cas.authentication.support.DelegatingAuthenticationHandler] - credentials.getUsername() = abcd
2015-09-16 12:12:30,672 INFO [com.emeter.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.emeter.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 por favor pode ajudar com este problema? Ou possivelmente apontar na direção certa? Qualquer ajuda seria muito apreciada.

Obrigado.

    

Answer 1

Eu vejo alguns problemas em potencial na 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 entrariam no aplicativo. Eles pretendem que o valor .userDn seja realmente uma cadeia DN do LDAP (semelhante ao que você tem para .searchBase), mas para o Active Directory, você pode usar o atributo userPrincipalName (UPN) (geralmente [email protected]). Portanto, o erro de credenciais ruins pode ser simplesmente que 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).

Assumindo que isso funcione, seu valor de filtro provavelmente também será um problema. Embora o atributo uid exista no Active Directory, geralmente não é preenchido por padrão. Você deve alterá-lo para sAMAccountName em vez disso, se quiser que os usuários façam login apenas com seu nome de usuário.

Quando você conseguir ativar o LDAP via SSL (LDAPS), precisará ter um certificado TLS no (s) controlador (es) de domínio em que o aplicativo java confia. Se for um certificado autoassinado, esse certificado precisará entrar no keystore dos documentos mencionados. Se for um certificado gerado a partir de uma infraestrutura pública ou interna de PKI, você deve adicionar a cadeia de certificados de autoridade de certificação dessa infraestrutura. Você também precisará alterar o URI do servidor LDAP para ldap s : // e porta 636 (ou 3269 para pesquisas de catálogo global).