You can have several Windows Azure subscriptions defined in Windows Azure PowerShell. This lets you easily manage several subscriptions from the same PowerShell console. These are the steps required to add a new Windows Azure Subscription to your Windows Azure PowerShell profile:

1. Generate a management certificate:
   makecert.exe -pe -n “CN=<certificate subject>” -ss My –r <certificate filename>.cer
2. Upload management certificate through Windows Azure portal (Settings->Management Certificates):
   
3. Copy the subscription ID:
   
4. Add subscription to default subscription data file:
   Set-AzureSubscription -SubscriptionName <subscription name> –SubscriptionId <subscription ID> –Certificate <path to cer file> –CurrentStorageAccount <storage account name>

Miscellaneous subscription related commands:

• List all subscriptions currently defined in Windows Azure PowerShell profile:
  Get-AzureSubscription
• List current subscription:
  Get-AzureSubscription –Default
• Set current subscription:
  Set-AzureSubscription -DefaultSubscription <subscription name>
• Do not specify a default subscription:
  Set-AzureSubscription –NoDefaultSubscription
• Display currently selected subscription:
  Get-AzureSubscription –Current
• Set a specific subscription as the active one:
  Select-AzureSubscription –SubscriptionName <subscription>

Introduction

I was involved in an ADFS deployment recently where the customer wanted to restrict access from the Internet to their ADFS proxy servers, located on their DMZ. They used ADFS to federate with Windows Azure Active Directory so they only wanted to allow traffic from the Microsoft Online Security Token Service (STS) servers into their ADFS. The rational behind this was that only a trusted party (Microsoft) should be able to communicate with an externally available service in their network. A good theory, but one doomed to failure. Let me explain why…

The WS-Federation Passive Requestor Profile

ADFS is Microsoft’s implementation of the OASIS group’s WS-* suite of protocols and mechanisms. A complete description of WS-*  is way beyond this post, but I will list some resources at the end of this post for the inquisitive among you. One of the purposes of the WS-* standard is to allow:

“different security realms to federate, such that authorized access to resources managed in one realm can be provided to security principals whose identities and attributes are managed in other realms”

In other words, to outsource authentication to somebody else that you trust.

The letters WS stand for Web Service, meaning that WS-* is created to work on the Internet, something e.g. Kerberos is not designed to do. Let’s look at a few pieces of WS-* terminology:

• Requestor
  The client that wants access to some resource/content/service. Often a browser. Requestors are broadly split into two groups; those that can emit Web Service messages using SOAP and those that cannot. (Remember this last bit because it is important.)
• Relying party (RP)
  The content provider that has something that a user wants access to. The RP has delegated the task of authentication to somebody else; the Identity Provider (IdP)/Security token Service (STS). The RP trusts the IdP/STS. In the Windows world an RP is often an IIS server with the Windows Identity Foundation (WIF) framework installed.
• Identity Provider (IdP)
  A secure storage of identity information that also provides authentication mechanisms, allowing a Security Token Service (STS) to use it to authenticate. Active Directory is ADFS’ IdP.
• Security Token Service (STS)
  A service that receives authentication requests from clients, authenticates them via its configured IdP, and issues tokens to clients, to be used at the RP.
• Trust
  A relationship between the RP and the IdP/STS established with digital certificates whereby the RP trusts the IdP/STS.

A browser cannot emit web service requests, i.e. it cannot talk SOAP, so it uses something called the WS-Federation Passive Requestor Profile (PRP). WS-Federation is an extension to the WS-Trust specification that allows requestors that cannot talk SOAP to still exchange security information (tokens). They do this by being passive, meaning they rely on the RP and IdP to tell them what to do.

An implementation of this can look like this:

This is what happens when the passive requestor profile is used to obtain access to a resource:

1. The requestor contacts the resource asking for access. The resource is the RP.
2. The RP know the requestor’s security realm so it sends an HTTP redirect instructing the requestor to authenticate at its own realm.
3. The requestor follows the redirect to its own realm where it is authenticated by its IdP/STS.
4. In the request for authentication the requestor has included the URI of the resource it wants to access to. After the IdP/STS has authenticated the requestor, it sends another HTTP redirect back to the original resource. Included with the redirect is also a token, possession of which assures that the user has been authenticated.
5. The requestor follows the redirect back to the original resource supplying the token and gains access to the resource.

The most important thing to note here is that when using the Passive Requestor Profile the RP and IdP/STS never need to communicate directly. It is only the requestor that needs to talk to all the involved parties.

Usually the RP is also an IdP/STS. In the case of Windows Azure Active Directory and federation with an on-premise Windows Server Active Directory the WAAD IdP/STS trusts your on-premise IdP/STS. This allows a single trust to be established. If not each RP would have to maintain its own trust with the IdP/STS.

So now that we know how the Passive Requestor Profile works how would this impact my customer’s request to only allow Microsoft’s STS to talk to its ADFS servers?

Security

Answer is that it would break it and no one would be able to access any resource in the Microsoft cloud. As we have seen it is not the WAAD STS that communicates with on-premise ADFS, or the other way around, it is the requestors, i.e. the clients. So restricting access would deny every client access to on-premise ADFS, and thus any resource they want to access. Don’t do that.

Other stuff and more info

The customer had actually started working on this “security improvement” before I got involved and had already discovered IPs they needed to allow. For the curious, the name of the Microsoft STS is login.microsoftonline.com, which is a CNAME that resolves to the A record login.microsoftonline.com.nsatc.net. The A record has several records (I do not know if this is a complete list):

• 157.56.53.213
• 157.56.58.13

To restrict access and always use least privilege is a very good idea, in this case it just backfired because how the system works was not known.

If you want to know more about WS-*, ADFS etc., you can have a look at these resources:

• Windows Identity Foundation 101’s : WS-Federation Passive Requestor Profile (part 1 of 2)
• OASIS Web Services Federation Language Draft
• ADFS Deployment Guide

Be secure!

A new version of the PowerShell module for Windows Azure Active Directory is available. This module was previously know as the Microsoft Online PowerShell module. The cmdlets all have the word MSOL in them, and the modules are called MSOnline and MSOnlineExtended. The version is still 1.0.0 as were the previous module. New in this release is support for Windows Server 2012; you can install the module on Windows Server 2012 and also configure the version of ADFS in Windows Server 2012. The documentation has also been updated.

• 32-bit http://g.microsoftonline.com/0BX10en/230
• 64-bit http://g.microsoftonline.com/0BX10en/423
• Documentation http://technet.microsoft.com/en-us/library/hh967628.aspx

I have published a 5 part blog series on the Norwegian Microsoft TechNet Blog, with step by step instructions for setting up integration between your on-premise Window Server Active Directory Directory Service and Windows Azure Active Directory. It covers concepts, single-sign on with ADFS, Directory Synchronization with the DirSync Tool and troubleshooting. So if you speak my native language; head on over:

• Part 1
• Part 2
• Part 3
• Part 4
• Part 5

Morgan

So here’s a quick one…

App Controller needs the following services/ports open on the SQL server it is configured to talk to during install:

• SQL (duh!) (Port TCP 1433)
• Remote Service Management (RPC SCManager UUID 367ABB81-9844-35F1-AD32-98F038001003)
• Windows Management Instrumentation (WMI)

If these are open the App Controller installer can automatically detect the SQL instance and you don’t get the pesky “The specified database has insufficient space” error:

By default, every Windows Azure subscription has a limit of 20 compute cores. This applies to both VMs (IaaS) and worker roles (PaaS). Fortunately this is a soft limit and you can increase it by submitting a support ticket to the Windows Azure team through the management portal here. The following table lists the number of cores for each available Windows Azure instance:

To see how many cores each of your cloud services are using just look in the management portal. You will se something like this:

Unfortunately you need to manually add all the cores for each cloud service to get the total number. To work around this limitation you can use PowerShell:

# CountWACores.ps1
# Morgan Simonsen, www.cloudpower.no
# Count all CPU cores for subscription across all cloud services

$colVMs = @()
$TotalCores = 0

$VMs = (Get-AzureService).servicename | foreach {Get-AzureVM -ServiceName $_ }

foreach ( $VM in $VMs )
{
$Instance = New-Object System.Object
$Instance | Add-Member -type NoteProperty -name “VM Name” -value $VM.Name
$Instance | Add-Member -type NoteProperty -name “VM Instance Size” -value $VM.InstanceSize

    Switch ($VM.InstanceSize)
{
# Should ever Windows Azure get additional instance sizes, add them here
“ExtraSmall”    {$VMCores=0.166666666666667}
“Small”        {$VMCores=1}
“Medium”    {$VMCores=2}
“Large”        {$VMCores=4}
“ExtraLarge”    {$VMCores=8}
}

    $Instance | Add-Member -type NoteProperty -name “VM Cores” -value $VMCores
$colVMs += $Instance
$TotalCores += $VMCores
}

$colVMs | Sort-Object “VM Name”
Write-Host “Total number of cores:” $TotalCores

Save the above as a PowerShell script and run it from a prompt with the Windows Azure PowerShell module added. It will return all your VMs, sorted by name, their instance sizes, the number of cores they each use and the total number of cores in use in your subscription.

If you are paying for your Windows Azure subscription with a credit card your credit limit is $15000 by default. This will let you increase to a total of 175 cores in your subscription. If you want more cores and still pay with a credit card you will have to go through a credit check process to increase your credit limit. If you move to an Enterprise Agreement there will be no need for any credit checks to increase your core count beyond 175.

For large deployments the Windows Azure Capacity Planning team will want information from you so that they can allocate the required resources in the regions you specify. Typical questions they will ask you is where (region) you want to deploy, if you can deploy in several regions, if you are creating a new deployment or growing an existing one, which VM sizes you require and other services, like CDN, SQL etc) that you may require.

Licensing rules have, to put it mildly, not kept up with the developments in virtualization and cloud computering, but things are moving along:

Oracle Throws in the Towel on VMware Licensing

Morgan