Are you ready for more Microsoft? A couple weeks ago, I posted an overview of the recent Windows Azure AD (WAAD) and Access Panel announcement that heralded Microsoft’s entry into the IDaaS market. In it, I looked at Sean Deuby’s excellent article on the WAAD news, as well as his analysis of Microsoft’s hybrid identity paradigm, which envisions a world where on-premises identity happily co-exists with—and empowers—identity in the cloud.

Now I want to take a deeper dive into how to make all this work, and why we here at Radiant believe you must normalize, aggregate, and remap your identity before shipping it off to the cloud. Today, we’ll look at making WAAD work in an environment made up of only Microsoft identity sources—your basic AD domains and forests. Of course, since even the most Microsoft-centric Fortune 1000 companies tend to have much more complicated environments (SQL and LDAP, oh my!), my next post will focus on enabling hybrid identity within the heterogeneous infrastructure.

But for today, let’s examine the deployment of a hybrid environment where WAAD functions as your service-based identity for the cloud, but your identity continues to be managed and originated on-premises at your enterprise.

WAAD is Your IDaaS, but AD is Still Your Co-Pilot

In this scenario, the most likely use case involves these steps:

  1. You move your local AD user accounts—or more likely, a sculpted subset of that user data—to populate accounts on WAAD.
  2. You point WAAD to an instance of ADFS that’s installed on-premises, so it can leverage your enterprise security means.

With these two steps, you’re using WAAD to identify a user by confirming that he/she exists in the WAAD global list, and then delegating ADFS to check the user’s credentials using your AD integrated authentication (Kerberos) and SAML to verify the user. We see this somewhat convoluted process play out here:

How Microsoft Would Authenticate Users for WAAD in a Federated Accounts Scenario

How Microsoft Would Authenticate Users for WAAD in a Federated Accounts Scenario

In the diagram above, we see that the operation can be divided into two main parts:

  1. The synchronization of identity from the local AD to WAAD, after some level of remapping.
  2. The delegation of authentication—credential checking—via ADFS back to your enterprise AD infrastructure using SAML and Kerberos.

For the first operation, DirSync works with WAAD and your on-premises forest and domains to synchronize your identity. On the surface, this seems pretty straightforward, beyond a little remapping to make the AD version of identity line up with the more specific federated version you’ve created for WAAD. But when you look at the real picture for most medium-to-large sizeable organizations, it’s not so simple.

Duplicate Users Across Domains: The Need for Normalization

First, even if you have only one homogeneous forest with multiple domains—and this supposes a world without multiple lines of business, mergers and acquisitions, or reorganizations—you still need to give some help to the mighty DirSync. Why? Because there are differences between theory and practice.

In a perfect world, a user is defined in one domain for a given forest, because most of the time, domains are created on a local network or a site with good connectivity boundaries. In many cases, a domain is created according to location (say, San Francisco or New York) or business function (sales, marketing, finance, and the like). So as a user, my ID would be “Novato/Michel” using location-based naming or “HQ/Michel” using function-based naming, with the domain acting as a partition of the namespace.

In practice, because a user plays different roles at different times, and access to applications and resources are often geographically or functionally distributed, a user tends to be defined across more than one domain. While there are ways to deal with this issue using trust and delegation, duplicate user accounts are often a quick and dirty way to solve administrative headaches. And hey, we all have a life, so not everything happens according to best practices.

Usually this is not a problem, because each of these domains is segregated by location or function, so while “Novato/Michel” and “Chicago/Michel” are two different identities for the same person, they exist in two clearly separated realms. But, like all things done in haste, duplicate accounts across domains will now lead to new hassles with the advent of WAAD, giving us the opportunity to repent at our leisure.

Yes, Those Chickens are Coming Home to Roost

To enable WAAD, you need to federate all your identities, creating a flat list of your users in the cloud so you can uniquely identity them and check their credentials. But by flattening your trees into a unique list, you will have to decide how to handle duplications across domains. Do you allow a user to have multiple logons, so I become both “NovatoMichel” and “ChicagoMichel”? But which profile will be used to transmit group and authorization attributes to my SaaS applications? Or do you pick one identity and eliminate the other? And how do you decide which one?

Before you can move identities into WAAD, you need to bring all your identities into one place to be cleaned and correlated. So even if you have only one forest and many domains, you are already facing the task of normalizing to create a federated view of your identity out of those multiple AD domains. (Of course, I haven’t really touched on the fact that DirSync synchronizes data only from a given domain for a given forest—and how many good-sized companies have only one?)

Does it seem like I’m painting too dark a picture here, insisting on the need for normalization? Think back and you’ll probably hear a little voice reminding you that no less than Microsoft itself has been recommending that you consolidate all those domains into one enterprise domain, that you normalize your identity to better adapt to the evolution of the ecosystem. (Hindsight is 20/20—I have done no better than anyone else here). But like all those resolutions we make about eating better or exercising more, most of us shut out those suggestions because normalizing your data without tools is hard—as painful as saying no to cake and yes to cardio.

Virtualization to the Rescue: The Tools You Need to Make WAAD Work

Without preaching too much to my choir, I have some good news for you. (This is the part of the blog where I tell you how great our technology is… 🙂 ) We’ve been working for many years on this problem and our solution for federating identity through advanced virtualization is now helping customers across the globe untangle their infrastructures and connect to the cloud.

In fact, this approach doesn’t just address duplication across domains within a single forest, it can even solve the all-too-common challenge of duplication across many forests, each with dozens of domains. So our federated identity service is purpose-built for the needs of the larger enterprise, enabling you to integrate and normalize your identity layer, then hook it to DirSync to synchronize the perfected image of your identity to WAAD and the cloud.

RadiantOne Normalizes Identity Data Across Forests to Create the “Golden Image” Required by WAAD

RadiantOne Normalizes Identity Data Across Forests to Create the Golden Image Required by WAAD

Next week, we’ll take a closer look at how our federated identity service works—even in diverse environments where there are tons of forests, along with a mess of databases, LDAP directories, and web services.

And don’t forget to sign up for our don’t-miss-it webinar, coming up on September 19 and featuring Microsoft maven Sean Deuby and our very own Lisa Grady.