在安装了ASP.NET 4.0的Windows Server 2008上,有一系列相关的用户账户,我不明白它们各自代表什么,它们之间有何区别,以及我的应用程序实际运行在哪个账户下。以下是列表:
- IIS_IUSRS
- IUSR
- DefaultAppPool
- ASP.NET v4.0
- NETWORK_SERVICE
- LOCAL SERVICE。
它们分别代表什么?
在安装了ASP.NET 4.0的Windows Server 2008上,有一系列相关的用户账户,我不明白它们各自代表什么,它们之间有何区别,以及我的应用程序实际运行在哪个账户下。以下是列表:
它们分别代表什么?
这是一个非常好的问题,不幸的是许多开发人员在做网站开发和设置IIS时并没有充分考虑到IIS/ASP.NET的安全性,所以我们开始吧...
以下是涉及的身份:
IIS_IUSRS:
这类似于旧版的 IIS6 IIS_WPG
组。它是一个内置组,其安全性被配置为此组的任何成员都可以扮演应用程序池标识的角色。
IUSR:
此帐户类似于旧版的 IUSR_<MACHINE_NAME>
本地帐户,是 IIS5 和 IIS6 网站的默认匿名用户(即通过网站属性的“目录安全性”选项卡进行配置的用户)。
有关 IIS_IUSRS
和 IUSR
的更多信息,请参见:
DefaultAppPool:
IIS AppPool\<pool name>
的“合成”帐户,用作池标识。在这种情况下,池的生命周期中将创建一个名为 IIS AppPool\DefaultAppPool
的合成帐户。如果删除了该池,则此帐户将不再存在。在为文件和文件夹应用权限时,必须使用 IIS AppPool\<pool name>
添加它们。您还将无法在计算机的用户管理器中看到这些池账户。有关更多信息,请参见以下内容:Application Pool Identities
ASP.NET v4.0:
-这将是 ASP.NET v4.0 应用程序池的应用程序池标识。请参阅上面的DefaultAppPool
。
NETWORK SERVICE:
-
NETWORK SERVICE
账户是Windows 2003引入的内置身份。 NETWORK SERVICE
是一个低权限帐户,您可以在其中运行应用程序池和网站。在运行在Windows 2003池中的网站仍然可以模拟站点的匿名帐户(IUSR_或您配置为匿名身份的任何内容)。
在Windows 2008之前的ASP.NET中,您可以让ASP.NET在应用程序池帐户(通常为NETWORK SERVICE
)下执行请求。或者,您可以通过<identity impersonate="true" />
设置在本地的web.config
文件中配置ASP.NET来模拟站点的匿名帐户(如果该设置被锁定,则需要由管理员在machine.config
文件中完成)。
在共享托管环境中,设置<identity impersonate="true">
很常见,其中使用共享应用程序池(与部分信任设置一起使用以防止解开模拟帐户)。
在IIS7.x/ASP.NET中,模拟控制现在通过站点的身份验证配置功能进行配置。因此,您可以配置为作为池标识、IUSR
或特定的自定义匿名帐户运行。
本地服务:
本地服务
帐户是服务控制管理器使用的内置帐户。它在本地计算机上拥有最小的特权集。它具有相当有限的使用范围:
本地系统:
虽然你没有问及,但我为了完整性而添加。这是一个本地内置帐户。它具有相当广泛的特权和信任。您永远不应配置网站或应用程序池以在此标识下运行。
实践中:
在实践中,保护网站的首选方法(如果该网站拥有自己的应用程序池-这是IIS7的MMC中新站点的默认设置)是使用Application Pool Identity
。这意味着将站点的Identity设置为其应用程序池的高级设置中的Application Pool Identity
:
右键单击并编辑匿名身份验证条目:
请确保选择了"应用程序池标识":
当您开始应用文件和文件夹权限时,您需要授予应用程序池标识所需的任何权限。例如,如果您正在为 ASP.NET v4.0
池授予应用程序池标识权限,则可以通过资源管理器执行此操作:
或者您可以使用ICACLS.EXE
实用程序来执行此操作:
icacls c:\wwwroot\mysite /grant "IIS AppPool\ASP.NET v4.0":(CI)(OI)(M)
...或者...如果您的站点应用程序池名为BobsCatPicBlog
,则:
icacls c:\wwwroot\mysite /grant "IIS AppPool\BobsCatPicBlog":(CI)(OI)(M)
更新:
我刚刚偶然发现了这个2009年的优秀答案,其中包含了许多有用的信息,非常值得一读:
<system.webServer>
和其他IIS特定配置;结果是当您部署时,您永远不知道您的东西是否在IIS上工作。在VS + Full Fat IIS中进行调试的问题在于需要相当多的知识才能使其正常工作。当然,在理想的世界中,开发人员应该知道如何使其正常工作,但许多人只想编写代码并将其推送到已为他们管理的某个托管环境中。 - Kev