First look: Windows Azure Active Directory preview

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.

What's in the WAAD cloud

Assuming you access WAAD via Office 365 and continue along with that experience, you'll find that the cloud directory instance is made up of the following discrete types of information:

• Users: Information about people, passwords, the security policies for those passwords and other related data.
• Groups: Security groups and distribution groups, like you're accustomed to in on-premises Active Directory.
• Role memberships: Information about which users belong to which roles. (Only users -- people, in other words -- can be members of roles; groups can't have roles.)
• Service principals: Any object that's not a person that is used to access objects in the directory. These could be computers, devices conference rooms, or anything else that isn't a specific user.
• Domains: Essentially a list of DNS domains that are connected to your cloud directory instance or Office 365 instance.
• Microsoft service-specific information: Items like subscription lists, licenses, service levels and more. These pieces don't really have a direct link to relevant administrative tasks and are included in the directory more for Microsoft's internal use.

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 Office 365 Administration Portal, shown here, is where you set up an instance of Windows Azure Active Directory at this time.

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.

The PowerShell command environment is the primary method, so far, for managing Windows Azure Active Directory instances.

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.

How does on-premises Group Policy work when ported to Active Directory in the cloud, or vice versa? Group Policy has been integrated with Active Directory and Windows Server since the 2000 release and most corporations have extensive deployments of Group Policy objects that manage access and permissions to a variety of servers, files and settings within the security domain.

But Group Policy is functional only with on-premises deployments, at least as it is currently written. How will this policy information carry over into the cloud? Will administrators be able to set Group Policy-based access to cloud services and get very granular with those permissions? Will they be able to set Group Policy Objects, or GPOs, on premises using existing Microsoft-built and third-party-developed management tools that companies have already invested significant money in? Will Group Policy administration move to the cloud and "trickle down" over time to on-premises deployments?

I can find no public statement about how Group Policy will grow and change along with cloud-based directories, so this is absolutely an area to watch as WAAD continues down its development path.

How does Windows Intune fit in with WAAD? Microsoft has been marketing Windows Intune as a way of bringing together the management of both domain-joined and non-domain-joined Windows machines in addition to iOS-based devices like the iPhone and iPad, and Windows devices.

Intune's meant more for small to midsize organizations that would like to manage all their IT assets from the cloud. The Intune model doesn't really integrate well with other management tools, making it a poor choice (at least in its current iteration) for larger organizations.

But since we don't know much about how Group Policy will work, is it possible that the Windows Intune management infrastructure will be subsumed into WAAD, and computer and device management will be enabled from there? Is this a way to bring integrated computer and device management to the cloud, particularly for larger customers with big numbers of deployed computers, and away from on-premises solutions? There may be an interesting story to tell here in the coming months; stay tuned.

What about Kerberos support? Kerberos is used in Active Directory environments to perform transparent seamless authentication and authorization, and while it's the basis of all Active Directory transactions, it is of particular emphasis and importance in cross-platform environments.

For example, large universities typically leverage Kerberos protocol sets to allow Unix and Linux, as well as Macintosh, machines to authenticate against Active Directory since those operating system platforms dont natively support the way Windows typically exchanges security information with Active Directory.

With WAAD, there's no mention of Kerberos support. With all of the talk of mobile support and managing identity information for phones, tablets and other devices, one is left to wonder whether support for Macs and Linux machines will be included with this release of WAAD. This could be a significant drawback to deploying this technology for organizations with large sets of non-Windows computers.

The last word

Windows Azure Active Directory is an interesting, but not yet compelling, addition to cloud-based directory services. In this July developer preview release, IT pros building applications both internally and for sale can now integrate with Microsoft accounts already being used for Office 365 and other cloud services and will soon be able to, with the final release version of WAAD, integrate with other consumer directory services. That's useful from an application-building standpoint.

Additionally, IT pros can enable federation scenarios and synchronization between on-premises Active Directory deployments and Windows Azure. But for now, unless you're running Office 365, there's not much with which to integrate. The cross-platform and administrative stories are simply not there yet.

Stay tuned for more developments on this promising technology -- as it matures, it could be quite interesting -- but unless you're building Azure apps right now, you can give this release a pass.

Jonathan Hassell runs 82 Ventures LLC, a consulting firm based out of Charlotte, N.C. He's also an editor with Apress Media LLC. Reach him at jhassell@gmail.com.

Read more about cloud computing in Computerworld's Cloud Computing Topic Center.