tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <>
Subject Re: Fwd: Re: Tomcat and LDAP Issues
Date Tue, 05 Aug 2003 22:16:44 GMT
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.  

> 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)


View raw message