I am integrating an application with AD/LDAP authentication via JAAS, and while this interface is working fine 90% of the time, occassionally I am getting technical errors when users try to log in.
The errors in the logs are like :
INFO -[LdapLoginModule] user provider: ldaps://<AD server>:636/DC=global,DC=mycompany,DC=com
INFO -[LdapLoginModule] searching for entry belonging to user: <user name>
INFO -[LdapLoginModule] authentication failed
INFO -[LdapLoginModule] aborted authentication
When enabling additional logs, I can see the below exception :
javax.security.auth.login.FailedLoginException: Cannot find user's LDAP entry
(This is not a credentials issue - as I explained it is occurring randomly and if user tries to login with same creds a few more times it will eventually succeed)
Checking the LdapLoginModule.java code from the below link, I am trying to follow the logs output in the code to understand where exactly this occurs but I am not able to understand exactly why the "authentication failed" output is reached/thrown :
LdapLoginModule.java
Could someone please help me understand what might be causing this random issue and point me to the right direction ? Could it be an issue on AD side or on JAAS config ?
Below some additional info :
SSL is enabled
"AD server" is not a domain controller but rather a DNS method of load balancing
Using anonymous binding (search-first) mode
JAAS config :
LDAP_AD {
com.sun.security.auth.module.LdapLoginModule REQUIRED
userProvider="ldaps://<AD server>:636/DC=global,DC=mycompany,DC=com"
userFilter="(&(sAMAccountName={USERNAME})(objectcategory=user)(memberof=CN=aGroup,OU=Security Groups,OU=Groups,OU=Geneva,OU=Switzerland,OU=EMEA,DC=global,DC=mycompany,DC=com))"
useSSL=true
debug=true;
};
Any idea on the root cause of this would be much appreciated.
Many thanks,
George
As you note there is a load balancer in the way, your symptoms suggest you are getting load balanced to a node that is not in sync. Which is unlikely, but more likely is an AD DC that is not happy with your config, but the others are ok with it.
On a new user, or a newly changed user, the replication delay would be a common example of this problem in real life.
On existing users, this seems less likely.
It also may have something to do with the memberOf attribute which is not a static attribute, rather it is a dynamic query that is evaluated when you query for it.
Related
I'm using Spring Security 4.2.13.RELEASE and spring-security-saml2-core 1.0.10.RELEASE.
The idp is Google (and I don't have access to its configuration).
My application is run on a tomcat-like server. After this short briefing, my issue!
Often, users complain about problem of connection, they are connect to their idp and when they try to access to my application they go to an error page. This page explain "Authentication Failed: Error validating SAML message". If they empty their web browser cache, they can have the right redirection to the idp and connect to my application.
Why appear this error? It seems configuration is right if they empty their cache.
I have change session time of tomcat to be the same of the idp, I also change maxAuthenticationAge and maxAssertionTime of WebSSOProfileConsumerImpl and WebSSOProfileConsumerHoKImpl but it seems the problem is steel here.
What should I do?
I have change the log level. The error was a session duration too short.
On the log, there is a stack exception bug this stack is only shown in debug mode.
maxAuthenticationAge was the right property to modifiy, I made a mistake on duration computation.
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.
I am trying to write a file to HDFS cluster from My windows machine but getting following error
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
Permission denied: user=..., access=WRITE ,
inode="/user/hadoop/Hadoop_File.txt":hdfs:hdfs:-rw-r--r--
In my hadoop configuration
hadoop.security.auth_to_local is set to DEFAULT
hadoop.security.authentication is set to SIMPLE
if i mention user name as "hdfs" by doing
System.setProperty("HADOOP_USER_NAME", "hdfs");
everything works fine .
but if the policy is simple it means no authentication it should allow any user to create file
Help me in understanding why this is happening
I got the answer :) you have to configure dfs.permissions.enable = false ,it was true in my case once it is turned off ,it doesn't complains for any user used
Simple authentication in Hadoop means you don't need to prove who you are, for example with a password or token, but you still need to say who you are. Whichever user you assert yourself to be, Hadoop will believe you and adopt user name for the operation you request.
There are still permissions in place on HDFS (you can see that with hdfs:hdfs:-rw-r--r-- in your message above), so you need to assert yourself to be a user who has the necessary permissions for your operation, which is what you did with System.setProperty("HADOOP_USER_NAME", "hdfs");
The short version is, identity is not the same as authentication :)
I'm using the code here to get authentication information from a Kerberos token. In there I've configured the domainUsername and domainUserPassword and just ran it as specified in the readme.md.
Then, from a browser that is in the AD domain, I connect to http://server:8080/spnego and I see on the opened page my username#domain. The page should also contain the SID of the AD groups to which my user belongs.
Looking at the server logs, I see:
org.jaaslounge.decoding.DecodingException: Malformed PAC logon info.
at org.jaaslounge.decoding.pac.PacLogonInfo.<init>(PacLogonInfo.java:209)
at org.jaaslounge.decoding.pac.Pac.<init>(Pac.java:45)
at org.jaaslounge.decoding.kerberos.KerberosPacAuthData.<init>(KerberosPacAuthData.java:13)
at org.jaaslounge.decoding.kerberos.KerberosAuthData.parse(KerberosAuthData.java:21)
at org.jaaslounge.decoding.kerberos.KerberosRelevantAuthData.<init>(KerberosRelevantAuthData.java:41)
at org.jaaslounge.decoding.kerberos.KerberosAuthData.parse(KerberosAuthData.java:18)
at org.jaaslounge.decoding.kerberos.KerberosEncData.<init>(KerberosEncData.java:136)
at org.jaaslounge.decoding.kerberos.KerberosTicket.<init>(KerberosTicket.java:103)
at org.jaaslounge.decoding.kerberos.KerberosApRequest.<init>(KerberosApRequest.java:62)
at org.jaaslounge.decoding.kerberos.KerberosToken.<init>(KerberosToken.java:52)
at com.example.ManualSpnegoNegotiateServlet.attemptNegotiation(ManualSpnegoNegotiateServlet.java:271)
Line 271 is the following
KerberosToken token = new KerberosToken(kerberosTokenData, keys);
That error message is too vague. I've no idea how to continue and I get the same error from different clients.
Does anyone have any tip about this?
I've figured this one out myself. It turns out that the message "Malformed PAC logon info" is actually correct. The code failed when it was trying to get the "Resource groups data".
Initially I thought that the PAC_LOGON_INFO structure has changed since the last jaaslounge implementation was written (somewhere in 2010). I thought that because the MS-PAC specification does not mention it at all.
Actually, the problem is coming from a completely different place: the KDC. It's running on a Win Server 2012, version in which Microsoft added by default resource SID Compression.
There you have it, if you turn off resource SID Compression on the KDC, everything will start working (no need to touch anything else, i.e. the version of jaaslounge or to patch hava with an unlimited JCE policy).
I'm having some trouble with PAM. I have a tomcat webapp that uses PAM to authenticate. During install we make a symbolic link in /etc/pam.d to the /etc/pam.d/sshd file. This has always worked.
Recently I added a way for users to authenticate each request (rather than using a JSESSIONID cookie). This was added because we need to batch load some data into a monitoring application periodically and using Basic Auth was easy.
If I curl my webservice repeatedly (like 10 times a second), then every once in a while PAM will fail. This happens around once every 500 times, though my client claims that it happens once every couple of times (note that they are running remotely, though i don't see why that matters).
I have replaced my sym-linked pam config with a minimal config of:
#%PAM-1.0
auth sufficient pam_unix.so audit
auth required pam_deny.so
I have also added this to my /etc/syslog.conf
*.debug /var/log/debug.log
The only applicable log messages can be found in the debug.log:
Mar 12 09:49:32 arques java: pam_unix(foo:auth): unable to obtain a password
Mar 12 09:49:32 arques java: pam_unix(foo:auth): auth could not identify password for [root]
How do I debug this further? I have tried:
Using different hosts. One which is a brand new install
I've turned off the nscd service
I'm having a similar problem with a Java application that uses PAM for authentication. For now, I'm guessing the problem is within the distributed Java PAM binding implementation on CentOS 6.4. I no longer have access to that system (but I'm still trying to solve this problem) so I cannot provide specifics such as JDK version, etc.
My solution ultimately was to harshly kludge PAM:
#%PAM-
auth sufficient pam_debug.so
To make this more explicit, you could use "pam_permit.so" instead.
That's it, basically. Any valid user would then be authenticated, with or without password. Ugh.
I'm continuing to research better answers.