Tech-Ed 2011 Day 4 - Azure Connect

COS303 Connecting Cloud and On-Premises Applications Using Windows Azure Virtual Network

A future component of Azure is Windows Azure Connect.  Currently available as a release candidate it can be used with current Azure deployments to connectivity from Windows Azure resources to internally hosted resources. This is huge in that it allows keeping portions (applications, data) out of the cloud but still consumed.

There are a few steps to enabling Connect, each with a bit of configuration.

In the Windows Azure portal, enable the WA role for external connectivity. This will generate an activation token.

Install the Azure Connect agent on the resource to be shared. This can only be installed on Windows Server 2008 or Windows Vista and later editions. Minimum requirement for this to function is that the resource can be resolved in DNS when requested, and that outbound SSL traffic is allowed. This creates a tunnel to the relay service in Windows Azure, which relays traffic to the roles in the Azure instance.

The agent runs as a service with a virtual NIC and an assigned IPv6 address. Users will see a tray icon and user interface for maintenance and manually refreshing policies. To bind to the relay service, an activation token must be configured (unique for your subscription and you can copy from the Azure portal).  The token is automatically configured when you download and install from the portal, or an offline installation can be done and push the token to a registration key.

Limitations of the agent is that it cannot connect to virtual IP addresses, so a resource cannot be a load balanced or clustered resource.

In the service to consume the remote resource, put the activation token in the ServiceConfiguration (.cscfg) file.

Manage the network policy from the Azure portal. When you create a local resource, it is unassigned, and must be placed into a group. Windows Azure roles can then connect to the group and through that the resource.

The most intriguing case use is to set an enterprise domain controller as a resource. To do this, install the Azure Connect agent on a domain control (likely could be a read-only DC, but need to check on this). You can then domain-join the Windows Azure compute resources (aka Windows VM), place them into an OU in your Active Directory, and use Active Directory resources.

Here is where it gets good. You can use integrated authentication from client  browsers connecting to a web roles in Azure.  Additionally, on the back-end by setting the IIS pool for a web role to a domain account, Windows authentication can be used to access local SQL resources (that are also made available via Azure Connect).