How to properly configure IIS 7 application pool identifier?

Question

When I deployed my site in IIS7.5, I discovered one strange behavior: when the default application pool identifier remains ApplicationPoolIdentity (as recommended in IIS application pool identifiers ), Ninject seems to be ignored, since I get the following error when creating the very first controller:

System.InvalidOperationException: An error occurred while trying to create a controller of type '..MainController. Make sure that the controller has an immortal public constructor. ---> System.DirectoryServices.DirectoryServicesCOMException: operation failed.

I tried to provide FullAccess to IIS AppPool\<MySiteAppPool> to the folder containing the site (including all subfolders and files), but that didn't change anything.

However, when I set the application pool identifier for any domain account (even a simple one, without administrative privileges, and also without any access to the folder with the site), it works fine.

Ninject is installed in accordance with Configuring the MVC3 application through the NuGet package.

I'm not sure if this matters, the site should be running on a Windows Authenticated Domain Intranet.

So, the only problem seems to be related to the application pool id. As far as I want to use the recommended method, I would like to have ApplicationPoolIdentity , and not a domain account.

What is the reason for this? Is it possible to mix everything together?

---

Here is an SO thread with a similar problem: ASP.NET MVC 4 + Ninject MVC 3 = There is no constructor without parameters for this object . However, no suitable answer exists.

---

As a comment made, I tried to use NetworkSerive as an identifier. And it worked correctly. However, I think this is not much better than a non-privileged domain account.

---

EDIT

Another dependency was unexpectedly discovered: the application pool identifier is used for Windows authentication on the sql server, although I expected that client-side user credentials would be used there.

Based on comments

Agree that a remote sql server can be accessed with authenticated credentials through impersonation.

---

However, it is still unclear what the problem is with ApplicationPoolIdentity and Ninject.

In the article mentioned at the very top of this question, I suggested that this could be due to the fact that the virtual account does not have a user profile. This aspect remains unclear to me, since you can still enable IIS to load a user profile using the LoadUserProfile attribute. I can’t get what IIS will load if there is no profile for the virtual account?

It says:

IIS does not load the Windows user profile, but some applications may use it anyway to store temporary data. SQL Express is an example application that does this. However, the user profile must be created to store temporary data in the profile or in the registry hive. User profile for Account NETWORKSERVICE was created by the system and was always available. However, with switching to a unique application pool of identifiers, a user profile is not created by the system. Only standard application pools (DefaultAppPool and Classic.NET AppPool) have user profiles on disk. A user profile is not created if the Administrator creates a new application pool.

However, if you want, you can configure IIS application pools to load the user profile by setting the "LoadUserProfile" attribute to "true".

---

I found the following thread on serverfault.com:

How to assign active directory permissions to the default application pool identifier

It also states that the application pool identifier cannot work as a network service, in particular, request AD.

Answer 1

From the detail in the question, this is very similar to the permission issue causing a COMException , which prevents the creation of an instance of the Ninject MainController . The exception is related to System.DirectoryServices , which are the classes used to query Active Directory.

When IIS runs under normal application pool accounts, these accounts do not have permissions to query Active Directory and a COMException may be COMException . I think that the actual message in the exception (cannot find the constructor without parameters) is a slightly red herring, and Ninject is trying to return to another constructor, since the normal one does not work.

This explains why when changing the IIS application pool to run as a domain account, it unexpectedly works because this account has permission to query the domain.

It is unclear whether you are using System.DirectoryServices yourself or using Ninject / IIS / ASP. If you use them yourself, make sure that none of the designers in your AD classes can throw exceptions (catch them and write to them or something else), which will prevent your application from crashing on startup. You will probably find out what I said above about permissions.

If you want IIS to start as a regular application pool account (which is a good idea), but still request AD as a domain user, you can specify DirectoryEntry credentials and use DirectorySearcher to search for AD. If you are on .Net 4 or higher, I would recommend using the new System.DirectoryServices.AccountManagement classes (which also allow you to specify credentials) instead.

With this method, you don’t need to impersonate AD requests, and your application pool can still work like regular application pool accounts.

Answer 2

Account

iispool \ appPoolName is called virtual accounts and was added in Windows 2008. The idea is that they are not really accounts in the true sense. They allow you to increase security between processes using a basic account.

Many services on your computer use networkService, a built-in account with network access. Because of this, if an attacker must use one of these services, any other process running under the same account will be available. Virtual accounts, such as those used by IIS, prevent this from being different accounts, although they are still the same account - your asp.net application still technically works as a network service and provides access to this account to things that shoudl still works. It also means that if you need to access network resources, iispool accounts will do this, as the network service does, and use the machine domain account.

If you are accessing a remote sql server, this is the account you must add in order to allow access from your web server. I would not recommend using impersonation unless you really need to see who is on the SQL server. Security of your application is easier if you do not disable it.

about why your injections don't work, it could be any of your failures. if ClassB is entered into controller A, which, in turn, is introduced by ClassC, and ClassD is not entered to this class, then the whole chain fails. It happened to me, and it took some time to understand that it was so far from what I was watching.