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


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to