With the General Availability (GA) release of Windows Azure Infrastructure as a Service (IaaS) a very powerful Identity Access Management (IAM) architecture is now available.   It brings a simplification to the authentication process for users of Office 365 whose companies utilize an Active Directory deployment for their organizational IAM process.

By leveraging the total cost of ownership advantages of Windows Azure Virtual Machines, or “VMs” (as part of Azure’s IaaS offering) companies can now host their Active Directory deployment in the Cloud in an inexpensive, scalable, and highly-available manner.   This includes their Active Directory Domain Controller (ADDC), and one or more IaaS VM servers running Active Directory Federation Services (ADFS) and ADFS Proxy Services (ADPS).  With the exception of the ADDC, the ADFS and ADPS servers can all be placed into a server farm.  Windows Azure provides “free of cost and hassle” dynamic round-robin load balanced functionality for its VMs.  Additionally through the concept of Azure IaaS availability sets, automatic failover is provided for VMs sharing a common endpoint. This provides not only a scalable architecture but a highly-available one as well.

For unified integration of AD domain accounts with Office 365 the AD deployment utilizes the Directory Synchronization (DirSync) tool.  This is run on a regularly scheduled basis to synchronize your email-enabled user objects from within your ADDC with managed accounts in Office 365. This maps licensed functionality for users to application capabilities within Office 365.

Through seamless integration with Office 365, the Active Directory deployment can subsequently federate identity management for Office 365 users.  Via the power of identity federation users within your organization log into Office 365 using their organizations credentials. They don’t have to create and maintain as separate set of credentials unique to their Office 365 account.   This offers a very powerful single sign on (SSO) experience for your users using a sole consistent identity principal.

In the following diagram you can see how at a high level the identity flows through the federation process.


  1. User goes to Office 365 and enters their email address which contains a domain.  Since you have already configured Office 365 to federate identity for that domain Office 365 redirects the user to the ADPS login screen for that domain.
  2. ADPS accepts the users login ID and password.
  3. ADPS lives within a DMZ and communicates with ADFS through a secure HTTPS channel. ADFS communicates with ADDC to authenticate the user.
  4. The claims-based SAML authentication token is sent back to Office 365 and the user is authenticated.

At that point Office 365 looks at its internal account for that user’s managed account to see what applications that user is licensed to use> Based upon that Office 365 makes application access permissions decisions. The user is allowed to use only those Office 365 applications to which they are licensed.

Alternative architectures are possible to take into account an existing ADDC on-premise.   By configuring an Azure IaaS Virtual Network (VNET) and connecting it through a VPN device to an on-premise network, an existing ADDC can remain on-premise while all the other parts of the AD deployment (ADFS, ADPS, and DirSync) can run in Azure IaaS VMs.

The power of identity federation exists through Office 365 and Active Directory integration.  It is now available in a scalable, inexpensive, and highly-available manner through Windows Azure IaaS.