Anyone that’s worked with Microsoft’s hybrid identity architecture of Windows Server Active Directory and Azure AD knows that the hardest step is stitching them together. The Microsoft identity bridge solution of Active Directory Federation Services (AD FS) for authentication and DirSync for identity provisioning are just not that easy to work with.
Microsoft knows this, and is hard at work making the experience easier. The next generation of DirSync - Azure Active Directory Sync (AADSync) - is soon to exit beta and supports multiple forests and selectable attributes and scope. Yesterday, the Azure AD team announced Azure Active Directory Connect, an identity bridge configuration wizard designed to simplify configuring AD FS and DirSync. Originally planned to enter beta in June, Azure AD Connect configures identity bridge components for two sign-in experiences: Password Sync and Single Sign On (also known as SSO). Let’s take a look at these two choices.
Password Sync and password hashes
The default settings for Password Sync (and the one advertised as “just four clicks”) is Express, which configures DirSync to synchronize a default set of Windows Server AD attributes – including the attribute containing the user password hash. (Passwords aren’t stored in the clear in Windows Server AD; instead, they’re converted to a one-way hash of the cleartext.) In contrast, if you configure DirSync directly you’ll see that password hash sync is available as a checkbox option; it’s not the default.
The Password Sync configuration is not single sign on. It’s what Microsoft calls “simple sign-on”, and the Cloud Security Alliance calls “reduced sign-on”. Azure AD prompts you for your credentials, but since you’ve synchronized both userid and its password hash, you just enter your corporate creds. Though this configuration is a pretty simple experience for the user, it’s definitely not an identity best practice. That calls for never allowing your corporate password to leave on premises.
Single Sign On
This is the full federation scenario, using AD FS for authentication and DirSync for identity synchronization. AADSync will install and configure multiple instances of AD FS and Web Application Proxy, and also configure DirSync. You have, yet again, the option to enable password hash synchronization to use as a fallback in case AD FS fails.
In this initial preview release the number of components and supported scenarios are restricted. The doc clearly states you shouldn't use this tool in a production environment yet. (Note that you now have both Windows Server AD and Azure AD production environments to think about.) This beta works with Windows Server 2012 R2 AD FS and Web Application Proxy only. It supports one forest, and the current released version of DirSync though AADSync support is certainly planned. And as with any externally facing production federation configuration, you must have a public SSL certificate, own the domain name and have configured DNS records to allow name resolution. Multi-forest support is in the works; in a move I’ve never seen before, the multi-forest capability is visible in the UI but greyed out with a clear indicator it’s in plan (Figure 1).
Figure 1: Azure AD Sync future multiple forest support
It seems to me that Microsoft has painted itself into a corner with its identity bridge components. AD FS isn’t going to change much due to its large installed base; in production environments it remains a heavyweight solution requiring multiple AD FS and Web Application Proxy instances, and perhaps external SQL Server databases (to support SAML artifact resolution) in a HA configuration. DirSync is evolving, but also has a large footprint compared to other provisioning methods. Meanwhile, third party IDaaS providers have developed lightweight, easy to install, load-balancing identity bridges that handle both authentication and provisioning, and are pretty much set and forget.
It’s clear that Microsoft wants to make the process of configuring a user-friendly sign-in to Office 365 as easy as possible. If configuring and maintaining federated SSO with AD FS and DirSync remains a challenge for IT admins (remember you still need to configure HA even if you use Azure AD Connect), you can see why Microsoft would steer admins towards the Password Sync configuration by default in the new tool. And their messaging so far (admittedly it’s only been out a day) has been aimed at the “just 4 clicks” default.
In fairness, your password hash stored in Azure AD is probably far more secure from hackers than it is on the DCs in your data center. But proliferation of passwords across multiple systems, even when managed by a synchronization engine, is currently just about the biggest problem we face in security today. What if you take the express Azure AD Connect configuration and (quite reasonably) never change the DirSync synchronization schedule from its default? That allows a terminated employee up to three hours of access to Azure AD-integrated SaaS apps (from the time their Windows Server AD account is disabled to when the change replicates to Azure AD). What happens if you want to move from password hash sync to a pure federation scenario? Is there a simple way to null out the password hash attribute in Azure AD? I’m not alone in these concerns; the Cloud Security Alliance's Security Guidance document points out in its Application Design for Identity section:
Designing a cloud system to scale (think of 100,000 users with an unconnected username and/or unsynchronized password) requires the need to avoid forcing a common help desk process, including manual or semi-automated synchronization scripts, password strength validation processes, password reset processes, password resets after a compromise, etc. all due to a lack of initial design thought about consuming external identities…As a rule, cloud services, and thus cloud applications, should accept the standard SSO federation formats such as SAML and OAuth (or even the less widely accepted WS-Federation).
Password hash sync is in the same category as IDaaS password vaulting. Password vaulting is a workaround of the fact that the vast majority of SaaS providers don’t support federated SSO, and thus require the user to manually enter a userid and password. The vaulting feature stores credentials in the IDaaS cloud service for the user and automatically fills out the SaaS logon screen, thus simulating single sign on. Both password hash sync and password vaulting are practical, less-than-optimal solutions to the imperfect cloud identity world we have today – but vaulting will slowly go away as more SaaS providers adopt federation.
Someone on the Azure AD team once told me that it takes the average IT shop two weeks to figure out how to get AD FS / DirSync working, and that the AD FS reference is over 100 pages long. As MIcrosoft's response to this situation - Azure AD Connect - rapidly matures, it will become the preferred configuration tool for Office 365 sign-on integration because it takes a huge amount of head-scratching and guesswork out of the process. I just hope more businesses opt for the Single Sign On scenario, now easier than ever with this tool, than the simpler but potentially more problematic Password Sync scenario.
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.
