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.
While @sysdmin1138 answer was correct it's worth mentioning that changing the scope is not the only reason why things are missing from the view. There are things that invisible by default.
Some objects such as physicalDeliveryOfficeName are hidden from view so you can't delegate them easily. A lot of other attributes are also hidden, but physicalDeliveryOfficeName is very specific and can be good example on how things works for Delegation.
The Per-Property Permissions tab for a user object that you view through Active Directory Users and Computers may not display every property of the user object. This is because the user interface for access control filters out object and property types to make the list easier to manage. While the properties of an object are defined in the schema, the list of filtered properties that are displayed is stored in the Dssec.dat file that is located in the %systemroot%\System32 folder on all domain controllers. You can edit the entries for an object in the file to display the filtered properties through the user interface.
A filtered property looks like this in the Dssec.dat file:
[User]
propertyname=7
To display the read and write permissions for a property of an object, you can edit the filter value to display one or both of the permissions. To display both the read and write permissions for a property, change the value to zero (0):
[User]
propertyname=0
To display only the write permission for a property, change the value to 1:
[User]
propertyname=1
To display only the read permissions for a property, change the value to 2:
[User]
propertyname=2
After you edit the Dssec.dat file, you must quit and restart Active Directory Users and Computers to see the properties that are no longer filtered. The file is also machine specific so changing it on one machine doesn’t update all others. It’s up to you whether you want it visible everywhere or not.
Full story about physicalDeliveryOfficeName and how to change it with screenshots can be read at my blog.
PS1. Since physicalDeliveryOfficeName is special case, after modifying this setting look for Read/Write Office Location. Unfortunately the name physicalDeliveryOfficeName never shows up.
PS2. Unless those settings are uncovered by modifying dssec.dat you won't be able to see them. Since this file is per computer it's entirely possible it's visible on some computers and not visible on others depending whether someone made the change earlier or not. This could explain why you could see it before and not later on.
PS3. Sorry for resurrection but just spent few hours trying to find the cause so thought I would share it for future reference.
Best Answer
You should be able to use Delegation of Control to delegate the required READ permission(s) to the Everyone group on User objects. If you set it at the domain root it should be inherited by all child nodes in the domain, avoiding the need to manually set the permissions on existing objects or new objects..