Windows XP and Apache WebDAV

WebDAV is an easy way to upload files through the services of a webserver - no FTP-program needed. Windows 95 and Windows 2000 made it even easier by enabling it's users to simply use the "Windows Explorer" and it's "Webfolder"-function. Unfortunately some of that simplicity is gone in Win XP.

The problem
Solutions on the client-side
1. Adding a port number to the webfolder-address
2. Adding a number-sign ("#") to the webfolder-address
3. Force Windows XP to use Basic Authentication
Solutions on the server-side
1. Using the Apache module mod_encoding.so
2. Using the Apache module "Mod_Auth_MSFix"
3. Using an SSL-encrypted webfolder
Summary
Comments
Add a comment

The screenshots come from my Windows XP-version so the language is german. I hope you can make some sense out of it anyway.

If you try to add a webfolder through "Windows Explorer - Network - My Network Places" you will be asked over and over for your username and password - although it is correct it won't be accepted.

As you may see in the image above, Windows XP tries to authenticate in the format "domain\username". But Apache accepts only "username" and password.

Another hint is given by the authentication window itself: By default, Windows XP uses the new "Microsoft-WebDAV-MiniRedir/5.1.2600" mechanism which presents the following window:

Other Windows Versions, f.i. Windows 2000 use the "Microsoft Data Access Internet Publishing Provider DAV 1.1" which works with webfolders/Apache WebDAV without any problems. This mechanism shows that kind of window:

If you look at the apache log file "access.log", you find the following entry for the wrong authentication by "Microsoft-WebDAV-MiniRedir/5.1.2600":

OPTIONS / HTTP/1.1" 200 - "-" "Microsoft-WebDAV-MiniRedir/5.1.2600
PROPFIND /dav HTTP/1.1" 401 409 "-" "Microsoft-WebDAV-MiniRedir/5.1.2600

There is no entry in the "error.log"-file, which can only mean that Windows XP made no attempt to authenticate.

So the following solutions seem to be possible:

My configuration is the following:

On the client side: Windows XP Professional, SP2; Office 2000.
On the server side: Debian GNU/Linux "Woody", Apache 1.3.26, libapache-mod-dav (1.0.3-3.1)

I will now describe the solutions I found in the web to fix the problem at the client and at the server side. Of course there maybe more and better solutions, and maybe I did some things wrong. Please use the form-window at the end of this page to add ideas and corrections.

Peter Clark describes in his weblog the trick to attach the port-number (80 by default) to the http-address you enter into the field of the "My Network Places"-assistant. As you can see in the following image and the linked screenshot, this will force Windows XP to use the "Microsoft Data Access Internet Publishing Provider DAV 1.1" mechanism instead of "Microsoft-WebDAV-MiniRedir/5.1.2600".

As one of Peter Clarks weblog guests noted, it is also possible to add the number sign # to the http-address you enter into the field of the "My Network Places"-assistant. As you can see in the following image and the linked screenshot, this will also force Windows XP to use the "Microsoft Data Access Internet Publishing Provider DAV 1.1" mechanism instead of "Microsoft-WebDAV-MiniRedir/5.1.2600".

There is a third way to get this working from the client-site. As described in the Microsoft Knowledge Base, Article ID: 841215, Windows XP disables "Basic Auth" in his "Microsoft-WebDAV-MiniRedir/5.1.2600"-mechanism by default for security reasons. Because the Apache Auth-Mechanism depends on "Basic Auth" we need to enable it on the client. This can be done in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters

This forces "Microsoft-WebDAV-MiniRedir/5.1.2600" to use the "basic auth"-mechanism to connect to the Apache-server.

Security issues: In a comment to my website here, Ian Griffiths critically remarks that using "basic auth" may be a security risk. Please read his comment further down in this document.

Unfortunately editing the registry won't work for people without admin-rights on their clients. So as webadmin I looked for solutions on the server-side.

The California Institute of Technology and the Apple-Forum macosxhints recommend to use the apache module "mod_encoding.so" (which can be found here) together with the module "mod_headers.so" to solve the problem. Both sites describe the procedure in detail so it isn't necessary to add a third page about it.

Just some hints for fellow Debian GNU/Linux -users:

It's also worth to mention, that the "mod_encoding" tar-file already includes the necessary library "iconv_hook" in a subdirectory - you should "make" and "make install" this library first.

Unfortunately this all didn't work for me - the XP-behavior didn't change at all for still unknown reasons.

The second possibility to solve the problem on the server-side is a module that seemed to be written exactly for this purpose: "Mod_Auth_MSFix" which can be found here or here on my server. Although written for Apache 2 the module can also be compiled for Apache 1.3 by using one of the modified c-files which can be found on the same site.

A working binary module for Debian Woody and Apache 1.3.26 can be found here (Version 0.2.1 by Charles Gentry, ported to the Apache 1.3 API by Michail Bachmann). It must be copied into the "usr/lib/apache/1.3" directory and enabled in httpd.conf.

The "Mod_Auth_MSFix" module re-writes the HTTP Basic authorization header that comes from Microsoft's Webdav clients. It is enabled in Apache's httpd.conf inside an 'AuthType BASIC' directory or location:

If someone accesses the directory the module will check the client's header against a pattern (Microsoft / not Microsoft). If it matches a Microsoft WebDav client it will rewrite the "domain\username" authentication to "username".

At least that's the theory. I installed it, but it didn't correct the XP-behavior when adding a webfolder from "Windows Explorer - Network - My Network Places".

After rethinking the problem, it seems obvious why the module can't succeed: The "Microsoft-WebDAV-MiniRedir/5.1.2600" won't even try to send the username and the password - because the basic authentication that apache requests is disabled by default in Windows XP SP2 (see the MS paper above). So when there is no HTTP Basic authorization header that comes from the Microsoft's Webdav client the module can't correct it.

"Mod_Auth_MSFix" proved nevertheless useful for correcting the authentication from Internet Explorer - this browser also uses the format "domain\user". Its correction may help some inexperienced IE users ;-).

The California Institute of Technology also suggests to use "https" for accessing the webfolder.

This also seems to force Windows XP to use the "Microsoft Data Access Internet Publishing Provider DAV 1.1" mechanism. I personally don't use this because my server is an old 486SX and it wouldn't be a good idea to encrypt all communications to the webfolder with that processor.

Summary

With the adding of the number-sign "#" there is a simple way to work around XP's authentication problems on the client-side. On the server-side there seems to be no easy solution yet (although Mod_Auth_MSFix may help IE users).

The logical solution on the server side would be an Apache auth-module which understands the handshake of Windows XPs "Microsoft-WebDAV-MiniRedir/5.1.2600". As long as that's not available, admins may tell their webfolder-users the trick with the "#"-sign.

Hope this helps.
Ulrich Hansen, 01.05.2005

The following comments were added to this article (newest first):

Have spent with this issue the whole day. Wonderful! ;-)



What did not work for me:
=========================

- Mod_Auth_MSFix - was not able to make it loaded into Apache 2.2

- mod_encoding.so - - was not able to make it loaded into Apache 2.2

(loading of both modules ended with "Syntax error on line 132 of C:/Program Files/Apache Software Foundation/Apache2.2/conf/httpd.conf: Cannot load C:/Program Files/Apache Software Foundation/Apache2.2/modules/mod_encoding.so into server: The specified module could not be found." - of course the modules WERE in the directory. Strange.)

- playing with ports i.e. adding :80 into URL

- playing with "#" character i.e. adding of slash to the end of the URL


What *DID* work for me:
========================

- As Marco, I managed to connect mixing a couple of client side solutions :
first created the registry key as of http://ulihansen.kicks-ass.net/aero/webdav/ ( mentioned earlier in this thread ), rebooted windows and added user@domain.com with htpasswd.

(Having Windows XP SP2, Apache 2.2)

Thanks for all the comments & many thanks to Ulrich for this very helpful site.

Regards,

Tomas

You say that the registry change tells the WebDAV redirector to use what you describe as:

"the correct "basic auth"-mechanism"

That seems like a misleading statement. The Microsoft client is in fact correct not to use basic auth here. The WebDAV spec is quite clear about this. Section 17.1 says:

"Basic authentication MUST NOT be used to authenticate a WebDAV client to a server unless the connection is secure"

So to describe basic auth as "the correct" mechanism is wrong. It would be more accurate to say this:

"Unlike the vast majority of WebDAV clients, Microsoft's WebDAV-MiniRedir pays attention to the part of the WebDAV spec which mandates that WebDAV clients must not use basic authentication unless there is good reason to believe that the connection is secure.

By default, the redirector presumes that plain HTTP communications are not secure, and so it takes the sensible precaution of refusing to send your credentials in the clear. This registry setting overrides this behaviour - you are in effect declaring that for some reason you believe the connection to be secure despite the fact that it's not using encryption, and you are happy for your username and password to be sent in unencrypted form, i.e. with basic authentication."

The WebDAV-MiniRedir client is not only behaving exactly as the spec says it should, it's making sure it doesn't compromise your credentials unless you explicitly tell it that this is what you want. So it seems pretty harsh of you to say that it's not using the correct mechanism!

I think it would also be good to clarify that by setting this registry flag, you are compromising your credentials - this arranges for them to be sent in the clear.

In general basic auth is a bad idea over unencrypted links. That's why WebDAV says not to use it. (I wish the SVN team understood this... They go out of their way to send domain credentials over basic auth if you use SVN with windows authentication - unbelievable!)

Ian

I stumbeled upon this thread while researching possibilities for using webdav with these criteria:
- Mounted as a drive letter
- XP SP2
- no extra software installed (nor registry hacks)

The registry hack above worked, but there is another possibility: enable Digest authentication.
Example

My final solution included:
- Digest authentication
- Using usernames with an ampersand user@domain style

My first findings, it works... but can someone tell me how I can get rid of these delays upon (re)opening?

have it all up and running. went through all the usual authentication issues. leaving one small issue. the folder i am currently browsing seems to echo itself. so for example, if the folder is called WebDAV, when i opnen it it contains a folder called WebDAV. clicking into this folder, just points to the same location with a folder called WebDAV again. you can click into these folder echos inifintely. then to get back you have to go back through each folder as if it were a real folder. very annoying!! anyone know how to get ridds of this?

I tried everything on this page to get XP to work with webdav/apache2.0, none works for me. The # and :80 trick both return "The folder does not appear to be valid", I've tried formatting it in every possible way, using IP, using host, using host.domain, trailing slash, none are accepted as valid. I tried the registry edit and it made no difference. This is a fresh XPpro SP2 install.

None of these methods worked for mounting the webdav as a drive letter.

I had to add PROPFIND to the LimitExcept, and then it worked like a charm


DAV On
AuthType Basic
AuthName "WebDAV 2Question Restricted"
AuthUserFile /path/to/.DAVlogin

Require user webdav

As luluware seems in fact to be down, here you find mod_auth_msfix.tar as source. I repacked it from my own install-diretory. Beneath the Apache 2-module I also included the sources of the backported version for Apache 1.3. This is legal, as the author, Charles Gentry, released the whole module under the GPL.

I just discovered that windows won't mount the root (eg http://webdav.example.com/) as it thinks it's a windows share and looks for some special files (such as _vti_inf.html, _vti_bin etc) as an index of "shares". If it doesn't find those, it claims the folder is invalid. You have to make it webdav.example.com/dav or something, which then gets you to the classic digest authentication issues mentioned on this page, which I'm now trying to sort out.

Unfortunatly the server for downloading the Apache 2 module Mod_Auth_MSFix is down since a few days. Does anyone know another source or can anyone share this module, if it's legal?

I am using WinXP "WebClient" Service properly as follows.
"WebClient" Service start -->
"Microsoft-WebDAV-MiniRedir/5.1.2600",
"WebClient" Service stop -->
"Microsoft Data Access Internet Publishing Provider DAV 1.1"

Thanks for these comments and clarifications! Please don't forget this site, if you have additional ideas!

Good luck!
Uli

well i have setup 2 debian sarge apache2 dav servers.
both using auth-mysql to auth webdav users.

one works.
the other one (almost same config) does not. i have gone crazy about that.

differences:
- working server uses: username@email.domain for usernames
(other one has only username format)
- working server has a domain an a virtual host for webdav
(other one is ip based and no ssl)

the cadaver webdav client on debian works with both

and the explanation for all these differences and weirdness is on a single page!

GREAT! :-)

Just some clarifications to some of the earlier points:

- the basic authentication suppression for the WebDAV Mini-Redirector (MRXDAV.SYS) occurred in XP SP2 (KB841215)

- the WebDAV Mini-Redirector (at least with the XP SP2 version 5.1.2600.2180) only handles HTTP resource requests, as was kind of mentioned. Any HTTPS ones are delegated to the Web Folder Client (MSDAIPP.DLL, the Microsoft Data Access... User-Agent talked about earlier). Having an SSL-only server therefore avoids both the registry problem and the need for a domain name (KB315621) - the latter only applies to the Mini-Redirector. This delegation will also occur for *HTTP* resources if the Web Client service is not running (this is what runs the Mini-Redirector).

Hope that's of use. Note that the problem lists at Green Bytes really helped me with this:
Web Folder Client Problems and WebDAV Mini-Redirector ones.

try to create your username with name@domain.com, cause windows don't send the domain

Hi there,

I use an SSL-encrypted folder or rahter: I want to.
Every time I try to connect to it via:
https://someip:443/DAVtest/testserver.php/ in My Network Places it fails.
Telling me that its not a vaild dirrectory.
I use the PEAR HTTP_WebDAV_Server Package to Implement the Server.

Any hints? Thanks for this article, Uli :)

excellent! i've been browsing around for hours and you article sums up about everything i've read sofar. and adds some sense.

BTW, there is a tool to tweek the windows registry to turn on the Basic Authentication in XP. But it's a commercial tool and I won't link it here. And I suspect once Basic Auth is working, you would still need Mod_Auth_MSFix to fix the domain\username style login....

There's another server side option.

The error only occurs if the URL is followed by a directory. For example:
www.somedomain.com/folder
But it works okay if your web folder is the base URL. So use a subdomain for your web folder.
folder.somedomain.com

In your Apache configuration, use a virtual domain for the subdomain, and set DocumentRoot to any folder you like.

Thank you, made my day ! Now it works flawless

I couldn't get WebDAV to work on Apache with the Windows XP Client. The # sign fix did the trick for me. Thank you for your help.

with Windows server 2003 you need:
enable and start the WebClient service
create the UseBasicAuth key
install webfldrs.msi, can be found on XP systems systemroot\system32 (Knowledge Base: 888123)
Restart!!!

Unfortunately there has been massive spamming to this site, so I temporarily disabled commentaries until I find a better solution. Please send me your comments as E-Mail and I will publish them here.

Thanks a lot!
Uli Hansen