简体繁体 English

如何正确设置IIS 7应用程序池标识？

[英]How to set up IIS 7 application pool identity correctly?

原文 2013-03-28 08:26:37 2 2 c#/ asp.net/ asp.net-mvc-3/ iis-7/ 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: 将我的网站部署到IIS7.5后，我发现了一个奇怪的行为：默认情况下，当应用程序池标识为ApplicationPoolIdentity （如IIS应用程序池标识中所推荐的那样）， Ninject似乎被忽略，因为我在创建时遇到以下错误第一个控制器：

System.InvalidOperationException: An error occurred when trying to create a controller of type '..MainController'. System.InvalidOperationException：尝试创建类型为“..MainController”的控制器时发生错误。 Make sure that the controller has a parameterless public constructor. 确保控制器具有无参数的公共构造函数。 ---> System.DirectoryServices.DirectoryServicesCOMException: An operations error occurred. ---> System.DirectoryServices.DirectoryServicesCOMException：发生操作错误。

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. 我试图将IIS AppPool\\<MySiteAppPool> FullAccess授予包含该站点（包括所有子文件夹和文件）的文件夹，但这并没有改变任何内容。

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 is installed according to Setting up an MVC3 application tutorial through the NuGet package. 根据通过NuGet包设置MVC3应用程序教程来安装Ninject。

I am not sure, if it's relevant, the site is supposed to work in a domain intranet with windows authentication. 我不确定，如果它是相关的，该站点应该在具有Windows身份验证的域Intranet中工作。

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. 至于我渴望使用推荐的方式，我希望拥有ApplicationPoolIdentity ，而不是域帐户。

What can this be connected with? 这有什么用？ Is it possible to mix all these together? 是否可以将所有这些混合在一起？

Here is an SO thread with a similar issue: ASP.NET MVC 4 + Ninject MVC 3 = No parameterless constructor defined for this object . 这是一个具有类似问题的SO线程： ASP.NET MVC 4 + Ninject MVC 3 =没有为此对象定义的无参数构造函数。 However no suitable answer there at all either. 但是根本没有合适的答案。

As a deleted comment suggested, I tried using NetworkSerive as the identity. 作为删除的评论建议，我尝试使用NetworkSerive作为身份。 And it worked properly. 它运作正常。 However, I guess this is not much better, than a non-privileged domain account. 但是，我想这并不比非特权域帐户好多少。

EDIT 编辑

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上的Windows身份验证，但我希望在那里使用客户端用户的凭据。

Based on comments 根据评论

Agree that a remote sql server can be accessed with the authenticated credentials via impersonation. 同意通过模拟可以使用经过身份验证的凭据访问远程SQL Server。

However it is still not clear what the problem is with ApplicationPoolIdentity and Ninject. 但是，仍然不清楚ApplicationPoolIdentity和Ninject的问题是什么。

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. 这个方面对我来说仍然不清楚，因为仍然可以使IIS使用LoadUserProfile属性加载用户配置文件。 I can't get, what is IIS going to load, if there is no profile for the virtual account? 如果虚拟帐户没有配置文件，我无法获取，IIS将加载什么？

It is said there: 有人说：

IIS doesn't load the Windows user profile, but certain applications might take advantage of it anyway to store temporary data. IIS不会加载Windows用户配置文件，但某些应用程序可能会利用它来存储临时数据。 SQL Express is an example of an application that does this. SQL Express是执行此操作的应用程序的示例。 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. NETWORKSERVICE帐户的用户配置文件由系统创建，始终可用。 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. 只有标准应用程序池（DefaultAppPool和Classic .NET AppPool）在磁盘上具有用户配置文件。 No user profile is 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". 但是，如果需要，可以通过将“LoadUserProfile”属性设置为“true”来配置IIS应用程序池以加载用户配置文件。

I found the following thread on serverfault.com: 我在serverfault.com上找到了以下主题：

How can I assign active directory permission to the default app pool identity 如何将活动目录权限分配给默认应用程序池标识

There it is also stated that app pool identity is unable to work as a network service, in particular, query the AD. 在那里还指出，应用程序池标识不能用作网络服务，特别是查询AD。

2 个解决方案

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. iispool \\ appPoolName帐户被称为虚拟帐户并被添加到Windows 2008.这个想法认为它们并不是真正意义上的帐户。 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. 您计算机上的许多服务都使用networkService，这是一个具有网络访问权限的内置帐户。 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. 虚拟帐户（例如IIS使用的帐户）通过显示为不同的帐户来防止这种情况，同时仍然是同一个帐户 - 您的asp.net应用程序仍然在技术上作为网络服务运行并授予此帐户访问权限仍然有用的功能。 This also means if you need to access network resources, the iispool accounts would do so as networkservice does & use the machines domain account. 这也意味着如果您需要访问网络资源，iispool帐户会这样做，因为网络服务会使用计算机域帐户。

If you are accessing a remote sql server, this is the account you should add to allow access from your web server. 如果要访问远程SQL Server，则应添加此帐户以允许从Web服务器进行访问。 I wouldn't advise using impersonation, unless you really really need to see who the user is on the SQL server. 我不建议使用模拟，除非你真的需要查看用户在SQL服务器上的用户。 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. 如果controllerA注入了ClassB，而ClassB又注入了ClassC并且该类没有注入ClassD，那么整个链就会失败。 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 . 从问题中的细节来看，它听起来很像是一个导致抛出COMException的权限问题，这阻止了Ninject实例化MainController 。 The exception is related to System.DirectoryServices which are the classes used to query Active Directory. 该异常与System.DirectoryServices有关， System.DirectoryServices是用于查询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. 当IIS在正常的应用程序池帐户下运行时，这些帐户无权对Active Directory进行查询，并且可能抛出COMException 。 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. 我认为异常中的实际消息（找不到无参数构造函数）有点像红色鲱鱼，并且Ninject试图回退到另一个构造函数，因为正常的消息不起作用。

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. 这可以解释为什么当您更改IIS应用程序池以作为域帐户运行时，它突然起作用，因为该帐户确实有权查询域。

It's not clear from the question whether or not you are using System.DirectoryServices yourself or whether Ninject/IIS/ASP is using them. 从您自己是否正在使用System.DirectoryServices或Ninject / IIS / ASP是否正在使用它们的问题中不清楚。 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. 如果您自己使用它们，请确保AD类中的任何构造函数都不能抛出异常（捕获它们并记录它们或其他东西），这会阻止您的应用程序在启动时崩溃。 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. 如果您需要IIS作为普通应用程序池帐户运行（这是一个好主意），但仍然将AD作为域用户进行查询，那么您可以指定DirectoryEntry的凭据并使用DirectorySearcher进行AD搜索。 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). 如果您使用的是.Net 4或更高版本，那么我建议您使用新的System.DirectoryServices.AccountManagement类（这也允许您指定凭据）。

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. 使用该方法，您不需要对AD查询进行任何模拟，您的应用程序池仍可以作为普通的应用程序池帐户运行。