我在Azure上使用WCF Web API使用自定义Api Token实现。这使用FormsAuthentication.Decrypt来获取FormsAuthenticationTicket。为了确保decrpyt进程在多个实例中工作，我在web.config中提供了一个MachineKey。 但是，我注意到MachineKey似乎没有在Azure上工作，因为它看起来像Azure使用随机机器密钥并覆盖我在web.config中指定的那个。我正在使用最新的Azure SDK 1.5（或1.6？）
我很清楚Azure SDK 1.3的这个问题，我相信这在1.4中得到了纠正。此问题是否有可能在Azure SDK1.5 / 1.6上重新出现？
答案 0 :(得分：0)
Windows Azure已在部署中跨同一角色同步计算机密钥。因此，您应该可以完全忽略web.config中的MachineKey设置，只需让Windows Azure为您处理（Web服务器场景得到很好的支持）。 Windows Azure开箱即可支持您的方案，无需修改（只需调用Decrypt）。
您可能正在讨论的问题是1.3问题，其中web.config文件被直接修改以同步机器密钥。当文件是只读（即TFS源控制）并导致部署失败时，此操作失败。这是在不久前修复的。
答案 1 :(得分：0)
我想我终于找到了解决方案。这与Azure或MachineKeys无关，但更多地与应用程序的测试方式有关。存储在我的电话应用程序上的加密密钥在不同的Web服务器上加密（但是，使用的机器密钥是相同的）。我刚刚卸载并重新安装了我的应用程序，从而迫使服务器生成一个新密钥。
似乎在另一台服务器上解密此密钥会导致问题。如果这将导致将来出现问题，我有点担心。不应该使用相同的机器密钥确保加密/解密在框中工作吗？
无论如何，对于给您带来的不便，我深表歉意。
答案 2 :(得分：0)
我们似乎也有同样的问题。我们在web.config文件中设置了machinekey set。事情很好，直到几天前Decrypt开始返回null。 decryptionkey和validationkey在所有机器上都是相同的。不确定是什么问题。
编辑 - Azure v1.6似乎尊重我们在配置文件中设置的机器密钥。我们想出了如何解决我们的问题 - 也许这会对你有所帮助 - 我们发现cookie上的解密对我们的Windows 7 64位开发机器不起作用。然后我们检查了挂起的更新，并且有一些与安全性相关的.NET更新。我们运行了更新，然后开始重新开始工作了。
答案 3 :(得分：0)
好的，所以我遇到了如上所述的3服务器NLB组中的问题。
看起来Windows自动更新已在三台服务器中的两台上安装了KB2656352，KB2656358和KB2657424。
我认为这是因为有些服务器正在运行补丁而有些服务器没有运行。我想已修补的机器不喜欢解码由非修补机器编码的内容（和/或反之亦然）。
无论如何，我已经在剩余的机器上安装了所有三个补丁并将其重新放回NLB组。似乎一切正常。
答案 4 :(得分：0)
我遇到了同样的问题，即在最近的Microsoft .Net 4.0安全性升级KB2656351之后，我的FormsAuthentication票证未在子域中进行验证。
我的FormsAuth票证是从我的专用服务器生成的，并在Windows Azure上的子域上读取。
为了让所有子域解密票证，我确保所有专用服务器都通过Windows Update修补了最新的.Net更新。然后我将Azure项目升级到1.6版，并在部署后选择了最新的Azure OS。这似乎可以解决问题。
以下是一些关于此问题的文章：
http://technet.microsoft.com/en-us/security/bulletin/ms11-100.mspx
欢呼声
弗朗西斯