问题描述

将我的网站部署到 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 AppPool<MySiteAppPool> 到包含站点(包括所有子文件夹和文件)的文件夹，但这并没有改变任何东西.

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.

但是，当我将应用程序池标识设置为任何域帐户时(即使是一个简单的，没有管理权限，也没有对站点文件夹的任何访问权限)，它可以正常工作.

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通过 NuGet 包编写的 MVC3 应用程序教程.

我不确定，如果相关，该站点应该在具有 Windows 身份验证的域 Intranet 中工作.

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 线程: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.

正如已删除的评论所建议的那样，我尝试使用 NetworkServe 作为身份.它工作正常.但是，我想这并不比非特权域帐户好多少.

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 服务器.

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.

这个问题开头提到的文章让我猜想这可能是由于虚拟帐户没有用户个人资料这一事实造成的.这方面我仍然不清楚，因为仍然可以使 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 Express是执行此操作的应用程序示例.然而，一个用户必须创建配置文件以将临时数据存储在profile 目录或注册表配置单元中.用户个人资料NETWORKSERVICE 帐户由系统创建并始终可用的.但是，随着切换到唯一的应用程序池身份，系统不会创建用户配置文件.只有标准应用程序池(DefaultAppPool 和 Classic .NET AppPool)在磁盘上有用户配置文件.如果管理员创建一个新的应用程序池.

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:

我该怎么做将活动目录权限分配给默认应用程序池标识

那里还说应用池身份无法作为网络服务工作，尤其是查询AD.

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

推荐答案

从问题的细节来看，这听起来很像权限问题导致抛出COMException，从而阻止了Ninject从实例化 MainController.该异常与用于查询 Active Directory 的类 System.DirectoryServices 有关.

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 类中的任何构造函数都不会抛出异常(捕获它们并记录它们或其他东西)，这将防止您的应用程序在启动时崩溃.你可能会发现我上面所说的关于权限的内容.

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做广告搜索.如果您使用的是 .Net 4 或更高版本，那么我建议您使用新的 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).

使用该方法，您无需模拟任何 AD 查询，您的应用程序池仍可作为普通应用程序池帐户运行.

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 应用程序池标识?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！