In IIS 4.0 and IIS 5.0, if you created a virtual directory that had a name that was identical to a user name, when the user logged in to the FTP site they would automatically be changed to their folder. When multiple users will access the same FTP content, you could create another virtual directory that is identical to the other user name and point it to the same content.
This allowed sharing a single FTP site across several users and content sets without advertising user names or content folders. Even though a user could type "
CD /" from an FTP prompt, they would not be able to see the virtual directories from other user accounts on that server because virtual directories are not listed when a user types "
ls -l" or "
dir" from an FTP prompt at the root. That being said, this security feature still doesn't go far enough from a security perspective.
One of the great IIS 6.0 features is User Isolation, which is discussed in the Hosting Multiple FTP Sites with FTP User Isolation (IIS 6.0) topic on MSDN. As a quick review, there are three different isolation modes that you can choose when creating an IIS 6.0 FTP site:
- "Do Not Isolate Users"
No user isolation; FTP works like IIS 4.0 or IIS 5.0.
(Not covered in this post.)
- "Isolate Users"
Simple user isolation through folders.
- "Isolate Users Using Active Directory"
Requires A.D. configuration.
(Not covered in this post.)
To configure the "Isolate Users" mode, you first need to create your FTP site and choose the "Isolate Users" option when prompted for FTP User Isolation. Once the FTP site has been created, you need to create a physical folder named "LocalUser" for local user accounts or named after your domain under your FTP server's root folder. To isolate users to a specific folder, you use these rules that I copied from the MSDN topic that I listed earlier in this post:
- For anonymous users, the home directory is LocalUser\Public under the FTP root directory.
- For local users, the home directory is LocalUser\UserName under the FTP root directory.
- For users that log on with Domain\UserName, the home directory is Domain\UserName under the FTP root directory.
This is very easy to configure, and when a user logs in to your FTP server they will be restricted to their physical folder under the FTP root. Typing "
CD /" from an FTP prompt will always restrict the user within their own site.
That being said, because physical directories are required for this configuration it may seem like a step backward when you consider that you used to be able to create multiple virtual directories that pointed to content in varying locations and for multiple user accounts. Not to worry, however, because Windows provides a way around this limitation using NTFS junctions.
For those of you that are not familiar with NTFS junctions, there are several topics that discuss this. (For example, see Inside Win2K NTFS, Part 1.) A junction is somewhat like a symbolic directory link in the UNIX world, where a junction looks like a folder but points to content that is physically located somewhere else. There are two tools that you can use to create junctions, LINKD from the Windows Resource Kit, and JUNCTION from www.sysinternals.com. Using these tools with IIS 6.0 can allow you the freedom to deploy FTP folder structures much like you did with IIS 4/5 while utilizing the user isolation features in IIS 6.
Here's an example - when configuring an IIS 6.0 FTP site, I used the following steps:
- I chose the "Isolate Users" option when creating my FTP site.
- I created the "LocalUser" physical folder under my FTP site's root folder.
- I created junctions under the "LocalUser" physical folder that were named after user accounts and pointed to various content folders.
When a user logs in to my FTP site using their user account, they are automatically dropped in their content folder via the junction. Since you can create multiple junctions that point to the same content folder, you can create junctions for every user account that will work with a set of content.
I hope this helps!
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/