IIS/ASP.NET有哪些用户账户,它们有何不同?

322

在安装了ASP.NET 4.0的Windows Server 2008上,有一系列相关的用户账户,我不明白它们各自代表什么,它们之间有何区别,以及我的应用程序实际运行在哪个账户下。以下是列表:

  • IIS_IUSRS
  • IUSR
  • DefaultAppPool
  • ASP.NET v4.0
  • NETWORK_SERVICE
  • LOCAL SERVICE。

它们分别代表什么?


使用 Windows Server 2012 和 ASP.NET 4.0 或更高版本? - Kiquenet
1个回答

479

这是一个非常好的问题,不幸的是许多开发人员在做网站开发和设置IIS时并没有充分考虑到IIS/ASP.NET的安全性,所以我们开始吧...

以下是涉及的身份:

IIS_IUSRS:

这类似于旧版的 IIS6 IIS_WPG 组。它是一个内置组,其安全性被配置为此组的任何成员都可以扮演应用程序池标识的角色。

IUSR:

此帐户类似于旧版的 IUSR_<MACHINE_NAME> 本地帐户,是 IIS5 和 IIS6 网站的默认匿名用户(即通过网站属性的“目录安全性”选项卡进行配置的用户)。

有关 IIS_IUSRSIUSR 的更多信息,请参见:

了解 IIS 7 中的内置用户和组帐户

DefaultAppPool:

如果应用程序池配置为使用应用程序池身份验证特性运行,则会动态创建一个称为 IIS AppPool\<pool name> 的“合成”帐户,用作池标识。在这种情况下,池的生命周期中将创建一个名为 IIS AppPool\DefaultAppPool 的合成帐户。如果删除了该池,则此帐户将不再存在。在为文件和文件夹应用权限时,必须使用 IIS AppPool\<pool name> 添加它们。您还将无法在计算机的用户管理器中看到这些池账户。有关更多信息,请参见以下内容:Application Pool Identities ASP.NET v4.0:-这将是 ASP.NET v4.0 应用程序池的应用程序池标识。请参阅上面的DefaultAppPoolNETWORK 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或特定的自定义匿名帐户运行。

本地服务:

本地服务帐户是服务控制管理器使用的内置帐户。它在本地计算机上拥有最小的特权集。它具有相当有限的使用范围:

LocalService Account

本地系统:

虽然你没有问及,但我为了完整性而添加。这是一个本地内置帐户。它具有相当广泛的特权和信任。您永远不应配置网站或应用程序池以在此标识下运行。

LocalSystem Account

实践中:

在实践中,保护网站的首选方法(如果该网站拥有自己的应用程序池-这是IIS7的MMC中新站点的默认设置)是使用Application Pool Identity。这意味着将站点的Identity设置为其应用程序池的高级设置中的Application Pool Identity

enter image description here

在网站中,您应该配置身份验证功能:

enter image description here

右键单击并编辑匿名身份验证条目:

enter image description here

请确保选择了"应用程序池标识"

enter image description here

当您开始应用文件和文件夹权限时,您需要授予应用程序池标识所需的任何权限。例如,如果您正在为 ASP.NET v4.0 池授予应用程序池标识权限,则可以通过资源管理器执行此操作:

enter image description here

点击“检查名称”按钮:

enter image description here

或者您可以使用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年的优秀答案,其中包含了许多有用的信息,非常值得一读:


2
@giammin - 为什么不呢?除非你有特殊情况,否则使用应用程序池标识是最安全的方法,只要每个站点都在自己的应用程序池中。虽然不想做“权威上诉”,但我已经担任共享Web主机工程师和安全专家15年了,在IIS7+上采用这种方法是显而易见的选择。 - Kev
1
@Kev,简单来说,我不喜欢在网站上给匿名用户写入权限。 - giammin
1
你的应用程序池可以通过使用IIS AppPool<name_of_apppool>来变得更加具体。另外,需要注意的是,IIS Express只能与IIS AppPool\ASP.NET v4.0配合使用,因为应用程序池虚拟账户未被创建。 - kevindaub
@daub815 - IIS Express的工作方式不同,因为它旨在在您的Windows登录下运行,并在开发和调试时根据需要启动和关闭。实际上,它并不实际使用或依赖于完整的IIS应用程序池或基础设施。 IIS Express的目的是为开发人员提供与真实环境相同的行为、特性和配置,因为VS的玩具Web服务器非常有限... - Kev
@daub815 - 即它不知道如何解析<system.webServer>和其他IIS特定配置;结果是当您部署时,您永远不知道您的东西是否在IIS上工作。在VS + Full Fat IIS中进行调试的问题在于需要相当多的知识才能使其正常工作。当然,在理想的世界中,开发人员应该知道如何使其正常工作,但许多人只想编写代码并将其推送到已为他们管理的某个托管环境中。 - Kev
显示剩余5条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接