Hello, There is a problem in Tomcat (all versions as far as i have tested, up to the 4.X versions) regarding the realm-based authentication on tomcat's side, with Windows XP clients. After several weeks trying to find how to solve this problem, here it is on the bug list.. Basically the problem is that the authentication provided by Tomcat is not working with the Windows XP clients using the windows xp 'Webclient' service as known as Webdav Mini-redirector. I won't explain in details how windows XP works with this Webclient service but here are the two things that are important: 1) In your 'Network Places' folder, try to add a folder with an HTTP url pointing to your favorite webdav servlet protected with BASIC authentication. Configure your tomcat server to provide this servlet on something like : http://host/davservlet It won't work at all because windows tries to authenticate with NTLM. The thing is that windows can't recognize the realm you are using and its type (BASIC). Windows thinks it's NTLM and provides your username like DOMAIN\username (which, obviously, is not your login at all...). 2) Configure your tomcat to provide SSL on port 443. Do the same as before : add your network folder httpS://host/davservlet : it works because another DLL file (the good one ! from microsoft office) is used to connect to it (because HTTPS is not supported by the real mini-redirector). 3) Configure your tomcat to provide HTTP (not HTTPS) acccess on port XXX other than 80. Do the same as before : it works again ! Because this is the same good DLL which is used. You'll say : change the port 80 to something else ! Or juste provide HTTPS which is even better ! I reply : yep, but what if i want to map my webdav access to a network drive ? Windows can handle that.... but not if your port is other than 80, and not if it's HTTPS !! So no solution so far ;(((( This is a well known bug of Tomcat since many versions. Please don't put this bug report INVALID or DECLINED as it affects many people.. I alreay saw this bug being INVALIDATED by a developper around here juste because it worked properly for him. Please try these things about the ports and the HTTPS things and you'll see by yourself that there is a problem. And as you can't change the windows DLL, perhaps on Tomcat's side, something can be done ? Thank you ! Henri
This doesn't surprise me at all. The Webdav Mini-redirector is a complete pain. There was a fix in 6.0.15 that helped a lot for webdav on port 80 for ms clients. I'll take a look at this and see what, if anything, we can do for BASIC authentication.
Hi Mark What happened to this 6.0.15 release ? huge security stuff inside ? As yo u talked about this version, i got the 6.014/6.015/6.016 tags from the SVN and trying to diff all them... From the bug database i can't find the bug fix you are speaking about. Do you have a small idea in which package it was fixed ? Do you think it has been lost in 6.016 ? Thanks Henri
6.0.15 was never voted stable due to issues with cookie parsing. The fix wasn't as a result of a bug. As I recall, there were some issues on the users list and I took a look as a result of that. The webdav fix was in the webdav servlet: http://svn.apache.org/viewvc?view=rev&revision=561186 The fix has not been lost.
I have taken a look at what is going on and there is nothing we can do on the Tomcat side. However, there does appear to be a workaround. Why we can't do anything ======================== I have been using TCPMon to monitor the requests and responses going back and forth. With the MiniRedir the sequence is: 1. PROPFIND -> 401 Unauthorized (as expected) 2. PROPFIND -> 401 Unauthorized (as expected - I don't know why it tries again) 3. OPTIONS ->200 4. PROPFIND -> 401 Unauthorized (as expected) and it prompts for a password Note the password box at this point does not have a "Remember my password" tick box After entering a password, no request is sent to Tomcat. I don't know what MiniRedir is doing at this point but since there is no request to Tomcat, there is nothing we can do. The workarounds =============== 1. If at this first password prompt you click cancel, then OK to the error message, then click next to try and connect again (this needs to be done quickly for some reason) it tries to connect again but this time using the DAV provider (the one that works) and all is well. 2. Alternatively if you specify the port (even if it is 80) when providing the URL the DAV provider is used first time around. The MS client is clearly broken and I am tempted to mark this as INVALID. However, I have an idea I want to try first to see if I can force the use of the DAV provider in all cases.
Created attachment 22093 [details] screenshot of mapping a dav folder Hello Mark I tried your workaround and it works for me also. Btw whenyou try to map a webdav folder in Windows, you can't use any other port than 80 in the URL. You can't even specify a port.
I've created a new Valve that does a redirect with an explicit port if it detects the MiniRedir WebDAV client. The fixes the problem for me and I can use web folders on port 80 without any of the workarounds described above. The Valve has been added to trunk and proposed for 6.0.x. If you want to try it yourself, the commit is: http://svn.apache.org/viewvc?rev=664345&view=rev
I tried the Valve and it's working nice in the webfolder. Thanks! Any idea regarding the drive mapping in windows XP ? Perhaps there is something to do in this way on that..
I've tried a similar trick with mapping drives but this process insists on using the Webdav Mini-redirector. If you can find a way to trick drive mapping into using the other DLL I can probably extend the valve to get the clients to work. I can't see anything else I can do now to work-around this MS bug. MS hosts a regular (annual?) 'How can we help Apache products work better in MS environments' workshop. Hopefully I'll be able to go to the next one and see if we can find a way around this. The down side is that it is about a year away.
This has been applied to 6.0.x and the valve will be in 6.0.17 onwards.