I’ve been getting a lot of questions about the differences between a domain-joined application running in Azure and an Azure application which is connected to AD through ACS/federation. I thought I’d try to illuminate the differences and give some guidance on when you’d choose one over the other.
An Active Directory Forest is a security boundary. A domain (container within a forest) is a management and policy boundary. When you add a member server to a domain, it is placed in a container, typically an Organizational Unit (OU) and there is an inheritance and permission structure that means a collection of group policy objects will be applied to the server. You can think of the server as “part of the organisation”, like as if it’s “one of us”. Assuming normal permissions/inheritance, you can change the effect of AD’s policy on the machine by changing one of the policy objects above it in the tree structure, or applying a policy from a different part of the tree. Some policies are domain-wide, such as password policy. Some apply just to the container and all child containers.
A domain-joined machine therefore enjoys being a good corporate citizen in that it is subject to management in a controlled and directed way. Its management is determined by the AD administrators. It also benefits from Active Directory security features – specifically authentication through Kerberos, and the consumption of Kerberos tickets issued by Domain Controllers (know as Kerberos Distribution Centres (KDCs) in the Kerberos world). Kerberos tickets have a field within them called the Privileged Attribute Certificate or PAC. This field contains a list of all the Security Identifiers (SIDs) that apply to the object in question, typically a user. Most of the SIDs relate to security groups the user is a member of.
In a “traditional” Windows Server application, it is the membership of different security groups that determines a user’s access to resources. Both the server running the application and the users who consume it are under the same security and management regime because they are part of the same Active Directory. In essence, the server “trusts” the Active Directory and is able to validate that users visiting it are from the same trusted Active Directory, or are not.
When you domain-join a Windows Azure instance to Active Directory, you are essentially extending your network’s boundaries out to the Windows Azure data-centre the instance is running in and making it part of your core networking and management set-up. It also gets the benefits of “trusting” your Active Directory and therefore “trusting” your users. It is subject to the same management regime as other servers in the same AD container. It can automatically receive Kerberos tickets and create access and impersonation tokens from them. If you use all the standard security APIs you can determine somebody’s access to a resource based on their group membership. The only difference between a server in your own data-center and one in Windows Azure is its physical location.
Diagram 1: Extending the boundaries of your AD in to the Azure Data Center
In diagram 1 you can see server objects in the local on-premise AD that represent the instances you have deployed on to the Windows Azure fabric in one of Microsoft’s Data Centers. Whatever AD management, security and policy you apply to these objects will physically manifest itself on to the servers in the cloud.
A computer can only be a member of one domain. It is only ever under the control and policy of a single Active Directory. Therefore, there is no real organisational boundary between the instances you have running in the Microsoft Azure Data Center and the resources you have running in AD in your on-premise environment.
You often come across organisations that have divided up “soft” organisational boundaries inside the parent organisation by creating partitions in Active Directory. A partition is a domain. So you might find for example a set of resources in one domain (this is common for say, Exchange) and different sets of users in other domains; perhaps there’s an EMEA domain and an APAC domain representing the geographical regions of the organisation. Although the entire infrastructure is owned and operated by say, The Plankytronixx Megacorp, it has been divided up into soft organisational boundaries. Some organisations are forced to go further and divide their network in to separate forests. Some have so many forests, they are laughingly referred to as “jungles”.
Let’s take the Exchange example above. If you want to give users in say the EMEA domain, access to the Exchange resources in the Exchange domain – there needs to be a Trust relationship between the 2 domains. The administrator of the Exchange Domain can grant users from the trusted domain access to Exchange resources such as a mailbox etc. This will all use the underlying Windows infrastructure – DNS, LDAP, Kerberos, security etc. There are a plethora of protocols that need to communicate across domain boundaries which is why you rarely see Windows trusts operating across the Internet (unless “tunnelled” inside a VPN or some similar protected network concept).
When trusts are setup between all these entities, the security information that is passed between them can be quite illuminating. For example, I mentioned group-bloat earlier. When you connect to a resource in a trusted domain and your Kerberos ticket is passed to that resource, it contains a list of all the groups you are a member of. Just simply browsing through this list could be interesting. Maybe as a nosey-neighbour, I’d find a group called “TopSecretSupersonicAircraftDesign”. Although that doesn’t reveal the design to me – it does reveal a little bit about the thinking of the operators of that domain. Generally it’s OK because we’re all in the same company – but it does prove the existence of a soft organisational boundary.
You could say that the trust you have in a domain-joined environment is very high, you tend to trust just about everything.
Let’s take Fred, a user, through the steps of opening an application on an instance which is running in Azure but is domain-joined to your Active Directory:
What actually happened behind the scenes:
I’m going to assume you understand a little of the basics of federation for this part of the post. If you don’t - read my federation primer to get yourself up to speed.
When you place an instance in Azure and you “protect” it using AppFab:ACS, you are typically crossing an organisational boundary. There are reasons you might not be doing that – which we’ll come to in a moment. For now, let’s assume you are say, a SaaS service provider. You have written the most fantastic expense submission application and everybody wants to use it.
You don’t want to go to the trouble of having to manage the users. You want to provide the service. So you set up federation trusts with those companies that want to use your service. They create the users, set their passwords, determine if the accounts are enabled or disabled. They delete the accounts when they are no longer relevant, they set password complexity policy, expiration policy and so on. If a user forgets their password they go to their own company’s helpdesk to get it reset, not yours.
They do this by configuring a service that sits on top of their Active Directory called Active Directory Federation Services 2.0 (ADFS 2.0). You in your turn configure the Windows Azure Application Fabric’s Access Control Service (AppFab:ACS) with details of your application and vice versa, you configure your application with details of your partition of AppFab:ACS.
You then set up a federation trust with any company that wants to access your application. This involves the exchange of URLs and certificates between their ADFS2 server and your partition of AppFab:ACS. There are metadata endpoints to simplify this process. Of course, you could set this up between your own company’s ADFS2 server and your own instance of AppFab:ACS, as shown below:
Now, when a user from your application wants to use the application you have deployed to the cloud, it will be as if the application lives inside your AD. It doesn’t, but the experience they would have is like this:
He was never prompted for credentials because of the way the dance works with federation/ADFS2 and Active Directory. The dance is explained in my federation primer, but what essentially happens is this:
There must be criteria you use when deciding whether to domain-join your application or to access it through federation.
You’ve seen from the 2 descriptions above that a domain-jined machine is subject to all the management and policy implemented and inherited to the container in AD that holds the server object. So you have a lot of control over the entire machine. A user can log on to it in the traditional way and Kerberos authentication will give you a great platform for all applications that use built-in Windows authentication.
With federation you still have to “manage” the machine as a separate entity. It isn’t subject to the management and policy regime implemented in your Active Directory. But you can connect the identity subsystem up to it. However, the application, generally has to be a web based application. Federation runs over ports 80 and 443 – http and ssl. You can use federation technologies with rich applications – Windows CardSpace allows this because the client is “active” and can respond to policy, but you are stuck with web based applications for most of the protocols. If using ADFS2, currently it has no support for the Cardspace client, so you’ll be using WS-Federation between your local on-premise environment and the cloud’s AppFab:ACS. that limits you to purely web based applications.
You can see how a traditional enterprise application which uses Windows authentication and is an NT token based application would be particularly suited to a domain-joined environment because it’ll “just work”. This lends itself very neatly to say the server part of a client/server app that you build on a virtual machine and deliver to Windows Azure in the new VMRole. Because these applications often want to make significant changes to the OS, file system, registry and also generally require admin access, you can see the particular suitability of this. That’s not to say an NT-Token based web application is not also suitable, it’s just that a traditional Windows server app is highly suited.
A federated application has to be web-based for starters. But also, if it’s an application you are delivering as a service to not only your own organisation but many others as well, you’ll be able to set up many federation trusts and give the Windows SSO experience to many organisations that do business with you. Because the machine is not domain joined to any of your customer’s domains it remains an independent entity. But this model is particularly suited to claims based applications (to understand more about that read the federation primer) and applications that will be shared among many other organisations.
You could of course create a domain joined machine in Windows Azure – subject it to all the management and policy strength of your local AD and then deploy on to it, a federated application that your customers access through federated technologies like ACS. That way:
I hope this clears up all the confusion I am coming across…