Environment
LDAP Server: TurnKey OpenLDAP
Spring-ldap-core version: 2.3.3.RELEASE
What is the activity
User is locked in LDAP server
User attempts to login through our webapp
Login failed
Error code 49 - Invalid Credentials is thrown
What is expected
Specific exception should be thrown(eg: Error code 775 USER_ACCOUNT_LOCKED)
Excepion
Some information like comment and data are not found in the exception
org.springframework.ldap.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]
at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:191)```
The LDAP protocol RFC doesn't provide the level of granularity that you want for a rejected authentication request, it's simply error code 49 invalidCredentials. There is no account locked in the standard.
In another LDAP wiki documentation here about error codes, it also specifies that error code 49 is valid for locked accounts.
If you are keen on having this functionality you could opt to take control of your security layer and impose a maximum retry count for your application (rather than relying of whatever is default in a third party LDAP server), keep track if it's reached, and throw/return the appropriate response that you want. I can see an example of how you could do that in this post, but I would invest a bit more time in finding the best solution if you want to go this way.
LDAP specification is base. It defines error codes.
Implementation of LDAP such as OPEN_LDAP, ACTIVE_DIRECTORY etc.. may define its own sub-error codes with exception message. Active Directory supplies its own sub-error codes within the error message.
ldap-related-rfcs
active-directory-error-codes
Related
java.sql.SQLRecoverableException: IO Error: The service in process is not supported. Operation unavailable (Mechanism level: KRB_CRED not generated correctly.)
I am getting this exception when my HikariDataSource is attempting to establish a connection with my oracle database by using kerberos as the means of authentication.
I am confident the issue is something to do with my principle not being accepted despite my credential cache file working perfectly fine for my other java 8 projects.
The reason I believe its an issue with the principal is because I have a separate credential cache file that is generated on my server that uses a different principal than the one I would use locally. That credential cache file from my server works perfectly fine when it is used locally for this java 11 project. However, I cannot locally generate credential cache files with that principal.
Additionally, I am using the same krb5.conf file so I don't understand how my principal is being accepted by 1 service but, not another... I also made sure to use the java 11 version of the kinit.exe file when executing the below command although, I don't think that should matter.
$kinit -c credential_cache_file instance#domain.realm
Using other flags such as -A -p -f also gives me a separate error but, that type of credential cache file won't work for any of my java 8 or java 11 services.
java.nio.BufferOverflowException: null
EDIT:
The lowest level error I am actually getting is this.
Caused by: sun.security.krb5.KrbException: Invalid option in ticket request. (101)
Actually a bit more information and stacktrace would have helped in debugging the issue. As per the information provided above,
This exception happens when there is a mismatch in the kerberos credential. Then GSSException occurs and this message is generated.
Operation unavailable (Mechanism level: KRB_CRED not generated correctly.)
Code Flow
Step 1:
This message is part of Krb5Context class. Here InquireType is KRB5_GET_KRB_CRED which means it is an attribute type for retrieving the KRB_CRED message that an initiator is about to send to an acceptor.
Links: Krb5Context InquireType
try {
byte[] krbCred = new KrbCred(tgt, serviceCreds, key).getMessage();
return new KerberosCredMessage( sender, recipient, krbCred);
} catch (KrbException | IOException e) {
GSSException gsse = new GSSException(GSSException.UNAVAILABLE, -1,
"KRB_CRED not generated correctly.");
gsse.initCause(e);
throw gsse;
}
Step 2:
Then it calls KrbCred class and here validation fails. This class encapsulates the KRB-CRED message that a client uses to send its delegated credentials to a server. In the condition check there is a mismatch in the Client of the Service Ticket with the client in Ticket Granting Ticket. So, as you mentioned it seems to me as a Principal issue. Link : KrbCred
PrincipalName client = tgt.getClient();
PrincipalName tgService = tgt.getServer();
if (!serviceTicket.getClient().equals(client))
throw new KrbException(Krb5.KRB_ERR_GENERIC,
Step 3: First KrbException is thrown thereafter it is caught by the catch block and GSSException is thrown back with message as Operation unavailable. Link: GSSException
Changes between Java 8 and Java 11
There has been a lot changes for kerberos in Java 11. You can find it in the changelog. E.g.
Support cross-realm MSSFU
Support for canonicalize in krb5.conf
Support for Kerberos Cross-Realm Referrals (RFC 6806)
LDAP Channel Binding Support for Java GSS/Kerberos
The are fewer InquireType in Krb5Context of Java 8 compared to Krb5Context of Java 11.
Possible Solution
The Kerberos client which you are using may not currently support the 'canonicalize' setting in the configuration file (krb5.conf). As a result, Name Canonicalization behavior cannot be customized. The client will claim support for it in every TGT request if sun.security.krb5.disableReferrals is false, and the KDC service may change the client name.
JDK 11: The 'canonicalize' flag in the krb5.conf file is now supported by the JDK Kerberos implementation. When set to true.
The new default behavior is different from previous releases where name canonicalization was always requested by clients in TGT requests to KDC services (provided that support for RFC 6806 was not explicitly disabled with the sun.security.krb5.disableReferrals system or security properties)
This issue was seen in few minor Java 8 version(1.8.0_242) as well. You can try the example in the ticket to reproduce. JDK-8239385
Some more information JDK-8244465
Cross-Realm Referrals Support is enabled by default and 5 is the maximum number of referral hops allowed. To turn it off, set the sun.security.krb5.disableReferrals security or system property to false. To configure a custom maximum number of referral hops, set the sun.security.krb5.maxReferrals security or system property to any positive value.
You can try changing the JAAS config to use a ticket in the ticket cache created upfront using kinit.
You can try to upgrade the java version as well.
Update from discussion in the comments section:
by: sun.security.krb5.KrbException: Invalid option in ticket request. (101)
This could be linked to proxiable=true in your krb5.conf. Removing the value can help in resolving the issue.
Kerberos authentication fails with “java.nio.BufferOverflowException"
This issue could be related to the JDBC driver. The current version may not support the operation. Upgrading or Downgrading oracle jdbc driver may lead to the resolution.
I was receiving this error using Java 11/ojdbc10.jar which was confusing given the accepted answer being about needing to upgrade from Java 8 to 11. I tried all the proposed solutions there, but in the end what resolved the error and allowed my application to connect was using kinit -f instead of just kinit.
Credit to http://jiggermast.blogspot.com/2014/06/kerberos-invalid-option-setting-in.html
Relevant portions:
However, before trying to access the web application, the login module tries to go to the KDC (again ApacheDS) to get a ticket; however, before it gets there a KrbException is thrown (see below).
Found ticket for wmmnpr#EXAMPLE.COM to go to
krbtgt/EXAMPLE.COM#EXAMPLE.COM
expiring on Wed Jun 04 10:03:36 CEST 2014
Entered Krb5Context.initSecContext with state=STATE_NEW
Service ticket not found in the subject
Credentials acquireServiceCreds: same realm
KrbException: Invalid option setting in ticket request. (101)
at sun.security.krb5.KrbTgsReq.<init>(KrbTgsReq.java:98)
at sun.security.krb5.KrbTgsReq.<init>(KrbTgsReq.java:62)
After looking at the sun.security.krb5.KrbTgsReq code at line 98 it occurred to me that it was the "forwardable" option that was causing problems. I then ran kinit as follows, with -f:
kinit.exe -f wmmnpr#EXAMPLE.COM
Password for wmmnpr#EXAMPLE.COM:
New ticket is stored in cache file C:\Users\wnpr\krb5cc_wnpr
My Problem is:
Upload 10000 Record from Excel To my Database. The Excel Sheet has 10000 Rows and 70 to 100 Column . We Store the Value in 6 Mapping Table using Hibernate cascade.
I call the method using ajax method. Due to inserting large amount of data. it return timeout error(502 (Proxy Error) OR 504 (Gateway Error)).
I am using AWS Services. Is any configuration mistake.. please help
Thanks in Advance
How You Might See a 502 Bad Gateway Error
Based on your web server, you might see a different 502 error. These all mean the same thing, it is only their naming conventions that differ. Here are a few examples of what you might see:
“502 Bad Gateway”
“HTTP Error 502 – Bad Gateway”
“502 Service Temporarily Overloaded”
“Error 502”
“502 Proxy Error”
“HTTP 502”
“502 Bad Gateway NGINX”
You can see in greater detail what the error specifically entails by going to your web server’s error log file. All error / diagnostic information is stored in this file making it a valuable resource to check when you need more details about a particular error. You can locate this file in Apache by going to /var/log/apache2/error.log and in Nginx by going to /var/log/nginx/error.log.
How to solve 502 errors?
Check if your FQDN is resolving correctly by using our DNS test tool.
Verify if your server is reachable by using a ping test or trace-route.
Check your firewall logs if you are seeing unusual drops.
Open a support in the KeyCDN dashboard if you can not solve the 502 problem.
My Mongo server should be set up correctly since I can query against it using GSSAPI mechanism with client.
According to the documentation, Java Driver's Kerberos Authentication can be as simple as
credentialList.add(MongoCredential.createGSSAPICredential("people/myhost.com#EXAMPLE.COM"));
The principal I used
I tested with Mongo's enterprise version of client and it works: authenticated against Mongo server with Kerberos and can find() against it. (database test, principal "people/myhost.com#EXAMPLE.COM")
kinit performed and the new ticket is showed in the klist, ticket cached stored under KRB5CCNAME=D:\Kerberos\tickets.txt (environment variable set)
To make sure krb5.ini/conf is read, I manually set the system property java.security.krb5.conf=C:/Windows/krb5.conf
Before I set the property javax.security.auth.useSubjectCredsOnly, GSSAPIAuthenticator.createSaslClient() catched exception of GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt).
After I set the property javax.security.auth.useSubjectCredsOnly=false, InternalStreamConnection.open() catched throwable: java.lang.SecurityException: Unable to locate a login configuration
I am really confused here. I thought it is using the ticket cache which is specified under KRB5CCNAME. If I use jaas configuration, what name should I assign it to be?
Name {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="D:\\Kerberos\\people.keytab"
useTicketCache=false;
};
I set it with a random name and it started complaining GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null)).
Can you guys help me on this? What else I can try here or are there more useful and detailed logs that I can enable in this case?
Security error messages are cryptic, by design :-/
But there is a nice "security trace flag" property to help you debug GSSAPI config issues:
-Djava.security.debug=gssloginconfig,configfile,configparser,logincontext
I have a few web services on a Weblogic 10 server. Each of these is part of a larger system. Running locally and on our qa environment the system works flawless, replies fast, and as expected. Everything looks to be okay.
Before going into production we're going to stress test the system, thus see how much load we can have before reply time becomes to large. When testing the web services (e.g. using front end or SOAPUI) we hit a certain load (e.g. to many replies per sec or something like that, I'm not sure what exactly triggers the system to fail) we get the error listed below. I haven't got the slightest clue as to why. Seconds later the system replies flawless again, so I'm guessing that it has something to do with the number of requests...
Any ideas or hints is much appreciated! I'm lost here, so please - anything will help.
We're running: Weblogic 10.3.2, Spring 2.5.6 (for architectural reasons we cannot upgrade), Spring-WS 1.5.9 (for architectural reasons we cannot upgrade) and Stripes 1.5.4
<11-11-2011 08:43:58 CET> <Error> <HTTP> <BEA-101017> <[ServletContext#11242741[app:salesoverview-ws-web module:salesoverview-ws-web path:/salesoverview-ws-web spec-version:2.5], request: weblogic.servlet.internal.ServletRequestImpl#1fbbfc5[POST /salesoverview-ws-web/services HTTP/1.1 Accept-Encoding: gzip,deflate Content-Type: text/xml;charset=UTF-8 SOAPAction: "" User-Agent: Jakarta Commons-HttpClient/3.1 Content-Length: 425]] Root cause of ServletException.
org.springframework.ws.soap.saaj.SaajSoapMessageException: Could not write message to OutputStream: Error attempting to save SOAPPart. java.io.IOException: java.net.SocketException: Software caused connection abort: socket write error; nested exception is javax.xml.soap.SOAPException: Error attempting to save SOAPPart. java.io.IOException: java.net.SocketException: Software caused connection abort: socket write error
at org.springframework.ws.soap.saaj.SaajSoapMessage.writeTo(SaajSoapMessage.java:169)
at org.springframework.ws.transport.AbstractWebServiceConnection.send(AbstractWebServiceConnection.java:45)
at org.springframework.ws.transport.support.WebServiceMessageReceiverObjectSupport.handleConnection(WebServiceMessageReceiverObjectSupport.java:97)
at org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter.handle(WebServiceMessageReceiverHandlerAdapter.java:57)
at org.springframework.ws.transport.http.MessageDispatcherServlet.doService(MessageDispatcherServlet.java:230)
Truncated. see log file for complete stacktrace
Caused By: javax.xml.soap.SOAPException: Error attempting to save SOAPPart. java.io.IOException: java.net.SocketException: Software caused connection abort: socket write error
at weblogic.xml.saaj.SOAPMessageImpl.SOAPPart_writeTo(SOAPMessageImpl.java:1011)
at weblogic.xml.saaj.SOAPMessageImpl.writeTo(SOAPMessageImpl.java:816)
at org.springframework.ws.soap.saaj.Saaj13Implementation.writeTo(Saaj13Implementation.java:292)
at org.springframework.ws.soap.saaj.SaajSoapMessage.writeTo(SaajSoapMessage.java:165)
at org.springframework.ws.transport.AbstractWebServiceConnection.send(AbstractWebServiceConnection.java:45)
Truncated. see log file for complete stacktrace
>
By digging BEA-101017 I found a little info about the from the Weblogic error dok - although this doesn't help me:
Error: [context] Root cause of ServletException.
Description: [context] Root cause of ServletException, which the Web
application container caught while servicing the request.
Cause: The Web application container caught an unexpected exception.
Action: Check the exception for the exact error message.
Assuming that the web service from your example doesn't access other web services (and therefore the above trace corresponds to your web service sending the response):
It seems that your web service, via SAAJ, is trying to write to a disconnected (or otherwise unavailable) socket. An usual cause for this is that the client has disconnected while waiting for the server reply.
I'd suggest to:
Check if your client was waiting for too long before receiving the response, that could have caused it to disconnect.
Check if the operating system might be having issues allocating sockets. Use 'netstat' or other monitoring tool (like TCPView on Windows) to check how many sockets are open (most operating system impose limits on the number of sockets allowed per user or globally).
Ensure there are absolutely no network errors during your tests (shouldn't be the case if you are testing on localhost, but otherwise you need to ensure your network devices (routers, switches, other computers) are not dropping connections or packets. Perhaps this is happening when traffic load is high.
Make sure you have no threading conflicts that could cause your web service to use or close other requests' sockets (this would be a rare situation especially if you are using Spring).
Check this thread Official reasons for "Software caused connection abort: socket write error" and other possible causes of "Software caused connection abort" (note that the issue could be specific to your application server and operating system).
Hope that helps.
After debugging a lot I found out that the problem happened due to DB2 issues - we hit a corner of our database, which triggered an internal stack overflow, which then probagated to the Dao and onwards to the SOAP-part (only making it harder to detect due to Spring JDBC templates in the Dao).
A long story short and the issue was an uncaught exception, which by Spring-WS resulted in a "SaajSoapMessageException". The hint came from "Software caused connection abort: socket write error", but happened on the WS side (not client nor the communication between client/server).
Hint: Surround your database with try/catch and catch Exception thus being able to find the exact exception thrown. In my case it threw a DB2 exception ("SQLCode -1218") and this is normally used when you run out of resources (e.g. data source connections). I my case it was the SQL which DB2 didn't like - and really didn't like under load. I can't explain it, but it has to do with DB2s own internal resources - gah, go figure! :)
Thank you jjmontes, for hints and pointers, but it was not the problem in this case.
I want Oracle Data Integrator 10.1.3 to be able to connect to Active Directory running on a Windows 2003.
I'm using SnpsLdapDriver but so far I'm dead unable to make it work.
I keep getting error 52e : Insufficient Credentials. I tried every possible possible way I could - locking my account numerous times- and just nothing but errors.
jdbc:snps:ldap?ldap_url=ldap://128.1.1.121:389/DC=mydc,DC=int??base?(objectClass=*)&ldap_password='encrypted_password_through_snpsldapo.jar'
I tried everything I could find on google....
HELP ????
TIA
52e is the LDAP error code indicating either an invalid user principal or invalid user password.