IIS 6: User Isolation with Active Directory

Tags: Active Directory, Windows Server, IIS

I'm busy migrating everything off our single host to a collection of virtual machines. One of the things we do is apply User Isolation in IIS 6 so that when people use FTP to access the system, they can only access their own files and sites (we do some very limited hosting for friends and family).

Since we have an Active Directory, it's pretty much a no brainer to use the same AD account for everything (except Community Server, which runs this site, and Countersoft Gemini, which we use for our internal bug database). We've had user isolation going for a couple of years with no dramas, but moving it off the old server onto the new VM has been ... painful.

Just so it's clear; we're not changing the way people log on, nor even the location of their data (luckily the same drive letter is in use on old and new hosts). But the new server just wouldn't work.

The old server still worked fine, so user isolation was operational and the data in AD was correct. There's nothing useful in the event logs; the standard error in the FTP client was as useful as ever:
530: User XXX cannot log in. Home directory inaccessible.

Turns out that you get this error when your username and password don't match the directory.

The fix is simple. I'll use $$ to indicate the metabase ID for your FTP site, they will all differ so use adsutil enum /p msftpsvc or the IIS console to find the right site number. Also, replace $DOMAIN with your NETBIOS domain name, $USERNAME with the account you want to use for directory access by the FTP service, and $PASSWORD with the correct password for that account:

pushd C:\INetPub\AdminScripts
adsutil set msftpsvc/$$/ADConnectionsUserName $DOMAIN\$USERNAME
adsutil set msftpsvc/$$/ADConnectionsUserName $PASSWORD
net user /domain $USERNAME $PASSWORD
popd
The five commands above are a good way to ensure that your domain connection will operate as expected. You could even massage the above into a command script to change the user and password (we all change service account passwords regularly, right?)

 

No Comments