Active Directory and Microsoft's Hybrid Identity Vision

A few weeks ago on campus, principal program manager Mark Wahl spent some time outlining Microsoft's identity division strategy for the Active Directory platform (in particular Domain Services, Azure AD, and Federation Services), which he generalized simply as hybrid identity. If I have one takeaway of interest to the hundreds of thousands of AD administrators out there, it's this: Your job isn't going away any time soon.

Windows Azure AD has been around for a few years, as it supports most of Microsoft's online services, but only in the last year has Microsoft begun to provide any details about this cloud service. In my recent article, I outlined my take on Azure AD as compared to other identity management as a service offerings. Its architectural underpinnings have been tested in the cloud production environment; of late, Microsoft has been broadening the service's capabilities, and consequently Azure AD is growing in visibility.  To broadly paraphrase Aragorn in The Return of the King), a day may come when Azure AD eclipses its on-premises version. But it is not this day.

The on-premises version of Active Directory (it seems odd to qualify AD this way), Active Directory Domain Services, is the foundation of hybrid identity. With such a massive installed base of customers – 93% of the Fortune 1000, most who have substantial investments in AD-integrated infrastructure and applications - it's not going anywhere any time soon. "We are not end-of-lifing AD Domain Services; it's a key part of our Windows Azure strategy. Azure AD is an extension, not a replacement, of AD Domain Services." They have no plans to invalidate existing identity and access management infrastructure. "We don't want to re-invent the thinking on how you populate your directory." Wahl said. "There's a great need for the Windows Azure AD experience to be consistent with your on-premises AD Domain Services experience."

What Microsoft is strongly moving towards is a hybrid identity environment where Azure AD is the common identity repository for a variety of Microsoft-related accounts: Your on-premises AD accounts, accounts created in Azure AD only, or Microsoft (formerly Live) accounts. Wahl said, "We're evolving the idea of what a directory provides, from being a technology component that a company purchases, designs, deploys, and operates, to being a component of a service." To me, this means that though Azure AD will continue to gain in functionality, administering your Azure AD tenant will never approach the degree of complexity we experience with AD Domain Services. Look to the simplicity and ease of use of the Azure management portal as an example of a simple user interface masking the complexity of the moving parts underneath.

There's also a great degree of flexibility built in to this vision so you can move the identity pieces around in various configurations. You can put a virtualized DC of your AD Domain Services forest in a Windows Azure-hosted VM. You could flip this scenario by creating an AD Domain Services forest hosted in Azure VMs, and land a DC from that forest into your local datacenter. You can use identities from an on-premises AD Domain Services forest to provide single sign on to Azure-hosted applications such as Office 365. You can create accounts in Azure AD to be used as an identity provider for third party web services (though this isn't a simple point-and-click solution yet).

Two components glue an on-premises AD Domain Services forest to Azure AD: Active Directory Federation Services (AD FS) and the DirSync Tool. AD FS is a Windows Server 2012 role or a downloadable add-on that functions as an authentication service head to AD Domain Services, extending its capability to web-based applications that use internet standards such as SAML. AD FS is the federation service that enables Office 365 users to logon using their enterprise AD credentials. DirSync is the account provisioning component of this connection; it replicates user accounts one-way from an on-premises forest to Azure AD, which is used by Office 365. When CRUD (create / rename / update / delete) changes are made to an AD Domain Services account – for example, disabling the account – DirSync immediately reflects these changes to Azure AD.

Note that some third party products from vendors like Optimal IdM, Ping Identity, and Centrify can also provide these capabilities in varying degrees, and are certified by Microsoft to do so. Other vendors are entering this "bridgeware" market to simplify the connectivity between on-premises AD and Azure AD compared to AD FS and DirSync, thereby reducing the friction to adopt Office 365.

There are still a lot of pieces in this vision to either create or to mature, however. You can still only synchronize one forest with Azure AD via AD FS and DirSync (though you could use a virtual directory service to present a single view). You can create on-premises accounts in Active Directory Administrative Center (ADAC) or Active Directory Users and Computers (ADUC), but you can't yet create or view Azure AD accounts from them. Conversely, you can create Azure AD accounts in the Azure AD management portal, but they won't replicate down to your on-premises forest. You can see replicated AD Domain Services accounts in the Azure AD management portal, but changes to them can only be made with on-premises utilities.

Finally, if you're into more of a visual approach, there's an excellent high-level chalk talk about Active Directory across the hybrid environment (from which I appropriated this article's graphic).

Pay attention to what Microsoft is doing in this hybrid identity space; if you have anything to do with identity or user accounts and Microsoft services it's practically guaranteed you'll need to know this. But good old-fashioned, on-premises Active Directory Domain Services isn't going anywhere, anytime soon, regardless of how rapidly Microsoft moves itself to the cloud. How do you adapt a cornerstone technology of 93% of the Fortune 1000 to the evolving computing landscape?

Very, very carefully.

Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.