MachineKey Azure SDK 1.5/1.6

我在Azure上使用WCF Web API的自定义Api令牌实现。这使用FormsAuthentication.Decrypt来获取FormsAuthenticationTicket。为了确保decrpyt进程可以跨多个实例工作，我在web.config中提供了一个MachineKey。但是，我注意到MachineKey似乎没有在Azure上工作，因为它看起来像Azure使用随机机器键并覆盖web.config中指定的一个我正在使用最新的Azure SDK 1.5（或1.6？）MachineKey Azure SDK 1.5/1.6

我很清楚这个问题与Azure SDK 1.3，我相信这是在1.4中纠正。自Azure SDK1.5/1.6上重新出现此问题后，是否有机会？

来源

2011-12-31 Anup Marwadi

只是想提供有关此问题的更新。我使用远程桌面登录到Azure托管服务部署，似乎machineKey在物理文件上是正确的。出于某种原因，感觉FormsAuthentication.Decrypt无法生成FormsAuthenticationTicket。这张票的原因是什么？ – 2012-01-02 04:36:31

我遇到了同样的问题，即最近的Microsoft .Net 4.0安全升级KB2656351之后，我的FormsAuthentication故障单未在子域中进行验证。

我的FormsAuth票据是从我的专用服务器生成的，并在Windows Azure的子域上读取。

为了获得所有子域的解密票据，我确保我所有的专用服务器都使用最新的.Net更新通过Windows Update进行了修补。然后我将Azure项目升级到1.6版，并在部署后选择了最新的Azure操作系统。这似乎是一个窍门。

以下是关于这个问题的一些文章：

http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-security-update-shipping-thursday-dec-29th.aspx

http://technet.microsoft.com/en-us/security/bulletin/ms11-100.mspx

欢呼

弗朗西斯

来源

2012-01-04 00:49:49 Francesco

Windows Azure已经在部署中跨同一角色同步机器密钥。因此，您应该很好地完全忽略web.config中的MachineKey设置，并让Windows Azure为您处理它（Web场景方案得到很好的支持）。 Windows Azure支持您的场景，无需任何修改（只需调用Decrypt即可）。

您可能会说的问题是1.3版问题，其中web.config文件被直接修改以同步机器密钥。当文件是只读的（即TFS源代码管理）并导致部署失败时，此操作失败。这是前段时间修复的。

来源

2012-01-01 15:41:42 dunnry

你好，谢谢你的回复。不幸的是，我需要控制MachineKey，因为我的Web服务和Web站点位于完全不同的实例中，用于加密/解密身份。想知道是否有办法确保我指定的机器密钥实际上正在使用中。 – 2012-01-02 03:32:06

我仍然认为你在这里错过了一些东西。正如我所提到的，Azure会自动同步角色中所有实例的机器密钥。它已经准备好了webfarm。唯一一次机器密钥同步会成为一个问题，如果你试图在不同的角色中加密和解密（不是单个角色的实例）。 – dunnry 2012-01-02 21:08:07

我想我终于找到了解决方案。这与Azure或MachineKeys无关，但与应用程序的测试方式有关。存储在我的电话应用程序中的加密密钥在不同的Web服务器上加密（但是，使用的机器密钥相同）。我只是卸载并重新安装我的应用程序，从而迫使服务器生成一个新的密钥。

似乎在不同的服务器上解密此密钥导致了问题。如果这会在将来导致问题，我有点担心。不应该使用相同的机器密钥，以确保加密/解密可以跨机器运行？

无论如何，我对造成的不便表示歉意。

来源

2012-01-02 05:34:39

我们似乎也有同样的问题。我们在web.config文件中设置machinekey。事情很好，直到几天前Decrypt开始返回null。所有机器上的解密密钥和验证密钥都是相同的。不确定是什么问题。

编辑 - Azure v1.6似乎尊重我们在配置文件中设置的machinekey。我们想出了如何解决我们的问题 - 也许这会对您有所帮助 - 我们发现cookie上的解密不适用于我们的Windows 7 64位开发机器。然后我们检查了挂起的更新，并且有一些与安全有关的.NET更新。我们运行了更新，然后再次开始工作。

来源

2012-01-02 06:37:04 user275157

有趣。是的，我肯定可以重现这个问题。令我困扰的是，如果我启动一个新的托管服务实例，并且无法验证用户，则该解密将失败，因为该实例未生成加密字符串。现在，解密工作IF和仅如果*给*服务器加密数据。这绝对是错误的。我在我们的测试环境中的其他服务器上安装了相同的服务，而且这似乎确实有效。这似乎是目前严重的障碍 – 2012-01-02 11:10:51

好吧，我有问题，如上所述在一个3服务器的NLB组。

它看起来像Windows自动更新在三台服务器中的两台上安装了KB2656352，KB2656358和KB2657424。

我会投入资金的事实，这是因为一些服务器运行的补丁，有些不是。我猜想已经打补丁的机器不喜欢解码由未修补机器编码的东西（和/或反之亦然）。

无论如何，我已经在剩下的机器上安装了所有三个补丁，并将其放回到NLB组中。它似乎一切正常。

来源

2012-01-03 06:48:44

MachineKey Azure SDK 1.5/1.6

回答

相关问题