（这是一个关于模糊问题的问题。我试图提供所有相关数据，希望有人提供有用的信息;为长篇描述道歉。）
我们的网络应用
我们有一个在IIS 7.5中运行的.NET 4 Web应用程序，可以访问Active Directory和SQL Server数据库。
通过将应用程序的应用程序池的标识设置为ApplicationPoolIdentity，此Web应用程序在虚拟“应用程序池标识”下运行。有关虚拟身份的简明描述可以在a StackOverflow 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"中报告了类似的问题，具体而言在one reply。
通过ADSI（System.DirectoryServices）的Active Directory操作开始失败，错误0x8000500C（“未知错误”），0x80072020（“发生操作错误。”）或0x200B（“指定的目录服务属性或价值不存在“）。
从Internet Explorer登录应用程序开始失败，出现HTTP 401错误。但是如果在IIS中我们然后在谈判之前放置NTLM然后再次工作。 （请注意，Kerberos需要访问AD，但NTLM不需要访问AD。）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中的错误吗？在哪种情况下会发生主要令牌丢失？
答案 0 :(得分：35)
通过Microsoft支持我发现我们遇到了Microsoft Knowledge Base article KB2545850中描述的问题。这仅在使用ApplicationPoolIdentity时发生。它很容易发生，即在更改机器帐户密码后（默认情况下每30天自动发生一次），然后重新启动IIS（例如，通过iisreset）。请注意，根据微软和我们的观察，重启后问题就会消失。
根据Microsoft的说法，无法检查您的Windows / IIS是否已进入此状态。
Microsoft在此知识库文章中附加了一个修补程序。没有迹象表明该修补程序何时将进入官方发布，并且该修补程序已经有10个月了。在我们的具体情况中，我们决定转而使用NetworkService。
答案 1 :(得分：2)
有关同一问题/解决方案的评论，请参阅https://serverfault.com/a/403534/126432。
使用您链接的修补程序允许我按照文档说的那样使ApplicationPoolIdentity正常工作。此修补程序没有具体描述用于访问网络资源的解决方案，如NT AUTHORITY \ ANONYMOUS LOGON，但它与计算机密码更改有关。最重要的是，至少到目前为止它对我有用。
答案 2 :(得分：0)
这对于使用Active Directory身份验证的Umbraco也很重要。 有时可能会遇到这种情况：
这显然是由此处列出的问题引起的。重新启动总是修复它。