Understanding identity Sync versus Federation when adopting cloud services

Hi all

I have a lot of conversations, on a daily basis, about identity … on-premises, in the cloud and hybrid models.  These mostly revolve around the gory details of on-premises identity realms, or customers adopting cloud services such as Office 365 and Windows Intune.

One of the first questions I ask is:  “Where are you comfortable storing your user passwords? ” (well, to be very clear, it’s where you are comfortable storing the password hashes, but these conversations are often with non-technical folk, so it’s best to stay clean on this).

And something that always comes up is the topic of sync and federation.  Now, this is a broad and sometimes complex topic, but this post is designed to cover the basics and answer the common questions.

First, lets take a look at the differences between the synchronization of identity, and the use of federation.

Sync has 2 options, with and without password hash. 

When you choose to sync the password hash (and let’s be clear, it’s not the password, it’s the hash of the hash of the password), you are choosing to store your users passwords in both Windows Server Active Directory and Azure Active Directory.

When you choose not to sync the password hash, only the user attributes (such as name, UPN etc) are sync, and all authentications are passed back down on-premises to Windows Server Active Directory … which leads us to Federation!

Federation can mean a few different things, but in this discussion we are referring to the configuration where identity sync is being done without password hash. 

In this scenario, whenever a user logs on to a cloud service, the authentication is passed to Active Directory Federation Services (AD FS) which brokers the validation of the user identity.  AD FS has had a number of significant investments in the 2012 and 2012 R2 releases, and is now easier to deploy and provides additional capability such as requiring a Multi-Factor Authentication as part of the user logon. 

A picture tells a thousand words, maybe a few less in this case, but you can see the differences between Sync and Federation in this diagram:

Today, we achieve sync with DirSync and FIM Sync, and federation with AD FS.  We continue to invest in these areas and you will hear more from us on these topics in the near future.

So now that we understand these basics, lets think about the different ways in which customers adopt technology and the ways they can validate users identity.

Let’s take a look at 3 different models, Cloud, Sync and Federation (these are not formal models, they are simply representative of the common setups customers have).  There is of course always a lot more complexity involved than this, but for this level of discussion, they will suffice.

Take note of where the green checks (that’s this:  ) are, as this indicates where authentication can take place (i.e. the password hash is stored).

The “Cloud” model

In the Cloud model, users identity and the applications they are accessing are all in the cloud, there is no on-premises infrastructure in play here, either because this is a green-fields customer who has never had it, or a customer who has isolated their on-premises infra from the cloud services and applications.

As you can see, authentication happens in the cloud as that is where all the identity information and validation engines are. 

The “Sync” model

In the Sync model, a customers has existing on-premises infrastructure (i.e. Active Directory) and wishes to extend this investment out to the cloud and have users able to log on to all applications and services with the same credentials, and is OK with storing the password hashes in the cloud.

As you can see in this model, authentication can happen in either location (depending on which application and service is being access … an on-premises application would hit Active Directory, a cloud application would hit Azure Active Directory) as the password hashes are stored and kept in sync in both locations.

The “Federation” Model

In the federation model, a customer is not able to sync password hashes to Azure Active Directory, for whatever reason (aversion, policy or compliance are typical reasons) so instead they only sync the user attributes (without the password hash) and install AD FS to broker the authentication when a user logs onto a cloud service.

As you can see, all authentication happens against the on-premises Active Directory, as that is the only place where the passwords are stored.

Which one is right for me?

Ah, the million dollar question (because if I had a dollar … you know the drill).  It all depends on your business requirements and options that you choose.  If you can sync password hashes to the cloud, it is clear that this is faster and easier to onboard to cloud services.  This is why it’s the first question I ask, it’s the most important question to know, understand and ensure a correct decision is made on.

If you cannot sync password hashes, then you will need to deploy the federation technologies of AD FS and the Web Application Proxy, typically 2 VMs for each role for HA but can be more dependent on customer environments and requirements.  We understand this additional load, and we are working to make this easier, again we’ll have more on this in the very near future.

I hope this has helped you understand Sync and Federation better!  As always, please post questions and feedback, I can always update and include more info

A.