Dealing with Windows Azure SDK1.3 MachineKey issue causing inconsistent Hash/Encryption with Powershell [Work in Progress]

There has been a rise in the number of Encryption questions on the Windows Azure Forums. First off, I’d have to applaud those who are playing the safety card in the cloud and encrypting their data.

With the recent FBI Take over of Instapaper’s Servers due to an unrelated raid, looming in the minds of Business and Technical Decision makers are thought of how secure their systems may be in a similar scenario. Fortunately instapaper had encrypted their users passwords, however other potentially sensitive data like email addresses, and bookmark information were not encrypted which may have exposed a number of their user base.

[NOTE: This post is currently a work in progress, but I wanted to share what I was working on. Currently this work around for the SDK 1.3 Machine Key issue is subject to a Race Condition which is described in more detail in my previous post: Windows Azure Role Startup Life-Cycle]

Known Issue: Windows Azure Machine Key is replaced on Deployment

To better understand the Machine Key Element in the web.config file check out the documentation on MSDN Library. You can also Generate a Machine Key using an online tool provided by ASPNetResources.com.

The reason behind this blog post is due to a known issue which was introduced in the Windows Azure SDK 1.3 which will replace the Machine Key in your web.config file in deployment. There is a work around for this issue that is posted within the Windows Azure Documentation on MSDN, however, their solution does have a security warning attached [See Below], which this solution is trying to mitigate.

Security Note

Elevated privileges are required to use IIS 7.0 Managed Configuration API for any purpose, such as programmatic configuration of sites.

The role entry point must run with elevated privileges for this workaround to function correctly. The steps below configure the role for elevated execution privilege. This configuration applies only to the role entry point process. It does not apply to the site itself. Note that the role entry point process remains runs with elevated privileges indefinitely. Exercise caution.

Avoiding an Indefinite Elevation of Privileges with Startup Tasks

Startup Tasks which were also introduced in Windows Azure SDK 1.3 are a very powerful tool in a Windows Azure Developers Arsenal.

Startup Task allow the execution of any Command Shell executable file, including msi, bat, cmd, and Powershell (ps1). The purpose is to modify the base Operating System provided to work for the Application that is being deployed.

Each individual startup task allows for a different elevation of privileges to be applied.

Scripting a Machine Key into the web.config of each Website within IIS with Powershell

Powershell is a powerful  scripting language which allows Access to IIS by using it’s WebAdministration Module. Below you will find a reusable script that will replace the machinekey in the web.config file located in the ‘siteroot’ in a Windows Azure Deployment.

This script could potentially be cleaned up by someone that has more experience with Powershell, but it definitely achieves the goal that has been set out.

Slight Script Assumption

As you can see, this script iterates over all of the sites within IIS, meaning each site will effectively get the same Machinekey within their individual web.config files. It’s up to you if this is acceptable behavior or not for your particular scenario. This might not be a desired case for a Multi-Tenant Application.

The powershell above is only one part of the equation. The secondary piece is where we actually call this powershell script, which can be handed off to a Command Script (.cmd) to be used as our startup task.

In order to run powershell script files within Windows Azure you *MUST* change the ExecutionPolicy, I suggest using RemoteSigned. Next -Command is referencing the Powershell Script and accepts the Arguments for the Decryption Type, DecryptionKey, Validation Type, and ValidationKey  which are the necessary values for the attributes in the machinekey element.

Then to setup the startup task add the following to the Service Definition File within the WebRole Definition.

When dealing with Startup Tasks it is important you set them up properly within your Web Project File [Read: How to Resolve Cannot Find File Error for Windows Azure Startup Tasks in Visual Studio].

How to Resolve ‘error: Cannot find file named ‘approot\bin\startup.cmd’’ for Windows Azure Startup Tasks in Visual Studio

A number of people have been coming across an issue when attempting to create Startup Tasks in their Windows Azure Deployments. Typically I’ve been packaging my deployments with the CSPack Utility which is part of the Windows Azure Tools for Visual Studio. [Read: Installing PHP in Windows Azure Leveraging Full IIS Support: Part 3]

You can resolve this issue by selecting your startup script file in the Solution Explorer, and Navigating to the Properties [Alt + Enter]. The Second Item down on the List is “Copy to Output Directory” this needs to be set to either “Copy Always” or “Copy if Newer”.

image

In the example above, my startup script is named PowershellRun, but this could be renamed to match the startup script name in the title startup.cmd.

Happy Clouding!