Difference between an Azure app “domain-joined” to your Active Directory and an Azure app joined to your Active Directory through AppFab:ACS.

  • Article

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.

Domain-joined

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.

image

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:

  1. It’s 09:00, Fred comes in to the office, hits CTRL-ALT-DEL and enters his AD credentials to log in to the domain.
  2. It’s 10:00 and he now needs to enter his expenses. He clicks a desktop icon which is a URL shortcut to the application in running on your instance in the Azure Data Center..
  3. The application opens, says “Welcome back Fred” and he uses the application to submit his expenses.

What actually happened behind the scenes:

  1. When Fred logged in at 09:00 he did a Kerberos logon with a Domain Controller (A KDC) and was given a special Kerberos ticket called a Ticket Granting Ticket (TGT). It stays in the ticket-cache on his computer.
  2. At 10:00, Fred goes to the application. The application sees he has not been authenticated and returns an error.
  3. This forces the client to present the TGT to the KDC and ask for a new “Service Ticket” that will work at the application.
  4. The KDC checks the TGT, sees that it did indeed issue the ticket to that user and so creates a service ticket which it returns to Fred’s machine.
  5. Fred’s machine now retries the application, only this time it has a service ticket. The service ticket has all the groups Fred is a member of embedded in to the PAC field.
  6. The application validates to service ticket, sees it is indeed issued by a trusted KDC.
  7. It extracts the group information from the ticket (the SIDs), creates an Access Token and attaches it to various objects the application will use to determine what Fred can and cannot do.
  8. At no time is Fred prompted for credentials when he tries to access the application. He had already completed that stage at 09:00 when he logged in to the domain. So the process of authenticating to the application exists (he had to present a service ticket, which he could only get because he had a TGT, which he could have only got if he’d had a valid username and password), but its entirely invisible to Fred.

Joined through AppFab:ACS

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:

image

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:

  1. It’s 09:00, Fred comes in to the office, hits CTRL-ALT-DEL and enters his AD credentials to log in to the domain.
  2. It’s 10:00 and he now needs to enter his expenses. He clicks a desktop icon which is a URL shortcut to the application in the cloud.
  3. The application opens, says “Welcome back Fred” and he uses the application to submit his expenses.

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:

  1. Fred clicks the icon and his browser takes him to the application
  2. The application redirects his browser to your partition of AppFab:ACS
  3. AppFab:ACS sees that Fred has come from its federation partner and redirects Fred's browser to his own ADFS2 server.
  4. On trying to reach the ADFS2 server, an authentication takes place. It’s all built-in to Windows and done through Kerberos. It’s entirely invisible to Fred as a user, the same as when he goes to a domain-joined IIS machine using Windows authentication. The authentication just works under the covers.
  5. On successful authentication, the ADFS2 server pushes Fred back to AppFab:ACS and appends a SAML token which it encrypts and digitally signs. If you need to understand encryption and signatures, read my crypto primer.
  6. AppFab:ACS receives the token, decrypts it and checks the digital signature. It is now assured the token has been issued by its federation partner.
  7. AppFab:ACS creates a new token and copies the claims in the original token in to the new token. At this point it might also do something called claims transformation. If you need to understand this – again, read the federation primer.
  8. It digitally signs and encrypts the token (optional) and redirects Fred’s browser back to the application it started appending the new SAML token.
  9. The application decrypts the token and checks the signature. It verifies the token was definitely issued by your partition of AppFab:ACS and grants access to Fred. Fred never had to enter a password, other than the password he entered when he logged on to AD at 09:00 when he started work.

Federated access or domain-joined access: how do you choose?

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:

  • You control the federated trusts
  • You determine which organisations can and can’t have access to the application
  • You apply AD policy to the machine automatically
  • Domain-joining the machine means you also need to deploy Azure Connect which means it looks as if the machine is on your local network and hence management is made even easier.

I hope this clears up all the confusion I am coming across…

Planky

Technorati Tags: AD,Azure Connect,federation,kerberos,AppFab,ACS,ADFS2,CardSpace,"Application Fabric",planky,plankytronixx