Share via

WebDAV authentication options

  • Article

Question

Wednesday, February 27, 2008 1:43 PM

I am not sure how WebDAV authentication works: some IIS7 WebDAV setup examples enable Windows Authentication, does that mean that the WebDAV implementation has a layer that maps to this, and users can write their credentials in HTTP, and this will be safe (without HTTPS)? My users are not domain users, they are on the internet, and use Windows and Mac systems.

Conversely, if I don't enable Windows Authentication, is Basic Authentication safe? I mean, is it as plain as in FTP, or does WebDAV use its own protocol on top of HTTP to ensure that the username and password are not exposed?

If based on the above neither Windows Authentication nor Basic Authentication are good to use (which makes me wonder why the examples use Windows Authentication, and don't mention that Basic Authentication is not safe), what should I use? Can I install a different SSL certificate for each WebDAV-enabled domain (same IP, different host name, like webdav.example1.com, webdav.example2.com, etc.)?

 Thanks so much.

All replies (5)

Thursday, February 28, 2008 1:09 PM ✅Answered

Unfortunately your statements about SSL are true - you can't use host headers on a single IP with SSL because the headers are encrypted. You can see the following Microsoft KB article for more on that:

http://support.microsoft.com/kb/187504/

One of the strengths of Digest Authentication is that the username/password is never sent over the wire – only an MD5 hash is passed. But unfortunately that leads to one of the biggest implementation challenges – Digest Authentication requires some method of access to the original username/password in order to create a hash for comparison. Active Directory has an optional field for storing an encrypted version of the original password with user accounts, while local user accounts do not. So unfortunately Digest Authentication cannot work with local user accounts unless Windows Server was re-engineered in order to accommodate this feature.

That said, it would be possible to create an HTTP module for IIS 7 that provides Digest Authentication using some form of user database that contains a username/password list, but that puts the burden of securing those passwords on the developer. (e.g. A flat-file text database is not very secure. ;-] )

Wednesday, February 27, 2008 4:01 PM

WebDAV doesn't actually provide any authentication of its own - IIS7 provides all of the authentication.

As far as which method to use, the following information is from Microsoft KB article 324274:

  • Integrated Windows authentication: Formerly named NTLM or Windows NT Challenge/Response authentication, this method sends user authentication information over the network as a Kerberos ticket, and provides a high level of security. Windows Integrated authentication uses Kerberos version 5 and NTLM authentication. To use this method, clients must use Microsoft Internet Explorer 2.0 or later. Additionally, Windows Integrated authentication is not supported over HTTP proxy connections. This option is best used for an intranet, where both the user and Web server computers are in the same domain, and administrators can make sure that every user is using Internet Explorer 2.0 or later.

    NOTE: If multiple authentication options are selected, IIS tries to negotiate the most secure method first, and then it works down the list of available authentication protocols until a mutual authentication protocol is supported by both client and server.

  • Digest authentication for Windows domain servers: Digest authentication requires a user ID and password, provides a medium level of security, and may be used when you want to grant access to secure information from public networks. This method offers the same functionality as basic authentication. However, this method transmits user credentials across the network as an MD5 hash, or message digest, in which the original user name and password cannot be deciphered from the hash. To use this method, clients must use Microsoft Internet Explorer 5.0 or later, and the Web servers must be a members of the Active Directory domain where the user accounts are stored.

    If you turn on digest authentication, type the realm name in the Realm box.

  • Basic authentication (password is sent in clear text): Basic authentication requires a user ID and password, and provides a low level of security. User credentials are sent in clear text across the network. This format provides a low level of security because the password can be read by almost all protocol analyzers. However, it is compatible with the widest number of Web clients. This option is best used when you want to grant access to information with little or no need for privacy.

    If you turn on basic authentication, type the domain name that you want to use in the Default domain box. You can also optionally enter a value in the Realm box.

Here's a short recap:

  • Windows authentication:
    • Most-secure
    • Doesn't work well over the Internet
    • Requires Internet Explorer as the browser.
  • Digest authentication:
    • Medium-secure
    • Should work with most browsers
    • Requires and Active Directory domain for user accounts
  • Basic authentication:
    • Least-secure
    • Works with all browsers
    • Should always be used over SSL

All that being said, you can use WebDAV over several sites using SSL using your example domains.

Wednesday, February 27, 2008 7:10 PM

Thanks. Your answer about WebDAV not having its own authentication went straight to the point. As this is not a domain system, and I need to support a diversity of clients, I would go for Basic authentication. Does this mean that the WebDAV URL needs to be HTTPS too? I mean, I don't want the whole interaction to pass through the overhead of HTTPS. How does this work, if I provide an URL like http://webdav.example.com, and there is an SSL certificate for the site, will IIS automatically use SSL for authentication, and the rest of WebDAV goes over HTTP? Or do I have to provide https://webdav.example.com in the first place?

And last, in IIS7 I can'f find a way to associate an HTTPS port on a site to a given host name. You can set the certificate, but not the host, so how does this work on different sites? The user goes to https://webdav.example1.com, how does IIS know that, when there are more sites on the same IP? For HTTP you can set the host, but for HTTPS? Does it get the host name from the HTTP binding? Or from the SSL certificate (but then, if you have *.example.com, how does it find it)?

Thank you for your patience. I thought that WebDAV was good and safe and easy and common, and that multiple sites on the same IP was also a common scenario, but I can'f find a step by step on this, which is probably what I would need.

Thursday, February 28, 2008 1:45 AM

 

> > Can I install a different SSL certificate for
> > each WebDAV-enabled domain (same IP, different
> > host name, like webdav.example1.com,
> > webdav.example2.com, etc.)?
> All that being said, you can use WebDAV over
> several sites using SSL using your example domains.

I came to the conclusion that this is not possible, but maybe someone here can correct me. I can install a wildcard SLL certificate like *.example.com, but supporting different WebDAV sites that do not have the same root domain, as in the above example, does not seem to be possible. In general I think multiple certificates used for the same IP are not possible, because the host name is encrypted in the initial handshaking, where only the IP is known.

So, I've come to the conclusion that WebDAV is not as good as I thought. I can't use Windows or Digest Authentication if I need to support non-domain and cross-platform clients, and Simple Authentication seems to be flawed just as badly as in FTP, which I was abandoning for this same reason. I was assuming that WebDAV, being newer than FTP, had its own more robust authentication. But since it needs SSL, I can't even WebDAV-enable multiple sites on one IP! Sure, one could use a wildcard certificate, but then the independence of the domains would be lost. I wanted "true" domains both for browsing and for WebDAV, not secondlevel.example.com.

Maybe the IIS7 Team could implement Digest authentication without needing a domain, i.e. just as an authentication mechanism for WebDAV, that can map to local users? Wouldn't that be a good solution for web servers?

Thursday, February 28, 2008 5:17 PM

Thanks. I reluctantly have a working implementation now, with a wildcard *.example.com certificate, and all www.example1.com, www.example2.com, etc. Clients must use webdav-example1.example.com for WebDAV access, rather than their own domain.

I don't know what to think about the AD requirement for Digest Authentication. My impression is that the IIS7 team is trying to force people to use Active Directory even when it is not strictly required. For example, the new FTP has a beautiful editable field where you could associate a directory to a user. But... this one option needs Active Directory! Why? IIS7 already stores so many options, including options mapped to users (like privileges), so how difficult can it be to also map a custom path to a user without Active Directory? I guess I don't have the vision of what Micrososft is trying to achieve here. If they want to push AD fine, it's understandable, but maybe they risk losing customers on the web hosting side, which is where IIS7 wants to playe? But I guess I am digressing... :-)