使用应用程序池标识IIS应用程序失去主令牌？ [英] IIS application using application pool identity loses primary token?

问题描述

（这是一个关于一个模糊的问题问题，我尝试present所有相关数据，希望有人有有用的信息;道歉的长描述。）

(This is a question about a vague problem. I try to present all relevant data, in the hope that someone has helpful information; apologies for the long description.)

我们的Web应用程序

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

We have a .NET 4 web application running in IIS 7.5 accessing Active Directory and a SQL Server database.

此Web应用程序在一个虚拟的应用程序池标识运行，应用程序的应用程序池的身份设置的 ApplicationPoolIdentity 。一简要说明虚拟身份可以在出现StackOverflow的答案和博客文章到它是指：一个应用程序池标识刚刚被添加到正在运行的网络服务Web应用程序的工作进程附加组。然而，一个源含糊地表明，网络服务和ApplicationPoolIdentity确实有区别的IIS.net网站文件不公布。因此，一个虚拟身份可能不仅仅是一个额外的组。

This web application is running under a virtual 'app pool identity', by setting the Identity of the application's application pool to ApplicationPoolIdentity. A concise description of virtual identities can be found in a StackOverflow answer, and the blog post to which it refers: an app pool identity is just an additional group which is added to the web application's worker processes which is running as 'network service'. However, one source vaguely suggests that "Network Service and ApplicationPoolIdentity do have differences that IIS.net site documents do not publish." So a virtual identity might be more than just an additional group.

我们选择使用ApplicationPoolIdentity，而不是网络服务，因为它成为了默认的IIS 7.5中（例如，见的此处），并根据Microsoft的建议：这个身份允许管理员指定只，涉及到其下的应用程序池运行，从而提高服务器安全性的身份权限 （从<一个href="http://msdn.microsoft.com/en-us/library/bb386459.aspx#attributesAndElementsToggle">processModel元素添加对applicationPools [IIS 7设置架构] ）应用程序池标识是一个强大的新的隔离功能，这（从的IIS.net文章应用程序池标识）

We chose to use ApplicationPoolIdentity, as opposed to NetworkService, because it became the default in IIS 7.5 (see, e.g., here), and per Microsoft's recommendation: "This identity allows administrators to specify permissions that pertain only to the identity under which the application pool is running, thereby increasing server security." (from processModel Element for add for applicationPools [IIS 7 Settings Schema]) "Application Pool Identities are a powerful new isolation feature" which "make running IIS applications even more secure and reliable. " (from IIS.net article "Application Pool Identities")

该应用程序使用集成Windows身份验证，但 ＆LT;身份冒充=假/＆GT; ，这样不是最终用户的身份，但虚拟应用程序池标识用于运行我们的code

The application uses Integrated Windows Authentication, but with <identity impersonate="false"/>, so that not the end user's identity but the virtual app pool identity is used to run our code.

该应用程序查询使用<一个活动目录href="http://msdn.microsoft.com/en-us/library/system.directoryservices.aspx">System.DirectoryServices类，即，在ADSI的API。在大多数地方，这样做是不指定一个额外的用户名/密码或其他凭证。

This application queries Active Directory using the System.DirectoryServices classes, i.e., the ADSI API. In most places this is done without specifying an additional username/password or other credentials.

这个应用程序还连接字符串中使用集成安全性=真连接到SQL Server数据库。如果数据库是本地的，那么我们可以看到， IIS APPPOOL \ OurAppPoolName 是用来连接到数据库;如果数据库是远程的，那么计算机帐户 OURDOMAIN \ ourwebserver $ 被使用。

This application also connects to a SQL Server database using Integrated Security=true in the connection string. If the database is local, then we see that IIS APPPOOL\OurAppPoolName is used to connect to the database; if the database is remote, then the machine account OURDOMAIN\ourwebserver$ is used.

我们的问题

我们经常在那里有一个工作开始安装在下列方式之一失败的问题。

We regularly have issues where a working installation starts to fail in one of the following ways.

• 在数据库是在远程系统上，则数据库连接，启动失败：登录失败，用户NT AUTHORITY \ ANONYMOUS登录原因：基于令牌的服务器访问验证失败，出现基础结构错误。检查previous的错误。在previous错误是错误：18456，严重性：14，状态：11。如此看来，现在 OURDOMAIN \ ourwebserver $ 时已不再使用，而是匿名访问尝试。 （我们有传闻证据表明，当UAC被关闭出现这个问题，而且它走了UAC的切换后，但请注意，改变UAC需要重新启动......。）类似的问题被报道的IIS.net线程使用ApplicationPoolIdentity连接到SQL，特别是在的one回复。

• When the database is on a remote system, then the database connection starts to fail: "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors." The previous error is "Error: 18456, Severity: 14, State: 11." So it seems that now OURDOMAIN\ourwebserver$ is not used anymore, but instead anonymous access is attempted. (We have anecdotal evidence that this problem occurred when UAC was switched off, and that it went away after switching on UAC. But note that changing UAC requires a reboot...) A similar problem is reported in IIS.net thread "use ApplicationPoolIdentity to connect to SQL", specifically in one reply.

通过ADSI的Active Directory操作（System.DirectoryServices中）开始失败，错误0x8000500C（未知错误），0x80072020（发生操作错误。），或0x200B（指定的目录服务属性或值不存在）。

Active Directory operations through ADSI (System.DirectoryServices) start to fail with error 0x8000500C ("Unknown Error"), 0x80072020 ("An operations error occurred."), or 0x200B ("The specified directory service attribute or value does not exist").

登录到从Internet Explorer的应用程序启动失败，与HTTP 401错误。但是，如果在IIS中，我们然后把NTLM前协商，然后它的作品了。 （请注意是需要的Kerberos而不是NTLM，获得AD。）类似的问题被报道 IIS.net线程窗口身份验证的应用程序池标识失败。

Signing in to the application from Internet Explorer starts to fail, with HTTP 401 errors. But if in IIS we then put NTLM before Negotiate then it works again. (Note that access to AD is needed for Kerberos but not for NTLM.) A similar problem is reported in IIS.net thread "Window Authentication Failing with AppPool Identity".

我们的假设和解决方法

目前至少AD和登录的问题似乎总是离ApplicationPoolIdentity切换应用程序池时，网络服务走开。 （我们发现一份报告证实这一点。）

At least the AD and sign-in problems always seem to go away when switching the application pool from ApplicationPoolIdentity to NetworkService. (We found one report confirming this.)

页故障排除验证问题上的ASP页面具有与主要与一些建议二级令牌，以及我感到鼓舞的是，它连接第一我们的两个错误：它提到 NT AUTHORITY \ ANONYMOUS登录接入和AD错误0x8000500C和指定的目录服务属性或值不存在。

Page "Troubleshooting Authentication Problems on ASP Pages" has some suggestions related to primary vs. secondary tokens, and what I find encouraging is that it links the first two of our errors: it mentions NT AUTHORITY\ANONYMOUS LOGON access, and AD errors 0x8000500C and "The specified directory service attribute or value does not exist".

（在同一页面中还提到ADSI架构缓存的问题，但一切，我们可以找到关于该主题已经老了。现在，我们认为这是不相关的。）

(The same page also mentions ADSI schema cache problems, but everything we can find on that topic is old. For now we consider this to be unrelated.)

根据以上情况，我们目前工作的假设的是，在一个虚拟的应用程序池标识仅运行时的我们的Web应用程序（IIS？工作进程？）突然失去了主令牌的，从而使IIS只有一个辅助令牌，让所有访问Active Directory和SQL Server是匿名进行，导致了所有的上述错误。

Based on the above, our current working hypothesis is that, only when running under a virtual app pool identity, our web application (IIS? worker process?) suddenly loses its primary token, so that IIS only has a secondary token, so that all access to Active Directory and SQL Server is done anonymously, leading to all of the above errors.

现在，我们打算从ApplicationPoolIdentity切换到网络服务。希望这使得所有上述问题消失。但是，我们不能肯定;我们想切换回如果可能的话。

For now we intend to switch from ApplicationPoolIdentity to NetworkService. Hopefully this makes all of the above problems go away. But we are not sure; and we would like to switch back if possible.

我们的问题

时的上述假设正确的，如果是的话，这是在IIS中/在Windows / .NET中的错误？在这情况下，这是否主令牌丢失发生的呢？

Is the above hypothesis correct, and if so, is this a bug in IIS/Windows/.NET? Under which circumstances does this primary token loss occur?

推荐答案

通过Microsoft支持我发现，我们跑进的 Microsoft知识库文章KB2545850 。这仅当ApplicationPoolIdentity时发生。它发生很容易，即后计算机帐户密码被更改（默认情况下会自动每隔30天），然后重新启动IIS（例如，通过 IISRESET ）。请注意，这个问题在重新启动后消失，根据微软和我们的意见。

Through Microsoft Support I found out that we ran into the issue described in Microsoft Knowledge Base article KB2545850. This only occurs when ApplicationPoolIdentity is used. It occurs very easily, namely, after the machine account password is changed (which by default happens automatically every 30 days), and then IIS is restarted (e.g., through iisreset). Note that the problem goes away after a reboot, according to Microsoft and our observations.

据微软称它是不可能的检查，如果您的Windows / IIS已经得到了进入这个状态。

According to Microsoft it is not possible to check if your Windows/IIS has gotten into this state.

微软已经连接到该知识库文章的修补程序。没有任何迹象表明，当该修补程序将被卷成正式交付，并修复已经是10个月大。在我们的具体情况，我们决定，而不是改用网络服务。

Microsoft has a hotfix attached to this KB article. There is no indication when that hotfix will be rolled into an official delivery, and the hotfix is already 10 months old. In our specific case, we decided to switch to NetworkService instead.

这篇关于使用应用程序池标识IIS应用程序失去主令牌？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！