WebDAV for Remote Access

Are you looking for a better way to provide remote workers access to internal file servers? Look no further than leveraging Windows XP's and Windows Server 2003's built-in support for the Web Distributed Authoring and Versioning (WebDAV) protocol, which provides secure access through an application proxy. An example of this kind of access is the way Outlook 2003 securely accesses Exchange Server through an HTTP proxy. Implementing WebDAV is easy because the protocol is encapsulated inside classic HTML. Therefore, it works across firewalls and enjoys support beyond the Windows platform, such as with the Mac OS. Securing WebDAV is as easy as using HTTP Secure (HTTPS).

Let's walk through setting up remote access to a folder on your internal file server via Web-DAV. The basic components of this setup are a Microsoft Internet Information Services (IIS) 6.0 server, a file server, your office's network connection, and your clients. The IIS server and file server don't necessarily have to be the same system. You'll also need a Windows 2003 system that's attached to your internal network and accessible from the Internet. We'll call this server the WebDAV server because eventually it will be running IIS 6.0 with the Web-DAV server extension. If your WebDAV server isn't already connected to the Internet, that's fine—but you'll need to lock it down.

Internet Access to the WebDAV Server
The way you set up access to the WebDAV server from the Internet depends on your current environment and size. Ultimately, you need to specify an IP address or DNS name and a TCP port number that remote users will use to access the Web-DAV server. Let's consider some typical scenarios.

If you're a small business and the only device you have connected to the Internet is a typical broadband router/ firewall, you can still set up Web-DAV access. You'll need the IP address that remote users will use to access the file server. First, determine whether your router has a static Internet address. If not, the easiest thing to do is pay your ISP for one. If static IP isn't available, you can use DDNS. Most broadband routers support DDNS. What about the TCP port? If you're already using HTTPS to access something behind your router, you can simply punch a hole in your firewall to forward incoming connections to TCP port 443 on the internal server running IIS 6.0 with WebDAV. Don't open this port at this point in the process; you first need to make sure the internal server is ready for it.

If you don't have an IIS server already connected to the Internet, consider making your file server the WebDAV server.

If your network is more sophisticated, you might already have a Windows 2003 system connected to the Internet, either directly or through a firewall, as I just described. If so, you can easily use that system. If the Windows 2003 server is already running IIS, such as for Microsoft Outlook Web Access (OWA), SharePoint, or a public Web site, you can either create a virtual directory under an existing Web site or create a new site. What's the difference? If you use an existing Web site, you'll simply take the existing Internet-side URL and add the name of the new virtual directory when you configure WebDAV client access. If you create a new site, you might need to select a new TCP port number for it. If you access an existing site via HTTPS by using HTTPS's default port 443, you'll need to select a new port for WebDAV client access. If the existing site is configured to use port 443 but no one ever accesses it through HTTPS, you can change the existing Secure Sockets Layer (SSL) port. If you use a port other than 443 as your SSL port, you'll need to add the port number to your URL. For example, for the domain name webdav.ultimatewindowssecurity.com, the URL would become https://webdav.ultimatewindowssecurity.com: XXXXX, where XXXXX is the port number.

Setting Up Secure WebDAV
In the following step-by-step directions, I assume you're installing IIS and WebDAV on a system separate from the file server. In this case, simply install IIS without enabling Active Server Pages (ASP) or any other options. After IIS installation, open the Microsoft Management Console (MMC) Internet Information Services (IIS6) Manager snap-in (which Figure 1 shows), expand the Web Service Extensions folder, and allow the Web-DAV node. To keep IIS's attack surface as small as possible, don't enable any other extensions.

Next, we're going to lock down IIS to accept only authenticated, encrypted connections. From the MMC IIS Manager snap-in, open Default Web Site Properties and select the Directory Security tab, which Figure 2 shows. First, you need an SSL certificate for the server. If you have an enterprise Certificate Authority (CA) running Microsoft Certificate Services in your domain, you can use the wizard to request a certificate. Otherwise, you'll need to purchase a certificate from a public CA or create your own self-signed certificate. (The Microsoft Windows Internet Information Server Resource Kit contains a tool for generating self-signed certificates.) If you have an enterprise CA, click the Server Certificate button to step through the Web Server Certificate Wizard. At the Delayed or Immediate Request page, select Send the request immediately to an online certification authority and keep clicking Next until you reach the page named Your Site's Common Name. Enter the DNS or IP address that remote users will use to access the site. (Note that if you enter an IP address and you're using DHCP with DDNS, the certificate will be invalid when the IP address changes.) Don't include https:// or any port number. (Using the example URL I gave earlier, you would enter webdav.ultimatewindowssecurity.com.) Click Next until you reach the SSL Port page. On this page, enter the TCP port you selected earlier. Keep clicking Next until you reach the Finish button and click it. You've now installed your SSL certificate. Return to the Default Web Site Properties Directory Security tab, click Edit under Secure communications to bring up the Secure Communications dialog box, and select the Require secure channel (SSL) and Require 128-bit encryption boxes.

Next, you need to require all users to authenticate when they access the server. On the Directory Security tab, click Edit under Authentication and access control. Clear the Enable anonymous access check box, as Figure 3 shows, and select the Basic authentication (password is sent in clear text) box. (You don't need to select basic authentication if all your clients are Windows-based.) Don't worry about the clear-text warning from IIS— you've already enabled SSL encryption. Configure the default domain to match the domain in which your remote user accounts reside; doing so relieves users from having to prefix their username with domain name. The Authentication Methods dialog box on your screen should resemble Figure 3.

Point IIS to the Shared Folder
Whether you set up a new IIS server, create a virtual directory on an existing Web site, or create a new Web site on an existing IIS server, you need to point IIS to the appropriate folder on your file server to direct requests from your WebDAV URL. When you create a site or a virtual directory under an existing site, IIS gives you the option of specifying the folder that contains the content for that directory or site. Because we're using an IIS installation dedicated to WebDAV, we need only point the root of the default Web site to the file server. In IIS Manager, return to Default Web Site Properties and select the Home Directory tab. Select A share located on another computer and enter the Universal Naming Convention (UNC) pathname of the shared folder to which remote users need access in the Network directory text box, as Figure 4 shows.

Next, you need to ensure that IIS impersonates the current user before accessing the file server. Click Connect As... and check Always use the authenticated user's credentials when validating access to the network directory. To enable users to download, upload, and browse files in the folder through WebDAV, select the Read, Write, and Directory browsing check boxes on the Home Directory tab, as Figure 4 shows. These boxes control only which WebDAV operations a user can request. The file server will enforce NTFS file permissions as if the user were connected locally. Don't enable any other options on the Home Directory tab, and set Execute permissions to None to keep security as tight as possible.

Now IIS is ready to accept WebDAV requests for accessing your file server. Before opening up the WebDAV server to the outside world, make certain the server is up to date with any IIS security updates, and keep the server up to date from this point on. Finally, open the appropriate port on your firewall and you're in business on the server side.

Enable Users
All that remains is to enable remote users. To do so, create an Add Network Place shortcut for users to access in My Network Places on their client machine. Each user then needs to go to My Network Places, double click the Add Network Place shortcut, and enter the URL of the Web-DAV site. The first time a user accesses the shortcut in My Network Places, Windows Explorer will prompt for credentials; afterward, users have access to the file server as though it were a typical shared folder.

Security Concerns
How secure is this method? If you already allow VPN access that's based on a user's password, using WebDAV to enable remote access is comparable in security. The only difference is an expanded attack surface when using WebDAV, due to opening port 443. However, attackers will be able to attempt HTTP-related exploits only if they can first successfully authenticate. If you want to strengthen security, you can add a degree of obscurity by changing the HTTPS port on the Web site from 443 to a higher port number, but be aware that doing so can limit accessibility for remote users behind another company's firewall that has strict restrictions on outgoing connections. The best way to further lock down any type of Web access is to require client certificates in addition to password authentication. You can enroll users remotely by prompting them through a few Web pages. For more information about client certificates, see "Configuring SSL/TLS," April 2006, InstantDoc ID 49556.