1

I am working on a third party Java application for which I need to authenticate its users using Active Directory.

This application is hosted on RHEL 6.5, and uses LDAP to authenticate with Windows Active Directory. The AD server has been set up, and is working fine with an earlier version of the application (which was configured to enable the integration).

For the newer version, the vendor has laid out some steps to modify/configure the application files to connect with the AD server, and which are expected to help us authenticate.

The application has one of its component as CAS, which is currently configured to use database as its authentication handler. When we enter the credentials - username: abcd, password: samplepswd, we are able to login successfully.

As the business requirement is that of authentication with Active Directory using LDAP, we have to modify the CAS properties file. As per instructions from the product vendor, we have changed the following properties to use 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

We also need to make changes in the casAuthConfig xml file for the following properties (as anonymous search is not supported): 1. anonymousReadOnly, value is set to false 2. java.naming.security.authentication, value is set to simple

There is provision to use ldap over SSL as well, but currently we are not using that. However, if we do use SSL, additional changes have to be made to the following properties:

ldapSSLConfig.enabled=true
ldapSSLConfig.trustStorePath=/home/dir1/subdir1/subdir2/keystorename.keystore
ldapSSLConfig.trustStoreType=jceks

These are the only configuration changes done on our (client) side; and in fact the only changes done. Nothing has been added/modified on the server (AD server), except another user, but that has no impact on the existing setup.

After restarting cas to reflect the changes, we encounter the error of bad credentials, although the values entered are correct:

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)

Can anybody please help with this issue? Or possibly point in the right direction? Any help would be greatly appreciated.

Thank you.

rud_hp9
  • 13

1 Answers1

1

I see a few potential problems in your configuration.

ldapContextSource.userDn and .password should be the credentials for an account in AD that has access to read all of the user accounts who would be logging into the application. They intend for the .userDn value to actually be an LDAP DN string (similar to what you have for .searchBase), but for Active Directory you can use the userPrincipalName (UPN) attribute instead (usually this is username@example.net). So the bad credentials error may simply be that you're not qualifying the username with anything. I always prefer to use UPN for LDAP integrations because the account can be moved within AD and the application doesn't care (unlike a DN that would change).

Assuming that gets worked out, your .filter value will likely be a problem as well. While the uid attribute does exist in Active Directory, it's not generally populated by default. You should change it to sAMAccountName instead if you want users to login with just their username.

When you get around to enabling LDAP over SSL (LDAPS), you'll need to have a TLS certificate on your domain controller(s) that the java application trusts. If it's a self-signed cert, that cert will need to go into the keystore their docs referenced. If it's a cert generated from a public or internal PKI infrastructure, you should instead add the CA certificate chain for that infrastructure. You'll also need to change the LDAP server URI to ldaps:// and port 636 (or 3269 for global catalog searches).

Ryan Bolger
  • 17,010