We Keep Coding

Java application authentication using Active Directory

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. After making required changes, we are only able to open the UI page, which does not accept the (correct) credentials, the page that helps us with application configuration is not accessible at all.
I am a newbie to this area, and as far as my understanding goes, I would just need to make the suggested changes, and not follow the steps presented in this document, as those are for authenticating the Linux users, and NOT the application's users. Could someone also please confirm the same.
Any help/guidance in this issue would be greatly appreciated.
Thanks very much!
Edit:
I am unable to provide details of the files as it is confidential property, but the changes have to be made in the server property files.
Kindly request more details if necessary, I will try my best to provide them as I can't disclose everything, citing confidentiality reasons.
Thank you very much.
Edit 2:
Have added more details with this edit, which are given below:
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.

How to authenticate a mobile ADF application

How can I authenticate a user onto IIS. Actually my purpose is that an online user to make supply enter the application by using a kind of verification. And on the other hand we have Microsoft web system. So probably, I need to solve the authentication issue on IIS. Essentially I know how to secure and authentication AMX page within weblogic system. Basic HTTP Authentication is a standard though and ADF mobile useS it too. But can it handle my expectation, I cannot be sure.
What is the best practice and best way?

This is acutally a question to the IIS guys - all you need is a URL on that server that will prompt you for a basic authentication.

NTLoginModule: Where does it retrieve user information?

I want the user to be able to Single-Sign-On, i.e. once logged on as Windows User, all services offered by my application should be accessible without further authentication.
In order to authenticate the user I'm using JAAS (Java Authentication and Authorization Services), which is integrated in Java.
The Java API ships also with a several JAAS LoginModules. One of them is called NTLoginModule, which retrieves user information about the currently logged on Windows User.
Where does NTLoginModule retrieve
its information from?
Can I use the
information returned by NTLoginModule in order to authenticate - in a safe manner -
the current user?
Are there any security issues I have to know about?
Thank you in advance!

I cannot help with JAAS, last tyime I did SSO with NTML, it was based on jCIFS.
However, I'm replying on your third point: There are security issues with NTLM
NTLM is quite weak (even v2), and you should lock accounts after a given number of login failures (to avoid brute force attack).
NTLM cannot work other a firewall.
NTLM token cannot be trusted by a third party, leading to the double-hop problem. Your application cannot take the identity of the logged in user to call another NTLM-protected server (like a web service; a RSS feed; or any web resource).
NTLM is not supported by all browsers. Internet Explorer and Chrome works natively ; Firefox needs to edit a configuration for each targeted site ; Opera, Konqueror don't support NTLM at all.

As I said in the comment to rds' answer: "I learned that NTLoginModule is quite insecure. I was able to fake the returned username by replacing the NTUserPrincipal.class file in the rt.jar package and so I was able to return a bogus user name. So it's not suitable for any kind of authentication."
Additionally, by doing some researches I found out that NTLoginModule retrieves it's information from nt.dll, which is part of the Java native libraries for Windows. nt.dll uses advapi32.dll in order to retrieve the current's user information.

How to validate a Kerberos ticket against a server in Java?

we are using JAAS to enable Single Sign On in a Java application using the Windows Kerberos ticket cache. Our jaas.conf config file looks like this:
LoginJaas {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true
doNotPrompt=true
debug=true;
};
With this, we can create a Jaas LoginContext and successfully get the user's Kerberos ticket. We send this ticket to out server application using JMI. What we don't manage to do though is to verify on the server that the Kerberos ticket was in fact created by our Active Directory.
At the moment, we do a very insecure validation of the ticket by simply checking if the Server Principal (KerberosTicket.getServer()) name has our domain name in the realm part. But of course, anyone could set up an own Kerberos server with the same realm name and use that ticket to start the application.
One idea I have found was to authenticate against the Active Directory LDAP using the Kerberos ticket. Unfortunately, we use Windows 7 and re-using the Kerberos ticket to authenticate against the LDAP only works when setting a Registry entry (see http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html, search for allowtgtsessionkey). This is unacceptable for our users.
Is there any way to validate the ticket against our Active Directory server? I suspect there is a way to check if the KerberosTicket.getServer() ticket equals the ticket of our server, but I have no idea how to do that. UPDATE: KerberosTicket().getServer() only returns a KerberosPrincipal that contains nothing but the server ticket name and realm, so it is not suitable for validation.
Thanks for your help,
memminger

As you mentioned, the proper way to solve this is by kerberizing your service, which is the whole point of the Kerberos protocol (authenticating clients against servers). Ticket reuse doesn't work exactly because it'd be a security problem if it did.
A Kerberos service does not need to "log into Active Directory", it just needs to have a shared key with AD.
BTW, to get SSO using JAAS requires having that allowtgtsessionkey set, there's no way around that on Windows.

As no one seems to really know an answer to this, I suppose we have to make a proper Kerberos service out of our server application. One that logs in to the Active Directory itself and that has the ServicePrincipalName attribute set properly. Kind of like SPNEGO does for HTTP. A good starting point how to do that will be the SPNEGO Servlet filter on SourceForge (http://spnego.sourceforge.net/). http://thejavamonkey.blogspot.com/2008/04/clientserver-hello-world-in-kerberos.html is also a very good example of how to do Service logon.
Unfortunately, this leads to the same problem with the registry key, so I posted a new question on Is there a way in Java or a command-line util to obtain a Kerberos ticket for a service using the native SSPI API?.

Glassfish caching LDAP passwords

I have some java code which allows users to reset their passwords stored on a LDAP server. The code runs as part of a web application running on Glassfish.
The problem I'm seeing is that after calling the change password operation, the user can subsequently use either password to access the application.
I have a unit test which runs directly against the LDAP server and I can verify that the password did indeed change and the user cannot gain access using the old password. The problem is not on the LDAP server.
What I've noticed is that if I restart Glassfish after the password change operation, only the new password is valid (as expected). I'm guessing that Glassfish is caching the credentials somewhere.
What do I need to set in Glassfish (or maybe in my web.xml) to either
tell Glassfish not to cache the LDAP credentials
reset the Glassfish password cache
Thanks in advance....
UPDATE
Still having this problem. I also thought that the browser could be storing this information, but that doesn't seem to be the case. I close out of my browser session and both passwords still work in the new session - even with different types of browsers. BTW - I don't know if it matters or not, but this is HTTP basic authentication.
UPDATE
We are also using the single sign on functionality included with Glassfish. From this article, it looks as if the session is tied to a cookie on the browser and maybe the user would be valid until the cookie expired? It looks as if the cookie is tied to a session. Getting closer to figuring this out....

Try adding this property to your ldap realm's additional properties:
com.sun.jndi.ldap.connect.pool=false

Could be your problem related to this Active Directory issue?
http://support.microsoft.com/?id=906305
My problem was.