(这是一个关于一个模糊问题的问题.我试图展示所有相关数据，希望有人能提供有用的信息；对于冗长的描述，我深表歉意.)
Our web app个
我们有一个.NET 4 web应用程序运行在IIS 7.5中，访问Active Directory和SQL Server数据库.
通过将应用程序的应用程序池标识设置为ApplicationPoolIdentity，此web应用程序在虚拟"应用程序池标识"下运行.关于虚拟身份的简要描述可以在a StackOverflow answer和它所指的博客帖子中找到:应用程序池身份只是添加到web应用程序的工作进程(作为"网络服务"运行)中的一个附加组.然而，one source模糊地暗示"网络服务和ApplicationPoolIdentity确实存在差异，IIS.net网站文档不会发布."因此，虚拟身份可能不仅仅是一个额外的群体.
我们 Select 使用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$.
Our problems
我们经常会遇到这样的问题:一个正常工作的安装开始以以下方式之一出现故障.
当数据库位于远程系统上时，数据库连接开始失败:"用户"NT AUTHORITY\ANONYMOUS LOGON"登录失败.原因:基于令牌的服务器访问验证失败，出现基础 struct 错误.请判断以前的错误."前一个错误是"错误:18456，严重性:14，状态:11"因此，现在
OURDOMAIN\ourwebserver$似乎不再使用，而是try 匿名访问.(我们有轶事证据表明，这个问题发生在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不需要.)据报道，IIS.net thread "Window Authentication Failing with AppPool Identity"例患者也有类似问题.
Our hypothesis and workaround
至少在将应用程序池从ApplicationPoolIdentity切换到NetworkService时，广告和登录问题似乎总是会消失.(我们发现有one report人证实了这一点.)
第"Troubleshooting Authentication Problems on ASP Pages"页提供了一些与主令牌和次令牌相关的建议，我发现令人鼓舞的是，它将我们的前两个错误联系起来:它提到NT AUTHORITY\ANONYMOUS LOGON访问，以及广告错误0x8000500C和"指定的目录服务属性或值不存在".
(同一页也提到了ADSI模式缓存问题，但是我们在这个主题上发现的所有东西都是旧的.现在我们认为这是无关的.)
基于以上，我们目前的工作hypothesis是，只有在虚拟应用池身份下运行时才有our web application (IIS? worker process?) suddenly loses its primary token，使得IIS只有一个二级令牌，使得所有对Active Directory和SQL Server的访问都是匿名进行的，导致了上述所有错误.
目前，我们打算从ApplicationPoolIdentity切换到NetworkService.希望这能解决上述所有问题.但我们不确定；如果可能的话，我们想换回go .
Our question个
上述假设正确吗？如果正确，这是IIS/Windows/.NET中的错误吗？这种主令牌丢失是在什么情况下发生的？