3

I am using a custom Api Token implementation using WCF Web API on Azure. This uses FormsAuthentication.Decrypt in order to obtain a FormsAuthenticationTicket. To make sure that the decrpyt process works across multiple instances, I have provided a MachineKey in my web.config. However, I've noticed that the MachineKey doesn't seem to be working on Azure because it looks like Azure is using a random machinekey and overwriting the one I specificed in the web.config I'm using the latest Azure SDK 1.5 (or 1.6?)

I am well aware of this issue with Azure SDK 1.3 and I believe this was rectified in 1.4. Is there a chance that this issue has since re-appeared on Azure SDK1.5/1.6?

Anup Marwadi
  • 2,517
  • 4
  • 25
  • 42
  • Just wanted to provide an update on this issue. I logged in to the Azure Hosted Service deployment using Remote Desktop and it seems that the machineKey is correct on the physical file. For some reason, it feels that the FormsAuthentication.Decrypt cannot generate a FormsAuthenticationTicket. What could be some reasons for this ticket to be null? – Anup Marwadi Jan 02 '12 at 04:36

5 Answers5

0

Windows Azure already synchronizes machine keys across the same role in a deployment. As such, you should be fine to completely ignore the MachineKey setting in web.config and just let Windows Azure handle it for you (the web farm scenario is well supported). Your scenario is supported on Windows Azure out of box with no modifications (just call Decrypt).

The issue that you might be talking about was a 1.3 issue where the web.config files were being modified directly to sync the machine keys. This failed when the file was read-only (i.e. TFS source control) and caused deployment failures. That was fixed some time ago.

dunnry
  • 6,858
  • 1
  • 20
  • 20
  • Hello, thanks for your response. Unfortunately, I need control over the MachineKey because I have Web Services and Web sites residing on completely different instances encrypting/decrypting identities. Wondering if there's a way to ensure that the machine keys I have specified are in fact being used. – Anup Marwadi Jan 02 '12 at 03:32
  • I still think you are missing something here. As I mentioned, Azure will automatically sync machine keys across all instances in a role. It is already webfarm ready. The only time machine key sync would be an issue is if you were trying to encrypt and decrypt in different *roles* (not instances of a single role). – dunnry Jan 02 '12 at 21:08
0

I think I finally found the solution. This had nothing to do with Azure or MachineKeys but had more to do with the way the app was being tested. The encrypted key that was stored on my Phone App was encrypted on a different web server (however, the machine key used was the same). I just un-installed and re-installed my app thereby forcing the server to generate a new key.

It seems that decrypting this key on a different server was causing problems. I'm a little worried if this will cause problems in the future. Shouldn't using the same Machine Keys ensure that encrypt/decrypt works across boxes?

Anyways, I apologize for the inconvenience caused.

Anup Marwadi
  • 2,517
  • 4
  • 25
  • 42
0

We seem to have the same problem as well. We set machinekey set in the web.config file. Things were fine until a couple of days ago when Decrypt started returning null. The decryptionkey and validationkey are identical on all machines. Not sure what the problem is.

EDIT - Azure v1.6 does seem to respect the machinekey we set in the config file. We figured out how to solve our problem - Maybe this would help you - we were seeing that decrypt on the cookie does not work on our Windows 7 64 bit dev machines. Then we checked pending updates and there were a couple of .NET updates related to security. We ran the updates and voila things started to work again.

user275157
  • 1,332
  • 4
  • 23
  • 45
  • Interesting. Yea, I can definitely recreate this issue. What bothers me is that this decrypt will fail if I fire a new hosted service instance and the user cannot be validated because that instance didn't generate the encrypted string. Right now, the decrypt works IF and ONLY IF *THAT* given server encrypts the data. This is definitely wrong. I installed the same services on other servers in our test environment, and that seems to be working for sure. This seems to be a serious impediment at this moment – Anup Marwadi Jan 02 '12 at 11:10
0

OK so I had the problem as described above in a 3-server NLB group.

It looks like the Windows Automatic Updates had installed KB2656352, KB2656358 and KB2657424 on two of the three servers.

I'd put money on the fact that it's because some of the servers are running with the patch and some aren't. I guess machines that have been patched don't like decoding things encoded by a non-patched machine (and/or vice-versa).

Anyway, I've installed all three patches on the remaining machine and put it back into the NLB group. It seems to all work fine.

David Brophy
  • 849
  • 9
  • 19
0

I was having the same problem where my FormsAuthentication tickets were not validating across sub domains after the recent Microsoft .Net 4.0 Security upgrade KB2656351.

My FormsAuth tickets are generated from my dedicated servers and read on sub domains on Windows Azure.

In order to get all sub domains to decrypt the tickets I made sure all my dedicated servers were patched with the latest .Net updates via Windows Update. Then I upgraded my Azure project to version 1.6 and selected the latest Azure OS after deploying. This seemed to do the trick.

Here are some articles about the issue:

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

cheers

Francesco

Francesco
  • 16