First look: Windows Azure Active Directory preview
Our analyst suggests giving this Microsoft release for app developers a pass. Here's why
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.
There is a huge restriction right now to how useful this service is. Right now DirSync is only one-way; it goes only from on-premises to cloud. If you were to, say, create a new user on your Office 365 cloud system, that user information wouldn't find its way down to your local directory. Equally frustrating, the users you may already have created on your cloud tenant AD instance won't propagate down to your local directory, even upon first connection.
This process is essentially the same as using the directory synchronization tool in Office 365, something I've done with success four times now on domains of various sizes ranging from 10 users to 122 users. Users and groups (and memberships thereon) were transferred as expected within a few hours. It's best to expect the process to take up to 36 hours to allow for a full initial synchronization, especially for a large domain.
The authentication process works as you would expect it would for a federated configuration -- the ADFS2 instance running locally handles all credential authentication, so no passwords make their way up to the cloud. The system sends only tokens that give a green light to certain operations based upon who the user is and what actions he or she is authorized to take.
Once everything is up and running, you'll find that there are four main ways to interact with your cloud-based AD instance.
What we don't know yet
As WAAD is only in a developer preview release as of early August, there are a lot of unanswered questions. The current preview is geared toward software developers building Windows Azure-based applications that will consume and interact with identity information. As such, there are not a lot of bells and whistles for the average IT administrator yet. Among the concerns and unknowns are the following:
What will the graphical user interface for managing WAAD look like? Right now, since it's still early days in the product's lifecycle, IT users can administer the service only via remote sessions of PowerShell; there's not yet a GUI.
Microsoft promises there will be a GUI included with a future preview release, but one wonders whether that GUI will be full-featured or if it will cover only the most commonly used aspects of WAAD. One also wonders whether to do advanced administration and federation, customers will have to drop down to PowerShell cmdlets and abandon any GUI completely for those more advanced features.