IIS7上的ASP.NET身份验证问题-Windows身份验证的User.Identity.Name为空

Question

我们在使用Windows身份验证的MVC 3的ASP.NET 4.0上拥有一个ASP.NET应用程序。

从Visual Studio 2010运行时，所有功能均按预期方式运行，但是当部署到IIS7时，Windows登录用户将永远不会填充（检查User.Identity.Name）。 也不显示有关用户凭据的对话框提示。

web.config设置：

<authentication mode="Windows" />

在IIS中，我可以看到启用了Windows身份验证，并且启用了匿名（禁用匿名会导致403禁止并且没有显示任何内容）。

我尝试过启用和禁用“内核模式身份验证”（useKernelMode =“ true”），但这似乎没有任何区别。 尽管我确实记得我们必须在其他服务器上的另一个站点上禁用此设置才能使身份验证正常工作（可能指向堆栈下方的潜在问题吗？）。

如果有用，请从IIS的applicationHost.config中：

<security>
  <authentication>
    <anonymousAuthentication enabled="true" />
    <digestAuthentication enabled="false" />
    <basicAuthentication enabled="false" />
    <windowsAuthentication enabled="true" useKernelMode="false">
      <providers>
        <clear />
        <add value="NTLM" />
      </providers>
    </windowsAuthentication>
  </authentication>
</security>

任何想法可能是什么问题？

在此先感谢您的任何建议。

更新1

我设法找到另一台IIS7服务器进行测试，发现是否禁用了匿名访问，一切都按预期进行。 但是，即使我也禁用了匿名访问，我仍然在原始IIS7服务器上遇到问题（我现在保持匿名禁用）。 因此，我想堆栈中肯定还有一些问题。 有任何想法吗？ 我需要修复一些问题，因为它会不断弹出并咬我们，我想。

更新2

如果我在有问题的IIS7框中启用了“摘要式身份验证”，那么我将遇到登录提示对话框的挑战，如果提供适当的凭据，一切将按预期进行。 但是，作为一个内部Web应用程序且用户已经登录到域，我们真的不希望以这种方式挑战他们。 凭据在第二个IIS7框上工作时应该透明地传递。

更新3

一些进展...我发现，如果Web应用程序位于根目录中而不是子站点中，则直接编辑IIS7的applicationHost.config文件以提供以下身份验证设置即可使该站点按预期方式工作：

<authentication>
  <anonymousAuthentication enabled="false" />
  <windowsAuthentication enabled="true">
    <providers>
      <clear />
      <add value="NTLM" />
    </providers>
  </windowsAuthentication>
  <digestAuthentication enabled="false" />
</authentication>

使用IIS7的UI来配置身份验证并不能给出正确的结果。 身份验证项在病房之后丢失（因为我猜想IIS7假定它们已被继承）或设置错误（windowsAuthentication似乎需要上面提供的提供者配置才能正确运行）。

不幸的是，有问题的Web应用程序实际上是一个子应用程序，因为它有一个内部版本（使用Windows身份验证> www.site.com/internal）和一个外部版本（使用表单身份验证> www.site.com/external）。 我仍然无法通过身份验证作为子应用程序工作。 我刚得到一个“错误代码：403禁止”。

Answer 1

在这种情况下，这是Microsoft ISA Server问题。 似乎该请求是通过Windows身份验证站点的ISA内部路由的，一旦删除了ISA，问题就消失了。

我对ISA及其路由请求的方式不甚了解，但我认为由于某些人会配置某些规则，因此它肯定已经从请求中剥离了一些重要信息。

作为一个旁注，以防它有助于诊断类似的设置：网络管理员告诉我，内部流量不是通过ISA路由的，但是在内部ping网站表明ISA实际上在起作用。

Answer 2

您提到禁用匿名访问在另一台服务器上有效，但是在主服务器上，您遇到403错误。 因此，我将在运行站点的文件夹中检查基于文件的权限。 过去，我需要授予\\ Network Serivce帐户对站点文件夹和所有子文件夹的完全控制权限，否则我将遇到403错误。 检查正在运行的服务器上的文件许可权，并查看与正在运行的服务器是否存在差异。

另外，如果这不是问题，我建议比较两个服务器之间的所有其他IIS设置，因为您知道它可以在一个服务器上运行，而不能在另一个服务器上运行。 找到差异。