FTP User Isolation with Multiple User Accounts

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 discused 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.
    (Described below.)

  • "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 mutiple virtual directories that pointed to content in varying locations and for mutiple 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:

  1. I chose the "Isolate Users" option when creating my FTP site.
  2. I created the "LocalUser" physical folder under my FTP site's root folder.
  3. 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 mutiple 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!

Comments (7)

  1. JohnGalt says:

    The question has to be asked: Why oh why don’t you guys just give FTP the same treatment as HTTP and allow virtual severs on the same IP Address? Problem really solved for ISPs and elminates all of the security issues!

  2. robmcm says:

    That’s an interesting question, and the answer has to do with how the HTTP and FTP protocols work.

    There are three ways that you can create unique bindings for a web/HTTP site: IP address, port, or host header. FTP can create unique bindings by IP address or port, but the FTP protocol does not allow for host headers.

    Here’s why – as I’m sure you’re aware, HTTP packets consist of a set of headers and possibly a block of data. Here’s an example of a simple GET request:

    GET /default.aspx HTTP/1.0 [crlf]
    Accept: */* [crlf]

    When HTTP 1.1 was published in RFC 2068 and RFC 2616 it defined a header for specifying a “host” name in a separate name/value pair:

    GET /default.aspx HTTP/1.1 [crlf]
    Host: example.com [crlf]
    Accept: */* [crlf]

    This allows multiple virtual servers (“hosts”) on the same IP address and port that are differentiated by host name. While this works great for the HTTP protocol, the FTP protocol currently has no comparable functionality. As such, the FTP protocol would have to be updated to allow multiple hosts on the same IP address and port, then IIS and all FTP clients would need to be updated to accommodate the changes to FTP.

  3. JohnGalt says:

    Couldn’t you do a reverse lookup?

    The way it works right now is maddening for ISPs and makes it incedibly hard to get the security settings correct so that only one account can login but can’t go backwards and it won’t work on another ftp etc. etc. etc. while still allowing ASP.NET to do what it needs to to display the site.

  4. robmcm says:

    I think you still don’t understand part of how HTTP works versus FTP.

    I realize that you are aware that when you attempt to connect to an HTTP or FTP server from a client, the client looks up the IP address using a name server and then creates a connection to the server by IP address. What I don’t think you realize is that the server is basically unaware of the host name that the client used, unless the connection protocol provides a mechanism for specifying the host name. (HTTP/1.1 provides a mechanism for specifying host names; but FTP does not.) In fact, if you were to open Network Monitor and capture an FTP connection between a client and a server, you would be able to see that the host name is not passed as part of the FTP conversation between the client and server.

    So reverse DNS is out of the question, because the server is not aware of the host name and therefore cannot perform a reverse lookup by host name. Likewise, if you have several host names that are registered to the same IP address, the server can perform a lookup on the IP address, but when the name server contains multiple registrations for the IP address, which host name should it map to? Since the FTP packets from the client cannot pass a host name, we have no way of knowing which host name to use from the list provided by a name server. But then again, if FTP provided a means to specify the host name the whole issue would be moot and a reverse lookup would not be needed.

    While I realize that the ability host multiple FTP sites on the same IP address and port like HTTP is a desired configuration, the simple answer is that FTP does not support this. To put things in perspective, RFC 959 is the governing document for FTP, and that was published in October of 1985. RFC 2068 and RFC 2616 are the governing documents for HTTP/1.1, and those were published, respectively, in January of 1997 and June of 1999. FTP was simply not designed in 1985 for the Internet as we use and understand it today, even though it is a generally reliable protocol that many people will continue to use for some time. HTTP/1.1 was designed much later and resolved this problem, but only for HTTP requests.

  5. robmcm says:

    Someone sent me an email asking if there was a way to restrict users to their own directories, but provide certain users the ability to read/write to all ftp user’s directories.

    It is possible to do something like that using a hierarchy that resembles the following example:

                User1 [junction] ==> d:userscontent1
                User2 [junction] ==> d:userscontent2
                    User1 [junction] ==> d:userscontent1
                    User2 [junction] ==> d:userscontent2

    That being said, you would have to make sure that the folders have the correct permissions. For example, User1 needs to have R/W access to the d:userscontent1 folder, User2 needs to have R/W access to d:userscontent2, and User3 needs to have R/W access to both the d:userscontent1 and d:userscontent2 folders.

  6. MJ says:

    I made an isolated FTP site, so how could it be used by multiple users

  7. Vishal says:

    I tried this works great. I am using local users so wile isolating i created a localuser folder, My question: is it mandatory to have folder named LocalUser or i can have any name for it. Cos when i renamed LocalUser folder to ABC it did not work

Skip to main content