December, 2010

December, 2010

  • Care, Share and Grow!

    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

    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"/>


    • 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.


  • Care, Share and Grow!

    Backing up ASP.Net configuration files


    Recently I authored a fast publish KB article on backing up configuration files for ASP.Net on IIS 6/7.

    If you would like PSS to write on more topics that may interest you please put up your suggestions.


  • Care, Share and Grow!

    CRL checking by IIS


    ·         When a Client certificate is presented to an IIS website, IIS looks for the CRL verification to determine the validity of the certificate, much in a similar way a browser does the CRL checking for an SSL enabled website. When IIS receives the client cert it looks into the CDP (CRL Distribution point) under the details tab of the client cert. It then uses one of the HTTP/LDAP links listed there to download the CRL on the server. This link will basically be pointing to one of the CDP servers hosted by the CA. IIS uses this link to download the CRL for future verification purpose. This is overall what IIS does. Obviously internally it is making calls to Crypto Subsystem for all these activities.

    When does IIS kick off a new download of a CRL? Does it look at the Next Update field within the CRL and then keep a log (somewhere on IIS or registry) on when it requires to download the next CRL from the CA?


    To answer the above question in specific it depends upon various settings/scenarios as described below.

    IIS by default looks into the downloaded CRL for the next update field. This is stored in its own memory cache and also physically in the server under either

    %windir%\System32\config\systemprofile\Application Data\Microsoft\CryptnetUrlCache\MetaData (on Win2k3 server), or

    %windir%\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData (on Win2k8)

    You can find the cached CRLs using this command as well Certutil –urlcache CRL at a command-line prompt.

    If the current date is well behind the ‘Next Update’ field value it will use the current CRL to validate the client certificates.

    CRL verification depends upon the metabase properties (IIS 6.0) like CertCheckMode, RevocationFreshnessTime and RevocationURLRetrievalTimeout.

    1. If CertCheckMode is set to 0, IIS does the CRL verification based on the cached CRL on the server (based on its properties like current date and ‘Next Update’ field).

    If the current date is in the range of ‘Effective Date’ and ‘Next Update’ fields it will use the local CRL cache. If the current date is beyond ‘Next Update’ field it will try downloading the CRL from the remote location and use it.

    2. If CertCheckMode is set to 1 Certificate revocation checking is not performed.

    3. If CertCheckMode is set to 2 Certificate revocation verification will be done based on the cached CRL on the IIS server. IIS will not try to connect to the remote server to download the CRL even if it has expired and in which case CRL verification will obviously fail.

    4. If CertCheckMode is set to 4 Certificate revocation verification will be done by downloading the remote CRL, even if we have the valid cached CRL on the server. It ignores the cached CRL completely.

    The frequency with which we download the remote CRL depends upon the value of the metabase property called RevocationFreshnessTime.

    If this property is set to 1 (true) then the CRL on the server is updated from the remote location (even though local cached CRL is valid) every 1 day by default. If the metabase property RevocationFreshnessTime is set to a higher value (instead of 1) IIS uses its value directly to look for the frequency with which CRL is updated. Remember the value defines the time interval in seconds.

    This default timeout interval for updating the CRL is controlled by another metabase property called RevocationURLRetrievalTimeout. This defines the timeout interval in milliseconds. You can increase this value if you think there might be some latency in downloading the CRL from the remote server.

              When you are dealing with the 4th option above ensure you check this link in case you are getting this same issue.      

    Hopefully the above explanation gives you an idea as to how and when IIS asks the Crypto subsystem to retrieve a copy of the CRL. This is finally done by Schannel during TLS negotiation.

    In IIS 7+ you can use netsh commands to set different values for CRL verification (Equivalent to setting CertCheckMode in IIS 6.0). Refer to this and this for details.



Page 1 of 1 (3 items)