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]
