Windows Azure Hybrid Cloud Authentication and Access Architectures – Discussion (31 Days of Windows Servers (VMs) in the Cloud – Part 31 of 31)
https://aka.ms/IaaSSeries is where you can catch up or review the previous posts in the 31 Days of Windows Servers (VMs) in the Cloud series
Today’s post is a guest post from Ira Bell, the COO of Nimbo.
Throughout January, some really bright people have come together to touch on several topics around Windows Servers (VMs) in the Cloud. We’ve seen things covering topics from the basics of creating Virtual Machines in the Cloud to more advanced PowerShell approaches for management of the Azure platform. The aim for these discussions has been centered on peeling the layers back to expose what’s capable with Windows Azure.
One of the topics that I discuss most with CIOs and CTOs in New York City is Authentication and Access using Windows Azure. The flexibility of Windows Azure is great – in that you can have isolated environments for development, testing, or production – as well as a hybrid environment using Azure’s Virtual Network connectivity offering. But how do you address the architecture around Authentication and Access when we’re connecting a new foreign environment to our on-premise environment?
The truth is – there are several solutions to several problems on Authentication and Access with Windows Azure. In fact, the topic is so broad that an entire book (or series of books) could probably be written on it. In this article, I’ve provided 6 architectures which I’d like to present as discussion topics for this blog. This certainly is not meant to represent the entire set of possibilities - but is intended to cover some of the scenarios Nimbo has implemented for Fortune level companies.
If you have specific questions on this thread – I suggest that you raise them at the Windows Azure MSDN Forums or send me an email at ira.bell@nimbo.com.
Before we begin, here are some Wikipedia primer articles which may be useful:
- Claims-based identity
- Lightweight Directory Access Protocol
- AD FS 2.0 Content Map
- Active Directory (specifically section 7 – Trusting)
- Security Assertion Markup Language
- Guidelines for Deploying Windows Server Active Directory Domains on Windows Azure Virtual Machines
(Note: Each scenario below starts with the topic, then displays the conceptual architecture, then has a description. )
Scenario 1 – Azure Domain Joined IaaS Virtual Machine to an On Premise Domain
The first and most simple method of interconnectivity between an on-premise environment and Windows Azure IaaS is to establish a Virtual Network which will ensure that all traffic between each environment is encrypted over an IPsec VPN Tunnel. Notice in this diagram that there’s an on-premise domain called nimbo.com which contains a single domain controller called DC1. As such, the Fully Qualified Domain Name (FQDN) for this server should be DC1.nimbo.com.
In the Azure Platform (pictured in the cloud) there are two servers: server4.nimbo.com and server5. The server on the left – connected by the red arrow – is a machine which is domain joined over the IPsec VPN tunnel which makes it a member server to the domain nimbo.com. Whereas server5 – connected by a green arrow – is not joined to any domain and as such is referred to as a workgroup member.
It’s important to note that both of the servers in the Azure Platform have private IP addresses as part of the Virtual Network and are accessed over the VPN. However, only one of these servers is joined to the on-premise domain. This is certainly an acceptable architecture but there are some potential issues which could arise. First, you’d have to open a large amount of ports within the on-premise firewall which handles the VPN tunnel endpoint (shown as a brick stack in the image.) Second, since there will be no domain controller in Azure there will be no Global Catalog Server present. This could be an issue if the VPN tunnel becomes disconnected as the domain joined machines (i.e. server4.nimbo.com) count on the on-premise domain controller for log on purposes as well as other things.
Scenario 2 – Domain Controller in Azure which is a Member of the On-Premise Domain
In this architecture the environment is the same as Scenario 1 but has the addition of a domain controller in Windows Azure which is a member of the nimbo.com domain. In this example, DC1.nimbo.com (on-premise) will replicate Active Directory traffic with DC2.nimbo.com (Windows Azure.) To implement this architecture, DC2.nimbo.com would have to (1) have its DNS settings directed to a domain controller for nimbo.com located in the on-premise environment, (2) joined to the nimbo.com domain, (3) and then promoted to a domain controller. The benefit of this architecture is that frequent replication would take place between the domain controllers and as such a temporary disconnection of the VPN tunnel would not likely result in a negative user experience for the cloud based nimbo.com domain-joined servers. The downside of this architecture is that we still have a large amount of ports which must be opened within the on-premise firewall which handles the VPN tunnel endpoint. Also, we may not be comfortable with having a domain controller for our Active Directory domain nimbo.com living in Windows Azure.
(Note: We could take this same architecture a step further and create a child domain of nimbo.com for a more hierarchical model. For example, the Fully Qualified Domain Name of DC2 could be DC2.cloud.nimbo.com. If we took that approach we would have an implementation such as shown below – but traditionally we only think about the use of child domains for addressing password policies, regulatory/legal/compliance mandates, or physical security. It’s my opinion that this is a great topic for discussion but isn’t necessarily a resounding architecture which warrants an isolated discussion.)
Scenario 3 – Cloud Domain in Azure with a One Way Trust to the On-Premise Domain
Now this architecture begins to get a bit more interesting. Here we’re leveraging one of Microsoft’s Active Directory Trust Features:
· Take a look: Creating External Trusts
Notice that the on-premise domain remains the same as nimbo.com yet the Windows Azure environment now has a new domain called contoso.com. Conceptually we have a cloud only domain for which Azure Virtual Machines can be domain joined. The unique thing about this approach is that I’ve depicted a one-way trust in which DC1.contoso.com trusts DC1.nimbo.com. Although it’s probably obvious, I should mention here that since this is in fact a one-way trust– DC1.nimbo.com most certainly does not trust DC1.contoso.com. This single direction allows us to ensure that those who are authenticated to the nimbo.com domain can access resources in the contoso.com domain, but not the other way around. This is a nice little security feature we can put in place to ensure that we have a central point of administration for Azure Virtual Machines but don’t take the approach of exposing our internal Active Directory environments away from our ‘perceived’ safe on-premise environments. I say ‘perceived’ because I believe that the Windows Azure Platform is quite secure – but we should always take precautions where possible in our architecture as long as it doesn’t inhibit our ability to be competitive, productive, and successful. So what happens to our on-premise domain nimbo.com if contoso.com becomes compromised? Probably nothing would be my initial assumption.
Scenario 4 - Cloud Domain in Azure with a One Way Trust to the On-Premise Domain with DMZ
But what if we wished to take this a step further? Perhaps we want to have our cloud-only domain contoso.com behind our on-premise firewall? How is that possible? Well, we could put a server called DC1.contoso.com in our on-premise DMZ environment. I suppose this might change the title of our cloud-only domain to something really confusing like hybrid-on-premise-and-cloud-domain-outside-of-our-internal-network. Whatever we choose to call it – it certainly creates another fantastic layer of security.
Notice that DC2.contoso.com has replication occurring over the VPN tunnel with DC1.contoso.com. Something that’s unique here is that DC2.contoso.com is a Read Only Domain Controller (Note : this feature is only available with Windows Server 2008 and above. ) This allows the Azure Virtual Machines to have a localized domain controller and global catalog server for all of the respective benefits, but facilitates an environment in which a compromise of DC2.contoso.com would not grant anyone (or any specific thing) the ability to make writes to DC1.contoso.com. In fact, this architecture has DC1.contoso.com living behind the on-premise firewall. And even though this is in the DMZ – a breach of the firewall would have to occur for access to contoso.com. And what if that occurred? We still haven’t exposed our internal Active Directory domain nimbo.com to the outside world because there’s that fantastic one-way trustin place where contoso.com trusts nimbo.com but nimbo.com does not trust contoso.com.
Platform as a Service Authentication
The above scenarios have briefly outlined some of the options around domains, domain joined machines, and workgroup servers for Azure connectivity to IaaS – but what about specific application authentication? Of course there are scenarios where a database in the cloud for an application in the cloud has a repository of users which can be used for access control and authentication. What if an organization’s risk management or security groups won’t allow a repository of users to be placed in the cloud for fear of a security breach? There may be situations where we would like to leverage an Active Directory domain for authentication but not be comfortable with the idea of (1) putting an extension of that Active Directory domain in the cloud (i.e. a new Site) or (2) establishing any sort of trust to a Cloud Active Directory Domain. Again – there are multiple methods of solving these problems but I’ve identified an example of Federation in the sections below.
(Note : The below image is not an architecture, but is a representation of the challenge in the above paragraph. )
Scenario 5 – Cloud Service in Azure Using Active Directory Federation Services 2.0
In the above image I’ve placed a single Cloud Service in the Azure platform with a backend database using SQL Database. This could represent several types of applications but for the sake of this example let’s explore the idea of this being a front-end IIS based web-application written in ASP.NET in C#.
Assume that the application has two menu items:
- General Access – Default View
- Administrative Control Panel
The objective might be to allow all authenticated users access to the first menu item, General Access – Default View but to only grant access to the second menu item Administrative Control Panel to users we deem to be application administrators.
Rather than having a giant repository of users in the SQL Database, we could simply have a SQL Table which represents something like the following:
eMailAddress |
isAdmin |
User1@nimbo.com |
True |
User2@nimbo.com |
True |
User3@nimbo.com |
False |
Theoretically, the email addresses for respective users accessing the application are likely stored in the Active Directory domain nimbo.com in addition to lots of other details about the Active Directory users (i.e. First Name, Last Name, Security Groups, Password, Home Address, etc.). Since we want to be secure – what if we’d only like to pass one piece of the information for a given user to the cloud based application rather than the full repository of information? In the example above – we could make a programmatic decision on whether to allow entry in to the Administrative Control Panel or not based on the (1) email address of a user being contained in the eMailAddress column of the SQL table and/or (2) the Boolean value of isAdmin having a value of ‘True’ in the SQL table. Enter Claims-based authentication.
Using Active Directory Federation Services 2.0 in the on-premise nimbo.com environment, we can create a relying party trust for the PaaS Cloud Service shown in the diagram.
Here’s a (very) high level description of the federation flow. The numbers below are represented by the numbered stars in the diagram:
- A user attempts to access the web application in the cloud.
- The application in the cloud returns the location of the Active Directory Federation Services (AD FS) 2.0 URI to the user and redirects the user’s browser to that respective URI.
- The user’s browser passes the users credentials (or token) along to the AD FS 2.0 environment.
- The AD FS 2.0 environment ensures that the certificates match and that the web application in the cloud corresponds to a pre-configured relying party trust. Then, it reaches out to a nimbo.com domain controller to verify that the credentials (or token) are valid. If everything checks out, the domain controller returns a ‘claim’ of an e-mail address and a token.
- The user then is able to access the application, passing the email claim along with the request which the application can use to determine whether the user can see the Administrative Control Panel screen in addition to the General Access – Default View screen.
There’s a bit more to this process – but I wanted to provide a less granular (and somehow more effective) description of this process. The key takeaway here is that we are able to leverage a single-sign on experience if the mobile user or on-premise user is using a nimbo.com domain joined machine and also withhold exposing the entire Active Directory domain repository to a ‘perceived’ foreign environment.
Scenario 6 – Cloud Service in Azure Using Active Directory Federation Services 2.0 with a VPN
Notice that the only change in this architecture is that the AD FS URI is no longer one which is routable over the internet. In the previous example (Scenario 5) the AD FS URI was noted as:
https://adfs.nimbo.com/FederationMetadata/2007-06/FederationMetadata.xml
However, in this scenario the URI is now noted as:
https://server6/FederationMetadata/2007-06/FederationMetadata.xml
Because public DNS servers would have no idea how to resolve an address of server6 – this provides an additional layer of security by inhibiting public access to the Active Directory Federation Services environment. How would a user access this? Quite simply, by being on a VPN (Note : this is not to be confused with the Windows Azure VPN and is specifically talking about a mobile user based VPN which connects to the on-premise environment and ensures that the internal DNS is made available for queries. )
Next Steps
Try to think outside the box when it comes to the realm of Authentication and Access. There are lots of moving parts which we can select and choose from. Each implementation and application will have different requirements. If you’re interested to try out a lab for federation, have a look at a blog I wrote:
Also – if you’re planning on getting up to speed I highly recommend learning the Windows Azure PowerShell Cmdlets:
https://blog.nimbo.com/the-ultimate-powershell-guide-windows-azure-management-cmdlets/
- Ira Bell