【问题标题】：IIS application using application pool identity loses primary token?使用应用程序池标识的 IIS 应用程序丢失主令牌？
【发布时间】：2012-03-29 23:32:36
【问题描述】：

（这是一个关于模糊问题的问题。我尝试提供所有相关数据，希望有人提供有用的信息；对于冗长的描述表示歉意。）

我们的网络应用

我们有一个在 IIS 7.5 中运行的 .NET 4 Web 应用程序访问 Active Directory 和 SQL Server 数据库。

通过将应用程序池的标识设置为ApplicationPoolIdentity，此 Web 应用程序在虚拟“应用程序池标识”下运行。虚拟身份的简明描述可以在a * answer 和它所引用的博客文章中找到：应用程序池身份只是一个附加组，它添加到作为“网络服务”运行的 Web 应用程序的工作进程中。但是，one source 含糊地暗示“网络服务和 ApplicationPoolIdentity 确实存在 IIS.net 站点文档未发布的差异”。因此，虚拟身份可能不仅仅是一个附加组。

我们选择使用 ApplicationPoolIdentity，而不是 NetworkService，因为它成为 IIS 7.5 中的默认设置（例如，请参阅 here），并且根据 Microsoft 的建议：“此身份允许管理员指定仅与运行应用程序池的身份，从而提高服务器安全性。” （来自processModel Element for add for applicationPools [IIS 7 Settings Schema]）“应用程序池标识是一种强大的新隔离功能”，它“使运行的IIS 应用程序更加安全可靠。”（来自IIS.net article "Application Pool Identities"）

应用程序使用集成 Windows 身份验证，但使用 <identity impersonate="false"/>，因此不是最终用户的身份而是虚拟应用程序池身份用于运行我们的代码。

此应用程序使用 System.DirectoryServices 类（即 ADSI API）查询 Active Directory。在大多数地方，这是在不指定额外的用户名/密码或其他凭据的情况下完成的。

此应用程序还使用连接字符串中的Integrated Security=true 连接到 SQL Server 数据库。如果数据库是本地的，那么我们看到IIS APPPOOL\OurAppPoolName是用来连接数据库的；如果数据库是远程的，则使用机器帐户OURDOMAIN\ourwebserver$。

我们的问题

我们经常遇到以下问题，即工作安装开始以下列方式之一失败。

当数据库位于远程系统上时，数据库连接开始失败：“用户 'NT AUTHORITY\ANONYMOUS LOGON' 登录失败。原因：基于令牌的服务器访问验证因基础结构错误而失败。检查以前的错误。”之前的错误是“错误：18456，严重性：14，状态：11”。所以现在OURDOMAIN\ourwebserver$ 似乎不再使用，而是尝试匿名访问。（我们有轶事证据表明此问题在 UAC 关闭时发生，并且在打开 UAC 后它消失了。但请注意，更改 UAC 需要重新启动...）IIS.net thread "use ApplicationPoolIdentity to connect to SQL" 中报告了类似的问题，特别是在 @ 987654330@.
通过 ADSI (System.DirectoryServices) 的 Active Directory 操作开始失败，出现错误 0x8000500C（“未知错误”）、0x80072020（“发生操作错误”）或 0x200B（“指定的目录服务属性或值不存在”）。
从 Internet Explorer 登录应用程序开始失败，出现 HTTP 401 错误。但是如果在 IIS 中我们将 NTLM 放在 Negotiate 之前，那么它会再次起作用。（请注意，Kerberos 需要访问 AD，但 NTLM 不需要。）IIS.net thread "Window Authentication Failing with AppPool Identity" 中报告了类似的问题。

我们的假设和解决方法

在将应用程序池从 ApplicationPoolIdentity 切换到 NetworkService 时，至少 AD 和登录问题似乎总能消失。（我们发现one report 证实了这一点。）

页面"Troubleshooting Authentication Problems on ASP Pages" 有一些与主要和次要令牌相关的建议，我发现令人鼓舞的是它链接了我们的前两个错误：它提到了NT AUTHORITY\ANONYMOUS LOGON 访问，以及 AD 错误 0x8000500C 和“指定目录服务属性或值不存在”。

（同一页面还提到了 ADSI 架构缓存问题，但我们可以找到的关于该主题的所有内容都是旧的。现在我们认为这无关紧要。）

基于上述，我们当前的工作假设是，只有在虚拟应用程序池身份下运行时，我们的 Web 应用程序（IIS？工作进程？）才会突然丢失其主令牌，这样 IIS 就只有一个二级令牌，所以对 Active Directory 和 SQL Server 的所有访问都是匿名完成的，导致上述所有错误。

现在我们打算从 ApplicationPoolIdentity 切换到 NetworkService。希望这可以消除上述所有问题。但我们不确定；如果可能的话，我们想切换回去。

我们的问题

上述假设是否正确，如果正确，这是 IIS/Windows/.NET 中的错误吗？在什么情况下会发生这种主要令牌丢失？

【问题讨论】：

FWIW 如果应用服务器、sql 服务器和域控制器之间的服务器时钟不同步超过 20 分钟（但这是使用标准域凭据），我们已经注意到类似的问题。
@marnixKlooster 在您之后几年，但完全相同的问题。感谢您的研究！ *.com/questions/26384891/…

标签： asp.net active-directory iis-7.5 adsi applicationpoolidentity

【解决方案1】：

通过 Microsoft 支持，我发现我们遇到了Microsoft Knowledge Base article KB2545850 中描述的问题。这仅在使用 ApplicationPoolIdentity 时发生。它很容易发生，即在更改机器帐户密码后（默认情况下每 30 天自动发生一次），然后重新启动 IIS（例如，通过iisreset）。请注意，根据 Microsoft 和我们的观察，重启后问题就会消失。

根据 Microsoft 的说法，无法检查您的 Windows/IIS 是否已进入此状态。

Microsoft 在此知识库文章中附加了一个修补程序。没有迹象表明该修补程序何时会正式发布，而且该修补程序已经使用了 10 个月。在我们的具体情况下，我们决定改用 NetworkService。

【讨论】：

附加说明：我没有发现“ADSI 架构缓存问题”在我们的情况中起作用（所有已知部署都使用 Windows Server 2008 R2 SP1）。
所以 - 坚持默认设置麻烦多于其价值。我一直对这个“虚拟”用户有些怀疑。
我们遇到了与您描述的完全相同的问题 - 401 错误和 ADSI 故障。决定走KB路线。使用 NETWORK SERVICE 作为工作进程凭据会带来太多潜在的安全问题 - 一个站点的妥协可能会影响使用 NETWORK SERVICE 的任何其他事情。许多服务和应用程序向该帐户授予太多默认权限，无法安全地将其用于 Web 请求。
非常感谢这篇刚刚解决了类似问题的帖子。
不错的发现！当我们部署我们的 WCF 服务时，我们遇到了一个问题，它开始以 401 响应带有协商身份验证的调用。我们在部署时停止 iis，并在复制文件后启动它。在我们启动服务后，它会以 401 响应某些调用（在 iis 停止之前工作）这些调用带有协商身份验证。重启解决了这个问题。 WCF 服务使用应用程序池标识。我认为这可能是相同的根本原因。

【解决方案2】：

请参阅https://serverfault.com/a/403534/126432 了解我的 cmets 对相同问题/解决方案的了解。

使用您链接到的修补程序，我可以让 ApplicationPoolIdentity 像文档所说的那样工作。这个hotfix没有具体描述NT AUTHORITY\ANONYMOUS LOGON访问网络资源的解决方案，但它与更改计算机密码有关。底线是它对我有用，至少到目前为止。

【讨论】：

【解决方案3】：

这也与使用 Active Directory 身份验证的 Umbraco 有关。有时您可能会遇到此异常：

配置错误

指定的目录服务属性或值不存在

这显然是由此处概述的问题引起的。重新启动总是会修复它。

【讨论】：