Running an FTP Server on IIS 5.0

FTP is the protocol used for copying files to and from remote computer systems using TCP/IP. It is the transport mechanism that many (if not most) Internet content management solutions use. This protocol lets users use FTP commands (or programs) to work with files, such as listing files and directories on a remote system. Windows 2000 installs a single FTP server by default when it installs Microsoft IIS. IIS 5.0 facilitates having many FTP servers on one machine.

The default FTP server that IIS 5.0 installs is configured and ready to go with anonymous access immediately after installation. If your network has a name resolution system (typically DNS), visitors can type ftp:// and the DNS name in the address bar of their browsers to reach your site (e.g., ftp://ftp.microsoft.com). If your network doesn't have a DNS-like system, visitors must type ftp:// and your server's numerical IP address. Command-line users can still use a standalone command-line FTP program that's available on many platforms and OSs.

Anonymous FTP access is an authentication mechanism that is identical to Anonymous authentication for the IIS 5.0 Web server. Users can connect to your FTP server without providing usernames and passwords (except for a username of Anonymous and a password of their email address) because IIS uses IUSR_computername to provide anonymous access. You can specify a different account for anonymous access. You can also restrict access to resources using NTFS permissions. Note that even if you enable Basic authentication, Anonymous authentication takes precedence, and IIS 5.0's FTP server will use it first.

Here are three "hot tips" about FTP site feature configurations that I found in the MSDN Library:

• Creating User Directories: To automatically place a user in his or her own FTP directory upon login, create a virtual FTP directory with the same name as the username.
• Limiting Access: You can lock anonymous users into the FTP directory so they can't browse outside it while enabling an authenticated client (who isn't using FrontPage) to upload files to the same FTP directory. To limit access, perform the following steps:

1. In Windows Explorer, place the FTP directory under the wwwroot directory.
2. In the IIS snap-in, point the FTP server to the FTP directory.
3. Also in the IIS snap-in, create a second FTP server under the first and give the second one the same name as the username of the client who wants to upload files.
4. Point the second FTP server to the FTP directory (the same one as in the second step).
5. 5. In Windows Explorer, set the following NTFS permissions on the FTP directory: Give Anonymous FTP User Full Control on the FTP directory and deny all permissions on the root directory.

After a user logs on, IIS places the authenticated client in the virtual FTP site of the same name. The client has full control over directory content and can upload files. An anonymous user who logs on can read the files but will have no control over them and won't be able to browse outside the virtual FTP directory.

One of the main drawbacks of using FTP as a content management solution on secured sites is that the transfer loses file permissions (ACLs) and attributes. If you secure a Web page by putting ACLs on it on your development or staging server and use FTP to copy that page to a production server, you lose the file permissions. If you use Visual SourceSafe (VSS) on your development server and you author a page and check it in, VSS sets a read-only attribute on the file. If you use FTP to transfer that file to a production server, you lose that read-only attribute.

Microsoft Content Replication System, which shipped in Microsoft Site Server 3.0 and now ships in Microsoft Application Center Server 2000, overcomes the problem. It retains file permissions and attributes when copying files. CRS has a file transfer mechanism very similar to FTP's, and because of its superior capabilities, Microsoft uses it extensively internally—and has for years—in content management solutions.