There are plenty of solutions out there to give you a “Web File Explorer” – good ones at that.

• extplorer
• Open Upload
• pydio (formerly AjaxPlorer)
• Many many others

All of them were lacking the simple components I needed for my client base – I needed the ability to authenticate to AD and I needed to redirect/isolate the users to specific folders based upon who they were.

After trying a few different solutions I crafted one of my own in my head. I knew if I could make IIS FTP server provide the access to the files that I needed I was certain I could either find or write a web-frontend for that FTP server.

This blog isn’t intended to outline the whole process, but rather just list the pitfalls that I encountered and how I got around them.

1) Nginx – All of my web traffic comes through a reverse proxy. Setting max_upload, max_execution and the other components in my webserver’s php.ini is a no-brainer. The following config directives were modified in php.ini:

upload_max_filesize
memory_limit
max_input_time
max_execution_time
post_max_size

what wasn’t a no-brainer was finding the bits of my nginx.conf that were causing me problems. Honestly I still haven’t gotten things JUST RIGHT through nginx and may have to bypass it for this site. I’ve discovered that through SSL there is some sort of bug in nginx that won’t allow the script execution to exceed 30 seconds. Ignoring that problem though I still had to modify the following line of my nginx.conf to suit my needs even for non-SSL usage:

client_max_body_size 1G;

Obviously all of these directives are now set to questionable limits for a production webserver, with such reckless limits on the php/webserver a lot of potential vulnerabilities are opened up

2) AD Authentication and folder redirection/isolation for FTP users is simple in IIS, it’s just not well documented and requires a very specific configuration. The process is as follows:

i – create your website, configure basic authentication and permit the requisite users, this is not complicated

ii – in your newly created site adjust FTP Directory Browsing as follows:

iii – Configure FTP User Isolation as follows (even if it seems counter-intuitive):

iv – Now the parts that are documented REALLY poorly and extremely important to avoid the following error:

530 User cannot log in, home directory inaccessible.
Login failed.

When you login using an AD account the isolated home folder that IIS FTP server looks for MUST be a virtual directory that is nested in another virtual directory that goes by the shortname of your AD Domain. It should be noted that I found some documentation that appeared to be useful but led me to create a folder structure on the actual filesystem instead of using virtual directories in IIS manager. That method DID NOT WORK. My experience says to create virtual directories for IIS to use, not real NTFS folders.

So, in the root of your FTP site create a virtual directory and give it the shortname of your domain for the alias. This can be modified if you don’t have a domain and are just using local user accounts (possibly even combined) by replacing the name of the domain with “LocalUser.” In my case though I am using domain accounts so I configured my virtual directory like this:

The physical path here is not likely going to be relevant, although there is no need to be reckless. I used the same physical path as my ftp site’s root.

v – Now time to make each user’s individual ftp root, no different than the step prior create a virtual directory, this time not in the root of the site but under the DOMAIN virtual directory. This time the Alias MUST be the user’s username. The physical path should be the location that you want that user to land when they first login. This doesn’t need be their home directory or any such, it can be any place of your choosing however in my case for the ease of the user I made it their home directory.

vi – you can quit at this point, you have a working FTP site that AD users can login to and get isolated up into their own custom home directory. If you want to take it a step further (which I did) you can nest even more virtual directories under the user’s own virtual directories that give them access to files in various locations around the network. An example might look like this:

This would give user4 access to an engineering folder on a file share from within his ftp home. In a sort of mystical and magical (and would only happen in a Microsoft world), the parent directory of engineering would still be user4’s home while user4 is FTP browsing.

The only part left for me was getting a web-ftp interface. I am experimenting with one I found called Monsta FTP. For the time being it is achieving the goal to some end. I need to do some branding and also troubleshoot some drag & drop features it claims to have but that isn’t working. Also in some browsers I couldn’t get it to upload at all, it does give me a starting platform though.

That’s it.