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

回答

相關問題