如何正确设置IIS 7应用程序池的身份？ [英] How to set up IIS 7 application pool identity correctly?

问题描述

已经部署了我的网站IIS7.5我发现一个奇怪的现象：当应用程序池标识是左是 ApplicationPoolIdentity 默认情况下（如在推荐的 IIS应用程序池标识）， Ninject 似乎被忽略，因为我得到了下面的错误，同时创造的第一控制器：

Having deployed my website to IIS7.5 I found one strange behaviour: when application pool identity is left to be ApplicationPoolIdentity by default (as recommended in IIS Application Pool Identities), Ninject seems to be ignored, as I get the following error, while creating the very first controller:

System.InvalidOperationException：在尝试时出错
  创建类型的控制器
  ..MainController。确保
  该控制器具有一个无参数公共构造函数。 --->
  System.DirectoryServices.DirectoryServicesCOMException：一个操作
  错误发生。

System.InvalidOperationException: An error occurred when trying to create a controller of type '..MainController'. Make sure that the controller has a parameterless public constructor. ---> System.DirectoryServices.DirectoryServicesCOMException: An operations error occurred.

我试图授予 FullAccess 到 IIS程序池\\＆LT; MySiteAppPool＆GT; 来的文件夹，包含该网站（包括所有子文件夹和文件），但这并没有改变任何东西。

I tried to grant FullAccess to IIS AppPool\<MySiteAppPool> to the folder, containing the site (including all subfolders and files), but this did not change anything.

然而，当我设置的应用程序池标识的域帐户（即使是一个简单的，没有管理的privilages，以及不会对文件夹的任何访问的网站），它工作正常。

However, when I set the application pool identity to any domain account (even a simple one, without administrative privilages, as well as without any access to the folder with the site), it works normally.

Ninject根据设置一个安装MVC3应用通过的NuGet包教程。

Ninject is installed according to Setting up an MVC3 application tutorial through the NuGet package.

我不知道，如果是相关的，网站应该在windows身份验证域联网工作。

I am not sure, if it's relevant, the site is supposed to work in a domain intranet with windows authentication.

所以，唯一的问题似乎与应用程序池标识。至于我渴望使用推荐的方式，我喜欢有 ApplicationPoolIdentity ，而不是域帐户。

So, the only problem seems to be with the application pool identity. As far as I am eager to use the recommended way, I'd love to have the ApplicationPoolIdentity, not a domain account.

可这有什么用连接？是否有可能混合所有这些结合在一起？

What can this be connected with? Is it possible to mix all these together?

下面是一个SO一个类似的问题主题：<一href=\"http://stackoverflow.com/questions/12311479/asp-net-mvc-4-ninject-mvc-3-no-parameterless-constructor-defined-for-this-ob\">ASP.NET MVC 4 + Ninject MVC 3 =该对象没有定义参数的构造函数。然而，在所有要么没有合适的答案在那里。

Here is an SO thread with a similar issue: ASP.NET MVC 4 + Ninject MVC 3 = No parameterless constructor defined for this object. However no suitable answer there at all either.

作为删除评论所说，我尝试使用 NetworkSerive 的身份。和它的工作正常。不过，我想这是不是比一个非特权域帐户要好得多。

As a deleted comment suggested, I tried using NetworkSerive as the identity. And it worked properly. However, I guess this is not much better, than a non-privileged domain account.

修改

突然发现了另一种相关性：应用程序池标识用于SQL Server上的Windows身份验证，但我预计客户端用户的凭据在那里使用

Suddenly found another dependency: the application pool identity is used for the windows authentication on sql server, though I expected the client-side user's credentials to be used there.

基于注释

同意，远程SQL Server可以通过模拟的验证凭据进行访问。

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

但它仍然是不明确的问题是ApplicationPoolIdentity和Ninject什么。

However it is still not clear what the problem is with ApplicationPoolIdentity and Ninject.

在这个问题的最顶端文章mentiond让我猜想，这可能由以下事实造成的，即虚拟账户的没有用户配置文件的。这一方面仍不清楚我，因为人们仍然可以启用IIS加载与 LoadUserProfile 属性的用户配置文件。我不能，什么是IIS将加载，如果有虚拟账户没有配置文件？

The article mentiond at the very top of this question made me suppose that this could be caused by the fact, that virtual account has no user profile. This aspect remains unclear to me, as one can still enable IIS to load the user profile with the LoadUserProfile attribute. I can't get, what is IIS going to load, if there is no profile for the virtual account?

据有说：

IIS不加载Windows用户配置文件，但某些应用程序
  可能利用它反正存储临时数据。 SQL防爆preSS
  是，这是否一个应用的一个例子。然而，用户
  信息必须被创建用于存储在临时数据要么
  配置文件目录或注册表配置单元。对于用户简档
  NetworkService帐户是由系统创建的，是永远
  可用。然而，随着开关独特的应用程序池
  身份，没有用户配置文件由系统创建。只有
  标准的应用程序池（默认应用和经典.net程序池）
  在磁盘上的用户配置文件。没有用户配置文件，如果创建的
  管理员创建一个新的应用程序池。

IIS doesn't load the Windows user profile, but certain applications might take advantage of it anyway to store temporary data. SQL Express is an example of an application that does this. However, a user profile has to be created to store temporary data in either the profile directory or in the registry hive. The user profile for the NETWORKSERVICE account was created by the system and was always available. However, with the switch to unique Application Pool identities, no user profile is created by the system. Only the standard Application Pools (DefaultAppPool and Classic .NET AppPool) have user profiles on disk. No user profile is created if the Administrator creates a new Application Pool.

不过，如果你愿意，你可以配置IIS应用程序池加载
  通过设置LoadUserProfile属性中的用户配置文件为true。

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

我发现serverfault.com以下主题：

---

I found the following thread on serverfault.com:

<一个href=\"http://serverfault.com/questions/510016/how-can-i-assign-active-directory-permission-to-the-default-app-pool-identity\">How我可以分配到默认的应用程序池标识的活动目录权限

有它也指出，应用程序池的身份是不能作为网络服务工作，特别是查询AD。

There it is also stated that app pool identity is unable to work as a network service, in particular, query the AD.

推荐答案

从问题的细节，听起来很像一个权限问题造成了收到COMException 是抛出，这是preventing Ninject从实例 MainController 。唯一的例外是有关的System.DirectoryServices 这是用于查询Active Directory中的类。

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.

在IIS下正常的应用程序池的帐户上运行，这些帐户没有权限作出对Active Directory和收到COMException 皆可抛查询。我认为，在异常的实际消息（找不到参数的构造函数）是一个有点红鲱鱼，并Ninject试图回落到另一个构造函数，因为正常的没有工作。

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.

这可以解释为什么当您更改IIS应用程序池为它突然工作的域帐户运行，因为该帐户是否有权限查询域。

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.

它无论您使用的是的System.DirectoryServices 自己还是Ninject / IIS / ASP使用它们不是来自这个问题清楚了。如果您是使用他们自己虽然，确保没有在你的AD类的构造函数可以抛出异常（抓住他们，并记录它们或东西），将prevent崩溃在启动您的应用程序。你可能会发现上面我所说的有关权限。

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.

如果您需要IIS作为正常的应用程序池帐户下运行（这是一个好主意），但仍查询作为AD域用户，那么你可以指定凭据的 的DirectoryEntry ，并使用的DirectorySearcher 做AD搜索。如果你在.NET 4.0或更高版本那么我建议你使用新的<一个href=\"http://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement%28v=vs.100%29.aspx\"相对=nofollow> System.DirectoryServices.AccountManagement 类，而不是（这也让你指定的凭证）。

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.

这篇关于如何正确设置IIS 7应用程序池的身份？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！