使用应用程序池标识的IIS应用程序丢失主令牌?

Mar*_*ica 59 asp.net adsi active-directory iis-7.5 applicationpoolidentity

(这是一个关于模糊问题的问题.我试图提供所有相关数据,希望有人提供有用的信息;为长篇描述道歉.)

我们的网络应用

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

此Web应用程序在一个虚拟的"应用程序池标识"运行,通过设置应用程序的应用程序池的标识ApplicationPoolIdentity.可以在StackOverflow答案和它所引用的博客文章中找到虚拟身份的简明描述:应用程序池标识只是一个附加组,它被添加到作为"网络服务"运行的Web应用程序的工作进程中.但是,一位消息人士模糊地暗示"网络服务和ApplicationPoolIdentity确实存在IIS.net站点文档不发布的差异".因此,虚拟身份可能不仅仅是一个额外的群体.

我们选择使用ApplicationPoolIdentity而不是NetworkService,因为它成为IIS 7.5中的默认设置(参见,例如,此处),并且根据Microsoft的建议:"此身份允许管理员指定仅与应用程序所属身份相关的权限池正在运行,从而提高了服务器的安全性." (来自processModel元素,用于为applicationPools添加[IIS 7设置架构])"应用程序池标识是一个强大的新隔离功能","使运行的IIS应用程序更安全可靠."(来自IIS.net文章"应用程序池标识")

该应用程序使用集成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线程中报告了类似的问题"使用ApplicationPoolIdentity连接到SQL",特别是在一个回复中.

  • 通过ADSI(System.DirectoryServices)的Active Directory操作开始失败,错误0x8000500C("未知错误"),0x80072020("发生操作错误.")或0x200B("指定的目录服务属性或值不存在") .

  • 从Internet Explorer登录应用程序开始失败,出现HTTP 401错误.但是如果在IIS中我们然后在谈判之前放置NTLM然后再次工作.(请注意,Kerberos需要访问AD,但NTLM不需要访问AD.)IIS.net线程"使用AppPool标识失败的窗口身份验证"中报告了类似的问题.

我们的假设和解决方法

将应用程序池从ApplicationPoolIdentity切换到NetworkService时,至少AD和登录问题似乎总是消失.(我们发现有一份报告证实了这一点.)

页面"解决ASP页面上的身份验证问题"有一些与主要和次要令牌相关的建议,我发现它令人鼓舞的是它链接了我们的前两个错误:它提到了NT AUTHORITY\ANONYMOUS LOGON访问,AD错误0x8000500C和"指定的目录服务属性或值不存在".

(同一页面也提到了ADSI架构缓存问题,但我们在该主题上找到的所有内容都是旧的.现在我们认为这是无关的.)

基于以上所述,我们当前的工作假设是,只有在虚拟应用程序池标识下运行时,我们的Web应用程序(IIS?工作进程?)突然丢失其主令牌,因此IIS只有一个辅助令牌,所以所有匿名访问Active Directory和SQL Server会导致上述所有错误.

目前我们打算从ApplicationPoolIdentity切换到NetworkService.希望这会使上述所有问题都消失.但我们不确定; 我们想尽可能转回去.

我们的问题

以上假设是否正确,如果是,这是IIS/Windows/.NET中的错误吗?在哪种情况下会发生主要令牌丢失?

Mar*_*ica 35

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

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

Microsoft在此知识库文章中附加了一个修补程序.没有迹象表明该修补程序何时将进入官方发布,并且该修补程序已经有10个月了.在我们的具体情况中,我们决定改用NetworkService.