Using Web DAV with IIS 5.0

Understanding WebDAV in IIS 5.0

Web Distributed Authoring and Versioning, or WebDAV, extends the standard HTTP protocol so that clients can treat web resources like local files. When you install IIS 5.0 on Windows 2000, WebDAV is baked into the core server engine. This means you don’t need to download a separate service or install extra software to start moving files around on the server. The same extension that powers simple HTTP file transfers also brings advanced file‑system operations such as creating directories, deleting files, and locking resources.

Unlike FTP, which requires its own server daemon and offers limited authentication options, WebDAV runs entirely over HTTP. It inherits the authentication and encryption mechanisms already in place for web sites. However, because the protocol is part of HTTP itself, the server can’t turn it on or off with a simple checkbox in the UI. In fact, until Service Pack 3 for IIS 5.0, there was no native way to disable WebDAV once the server was installed. A registry tweak later added the ability to globally disable the feature, but many administrators remained unaware of that option.

Microsoft’s earlier tools for remote website management - such as the FTP service, the Posting Acceptor, FrontPage Server Extensions, and Visual InterDev - each had distinct pros and cons. FTP required a separate service and offered weak security by default. Posting Acceptor allowed file uploads but demanded higher permissions than most users were comfortable with. FrontPage and Visual InterDev let developers push pages to the server but introduced proprietary formats and added administrative complexity. WebDAV tried to bridge these gaps by offering a single, protocol‑based method that works with standard browsers and file‑explorer–like tools.

Because WebDAV sits on top of HTTP, it is supported by a variety of clients beyond IIS. The protocol is defined by RFC‑2518 and maintained by the W3C, so open‑source browsers, file managers, and scripting engines can interact with WebDAV‑enabled servers. The extension is not limited to Microsoft products; you can use the same verbs with non‑Microsoft servers that implement the WebDAV standard.

When a client requests a URL from an IIS 5.0 server using a WebDAV verb (such as PROPFIND or MKCOL), the request is routed internally to the httpext.dll module. That module interprets the verb, performs the necessary file‑system operation, and returns an HTTP status code that reflects the outcome. The server does not rely on file‑extension mappings because WebDAV verbs are part of the request line itself. For example, the request “PROPFIND /images/logo.png” is understood by IIS without looking for a handler mapped to .png. This design choice explains why WebDAV cannot be turned off through the usual web‑site permissions panel.

Because WebDAV is so tightly integrated, administrators who discover it for the first time often find themselves surprised. An email exchange I had with a server owner revealed that he had been trying to locate a switch to disable WebDAV when, in fact, the feature had already been enabled by default. The same conversation made it clear that many users expected to toggle a setting, only to learn that the protocol was always on and only disabled by editing the registry. The registry key introduced in SP3 (HKLM\Software\Microsoft\IIS\WebDAV\Disable) provides the control, but the documentation is buried in a KB article that most people overlook.

In addition to IIS, Microsoft Exchange 2000 also implements WebDAV to allow Outlook clients to store public folder items and mailbox attachments directly on the server. This cross‑product implementation demonstrates the flexibility of the protocol and how it can be leveraged for various file‑based services beyond static web pages.

Overall, WebDAV’s inclusion in IIS 5.0 is a double‑edged sword. On one side it offers a simple, protocol‑based file management system that works with most browsers and file explorers. On the other, its always‑on nature and lack of fine‑grained UI controls can expose administrators to security risks if not properly managed. Understanding the architecture and default behavior of WebDAV is the first step toward using it effectively and safely.

Enabling and Configuring WebDAV

In a default IIS 5.0 installation, WebDAV is already active because the HTTP extensions it relies on are hard‑wired into the core of the server. When you open a URL in Internet Explorer 5.0 or Windows 2000’s My Network Places, the browser automatically treats the resource as a WebDAV folder. This auto‑detection eliminates the need for an installation wizard or a separate service to start moving files around.

However, administrators sometimes wish to fine‑tune which operations are allowed or to turn the feature off entirely. The IIS 5.0 MMC snap‑in provides basic access control through the standard Read, Write, and Execute permissions. For WebDAV, the Write permission is mandatory to create or modify files, while Read is required to fetch existing resources. If you want users to be able to list a directory’s contents, you must also enable Directory Browsing on the site or virtual directory. Without Directory Browsing, even a user with Read rights will see an HTTP error when attempting to enumerate a folder’s items.

Beyond these simple checks, WebDAV offers two advanced server‑side options that appear in the Properties dialog for a web site or virtual directory: “Allow script source access” and “Allow WebDAV methods”. The first option controls the use of the Microsoft‑specific TRANSLATE header, which enables a browser to download the raw source code of a script instead of executing it. When checked, clients can retrieve files like .asp or .aspx by using the script source access flag. Unchecking it prevents this behavior but leaves WebDAV operations like PROPFIND and MKCOL untouched.

The second option, introduced in later service packs, lets administrators disable individual WebDAV verbs for a particular resource. For example, you could disable MKCOL to prevent clients from creating new subdirectories while still allowing them to download files. These settings are stored in the metabase and can be edited through the IIS snap‑in or directly in the registry under HKLM\Software\Microsoft\InetStp\WebDAV. Because these options are rarely documented, many admins remain unaware that they exist.

To disable WebDAV globally, Service Pack 3 for IIS 5.0 added a registry key that turns the protocol off for the entire server: HKLM\Software\Microsoft\IIS\WebDAV\Disable. Setting this DWORD to 1 instructs the server to ignore any WebDAV verbs it receives, returning a generic 400 Bad Request for unsupported methods. This registry change requires a server restart to take effect. While this provides a straightforward solution, administrators must still consider the impact on other applications that rely on WebDAV, such as Exchange or third‑party file‑transfer tools.

Another common configuration tweak is to enable or disable the 207 Multi‑Status error code. When enabled, IIS returns a detailed XML document describing the status of each file involved in a multi‑resource operation like a batch MOVE. Some clients parse this response to provide more informative progress reports. Turning it off simplifies the server’s response but reduces client insight into complex operations.

In practice, most administrators never touch these advanced settings. They rely on the default behavior: WebDAV is enabled, Read and Write permissions are set at the file‑system level, and the site is left to serve files. If you find yourself needing finer control - perhaps to block directory creation or to limit access to specific file types - exploring the metabase options and registry tweaks is a worthwhile exercise. It gives you the ability to shape the user experience without rewriting server code.

WebDAV Commands and Server Mechanics

WebDAV extends HTTP by adding several verbs that map closely to file‑system operations. The most common verbs are PROPFIND, PROPPATCH, MKCOL, and DELETE. PROPFIND asks the server to return properties of a resource - such as its size, modification date, or custom metadata - encoded in an XML document. When a client sends a PROPFIND for a directory, the server returns an XML tree listing each child item and its properties. This is the mechanism behind directory browsing in WebDAV clients.

PROPPATCH allows a client to set or modify properties on a resource. For example, a WebDAV client could apply a custom “author” tag to a file. The server processes the XML payload, updates the underlying metabase entries, and responds with a 207 Multi‑Status indicating which properties were successfully updated.

MKCOL is the verb that creates a new collection - a directory in file‑system terms. When a client issues MKCOL /newfolder/, IIS creates a folder called “newfolder” under the current path. If the folder already exists, the server returns a 405 Method Not Allowed or 409 Conflict, depending on the circumstances. The complementary verb for removing a directory is also called MKCOL in the original RFC, but IIS uses the standard DELETE verb on a directory to perform that action.

DELETE removes a file or collection. The server checks for locks before proceeding; if a file is locked by another client, it replies with a 423 Locked status. To avoid accidental data loss, many WebDAV clients prompt the user when a DELETE operation is requested.

Beyond these CRUD verbs, WebDAV defines LOCK and UNLOCK to provide optimistic concurrency control. When a client wants to edit a file, it can send a LOCK request, which the server records in the metabase with an expiry time. Subsequent operations that attempt to modify the same file will be rejected until the lock expires or is explicitly released with UNLOCK. The server tracks each lock with a unique token that the client must present in future requests.

The HTTP error codes introduced with WebDAV add further clarity. 102 Processing indicates that the server is still working on a request, which is useful for long uploads. 422 Unprocessable Entity signals that the target resource could not be found or processed - an alternative to the older 404 Not Found. 424 Method Failure reports a failure in a sub‑operation within a batch request. 425 Insufficient Space informs the client that the server cannot accommodate the upload due to disk space limits.

All these verbs are handled by the httpext.dll ISAPI extension. Because WebDAV verbs are part of the request line, the server does not route them through the standard handler mapping that IIS uses for file extensions. Instead, the HTTP runtime intercepts any request whose method is one of the WebDAV verbs and passes it directly to httpext.dll. That module performs the requested action, writes a response, and exits. The design keeps WebDAV lightweight and tightly integrated into the HTTP pipeline.

In practice, when you type http://yourserver.com/site/ into Internet Explorer, the browser automatically uses PROPFIND to discover the folder structure. The server returns the XML, and IE renders a list view that looks like Windows Explorer. When you click a file, IE sends a GET request for that file. If the URL points to a script, the script is executed unless the TRANSLATE header is set to fetch the raw source. This subtle distinction allows developers to review server‑side code from a remote location without running it.

Because WebDAV’s verbs are so expressive, many developers use them for remote management scripts. A simple PowerShell script can iterate over a WebDAV folder, download all files, and apply metadata changes via PROPPATCH. The built‑in Windows WebDAV client on newer versions of Windows (Vista and later) also supports these verbs, letting users treat any WebDAV resource as a network drive.

Understanding the verbs and the server’s internal handling clarifies why WebDAV behaves the way it does. It also explains why administrators sometimes see unexpected behavior - such as files not appearing in Explorer when a lock is active - or why certain operations return error codes that differ from traditional HTTP responses.

Security and Permissions in WebDAV

Because WebDAV is a feature of the HTTP stack, the same authentication methods that protect web pages also secure WebDAV resources. When a client attempts a PROPFIND or MKCOL request, the server challenges it for credentials. Windows 2000 supports Basic and Digest authentication, with Digest offering stronger protection by hashing the password before sending it over the network. If you enable SSL, you can also use HTTPS to encrypt the entire conversation, including the verbs and any data payloads.

However, the ability to create, delete, and lock files means that misconfigured permissions can lead to serious security incidents. IIS uses NTFS file‑system permissions to control who can write or read a file, but those permissions are applied only after the authentication phase. If an attacker gains a valid credential - perhaps through phishing or brute force - they can then exploit WebDAV to upload malicious scripts or modify configuration files.

One challenge administrators face is that the “Script Source Access” checkbox in the IIS properties cannot be set per user. It is a global setting that applies to all clients that connect to that site. This limits the ability to allow a trusted developer to read script files while denying other users that capability. Similarly, the inability to disable individual WebDAV verbs at the UI level forces admins to rely on the more opaque registry or metabase settings for fine‑grained control.

Because WebDAV can lock files, it also introduces a concurrency risk. A malicious user could lock a critical configuration file for an extended period, preventing legitimate administrators from editing it. While the LOCK request includes an expiry, an attacker could send repeated LOCK requests to maintain control indefinitely. The server’s response to such abuse is a 423 Locked status, but the attacker can still observe that the lock exists.

To mitigate these risks, administrators should adopt a layered approach. First, enforce strong passwords and enable two‑factor authentication where possible. Second, restrict WebDAV access to a narrow IP range using Windows Firewall or the IIS IP and Domain Restrictions feature. Third, apply the least‑privilege principle on the file system: grant only the minimum NTFS rights necessary for each role. For example, a user who only needs to upload files should have Write permission on the target folder but no permission to delete or modify system files.

Monitoring is another essential component. IIS logs every request, including WebDAV verbs. By parsing these logs, you can detect unusual patterns, such as repeated DELETE or MKCOL requests from a single IP, or a sudden spike in PROPFIND activity. Setting up alerts on these patterns can help you catch potential abuse early.

Finally, consider disabling WebDAV entirely on production servers that do not require it. The registry key mentioned earlier - HKLM\Software\Microsoft\IIS\WebDAV\Disable - provides a quick way to turn the protocol off for the entire server. This removes the attack surface associated with WebDAV verbs, leaving only standard HTTP methods to serve content. If you do need WebDAV on a specific site, isolate it behind a separate virtual directory with its own dedicated metabase configuration, and limit exposure to trusted users.

In sum, WebDAV offers powerful remote file‑management capabilities, but it also brings responsibilities. Proper authentication, strict NTFS permissions, network restrictions, and vigilant monitoring form the backbone of a secure WebDAV deployment.

Client Access and Practical Uses

Windows 2000’s My Network Places provides a simple way to map a WebDAV share to a network drive. By entering http://yourserver.com/site/ into the “Connect to a Web Site” dialog, the OS creates a virtual drive letter that behaves like a local folder. From there, users can drag and drop files, rename items, or delete them as they would on any network share. The same interface works in later Windows versions, though the wording has shifted to “Map network drive.”

Internet Explorer 5.0 and later versions also support WebDAV out of the box. When you navigate to a URL that points to a WebDAV-enabled site, the browser switches from rendering HTML to showing a folder view. Double‑clicking a file initiates a GET request and displays the file’s contents, just like opening a local document. If the file is an executable script, the browser follows the TRANSLATE header logic to decide whether to run it or download the source.

Microsoft Office 2000 introduced WebDAV integration for applications such as Word, Excel, and Outlook. In theory, you could open a Word document directly from a WebDAV server, edit it, and save the changes back to the site. In practice, the experience can be inconsistent, especially if the server does not support all required verbs or if the client uses an older Office version that mishandles the lock mechanism.

Third‑party file managers also provide robust WebDAV support. Tools like Cyberduck, WinSCP, and FileZilla let users connect to WebDAV servers using familiar FTP‑style interfaces. They support advanced operations such as batch uploads, resumeable downloads, and permission setting, making them ideal for developers who need to manage large sets of files remotely.

Beyond file transfer, WebDAV can be employed for content management workflows. For instance, a team can maintain a staging environment where authors upload new pages, preview them via the WebDAV folder view, and then promote them to production. Because WebDAV respects file timestamps and MIME types, servers can automatically trigger build scripts or cache invalidation when a file changes.

Another practical use is automated backups. A scheduled PowerShell script can connect to a WebDAV share, enumerate all files with PROPFIND, and download them to a local backup location. The script can also use PROPPATCH to set a “backup” property on each file, providing metadata that indicates the backup status.

Because WebDAV relies on HTTP, it can traverse NATs and firewalls that allow web traffic. This eliminates the need for dedicated VPN tunnels or FTP ports. When combined with HTTPS, WebDAV offers a secure channel that can be used in environments with strict compliance requirements.

When using WebDAV, it is crucial to remember that the protocol does not provide its own encryption or integrity checks beyond what HTTP offers. Thus, always pair WebDAV with HTTPS to protect data in transit. Also, ensure that the server’s SSL certificates are valid and not expired; otherwise, clients may experience warning messages or fail to connect.

In the end, WebDAV’s real strength lies in its simplicity and ubiquity. By treating a web folder like a network share, developers and administrators can manage resources without installing complex tools. The key to a successful deployment is to understand the protocol’s capabilities, enforce proper security measures, and choose the right client tools for the task at hand.