How to set up IIS 7 application pool identity correctly?

iispool\appPoolName account are called virtual accounts & were added to Windows 2008. The idea goes that they aren't really accounts in the true sense. What they allow is enhanced security between processes using the base account.

Many services on your machine use networkService, a built in account with network access. Because of this, if an attacker were to exploit one of those services, any other process running under the same account would be accessible. Virtual accounts, such as those used by IIS prevent this by appearing as different accounts, whilst still being the same account - your asp.net app is still technically running as networkservice & granting this account access to things shoudl still work. This also means if you need to access network resources, the iispool accounts would do so as networkservice does & use the machines domain account.

If you are accessing a remote sql server, this is the account you should add to allow access from your web server. I wouldn't advise using impersonation, unless you really really need to see who the user is on the SQL server. Your app security is simpler if you leave it off.

as to why your injections aren't working, it could be any of your dependencies failing. if controllerA is injected with ClassB which in turn is injected with ClassC & that class fails to have ClassD injected, then the whole chain fails. I've had that happen & it took a while to realise it was something so removed from what I was looking at.

From the detail in the question, it sounds a lot like a permissions problem causing a COMException to be thrown, which is preventing Ninject from instantiating MainController. The exception is related to System.DirectoryServices which are the classes used to query Active Directory.

When IIS is running under the normal app pool accounts, those accounts don't have permissions to make queries against Active Directory and a COMException can be thrown. I think the actual message in the exception (can't find a parameterless constructor) is a bit of a red herring and is Ninject trying to fall back to another constructor since the normal one didn't work.

That would explain why when you change the IIS app pool to run as a domain account it suddenly works, because that account does have permission to query the domain.

It's not clear from the question whether or not you are using System.DirectoryServices yourself or whether Ninject/IIS/ASP is using them. If you are using them yourself though, make sure none of the constructors in your AD classes can throw exceptions (catch them and log them or something) which will prevent your app from crashing on start-up. You'll probably find out what I said above about permissions.

If you need IIS to run as the normal app pool account (which is a good idea) but still query AD as a domain user then you can specify the credentials to DirectoryEntry and use a DirectorySearcher to do the AD search. If you're on .Net 4 or higher then I'd recommend using the new System.DirectoryServices.AccountManagement classes instead (which also allow you to specify credentials).

With that method, you won't need any impersonation for AD queries and your app pool can still run as the normal app pool accounts.