RE: JNDIRealm strangeness
Well you have prompted me to respond once more! Tomcat should not have to do anything to establish a encrypted SSL connection to your LDAP server except pass on the correct parameters to the chosen LDAP driver, and instantiate it. It is the LDAP drivers job to handle all the nasty details of doing the SSL connection, and talking LDAP. That said, some LDAP driver factories do offer extra parameters for configuring SSL parameters beyond the SECURITY_PROTOCOL parameter. (Of course, Tomcat will be issuing the appropriate LDAP queries to do the Realm authentication, etc). I took a quick look at the Tomcat JDNI Realm configuration document, and it does specify that you can put in your own contextFactory so if you have another LDAP driver, other than Suns reference driver then you could use try that out to see if it fixes your problem. I don't know if OpenLDAP provides their own Java LDAP Driver but its worth a look! Have a hunt around and see what you can find. Technically speaking any driver that implements the LDAP RFCs should be able to talk to any LDAP server that implements the RFCs, but cruel reality often imposes itself :) But yes, someone should get around to putting in a bug report about that ldaps matter :) If it has not already been done that is. Regards, Shane. -Original Message- From: Chong Yu Meng [mailto:[EMAIL PROTECTED] Sent: Monday, 10 May 2004 11:53 AM To: Tomcat Users List Subject: Re: JNDIRealm strangeness Hi Shane ! Thanks for your help! After experimenting over the weekend, I think that this is probably a bug in the Tomcat code. I checked and corrected some problems in my OpenLDAP setup, and verified that SSL/TLS connections can be made successfully to it using ldapsearch. When I tried starting up Tomcat again, it gave me the same error. I think Tomcat may not be able to establish an encrypted connection to OpenLDAP. Unencrypted connections on port 389 seem to be ok. Incidentally, I'm also anal retentive (that, I am told, is a national characteristic of my country), and I tried ldaps://, but Tomcat will throw a parse error and will not accept the JNDI Realm parameters. They may have fixed it in the just-released 5.0.24, though. Thanks for your help, again ! I'm not on any specific timetable, so I don't need to fix this soon. I'll direct my question to the Tomcat developers and see if they are aware of the issue. Regards, pascal chong Shane Linley wrote: Hi, What happens on failed connections IS driver specific, but it should NOT BY DEFAULT switch to using a non SSL connection, for the sake of security if nothing else. The connection should tried to be established, if it fails then it should send back the appropriate naming exception. That said drivers do accept configuration properties to modify their behaviour, so technically anything is possible, based on your drivers documentation. I have never used OpenLDAP so its error logs don't really mean all that much to me, but having done similar things in the past you should look up your error codes in the OpenLDAP documentation (but its probably the OpenSSL doco) as to what the error codes really mean to work out what the problem is. I'm referring specifically to this line (as id does match up to the Request: 1 cancelled) message that the LDAP client driver reports. May 7 20:03:56 localhost slapd[6346]: connection_read(11): TLS accept error error=-1 id=0, closing Thats all I have! Good luck. Regards, Shane. P.S. The anal retentive part of me still wants you to specify the ldap connection as ldaps://server:636 but that is completely besides the point! :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JNDIRealm strangeness
Hi, What happens on failed connections IS driver specific, but it should NOT BY DEFAULT switch to using a non SSL connection, for the sake of security if nothing else. The connection should tried to be established, if it fails then it should send back the appropriate naming exception. That said drivers do accept configuration properties to modify their behaviour, so technically anything is possible, based on your drivers documentation. I have never used OpenLDAP so its error logs don't really mean all that much to me, but having done similar things in the past you should look up your error codes in the OpenLDAP documentation (but its probably the OpenSSL doco) as to what the error codes really mean to work out what the problem is. I'm referring specifically to this line (as id does match up to the Request: 1 cancelled) message that the LDAP client driver reports. May 7 20:03:56 localhost slapd[6346]: connection_read(11): TLS accept error error=-1 id=0, closing Thats all I have! Good luck. Regards, Shane. P.S. The anal retentive part of me still wants you to specify the ldap connection as ldaps://server:636 but that is completely besides the point! :) -Original Message- From: Chong Yu Meng [mailto:[EMAIL PROTECTED] Sent: Friday, 7 May 2004 8:17 PM To: Tomcat Users List Subject: Re: JNDIRealm strangeness Hi Shane ! Thanks for the description and advice! I managed to finally turn on OpenLDAP logging (a pain in Fedora Core 1), and set the loglevel to 256. Here's what I get. When the Tomcat server starts up, the connection errors seem to be related to port 636 : May 7 19:51:50 localhost slapd[6049]: conn=4 fd=11 ACCEPT from IP=127.0.0.1:32892 (IP=0.0.0.0:636) May 7 19:51:50 localhost slapd[6049]: conn=4 fd=11 closed May 7 19:51:50 localhost slapd[6049]: conn=5 fd=11 ACCEPT from IP=127.0.0.1:32894 (IP=0.0.0.0:389) May 7 19:51:50 localhost slapd[6049]: conn=5 op=0 BIND dn= method=128 May 7 19:51:50 localhost slapd[6049]: conn=5 op=0 RESULT tag=97 err=0 text= May 7 19:52:02 localhost slapd[6049]: conn=6 fd=12 ACCEPT from IP=127.0.0.1:32895 (IP=0.0.0.0:636) May 7 19:52:02 localhost slapd[6049]: conn=6 fd=12 closed May 7 19:52:02 localhost slapd[6049]: conn=7 fd=12 ACCEPT from IP=127.0.0.1:32897 (IP=0.0.0.0:389) May 7 19:52:02 localhost slapd[6049]: conn=7 op=0 BIND dn= method=128 May 7 19:52:02 localhost slapd[6049]: conn=7 op=0 RESULT tag=97 err=0 text= Bumping up loglevel to 4095, I get these details for the errors on port 636: May 7 20:03:56 localhost slapd[6346]: connection_read(11): TLS accept error error=-1 id=0, closing May 7 20:03:56 localhost slapd[6346]: connection_closing: readying conn=0 sd=11 for close May 7 20:03:56 localhost slapd[6346]: connection_close: conn=0 sd=11 Seems to indicate that there is something wrong with my SSL/TLS connection. But my JNDIRealm still works ! Users can still authenticate successfully. Does the connection fallback to port 389 if a connection on 636 is not possible? Thanks for the help, Shane ! If you have any further suggestions, I would really appreciate it ! Regards, pascal chong Shane Linley wrote: Hi, Knowledge on configuring JNDIRealms security: zip! Knowledge on the JNDI LDAP interface: guru! The root cause: javax.naming.CommunicationException, refers to there being an underlying network problem with communicating between the LDAP client, and the LDAP server. The message received from the ldap driver: Request: 1 cancelled is the reason as to why this error occured. As can be seen its not very helpful. (I've been spoilt on receiving error codes from servers and detailed messages and such). You appear to be using the Sun JNDI LDAP reference implementation, which I found to not always offer the best error messages. I cant remember if it has any extra logging capabilities (from memory it doesn't) to try and wring more information out of the driver, however the key to solving the problem may lie elsewhere. I would recommended turning on the detailed debugging in your LDAP server to determine what error it is trying to communicate back to the LDAP driver (and if the server is successfully contacted in this first instance), by of course inspecting its logs. This approach I have had to use a number of times on less than helpful LDAP drivers that don't seem to think good error messages are needed. You are trying to use a secure SSL connection to the LDAP server, but it does not appear to be SSL related as you normally get a specific SSL error back when it is SSL related, usually ugly and unhelpful. Regards, Shane. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDIRealm strangeness
Hi Shane ! Thanks for your help! After experimenting over the weekend, I think that this is probably a bug in the Tomcat code. I checked and corrected some problems in my OpenLDAP setup, and verified that SSL/TLS connections can be made successfully to it using ldapsearch. When I tried starting up Tomcat again, it gave me the same error. I think Tomcat may not be able to establish an encrypted connection to OpenLDAP. Unencrypted connections on port 389 seem to be ok. Incidentally, I'm also anal retentive (that, I am told, is a national characteristic of my country), and I tried ldaps://, but Tomcat will throw a parse error and will not accept the JNDI Realm parameters. They may have fixed it in the just-released 5.0.24, though. Thanks for your help, again ! I'm not on any specific timetable, so I don't need to fix this soon. I'll direct my question to the Tomcat developers and see if they are aware of the issue. Regards, pascal chong Shane Linley wrote: Hi, What happens on failed connections IS driver specific, but it should NOT BY DEFAULT switch to using a non SSL connection, for the sake of security if nothing else. The connection should tried to be established, if it fails then it should send back the appropriate naming exception. That said drivers do accept configuration properties to modify their behaviour, so technically anything is possible, based on your drivers documentation. I have never used OpenLDAP so its error logs don't really mean all that much to me, but having done similar things in the past you should look up your error codes in the OpenLDAP documentation (but its probably the OpenSSL doco) as to what the error codes really mean to work out what the problem is. I'm referring specifically to this line (as id does match up to the Request: 1 cancelled) message that the LDAP client driver reports. May 7 20:03:56 localhost slapd[6346]: connection_read(11): TLS accept error error=-1 id=0, closing Thats all I have! Good luck. Regards, Shane. P.S. The anal retentive part of me still wants you to specify the ldap connection as ldaps://server:636 but that is completely besides the point! :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JNDIRealm strangeness
Hi All ! I wonder if anyone has seen this anomaly, when following my instructions on setting up a JNDIRealm, on my website (http://cymulacrum.net/writings/adv_tomcat/c487.html). I wrote these instructions after version 5.0.19 of Tomcat came out and fixed the character encoding issue in the JNDIRealm. In my document I described how to : 1. Setup OpenLDAP so it runs with SSL/TLS enabled 2. Setup Tomcat's JNDIRealm so that it communicates with ldap://localhost:636, the secure port instead of 389. I never noticed anything strange, because my JNDIRealm setup seemed to work fine, but when I tried to put SecurityFilter on, I found an error. Thinking that it was probably SecurityFilter, I looked at the logfiles, and I was surprised to find that, even before I had installed SecurityFilter, there was that same error being logged inside catalina.out. I just never bothered to look before because everything seemed to be running fine. Here's what the error looks like. It only occurs on startup, all LDAP operations work fine with no errors: JNDIRealm[Catalina]: Connecting to URL ldap://localhost:636 JNDIRealm[Catalina]: Exception performing authentication javax.naming.CommunicationException: Request: 1 cancelled at com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:76) at com.sun.jndi.ldap.Connection.readReply(Connection.java:433) at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:356) at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:187) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2615) at com.sun.jndi.ldap.LdapCtx.init(LdapCtx.java:293) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:190) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:208) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:674) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:256) at javax.naming.InitialContext.init(InitialContext.java:232) at javax.naming.InitialContext.init(InitialContext.java:208) rest of errors snipped I'm not really sure where to begin, or even if it is significant (since LDAP authentication still works). If you want to repeat this error for yourself, you can follow the instructions on my web page. Any help would be greatly appreciated ! Regards, pascal chong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JNDIRealm strangeness
Hi, Knowledge on configuring JNDIRealms security: zip! Knowledge on the JNDI LDAP interface: guru! The root cause: javax.naming.CommunicationException, refers to there being an underlying network problem with communicating between the LDAP client, and the LDAP server. The message received from the ldap driver: Request: 1 cancelled is the reason as to why this error occured. As can be seen its not very helpful. (I've been spoilt on receiving error codes from servers and detailed messages and such). You appear to be using the Sun JNDI LDAP reference implementation, which I found to not always offer the best error messages. I cant remember if it has any extra logging capabilities (from memory it doesn't) to try and wring more information out of the driver, however the key to solving the problem may lie elsewhere. I would recommended turning on the detailed debugging in your LDAP server to determine what error it is trying to communicate back to the LDAP driver (and if the server is successfully contacted in this first instance), by of course inspecting its logs. This approach I have had to use a number of times on less than helpful LDAP drivers that don't seem to think good error messages are needed. You are trying to use a secure SSL connection to the LDAP server, but it does not appear to be SSL related as you normally get a specific SSL error back when it is SSL related, usually ugly and unhelpful. Regards, Shane. -Original Message- From: Chong Yu Meng [mailto:[EMAIL PROTECTED] Sent: Friday, 7 May 2004 4:32 PM To: Tomcat Users List Subject: JNDIRealm strangeness Hi All ! I wonder if anyone has seen this anomaly, when following my instructions on setting up a JNDIRealm, on my website (http://cymulacrum.net/writings/adv_tomcat/c487.html). I wrote these instructions after version 5.0.19 of Tomcat came out and fixed the character encoding issue in the JNDIRealm. In my document I described how to : 1. Setup OpenLDAP so it runs with SSL/TLS enabled 2. Setup Tomcat's JNDIRealm so that it communicates with ldap://localhost:636, the secure port instead of 389. I never noticed anything strange, because my JNDIRealm setup seemed to work fine, but when I tried to put SecurityFilter on, I found an error. Thinking that it was probably SecurityFilter, I looked at the logfiles, and I was surprised to find that, even before I had installed SecurityFilter, there was that same error being logged inside catalina.out. I just never bothered to look before because everything seemed to be running fine. Here's what the error looks like. It only occurs on startup, all LDAP operations work fine with no errors: JNDIRealm[Catalina]: Connecting to URL ldap://localhost:636 JNDIRealm[Catalina]: Exception performing authentication javax.naming.CommunicationException: Request: 1 cancelled at com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:76) at com.sun.jndi.ldap.Connection.readReply(Connection.java:433) at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:356) at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:187) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2615) at com.sun.jndi.ldap.LdapCtx.init(LdapCtx.java:293) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:190) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:208) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:674) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:256) at javax.naming.InitialContext.init(InitialContext.java:232) at javax.naming.InitialContext.init(InitialContext.java:208) rest of errors snipped I'm not really sure where to begin, or even if it is significant (since LDAP authentication still works). If you want to repeat this error for yourself, you can follow the instructions on my web page. Any help would be greatly appreciated ! Regards, pascal chong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDIRealm strangeness
Hi Shane ! Thanks for the description and advice! I managed to finally turn on OpenLDAP logging (a pain in Fedora Core 1), and set the loglevel to 256. Here's what I get. When the Tomcat server starts up, the connection errors seem to be related to port 636 : May 7 19:51:50 localhost slapd[6049]: conn=4 fd=11 ACCEPT from IP=127.0.0.1:32892 (IP=0.0.0.0:636) May 7 19:51:50 localhost slapd[6049]: conn=4 fd=11 closed May 7 19:51:50 localhost slapd[6049]: conn=5 fd=11 ACCEPT from IP=127.0.0.1:32894 (IP=0.0.0.0:389) May 7 19:51:50 localhost slapd[6049]: conn=5 op=0 BIND dn= method=128 May 7 19:51:50 localhost slapd[6049]: conn=5 op=0 RESULT tag=97 err=0 text= May 7 19:52:02 localhost slapd[6049]: conn=6 fd=12 ACCEPT from IP=127.0.0.1:32895 (IP=0.0.0.0:636) May 7 19:52:02 localhost slapd[6049]: conn=6 fd=12 closed May 7 19:52:02 localhost slapd[6049]: conn=7 fd=12 ACCEPT from IP=127.0.0.1:32897 (IP=0.0.0.0:389) May 7 19:52:02 localhost slapd[6049]: conn=7 op=0 BIND dn= method=128 May 7 19:52:02 localhost slapd[6049]: conn=7 op=0 RESULT tag=97 err=0 text= Bumping up loglevel to 4095, I get these details for the errors on port 636: May 7 20:03:56 localhost slapd[6346]: connection_read(11): TLS accept error error=-1 id=0, closing May 7 20:03:56 localhost slapd[6346]: connection_closing: readying conn=0 sd=11 for close May 7 20:03:56 localhost slapd[6346]: connection_close: conn=0 sd=11 Seems to indicate that there is something wrong with my SSL/TLS connection. But my JNDIRealm still works ! Users can still authenticate successfully. Does the connection fallback to port 389 if a connection on 636 is not possible? Thanks for the help, Shane ! If you have any further suggestions, I would really appreciate it ! Regards, pascal chong Shane Linley wrote: Hi, Knowledge on configuring JNDIRealms security: zip! Knowledge on the JNDI LDAP interface: guru! The root cause: javax.naming.CommunicationException, refers to there being an underlying network problem with communicating between the LDAP client, and the LDAP server. The message received from the ldap driver: Request: 1 cancelled is the reason as to why this error occured. As can be seen its not very helpful. (I've been spoilt on receiving error codes from servers and detailed messages and such). You appear to be using the Sun JNDI LDAP reference implementation, which I found to not always offer the best error messages. I cant remember if it has any extra logging capabilities (from memory it doesn't) to try and wring more information out of the driver, however the key to solving the problem may lie elsewhere. I would recommended turning on the detailed debugging in your LDAP server to determine what error it is trying to communicate back to the LDAP driver (and if the server is successfully contacted in this first instance), by of course inspecting its logs. This approach I have had to use a number of times on less than helpful LDAP drivers that don't seem to think good error messages are needed. You are trying to use a secure SSL connection to the LDAP server, but it does not appear to be SSL related as you normally get a specific SSL error back when it is SSL related, usually ugly and unhelpful. Regards, Shane. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
