Microsoft has taken their next steps bridging Windows Server Active Directory and Azure Active Directory more tightly together. And they're big steps: a new directory synchronization tool and the ability to reset Windows Server AD user passwords from a web portal.
Hybrid password reset
This feature, which Microsoft calls “DirSync with password reset writeback”, is part of the Azure AD Premium offering I covered back in March. If you enable this feature, it allows users to reset their Azure AD user account password via the My Apps web portal. But at the time of announcement, this feature only reset the Azure AD account password; the user’s corresponding Windows Server AD account password was not updated. Though this capability is useful in certain scenarios (for example, new or small companies using only Azure AD with no on-premises Windows Server AD), it was of little value to the 90% of the world’s large companies running Windows Server AD. They need the in-the-cloud password change to replicate back to the on-premises AD their users log on to every day.
The Microsoft directory services team knows this very well, of course, but to make writeback work they had to update DirSync. And update it they have; 3 weeks after announcing Azure AD Premium, an updated DirSync writeback installation guide page for updates.
(4/29 Update: the DirSync writeback installation guide is now available.)
Azure AD Sync
Microsoft’s identity synchronization utility, DirSync, has been around for a number of years. Until recently it was the only way companies could provision their on-premises Windows Server AD identities into Azure AD to provide single sign on to Office 365 and other Microsoft online services. DirSync suffers from a number of limitations, but the most painful for large companies is that it only synchronizes identity data from one forest to Azure AD. Many companies, of course, have more than one AD forest in production; indeed, Microsoft changed its original “one forest to rule them all” guidance in the mid-2000s to acknowledge that there were many legitimate business requirements for having multiple forests. If they were to use DirSync, these multi-forest companies had to either pick one forest to sync, or invest in a tool like Forefront Identity Manager or a virtual directory server to consolidate their identities.
Azure AD Sync (AADSync for short) has its underpinnings from components of Microsoft's Forefront Identity Manager (FIM) metadirectory service, so its architecture is similar to both DirSync and FIM. You connect your data sources – AD forests – to AADSync via a connector (a management agent in FIMspeak). Like FIM and other metadirectory services, these connectors feed into a metaverse that contains a consolidated view of all the inbound identities. It’s this consolidated view that AADSync replicates to Azure AD.
ne of the differences between AADSync and its predecessors is how the admin configures it. What objects and attributes are synchronized to the metaverse, and which objects are authoritative over others, is determined by inbound synchronization rules (ISRs), and these ISRs are configured entirely by declarative provisioning. In non-Microsoft speak, this means the admin configures it entirely through the UI instead of coding together a management agent as you might need to do with FIM (Figure 1). The AADSync admin can also easily include what Windows Server AD containers to include in the sync. Once the configuration is complete, the changes are applied to AADSync via PowerShell scripts.
Azure AD Sync Scenarios
The current AADSync feature set is designed to support three scenarios. The first scenario, known as “separate topologies”, describes where a company has multiple, separate AD forests that share nothing with each other. Common examples of this scenario would be an acquisition, or separate legal entities within a corporation (Figure 2).
The second, “full mesh” scenario is the opposition configuration: multiple AD forests with two-way forest trusts between them. Users and resources can be located in any forest. This is the most flexible on-premises configuration if your business requirements and regulations allow it. In AADSync, identities from both forests are consolidated into the service’s metaverse (Figure 3).
The final scenario, “account-resource forest”, handles a fairly common AD configuration where separate organizations access shared resources such as a corporate Exchange system (Figure 4). In this configuration, each organization has several AD forests that contain accounts and resources used only by that organization. In addition to these account forests, there is a resource forest containing enterprise services such as Exchange or Lync; one-way trusts from this resource forest to the account forests ensure members of each account forest can use services in the resource forest.
As it stands today, AADSync supports multi-forest sync, including the ability to include multiple Exchange orgs. It doesn't yet have password reset writeback (e.g. you still need the most recent update to the older DirSync service I linked above), or password hash sync. There’s no support yet for on-premises GAL sync, and no migration path from DirSync. Support for data sources other than Windows Server AD has not been announced. I expect many of these capabilities to show up during the course of the product’s preview.
General availability of AADSync is planned for Q3CY14. The product’s licensing is based on Azure AD licensing, so it's essentially free (since there’s no point to using it if you don’t have an Azure AD tenant). However, the free version only supports one-way sync from on-premises to Azure AD. The Premium version will support writeback to both on-premises data sources and between on-premises data sources when the AADSync feature for the service becomes available.
My Thoughts
These are two important announcements from Microsoft. AADSync provides a number of badly-needed capabilities, but I believe that writeback is more significant strategically. In fact, I believe password writeback is one of the more important milestones in the history of Active Directory. This the first time Microsoft has enabled its new cloud AD to update its venerable on-premises AD; the identity flow is no longer just out to the cloud. It’s true that only 7 attributes are enabled for writeback, but that’s certainly just the tip of the iceberg. There’s no reason why the two shouldn’t eventually share the same schema and all appropriate attributes.
Many organizations will be very uncomfortable at first with the idea of a cloud service updating their on-premises AD, and that’s perfectly understandable. But an integrated on-premises / cloud identity directory is a key piece of Microsoft’s Cloud OS vision, so you need to consider if this concern will affect your Microsoft adoption in the future. Writeback also increases the importance of a highly available AD FS + DirSync identity bridge; down time in the DirSync component will affect your on-premises operations, not access to cloud applications. (Third party identity bridge support for writeback is unknown.)
Azure AD Sync will be welcomed as a significant improvement from DirSync. But since Microsoft updated the Graph API to support full identity lifecycle management for federated users, third party IDaaS vendors have been building their own Azure AD provisioning mechanisms that don’t require a Microsoft directory synchronization service. If you want to have single sign on for Office 365 or other Microsoft online service, DirSync or AADSync will no longer be your only choice.
Here’s the full announcement from Alex Simons.
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.
