IIS 7 and Above
IIS10 FTP on Azure Files (UNC with common user account) problem with...
Last post Oct 21, 2018 11:56 PM by bsmithoz
Oct 05, 2018 10:52 AM|bsmithoz|LINK
We are using Azure File Storage to store files for an FTP site. The FTP site is run on a Windows Server 2016 VM running IIS 10. We use IIS Manager users with isolation (guide at https://community.rackspace.com/products/f/public-cloud-forum/491/ftp-user-isolation-with-virtual-directories-not-global-in-iis-7-5 ).
And this has worked for me on a IIS 8 machine with local disks before.
I've set up a local user with the same credentials as the storage account (https://blog.bitscry.com/2018/08/21/creating-an-ftp-site-in-azure-with-azure-storage-file-share/)
The FTP site has its Physical Path set to \\storageaccount.core.windows.net\sharename\FTPRoot and it is configured to Connect As the local storageaccount user.
The FTPRoot directory has a LocalUser directory, and then Virtual Directories are used for each user's home directory, pointing to another directory on the same share. I found that it was not working properly (as it was on the previous server.)
Even with user isolation turned off, I can connect and browse as far as LocalUser without problems, but when I try to list the user Virtual Directories not all appear at the client end.
I've taken a trace with Process Monitor and it seems to indicate that there is a problem where only one third of the CreateFile requests have the user impersonation enabled (and these are the requests which succeed.)
If on each virtual directory I configure it to Connect As the local storageaccount user, the problem appears to go away, and the Process Monitor trace shows the account impersonation being used consistently.
This looks to me as if it's a bug in IIS - at least I can work around it by replicating the same credentials over and over again (hope I don't have to change the password too often!)
Am I missing something here, is there some way I can fix it properly?
Oct 10, 2018 09:30 AM|Terry Peng|LINK
In fact, the whole folder for the site is an virtual directory. So You have set user impersonation enable for the FTPRoot virtual directory. However, for the Virtual Directories you added in the use folder, they are also virtual directories and will not
inherit the user impersonation setting from FTPRoot. So when you go to the virtual directories, IIS will not impersonate an user to access the folder and your original account does not have permission on the folder, so you will get error.
The solution is as you said, set user impersonation enabled("Contact as") for each virtual directory or grant your original user account permission on the single virtual directory.
Oct 21, 2018 11:56 PM|bsmithoz|LINK
Thanks for your comment.
The main thing that suggests to me that this is a bug is the fact that when user isolation is disabled, the directory listing shows 1 in 3 directories (and the first Process Monitor trace shows this difference in the CreateFile calls).
Surely if IIS wasn't intended to inherit the user impersonation from the root, it would never call CreateFile with impersonation enabled, and no directories would be shown?
Conversely, if IIS is intended to inherit the user impersonation settings from the root, it should always call CreateFile with impersonation enabled, and all directories would be shown. It doesn't make sense to me (as a system user) to have something half-working.