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.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) 

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

Thank you.

0

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).

  • Thanks Ryan. When you say that the userDn and password should be of the account that has access to read all of the user accounts, it would be an admin account, right? If so, we are already using an admin account. In other configurations that we tried, we have used the value of userDn as "uid=abcd,OU=DEF,OU=PQR,OU=XYZ,DC=ADserver,DC=example,DC=net" and "cn=abcd,OU=DEF,OU=PQR,OU=XYZ,DC=ADserver,DC=example,DC=net", and you are suggesting that I set it to abcd@ADserver.example.net. Also, I would have to change value of filter to sAMAccountName=%u, is that correct? I'm sorry, I'm quite new to this – rud_hp9 Sep 28 '15 at 12:59
  • It does not need to be an admin account. In fact, it doesn't need any permissions other than basic read access to AD which new accounts get by default unless the default AD permissions have been changed. If ADserver in your example is the hostname of a domain controller, then your domain's FQDN is example.net. Your userDn would be abcd@example.net. You can also look up the full DN value by looking at the Attributes tab on the account. The attribute is called distinguishedName. – Ryan Bolger Sep 28 '15 at 16:02
  • I have not mentioned the name of the domain controller in my example (as we have multiple DCs in the domain, and we attempt to connect to the domain, and not a single DC for redundancy). I am quite sure that the domain's FQDN is ADserver.example.net, so the userDn would be abcd@ADserver.example.net. I will try with that and let you know of the results. The full DN, as seen in the Attributes tab is: cn=abcd,OU=DEF,OU=PQR,OU=XYZ,DC=ADserver,DC=example,DC=net (the vendor has suggested to use this as userDn) We do have to connect this over SSL, but will work on that once current setup works. – rud_hp9 Sep 28 '15 at 17:51
  • My mistake. "ADserver" makes it sound like a single machine. – Ryan Bolger Sep 28 '15 at 17:53
  • Be wary of using the domain's FQDN as your LDAP server if you have domain controllers in multiple sites. Unless the application is smart enough to use DNS SRV records to find the closes domain controller (most aren't), the application will essentially be using round-robin DNS across all of your DCs to choose which one to authenticate against. – Ryan Bolger Sep 28 '15 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.