A hybrid cloud computing architecture can be confusing. One reason is that you can arrange the building blocks in a variety of combinations, both on premises and in the cloud. This model clearly applies to identity in general and to Active Directory (AD) in particular. And this capability leads to numerous questions. When should you deploy AD in the cloud? When should you use Windows Azure AD? When might a third-party cloud Identity as a Service (IDaaS) better meet your requirements?

Over the next few months, I'll help you answer some of these questions. I'll cover each major configuration of Windows Server AD, Windows Azure AD, and third-party IDaaS, as well as the most applicable scenarios for each configuration.

So Many Choices

Here are the possible configurations of Windows Server AD and Windows Azure AD, in relative order of maturity:

  • Windows Server AD on premises only—Microsoft's identity service, before the cloud shook up the status quo
  • Windows Server AD on premises and extended into a public IaaS cloud—Windows Server AD domain controllers (DCs), hosting one or more on-premises domains and running on virtual machines (VMs) in an IaaS cloud (such as Windows Azure IaaS or Amazon Web Services), with a communication link (such as a VPN) back to on-premises DCs
  • Windows Server AD on premises, in the cloud, and with an identity bridge to Windows Azure AD—Windows Server AD DCs, both on premises and as VMs in an IaaS cloud, and sharing identity information with Windows Azure AD via an identity bridge
  • Windows Server AD on premises, with an identity bridge to Windows Azure AD—Microsoft's hybrid "Cloud OS" vision, consisting of on-premises DCs sharing identity information with Windows Azure AD via an identity bridge
  • Windows Azure AD in the cloud only—No on-premises directory services, all identities being sourced from Windows Azure AD in the cloud

Your organization might not go through all these configurations or go through them only in this order. But this is the most likely sequence, even if you skip a step. For simplicity's sake, I've described only a single Windows Server AD forest in each configuration here. But I'll cover multiple-forest variations as I discuss each configuration in more detail.

First Things First

The first configuration, Windows Server AD on premises only, is well known and doesn't need much elaboration. But this is a good opportunity to address the popular question about Windows Server AD's strategic future in Microsoft and with customers. Despite rumors to the contrary, the on-premises enterprise IT world is not going away any time soon. There are just too many legitimate reasons for having local control over your computing resources. That's why most cloud-computing conversations move from the public cloud to on-premises private cloud configurations before eventually evolving to the hybrid cloud. And if—or when—your company moves the majority of its resources to the cloud, one of the last components to be removed from your data center will be the identity infrastructure.

At the RSA conference in February, I asked Radiant Logic CEO Michel Prompt to predict how long on-premises IT would be around. His response?

"Remember when everyone said the mainframe was going away?" recalled Prompt. "That was back in the late 90s. Mainframes are still around today. And Active Directory is far more widespread than mainframes ever were."

However, with that said, Microsoft is focusing on enhancing Windows Azure AD over Windows Server AD. As Windows Azure AD is a web service, Microsoft can (and has) rapidly deployed new features to it. Many of these features simply add basic capabilities (such as group management). But others, such as multifactor authentication, take advantage of the quick implementation that the cloud service model provides. That is, if you've established a connection between your on-premises Windows Server AD and Windows Azure AD and you're willing to pay a monthly fee for the capability.

Windows Server AD might (or might not) add the same features on its next release cycle. Within Windows Server AD, the core Active Directory Domain Services (AD DS) application is quite mature. The vast majority of Windows Server 2012 R2 identity enhancements were to Active Directory Federation Services (ADFS), the AD DS authentication link to web services, mobile devices, and Internet standards.

Looking Forward

Next time, I'll go over the second configuration. I'll discuss scenarios in which you want to extend your Windows Server AD presence directly into the cloud.

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.