Iis – How to determine domain controller used for authentication

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.

Reverse-engineering the script provides some hints about what it does, but ultimately the behavior that it attempts to invoke occurs inside the "black box" of the Active Directory domain controller code itself, so troubleshooting it is going to be difficult (unless you've got source code access to AD... >smile<).

Essentially, the script prepares the domain for an runSamUpgradeTasks call, then executes it. This involves appending a value to the otherWellKnownObjects attribute of the "CN=Server, CN=System. DC=domain..." object in the directory, then making an LDAP call to modify the runSamUpgradeTasks attribute. That's supposed to trigger the W2K8 domain controller to automatically create its default groups and users in the directory and, as such, cause the missing account and group to be created.

I'm a little dubious of the script because the runSamUpgradeTasks reference calls for the balue to be appended to otherWellKnownObjects attribute to end with "...:X", whereas the script doesn't do that. Even so, you indicate that the "IIS_IUSRS" group was created, so that means that, presumably, the W2K8 DC "got the message" and created groups.

This one is fairly perplexing, and I'd opt to go to Microsoft Product Support Services on it. You're not going to spend a lot of money, but given the strangeness of the behaviour you're seeing they're probably the best people on the planet to help you.