When you are using a cloud service, whether it be Office 365, Facebook, LinkedIn or Gmail you are using a user account, and these are also referred to as ‘identities’. Typically there are three types of identities in a cloud service: Cloud Identities, Synced Identities and Federated Identities.

• Cloud Identity – a Cloud Identity is a user account that’s created and managed in the cloud service. In case of Office 365 this account is created and managed in the Microsoft Online Portal. Important to note is that when you access an Office 365 service, authentication takes place against the Windows Azure Active Directory Domain Controllers.
  In the Microsoft Online Portal these accounts are easily identifiable as Cloud Identities as can be seen in the following figure:
  
• Synced Identity – a Synced Identity is created and managed in your local Active Directory and synchronized with the Cloud service. In Office 365 you can opt to synchronize the passwords as well, although not the actual password is synchronized but a hash of the password. Like Cloud Identities authentication takes place against the Windows Azure Active Directory Domain Controllers. These accounts are identified in the Microsoft Online Portal as ‘Synced with Active Directory’ as shown in the following figure:
  
  Although the username and password are identical in Office 365 and in the local Active Directory, this is not a Single Sign-On solution, but I always refer to this as a ‘Same Set of Credentials’ solution.
• Federated Identity – a Federated Identity is a user account that’s created and managed in your local Active Directory and that’s synchronized with Office 365. When the account is synchronized an account in Office 365 (Windows Azure Active Directory) is created. When a service in Office 365 is accessed, the user is not authenticated against the Windows Azure Active Directory Domain Controllers, but the authentication request is redirected to your local Active Directory and Domain Controllers. To achieve this an Active Directory Federation Service (ADFS) needs to be in place. Since there’s only one set of credentials (all authentication takes place against your local Domain Controllers!) this is referred to as ‘Single Sign-On’.

When and where to use these identities

• Cloud Identities – Cloud Identities are typically used in smaller environment where a local Active Directory sometimes is not even available. All management takes place in the Microsoft Online portal and there’s no link between Office 365 and the on-premises environment. Easy to implement, easy to use and easy to manage. The only thing is that users have a separate account (perhaps with the same username) and a different password. You can set the password identical to the password on-premises, but you have to take care about the password policy. You can add or remove Exchange Online Mailboxes or enable accounts for Lync usage without any interference of your on-premises environment.
• Linked Identities – Linked Identities are typically used in larger environment where the local Active Directory is managed (and connected to for example an HRM solution) and you don’t want to manage the user accounts in Office 365 manually via the Microsoft Online Portal or via PowerShell. All user account changes (add/change/remove) are made in local Active Directory and all changes are replicated to Office 365. Also passwords are managed in local Active Directory, although there’s an option to change passwords in Office 365 and have these replicate back to local Active Directory.
  Office 365 licenses and services can be added to Linked Identities, but you always have to be aware that management of the accounts takes place on-premises. When accessing services in Office 365 users always have to logon and are faced with a credentials prompt.
  You can combine Linked Identities with an Exchange Hybrid solution, where your local Exchange (2010 or 2013) environment is integrated with Exchange Online, thus offering a fully transparent Exchange solution.
• Federated Identities – Federated Identities are used when you want to offer a Single Sign-On experience to your users. For Single Sign-On you need an ADFS infrastructure and a Directory Synchronization solution so this adds complexity to the solution. As with Linked Identities you can add an Exchange Hybrid solution to Federated Identities.
  Single Sign-On works fine with Internet Explorer (OWA, Portal, SharePoint) and the Lync Online client, but Outlook cannot work with Single Sign-On so Outlook users will still be presented a credentials prompt. Microsoft is working on this with a ‘modern authentication’ in Outlook 2013 though.

Summary

In Office 365 there’s the concept of Cloud Identities, Linked Identities and Federated Identities. Cloud Identities are easy to implement and you have this up-and-running from scratch in 10 minutes, and for Single Sign-On you need Federated Identities and a federation infrastructure. Linked Identities can be combined with an Exchange Hybrid solution offering a similar experience as Federated Identities, but without the complexity of a Federation infrastructure.

In the upcoming posts I’ll explain how to setup Directory Synchronization and Federation and how to manage these, both with GUIs as well as PowerShell.