# Is it possible to use IIS 7 Application Pool Identities on a 2008 Domain Controller

So, let me put the disclaimer in first: I wouldn't typically piggy-back IIS on a domain controller, but that's what I've got and I can't change that in this instance.

I've got a WCF web service I need to host here. I'd like to be able to use an application pool identity from IIS to grant filesystem permissions as well as Launch and Activation Permissions in component services. I'm not able to find the account when I browse for it by trying to select "IIS AppPool\DefaultAppPool".

Does anyone know if this is even possible on a 2008R2 domain controller?

Granting permissions to Application Pool Identity's via the UI on Windows 2008R2 can be a bit prone to not working now and again, but can be achieved using a couple of command line tools.

NTFS Permissions:

Use the ICACLS command line tool to set NTFS permissions:

icacls c:\wwwroot /grant "IIS AppPool\DefaultAppPool":(CI)(OI)(M)


The above configures the DefaultAppPool identity to have Modify permissions on c:\wwwroot with File and Folder inheritance. In the UI it looks like:

and under the permissions Advanced UI:

DCOM Launch and Activation and Access Permissions:

Again, the UI can be a bit hinky here when it comes to IIS AppPool\<ident> accounts and there's no built-in command line tool to configure Launch and Activation Permissions and Access Permissions. You could try setting these values in the registry but unless you know how to create a serialised ACL for LaunchPermission and AccessPermission it's going to be hard going.

All is not lost though. There's a tool called dcomperm.exe which is included as a sample project in the Microsoft Windows SDK for Windows 7 and .NET Framework 4.

This chap has written about it here:

Another step closer to the 100% scripted SharePoint installation with DcomPerm.exe

You can try and build it yourself or download a prebuilt binary from his Microsoft Live SkyDrive.

To use dcomperm.exe it you'll need to know the AppID of your DCOM app. You can do this by locating it in the General tab of your application's DCOM configuration properties. For example, I've picked the IIS CertObj library as a working example.:

You can place your cursor in the Application ID field and select the whole field, make sure you include the curly braces as well.

Next open a command line prompt (running as Administrator). To grant your application pool identity Local Launch and Local Activation permissions you would execute:

DComPerm.exe -al {62B8CCBE-5A45-4372-8C4A-6A87DD3EDD60} set "IIS AppPool\DefaultAppPool" permit level:ll,la


Where:

• -al = Modify or list the launch and activation permission

• {62B8CCBE-5A45-4372-8C4A-6A87DD3EDD60} = the App ID we copied from the DCOMCNFG UI

• set "IIS AppPool\DefaultAppPool" = set this identity

• permit = set the permit flag

• ll = Local Launch

• la = Local Activation

This looks like the following in the UI:

• This should've been marked as an answer. @Kev: Just curious why does icacls can do what Windows Explorer can't? – c00000fd Oct 8 '13 at 6:31
• @c00000fd - sadly won't happen, OP asked his question then never re-appeared to follow up. WRT to ICACLS, I've no idea why the UI sometimes doesn't work. We experienced this on some servers prior to rolling out SP1, after SP1 the GUI seemed to work. – Kev Oct 8 '13 at 8:52

It seems that if you are running a domain functional level earlier than 2008, the built-in IIS accounts cannot be resolved from the GUI.

Either raise the domain functional level to at least 2008, or try running the JScript provided by Microsoft in KB946139

Also note the running web applications on domain controllers is NOT recommended, here's a few reasons: http://blogs.technet.com/b/abizerh/archive/2009/07/16/should-iis-be-installed-on-domain-controller.aspx

This is concerning issues with IIS 6/Windows 2k3, but some of it still holds true, eg. the DCPROMO issue

• Even at both domain and forest functional levels of "Windows Server 2008 R2" you can't resolve the ApplicationPoolIdentity accounts in the UI i.e. the ones that are synthesised pool identities. The built-in's resolve fine, but not pool identities. I was able to repro this on one of our lab 2008R2 DC's running at "Windows Server 2008 R2" and this server was built as such. – Kev Jan 22 '12 at 2:36
• Just because you can't list them in the GUI doesn't mean you can't resolve them by name. Have you tried it in a 2003 environment? – Mathias R. Jessen Jan 22 '12 at 2:44
• There is no such thing as an Application Pool Identity on Windows 2003/IIS6. They are not the same as the built-ins such as NETWORK SERVICE. The accounts are named after the IIS7 application pool and to specify the you would prefix with IIS AppPool\<pool_name>, they are "virtual" accounts synthesised for the pool. – Kev Jan 22 '12 at 2:51
• Not a 2003 server, a 2003 environment, as in "on a 2008 or 2008r2 DC in a domain with a 2003 functional level" – Mathias R. Jessen Jan 22 '12 at 2:53
• I amended my previous comment. What I'm saying is that even at full Windows 2008R2 functional level, these accounts can't be resolved in the GUI. They are a type of account that are particular to IIS7's security architecture and at times Windows 2008R2 is prone to not resolving them in the UI (even on standalone servers not members of AD), hence you need to use ICACLS and command line tools to get around this. – Kev Jan 22 '12 at 2:59