AzureでWCFWebAPIを使用したカスタムApiトークンの実装を使用しています。これは、FormsAuthenticationTicketを取得するためにFormsAuthentication.Decryptを使用します。decrpytプロセスが複数のインスタンスで機能することを確認するために、web.configでMachineKeyを提供しました。ただし、Azureがランダムなマシンキーを使用していて、最新のAzure SDK 1.5（または1.6？）
Azure SDK 1.3のこの問題をよく知っており、1.4で修正されたと思います。その後、この問題がAzure SDK1.5 / 1.6で再発する可能性はありますか？
最近のMicrosoft.Net4.0セキュリティアップグレードKB2656351の後で、FormsAuthenticationチケットがサブドメイン間で検証されないという同じ問題が発生していました。
私のFormsAuthチケットは、専用サーバーから生成され、WindowsAzureのサブドメインで読み取られます。
すべてのサブドメインでチケットを復号化するために、すべての専用サーバーにWindowsUpdateを介して最新の.Net更新プログラムが適用されていることを確認しました。次に、Azureプロジェクトをバージョン1.6にアップグレードし、デプロイ後に最新のAzureOSを選択しました。これでうまくいくようです。
この問題に関する記事は次のとおりです。
http://technet.microsoft.com/en-us/security/bulletin/ms11-100.mspx
乾杯
フランチェスコ
Windows Azureは、展開内の同じ役割間でマシンキーを既に同期しています。そのため、web.configのMachineKey設定を完全に無視して、Windows Azureに処理させるだけで問題ありません（Webファームシナリオは十分にサポートされています）。シナリオは、変更なしでWindows Azureでサポートされます（Decryptを呼び出すだけです）。
あなたが話しているかもしれない問題は、マシンキーを同期するためにweb.configファイルが直接変更されていた1.3の問題でした。これは、ファイルが読み取り専用（つまり、TFSソース管理）の場合に失敗し、展開の失敗を引き起こしました。それは少し前に修正されました。
私はついに解決策を見つけたと思います。これはAzureやMachineKeysとは何の関係もありませんでしたが、アプリのテスト方法とはもっと関係がありました。電話アプリに保存されていた暗号化されたキーは、別のWebサーバーで暗号化されていました（ただし、使用されたマシンキーは同じでした）。アプリをアンインストールして再インストールしたところ、サーバーに新しいキーが生成されました。
別のサーバーでこのキーを復号化すると問題が発生したようです。これが将来問題になるのではないかと少し心配です。同じマシンキーを使用して、暗号化/復号化がボックス間で機能することを確認するべきではありませんか？
とにかく、ご不便をおかけして申し訳ございません。
私たちも同じ問題を抱えているようです。web.configファイルでmachinekeysetを設定します。Decryptがnullを返し始めた数日前までは問題ありませんでした。復号化キーと検証キーはすべてのマシンで同一です。問題が何であるかわからない。
編集-Azurev1.6は、構成ファイルで設定したマシンキーを尊重しているようです。問題を解決する方法を見つけました-おそらくこれはあなたを助けるでしょう-私たちは、Cookieの復号化がWindows764ビット開発マシンでは機能しないことを確認していました。次に、保留中の更新を確認し、セキュリティに関連する.NET更新がいくつかありました。アップデートを実行すると、出来上がりが再び機能し始めました。
OK、3サーバーのNLBグループで上記のような問題が発生しました。
Windows自動更新により、3台のサーバーのうち2台にKB2656352、KB2656358、およびKB2657424がインストールされたようです。
一部のサーバーはパッチを適用して実行されており、一部は実行されていないためです。パッチが適用されたマシンは、パッチが適用されていないマシンによってエンコードされたものをデコードするのが好きではないと思います（および/またはその逆）。
とにかく、残りのマシンに3つのパッチをすべてインストールして、NLBグループに戻しました。それはすべてうまくいくようです。