Update: The original question was for Windows Server 2008, but the solution is easier for Windows Server 2008 R2 and Windows Server 2012 (and Windows 7 and 8). You can add the user through the NTFS UI by typing it in directly. The name is in the format of IIS APPPOOL\{app pool name}. For example: IIS APPPOOL\DefaultAppPool.
IIS APPPOOL\{app pool name}
Note: Per comments below, there are two things to be aware of:
- Enter the string directly into the "Select User or Group" and not in the search field.
- In a domain environment you need to set the Location to your local computer first.
Reference to Microsoft Docs article: Application Pool Identities > Securing Resources
Original response: (for Windows Server 2008) This is a great feature, but as you mentioned it's not fully implemented yet. You can add the app pool identity from the command prompt with something like icacls, then you can manage it from the GUI. For example, run something like this from the command prompt:
icacls c:\inetpub\wwwroot /grant "IIS APPPOOL\DefaultAppPool":(OI)(CI)(RX)
Then, in Windows Explorer, go to the wwwroot folder and edit the security permissions. You will see what looks like a group (the group icon) called DefaultAppPool. You can now edit the permissions.
However, you don't need to use this at all. It's a bonus that you can use if you want. You can use the old way of creating a custom user per app pool and assigning the custom user to disk. That has full UI support.
This SID injection method is nice because it allows you to use a single user but fully isolate each site from each other without having to create unique users for each app pool. Pretty impressive, and it will be even better with UI support.
Note: If you are unable to find the application pool user, check to see if the Windows service called Application Host Helper Service is running. It's the service that maps application pool users to Windows accounts.
Ok, I have figured out my own problem. Wanted to share my insights briefly.
Application Pool
: .NET = No Managed Code
: Pipeline Mode = Integrated
: Identity = NetworkService
The trick here is that the new FTP Authorization Rules do not verify Active Directory (or local) usernames or groups. Therefore, you could put in anything here, thinking you've got the right group name, and you wouldn't know except that permissions didn't work to allow the rule you've set.
I got this to work by
- Ensuring correct folder/file-level permissions per group or user
- Setting FTP Authentication to enable Basic and disable Anonymous
- Setting the Site Properties to "Connect As..." = "Application user (pass-through authentication)"
- Setting the FTP Authorization Rules as desired for each Virtual directory
I hope this helps someone!
Best Answer
Files and folders that are direct physical children of the FTP root can't be hidden. You could mark these files and folders as hidden in explorer, but that only prevents the most casual of browsers from seeing subfolders and files. It is still possible to override this using
ls -ain the ftp client.You can only control directory browsing of virtual directories in an IIS FTP 7.5 site. i.e. where you've right clicked on the site and added a virtual directory mapped to a folder not under the FTP site root:
They look like this when added:
To control their visibility open the directory browsing feature:
Uncheck the Virtual Directories directory listing option then click
Apply:There's also no support to control directory browsing in the FTP Extensibility hooks either which was another place I've looked at in the past.
If you need more fine grained level of control over your FTP site then you're going to have to replace IIS FTP with a more featured FTP server such as Filezilla (free) or Gene6 FTP (commercial) which is a product we use (it has a COM configuration API which is even callable from .NET apps via interop).