Everyone knows by now that Microsoft is getting into the cloud business. But for a long time one of the biggest obstacles to corporate customers joining Microsoft on that move was the lack of an identity management platform that could span the boundary between cloud provider and enterprise.
Organizations have spent gobs of budget over the years getting single sign-on (SSO) and single-pane-of-glass identity management working within the walls of their businesses, and they're in no hurry to have to create a separate set of cloud-only credentials for their users.
Enter Windows Azure Active Directory, the cloud version of Microsoft's highly successful directory service that has been a part of Windows Server for years.
There are three major parts of the Windows Azure Active Directory (WAAD) service:
- First, developers can connect to a REST-based Web service to create, read, update and delete identity information in the cloud for use right within their applications. They can also leverage the SSO abilities of Windows Azure Active Directory to permit individuals to use the same identity credentials used by Office 365, Dynamics CRM, Windows Intune and other Microsoft cloud products.
- Second, the developer preview allows companies to synchronize their on-premises directory information with WAAD and support certain identity federation scenarios as well.
- Finally, the recently released developer preview supports integration of WAAD with consumer identity networks like Facebook and Google, making for one less ID necessary to integrate identity information with apps and services.
Let's take a look at WAAD as it stands now in developer preview form, what we can expect from it and what we still don't know about the code.
How Windows Azure Active Directory works
In this early stage, WAAD is hosted by Microsoft in its data centers and is used largely by Office 365, the vendor's cloud Office suite. Information about users, groups and services that are part of the Office 365 offering are stored in a cloud-based AD instance that lives as a tenant on Microsoft's services.
For now, that's pretty much the only way to get started with exploring and testing WAAD, since currently there isn't a front end to generate just a directory instance. Even the Microsoft documentation will tell you to sign up for a trial of Office 365 to get started.
Microsoft says that in the future, you'll be able to bring up an instance of WAAD as part of your overall Azure subscription, but for now, Office 365 is the entry point.
Once you've gotten an Office 365 trial for your account, to fully connect your AD tenant on Windows Azure to your on-premises Active Directory deployment, you will need to create an instance of Active Directory Federation Services Version 2 (ADFS2) on your corporate network.
ADFS2 basically acts as a proxy or an intermediary between the cloud and your on-premises network and is the trust point for credentials. The WAAD tenant connects to this local ADFS2 instance.
Setting up your cloud tenant instance of Active Directory this way allows the users and groups to come straight from your on-premises directory. This primarily happens the first time that you connect your on-premises ADFS2 instance up to WAAD.
After the connection is made, a tool called DirSync -- short for Directory Synchronization, unsurprisingly -- runs. DirSync makes a copy of your local directory and then propagates itself up to the cloud tenant AD instance. After that, DirSync runs every three hours to propagate changes made to the on-premises directory up to the cloud.