Partager via


Anonymous PUT in WebDAV on IIS 7+ deprecated

I have been seeing this question being put up on lot many forums plus we are getting a lot of support cases opened by customers requesting for this feature.

In IIS 7+ we have changed the feature of allowing PUT, MKCOL, PROPPATCH, COPY, MOVE, and DELETE to require authentication. Anonymous PROPFINDs are allowed for file listings, but others require the request be authenticated. This was done as a security measure. In IIS 6.0 we did have the provision of using the above methods using anonymous requests from the clients but not anymore. I think the reason people still want this feature in IIS 7 is because of some 3rd party applications like CURL etc which send Anonymous PUT requests to a WebDAV site.

Lot of people who have migrated from IIS 6.0 to IIS 7+ still request for this functionality. Please note that this is neither recommended nor supported by Microsoft Product Support Services (PSS).

Here, however I will show you a method of achieving a similar feature without users requiring to send user credentials for WebDAV requests. Basically the WebDAV module checks whether the request is authenticated or not. If not (i.e. using Anonymous authentication) WebDAV module will respond saying “Anonymous access not allowed” in the FREB logs.

 

There is a KB article which talks about this as well https://support.microsoft.com/kb/2021641/en-us

So one way of hacking this is to convince WebDAV module that your request is authenticated. So before the WebDAV module gets a chance to handle the request ensure we change the identity context as an authenticated user. In IIS 7 we can write a native ISAPI filter (preferred for performance reasons) or a managed HTTP Module which can intercept the request and change the user context to some pre-configured windows identity. Or else you can read a username/password from a configuration file (or hard code the vale) and then create a basic Base64 hash for the combination and add it to the Request header collection. This in my opinion is a neater way than the first method.

Here are the steps for injecting Basic Base64 hash in the Request header collection:

  • Create a custom HTTP Module (attached with the post) and on Application_BeginRequest read the username/password (either a local or a domain user credential, your choice). Here in the sample I have hardcoded these values but you can read it from a configuration file or by some other means. After we have the username and the password, we concatenate the strings separated by a colon (:), and then compute the Base64 hash for this string and then add a custom HTTP header (“Authorization”) to the incoming request with this Base64 value. The processing in the remaining pipeline thinks that the end user has sent a Basic authentication credential whereas our module is adding this in the BeginRequest event.
  • Compile the Http Module and copy the dll in to the bin folder under your WebDAV site in IIs 7.
  • Ensure that the custom HTTP Module is invoked before the WebDAV module. WebDAV module thinks that the request is authenticated and hence allows operations like PUT/DELETE etc.
  • In the Web.config file under your WebDAV site, add the following:

<modules runManagedModulesForWebDavRequests="true">

<add name="CustomBasicWebDAVModule" type="CustomBasicWebDAVModule"/>

</modules>

  • Ensure that we have added the following attribute runManagedModulesForWebDavRequests="true" to the Modules section as shown above.
  • Last but not least enable only Basic authentication for your WebDAV site (Don’t worry user/client won’t be required to pass in any credentials).

Now go ahead and you should be able to use PUT/DELETE etc verbs for the WebDAV requests for this site anonymously (well, not technically correct though).

Thanks to Robert for the valuable suggestion on this forum and the inputs.

**PLEASE NOTE THAT THIS IS NEITHER RECOMMENDED NOR SUPPORTED BY MICROSOFT PSS. USE IT WITH CAUTION.

HTTP Module class.txt

Comments

  • Anonymous
    January 05, 2011
    Ensure you have the .Net Extensibility feature installed for IIS to allow custom modules.

  • Anonymous
    January 12, 2011
    how do you ensure that the custom http module is invoked before the webdav module? When i try to reorder it on my site, it tells me that the entries can not be reordered because they are locked by the parent.  Do i need to sign the custom module, gac it and add it at the server level?

  • Anonymous
    January 12, 2011
    I would suggest not to worry about ordering and try and see if it works for you or not. Since the module is configured to start on Application_BeginRequest it should get invoked prior to WebDAV module. You can capture a FREB log to verify this if required. You don't have to really sign/gac it etc. You can run it from the bin folder under your website.

  • Anonymous
    March 24, 2011
    I create an ISAPI to add the request header, but it doesn't work, why? And the virtual directory check Anonymous/Basic authentication.

  • Anonymous
    March 24, 2011
    pany2008: Please do not enable Anonymous Authentication, just keep Basic authentication enabled.

  • Anonymous
    October 24, 2011
    Thanks alot your article is really helpfull

  • Anonymous
    November 22, 2011
    I done all this but it still require user name and password when opening the file. any suggest

  • Anonymous
    March 14, 2013
    Solution: artisticcheese.blogspot.ru/.../using-urlrewrite-in-curcumvential.html

  • Anonymous
    July 25, 2014
    Thank you for your useful article. But I didn't understand why anonymous authentication has been unsupported in IIS 7+. Consider this sernario. Suppose that there is a web application and users that sing in to that web application, need to access documents or files via WebDAV. Preferably they should not be asked about their credentials agian. They should be authenticated transparently. This goal could be achived by anonymous access and handling authentication in that web application, but now it can not be implemented normally and a workaround should used as you described in your article.