Category Archives: DevOps

Get ASP.NET auth cookie using PowerShell (when using AntiForgeryToken)

At FundApps we run a regular SkipFish scan against our application as one of our tools for monitoring for security vulnerabilities. In order for it to test beyond our login page, we need to provide a valid .ASPXAUTH cookie (you’ve renamed it, right?) to the tool.

Because we want to prevent Cross-site request forgeries to our login pages, we’re using the AntiForgeryToken support in MVC. This means we can’t just post our credentials to the login url and fetch the cookie that is returned. So here’s the script we use to fetch a valid authentication cookie before we call SkipFish with its command line arguments:

Updating Azure Virtual Network to use point-to-site feature

Scott recently announced support for point-to-site VPN connections into Azure – awesome! But what might not be so clear is how to enable it on your existing Virtual Network configuration – because you can’t make changes (at least through the UI) to your virtual network after it has been deployed and is in use.

Fortunately, there appears to be a workaround.

1) Export your existing configuration (go to the Networks view in the Azure management portal, and click the Export button).

2) Modify the XML with the following. Firstly, you need to add a new “GatewaySubnet” entry, which should be inside the address space of your virtual network. You then need to add a “VPNClientAddressPool” node, with an AddressPrefix outside the address space of your virtual network.

<VirtualNetworkSite name="XNetwork" AffinityGroup="NorthEurope">
  <AddressSpace>
    <AddressPrefix>10.4.0.0/16</AddressPrefix>
  </AddressSpace>
  <Subnets>
    ...
    <Subnet name="GatewaySubnet">
      <AddressPrefix>10.4.1.0/24</AddressPrefix>
    </Subnet>
  </Subnets>
  <Gateway>
    <VPNClientAddressPool> 
      <AddressPrefix>10.0.0.0/24</AddressPrefix> 
    </VPNClientAddressPool>
    ...
  </Gateway>
</VirtualNetworkSite>

3) Go to Networks | Virtual Network | Import Configuration and re-upload your XML file.

Sorted! Now you can continue to configure point-to-site connectivity from the network dashboard as described here.

Configure Visual Studio 2012 to use 64 bit version of IIS Express

By default Visual Studio (as a x86/32bit process) will always launch the 32bit version of IIS Express. If you have components that specifically require running under 64bit, you can can configure Visual Studio 2012 to use IIS Express x64 version by setting the following registry key:

reg add HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\WebProjects /v Use64BitIISExpress /t REG_DWORD /d 1

You should note that this feature is not supported and has not been fully tested by Microsoft – you have been warned!

Cisco VPN Client for Windows 8

There isn’t currently a version of Cisco’s VPN client that supports Windows 8, and after installation I received an error message complaining that the “VPN Client failed to enable virtual adapter.”.

Fortunately, there is a way to get this “legacy” VPN client to work, with a small registry change:

  • Open up the registry editor by typing regedit in Run prompt
  • Browse to the Registry Key HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\CVirtA
  • Edit the DisplayName entry and remove the leading characters from the value data upto “%;” i.e.
    • For x86, change the value data from something like “@oem8.inf,%CVirtA_Desc%;Cisco Systems VPN Adapter” to “Cisco Systems VPN Adapter”
    • For x64, change the value data from something like “@oem8.inf,%CVirtA_Desc%;Cisco Systems VPN Adapter for 64-bit Windows” to “Cisco Systems VPN Adapter for 64-bit Windows”

Then you can try connecting again – this did the trick for me.

Debugging Powershell and Psake commands and parameters

Getting commands and parameters in Powershell and Psake can be pretty troublesome at times. The echoargs helper from the PowerShell Community Extensions can be a lifesaver. If, for instance, you are calling

msbuild.exe /t:Build /p:SomeTroublesomeParametersHere

if you swap msbuild for echoargs (after placing the extensions in C:\Windows\System32\WindowsPowerShell\v1.0\Modules and calling Import-Module pscx), then you’ll see the exact parameters being passed to the executable:

Arg 0 is </t:Build>
Arg 1 is </p:SomeTroublesomeParametersHere>

However, to make it easier for those dipping into our build scripts, I decided to create a wrapper function so that we would always output parameters to the external functions we call to the console for debugging purposes.

function Invoke-EchoCommand
{
    $cmdName = $args[0];
    $remainingArgs = $args[1..$args.Length]
    Write-Host "Executing $cmdName" -ForegroundColor darkgray
    & "$base_dir/tools/build/echoargs" @remainingArgs | Write-Host -ForegroundColor darkgray
    exec { & $cmdName @remainingArgs } # using exec helper in PSake
}

You can then replace any calls to exec with

Invoke-EchoCommand msbuild.exe /t:Build /p:SomeTroublesomeParametersHere

and you’ll get some helpful debug information over how the parameters were actually passed. The only nifty bit in the function is that it uses the first parameter as the command name, and then passes all remaining arguments on to the executed command.