我想设置窗体身份验证跨多个服务器和子域。我已经建立了像这样每个应用程序的静态机键：

I'm trying to set up forms authentication across multiple servers and subdomains. I have static machine keys set up for each application like so:

<system.web>
    <machineKey validationKey="574...7A7" 
                decryptionKey="2C3...A0D" 
                validation="HMACSHA256" 
                decryption="AES" />
</system.web>

...和我的窗体身份验证的配置相同为每个应用程序：

...and my forms authentication is configured the same for each application:

<forms loginUrl="/login" timeout="2880" defaultUrl="/" path="/" name=".SHAREDAUTH" domain="domain.com" protection="All" />

我也试着prefixing我的域名用了一段，因为我见过一些人建议，但也不能工作。

I've also tried prefixing my domain with a period as I've seen some people suggest, but that didn't work either.

这工作正常在我的本地机器在IIS中设置为每个子域单独的网站。这也是我们开发服务器，所有的网站仍驻留在一台计算机上正常工作。当我部署到我们的临时环境，然而，跨域身份验证将停止工作。在这种环境下，我有主站点（如登录时）运行的一台服务器上，并辅助站点（在我的认证要坚持）在两个负载平衡服务器上运行。所有的都在是Windows 7（本地）或Windows Server 2008 R2（DEV和分期）运行IIS 7下。

This works fine on my local machine with separate sites set up in IIS for each subdomain. It also works fine on our dev server, where all sites still reside on a single machine. When I deploy to our staging environment, however, the cross-domain authentication stops working. In that environment, I have the primary site (where login occurs) running on a single server, and the secondary site (where my authentication should persist) running on two load-balanced servers. All are running under IIS 7 on either Windows 7 (local) or Server 2008 R2 (dev and staging).

我证实，该机器密钥是相同的用 MachineKey.En code 编码在主站点上的字符串，并与从服务器上的结果进行解码 MachineKey.De code。我也，既通过检查请求头所报告的Firefox和验证了.SHAREDAUTH cookie被传递到请求中的第二个应用程序Chrome和挂钩调试器的Application_BeginRequest 和 Application_AuthenticateRequest。在的Application_BeginRequest我能看到的cookie 执行，但它的消失，当 Application_AuthenticateRequest 被调用。从我可以从不同的机键聚集，这似乎意味着身份验证票证的反序列化失败了，但我不明白，为什么这可能会发生在多服务器环境中，而不是单一的服务器环境，除了，我已经证实并非如此。

I verified that the machine keys are the same by encoding a string on the primary site with MachineKey.Encode and decoding the result on the secondary server with MachineKey.Decode. I also verified that the .SHAREDAUTH cookie is passed to the second application in the request, both by checking the request headers as reported by Firefox and Chrome, and hooking the debugger to Application_BeginRequest and Application_AuthenticateRequest. I can see the cookie during Application_BeginRequest execution, but it's gone when Application_AuthenticateRequest is called. From what I can gather, that seems to mean that the deserialization of the authentication ticket failed, but I can't figure out why that could be happening in the multi-server environment, but not the single server environment, aside from different machine keys, which I already confirmed was not the case.

我也有一个自定义的MembershipProvider和RoleProvider成立，而那些做工精细分别在每个站点上。

I also have a custom MembershipProvider and RoleProvider set up, and those work fine independently on each site.

我在想什么？

推荐答案

所以，很长的跋涉，我发现后 MS安全公告MS11-100 ，该补丁特权漏洞的表单认证的海拔。不幸的是，这个补丁并不向后兼容。它被应用到我们的负载均衡的服务器，而不是服务器托管创建初始的登录，这意味着该平衡的服务器无法反序列化写的应用程序服务器的身份验证票的应用程序。

So, after a long slog I discovered MS security bulletin MS11-100, which patches an elevation of privilege vulnerability in forms authentication. Unfortunately, the patch is not backwards compatible. It was applied to our load balanced servers, but not to the server hosting the application that created the initial log-in, which meant that the balanced servers couldn't deserialize the authentication ticket written by the app server.

％的MS部署指南文章，如果你发现自己在这种情况下，您可以添加

Per the MS deployment guidance article, if you find yourself in this situation, you can add

<add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" />

到的appSettings 在web.config上安装了补丁程序（或计算机级配置）的机器应用部分。或者，更好的是，请确保您的托管管理公司的同时实现修补所有服务器...

to the appSettings section in the web.config for applications on the machines with the patch installed (or to the machine-level config). Or, better yet, make sure you're hosting management company applies the patch to all of your servers at the same time...