Re: Fwd: Re: Tomcat and LDAP Issues
I emailed marek about the CLIENT-CERT problem, still no response. I'm going to look into it and see what the gist of Mario's objections were, and if the patch is good. Good Words ;-) If you have any question do not hesitate to contact me. Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Re: Tomcat and LDAP Issues
Oops forgot about that one. There is a PATCH but the writer says that the bug is really with the JNDI Provider (Netscape) and not tomcat. The patch is a workaround to the Netcape's bug. (But maybe I took those words out of context) Remy - your thoughts on this one? (My pref is WONTFIX since the patch is a workaround a a vendor's buggy code, and I could put a note in the javadocs for JNDIRealm) Since the bug is over a year old, I wonder if Netscape fixed the bug in their code and this bugzilla bug is no longer valid. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11210 -Tim Jeff Tulley wrote: Oh, I was confusing this with bug #11210, also dealing with Netscape. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Re: Tomcat and LDAP Issues
Tim, I've attached the diff file for the defect referenced by Jon on the user list. I was able to (fortunately) duplicate this going against eDirectory on NetWare; this one fix seems to solve bug #19864, and bug #11678 as well (JNDIRealm re-prompting for a password). Actually, the new code was already trying to resolve that defect by doing a retry but had that one NullPointerException throwing a wrench in the works. My only fear in making this change is if THIS method will also work among different providers and Directories. My understanding is that toString() SHOULD contain at least the same thing as toMessage() and more in the case of providers that use toMessage(). That and changing to looking for closed should get both of the types of messages we are aware of (Socket closed and Connection closed). I'll look into the other 7. I've already emailed some of the people who were discussing them, soliciting more input so I can reproduce them. It would be good to get some of those fixed; I did sense some frustration on the users part in some of the bug reports. I've personally seen at least one of them, so I'll start there. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com Tim Funk [EMAIL PROTECTED] 8/2/03 8:08:59 AM Jeff, I see nine bugs out there for JNDIRealm for tomat 4 and 5, included is the one mentioned below in the previous email. http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Tomcat+4product=Tomcat+5short_desc=jndirealmshort_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=Reuse+same+sort+as+last+time I have used JNDIRealm in the past but stopped using it in favor of other solutions for unrelated reasons. Can you do me a favor? If you are able, can you update the bugs above and send me a patch for the stuff below (and any applicable bugs above) and I'll try to get 'em in next week. -Tim Jeff Tulley wrote: Something from the user list of note for development. The current method does something like this when handling a communication exception at authenticate time: / If not a Socket closed. error then rethrow. if (e.getMessage().indexOf(Socket closed) 0) throw(e); This seems to have two problems 1) e.getMessage() is sometimes null with some LDAP providers. 2) some LDAP providers set the exception to actually be connection closed (retrieved by e.toString()) Just forwarding this on for the user, since this code currently has some problems that ought to be fixed. (I have a vested interest being a heavy user of JNDIRealm). For a stopgap measure, one could do the following I guess: if (e.toString().indexOf(closed) 0) throw(e); Though as the bug report points out there may be yet other error messages given by other LDAP providers, and I don't know if closed is too general to check on or not. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/1/03 2:00:46 PM Well, I understand this is now a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19864 Was this fixed in the 4.1.27 version? Can't seem to determine if it was based on the README in the download. Jon On Friday, August 1, 2003, at 12:07 PM, Jon Wynacht wrote: Hi, I have Tomcat 4.1.24 installed on a server that hosts a web application. I have set up the container to do authentication via LDAP and it works for a bit then just stops working. The only way to get things working again is to restart Tomcat. I've included the error message below and am wondering if anybody on this list has had a similar experience? If so, how did you solve it? Thanks in advance, Jon 2003-08-01 10:37:29 JNDIRealm[Standalone]: lookupUser(jwynacht) 2003-08-01 10:37:29 JNDIRealm[Standalone]: dn=uid=jwynacht, ou=active, ou=employees, ou=people, o=cisco.com 2003-08-01 10:37:29 JNDIRealm[Standalone]: validating credentials by binding as the user 2003-08-01 10:37:29 JNDIRealm[Standalone]: binding as uid=jwynacht, ou=active, ou=employees, ou=people, o=cisco.com 2003-08-01 10:37:29 CoyoteAdapter An exception or error occurred in the container during the request processing java.lang.NullPointerException at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:793) at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(Basic Authenticator.java:161) at
Re: Fwd: Re: Tomcat and LDAP Issues
I got eager and saw you bug update yesterday and applied a patch to 4.1 last night. Here's a link to the PATCH email: http://marc.theaimsgroup.com/?l=tomcat-devm=106004487327965w=2 The commit also does a null pointer check on the getMessage() to fix a related bug and also avoids doing the toString(). As for bug 20518 - did this seem right? It seemed like an innocent fix. (But they are the ones that seem to cause the most trouble) IIRC, the only two bugs left I know of is: 1) The CLIENT-CERT one which I wish not to do but rather leave to someone to Extend JNDIRealm. (But if someone else wants to commit it - I won't care) 2) Enhancement request for IPlanet since in a non-user binding the SHA1 check isn't compatible with the way tomcat generates a hash. I have a patch on my own from another project that might fix this. (If I can find the code) AFAIK - All other JNDIRealm bugs are fixed or enhancements. If you can test from 4.1 and give me the OK - I can port the patch to 5. (I know I committed in the wrong order :( , but did it on the hope that the patch had a better chance of being tested) -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Re: Tomcat and LDAP Issues
I just tested it, and the fix seems to work well. At first I thought that your null check would actually cause a problem, in case the exception is something besides a connection(or socket) closed, and the provider chose to not to set the message on the exception. But, I think the fact that the retry is wrapped in yet another try catch block means that life will probably go on. I've been doing all sorts of fun weird things to my LDAP server to try to get other types of exceptions thrown, and it behaves as I would expect with your fix. With defect 20518 -- It does seem innocent, though if the primary LDAP server is down for an extended period of time, you would constantly be trying it first, then the alternate. But, I'm guessing the performance hit is not huge and the fix seems correct beyond that. (IE, to assume the primary is forever gone is a bad idea and it is better to take the potential performance hit). You closed the bug regarding the userSubtree not working I see. I'm not sure but that there are still issues there, and I'm still investigating. I can get it to work if I add the [Public] object as a trustee to any subcontext that I want searched, but this is by no means a standard thing to do since it opens up your user containers to potential security exploits. Most of the exploits involve social engineering; with public access to the names of the users in the container, you can impersonate a user whose name you see and call up and ask a help desk technician to change their password for you. What I'm not sure about is if there is some other acceptable way to grant browse rights to some other object and then have Tomcat go in as that object. If so, then that would need to be documented if it is not already. If that is not possible, then the userSubtree feature is fairly useless since most directory administrators would not take the security risk to make it work. Also, there are other bugs with this feature like the fact that the first level is not searched for users, ONLY the sublevels are. I emailed marek about the CLIENT-CERT problem, still no response. I'm going to look into it and see what the gist of Mario's objections were, and if the patch is good. I know nothing about the iPlanet issue (except for what is in the bug report), so that will be great if you have a fix... Thanks Tim for working on these issues. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/5/03 11:42:43 AM I got eager and saw you bug update yesterday and applied a patch to 4.1 last night. Here's a link to the PATCH email: http://marc.theaimsgroup.com/?l=tomcat-devm=106004487327965w=2 The commit also does a null pointer check on the getMessage() to fix a related bug and also avoids doing the toString(). As for bug 20518 - did this seem right? It seemed like an innocent fix. (But they are the ones that seem to cause the most trouble) IIRC, the only two bugs left I know of is: 1) The CLIENT-CERT one which I wish not to do but rather leave to someone to Extend JNDIRealm. (But if someone else wants to commit it - I won't care) 2) Enhancement request for IPlanet since in a non-user binding the SHA1 check isn't compatible with the way tomcat generates a hash. I have a patch on my own from another project that might fix this. (If I can find the code) AFAIK - All other JNDIRealm bugs are fixed or enhancements. If you can test from 4.1 and give me the OK - I can port the patch to 5. (I know I committed in the wrong order :( , but did it on the hope that the patch had a better chance of being tested) -Tim - 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: Fwd: Re: Tomcat and LDAP Issues
Tim Funk wrote: Oops forgot about that one. There is a PATCH but the writer says that the bug is really with the JNDI Provider (Netscape) and not tomcat. The patch is a workaround to the Netcape's bug. (But maybe I took those words out of context) Remy - your thoughts on this one? (My pref is WONTFIX since the patch is a workaround a a vendor's buggy code, and I could put a note in the javadocs for JNDIRealm) Since the bug is over a year old, I wonder if Netscape fixed the bug in their code and this bugzilla bug is no longer valid. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11210 WONTFIX seems reasonable indeed. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Re: Tomcat and LDAP Issues
in line ... Jeff Tulley wrote: With defect 20518 -- It does seem innocent, though if the primary LDAP server is down for an extended period of time, you would constantly be trying it first, then the alternate. But, I'm guessing the performance hit is not huge and the fix seems correct beyond that. (IE, to assume the primary is forever gone is a bad idea and it is better to take the potential performance hit). That was my thoughts too. You closed the bug regarding the userSubtree not working I see. I'm not sure but that there are still issues there, and I'm still investigating. I can get it to work if I add the [Public] object as a trustee to any subcontext that I want searched, but this is by no means a standard thing to do since it opens up your user containers to potential security exploits. Most of the exploits involve social engineering; with public access to the names of the users in the container, you can impersonate a user whose name you see and call up and ask a help desk technician to change their password for you. What I'm not sure about is if there is some other acceptable way to grant browse rights to some other object and then have Tomcat go in as that object. If so, then that would need to be documented if it is not already. If that is not possible, then the userSubtree feature is fairly useless since most directory administrators would not take the security risk to make it work. Also, there are other bugs with this feature like the fact that the first level is not searched for users, ONLY the sublevels are. From another user's comment, it looked like it was invalid and there didn't seem to be a rebuttal. But I had many windows open at the same time and may have gotten it confused with something else. I emailed marek about the CLIENT-CERT problem, still no response. I'm going to look into it and see what the gist of Mario's objections were, and if the patch is good. ok I know nothing about the iPlanet issue (except for what is in the bug report), so that will be great if you have a fix... When pulling the password back - it is SHA1 encrypted. When tomcats digests the browser provided password - it returns the SHA1 in an incompatible manner. (HEX vs BASE64 IIRC) So the solution here will probably be to add a flag on how to perform SHA1 password checks. (Or similar) -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Re: Tomcat and LDAP Issues
From another user's comment, it looked like it was invalid and there didn't seem to be a rebuttal. But I had many windows open at the same time and may have gotten it confused with something else. Yeah, somebody was nitpicking the snippet of server.xml that he had there, where the thing they were nitpicking was really just a typo in the bug report. I have indeed seen this issue and for a while was frustrated with the userSubtree functionality. Like I say, it is a rights issue, and it may have to still be dealt with in some way or another. It might result in a fundamentally different way of doing the search in JNDIRealm than the current code. I don't know, I'll investigate when I get some time. I know nothing about the iPlanet issue (except for what is in the bug report), so that will be great if you have a fix... When pulling the password back - it is SHA1 encrypted. When tomcats digests the browser provided password - it returns the SHA1 in an incompatible manner. (HEX vs BASE64 IIRC) So the solution here will probably be to add a flag on how to perform SHA1 password checks. (Or similar) Oh, I was confusing this with bug #11210, also dealing with Netscape. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Re: Tomcat and LDAP Issues
Jeff, I see nine bugs out there for JNDIRealm for tomat 4 and 5, included is the one mentioned below in the previous email. http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Tomcat+4product=Tomcat+5short_desc=jndirealmshort_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=Reuse+same+sort+as+last+time I have used JNDIRealm in the past but stopped using it in favor of other solutions for unrelated reasons. Can you do me a favor? If you are able, can you update the bugs above and send me a patch for the stuff below (and any applicable bugs above) and I'll try to get 'em in next week. -Tim Jeff Tulley wrote: Something from the user list of note for development. The current method does something like this when handling a communication exception at authenticate time: / If not a Socket closed. error then rethrow. if (e.getMessage().indexOf(Socket closed) 0) throw(e); This seems to have two problems 1) e.getMessage() is sometimes null with some LDAP providers. 2) some LDAP providers set the exception to actually be connection closed (retrieved by e.toString()) Just forwarding this on for the user, since this code currently has some problems that ought to be fixed. (I have a vested interest being a heavy user of JNDIRealm). For a stopgap measure, one could do the following I guess: if (e.toString().indexOf(closed) 0) throw(e); Though as the bug report points out there may be yet other error messages given by other LDAP providers, and I don't know if closed is too general to check on or not. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/1/03 2:00:46 PM Well, I understand this is now a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19864 Was this fixed in the 4.1.27 version? Can't seem to determine if it was based on the README in the download. Jon On Friday, August 1, 2003, at 12:07 PM, Jon Wynacht wrote: Hi, I have Tomcat 4.1.24 installed on a server that hosts a web application. I have set up the container to do authentication via LDAP and it works for a bit then just stops working. The only way to get things working again is to restart Tomcat. I've included the error message below and am wondering if anybody on this list has had a similar experience? If so, how did you solve it? Thanks in advance, Jon 2003-08-01 10:37:29 JNDIRealm[Standalone]: lookupUser(jwynacht) 2003-08-01 10:37:29 JNDIRealm[Standalone]: dn=uid=jwynacht, ou=active, ou=employees, ou=people, o=cisco.com 2003-08-01 10:37:29 JNDIRealm[Standalone]: validating credentials by binding as the user 2003-08-01 10:37:29 JNDIRealm[Standalone]: binding as uid=jwynacht, ou=active, ou=employees, ou=people, o=cisco.com 2003-08-01 10:37:29 CoyoteAdapter An exception or error occurred in the container during the request processing java.lang.NullPointerException at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:793) at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(Basic Authenticator.java:161) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticato rBase.java:526) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:24 15) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav a:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherV alve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav a:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve .java:174) at
Fwd: Re: Tomcat and LDAP Issues
Something from the user list of note for development. The current method does something like this when handling a communication exception at authenticate time: / If not a Socket closed. error then rethrow. if (e.getMessage().indexOf(Socket closed) 0) throw(e); This seems to have two problems 1) e.getMessage() is sometimes null with some LDAP providers. 2) some LDAP providers set the exception to actually be connection closed (retrieved by e.toString()) Just forwarding this on for the user, since this code currently has some problems that ought to be fixed. (I have a vested interest being a heavy user of JNDIRealm). For a stopgap measure, one could do the following I guess: if (e.toString().indexOf(closed) 0) throw(e); Though as the bug report points out there may be yet other error messages given by other LDAP providers, and I don't know if closed is too general to check on or not. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/1/03 2:00:46 PM Well, I understand this is now a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19864 Was this fixed in the 4.1.27 version? Can't seem to determine if it was based on the README in the download. Jon On Friday, August 1, 2003, at 12:07 PM, Jon Wynacht wrote: Hi, I have Tomcat 4.1.24 installed on a server that hosts a web application. I have set up the container to do authentication via LDAP and it works for a bit then just stops working. The only way to get things working again is to restart Tomcat. I've included the error message below and am wondering if anybody on this list has had a similar experience? If so, how did you solve it? Thanks in advance, Jon 2003-08-01 10:37:29 JNDIRealm[Standalone]: lookupUser(jwynacht) 2003-08-01 10:37:29 JNDIRealm[Standalone]: dn=uid=jwynacht, ou=active, ou=employees, ou=people, o=cisco.com 2003-08-01 10:37:29 JNDIRealm[Standalone]: validating credentials by binding as the user 2003-08-01 10:37:29 JNDIRealm[Standalone]: binding as uid=jwynacht, ou=active, ou=employees, ou=people, o=cisco.com 2003-08-01 10:37:29 CoyoteAdapter An exception or error occurred in the container during the request processing java.lang.NullPointerException at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:793) at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(Basic Authenticator.java:161) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticato rBase.java:526) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:24 15) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav a:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherV alve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav a:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve .java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:5 94) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process Connection(Http11Protocol.java:392) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:5 65) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPoo l.java:619) at java.lang.Thread.run(Thread.java:536) - To unsubscribe, e-mail: [EMAIL PROTECTED] For
