The concept of Identities is important in every cloud deployment. The way that identities are implemented determines where the accounts exist, who owns the accounts and who controls them.

There are two types of identities:

• Cloud Identities;
• Federated Identities.

I’ll discuss both of them and how they relate to Office 365.

Cloud Identities

Cloud Identities are identities that are created in the cloud solution. Real live example of Cloud Identities are:

• Microsoft accounts;
• Facebook accounts;
• LinkedIn accounts;
• Instagram accounts;
• Twitter accounts;
• LinkedIn accounts;
• PayPal accounts;

There are many more of these accounts. You’ll be expected to create them in your financial application like SAP, in your company’s HR application, at your (business) travel agency, favorite airliner, credit card company, there are so many accounts you have in the cloud that most likely you can no longer keep track of  all of them.

Most of these accounts are created ‘on the fly’ as you need them. You create a username, which is quite often identical to the email address, enter a password and you’re done. Now try to create a list of the number of accounts you have and the accompanying passwords. Most likely you only have one or two standard passwords for all these accounts, or you need to use a tool like Keepass to track and secure all your passwords.

Imagine what happens when an account and password gets compromised? It will take some time before this gets discovered, especially when it’s an account that’s not used that often and one can hope and pray no damage was done with the compromised accounts. Even worse, since uses tend to use identical passwords for multiple cloud identities the damage can be much worse.

The task for the System Administrator is increasingly tricky: If an employee leaves the company, it isn’t just his or her Active Directory account that needs to be disabled or removed: all business applications that have an account for this employee need to be checked, and the associated accounts need to be disabled or removed as well.

There are problems presented by all these accounts that nowadays face the executors of estate of the deceased. Somebody need to check all cloud accounts and try to have these removed, which can prove to be extremely difficult. One of my former colleagues passed away a couple of years ago and it still happens that I get a reminder about his birthday somewhere, or his name pops up in a ‘people you may know’ window of a social network.

Who own all of these accounts and who control these accounts? Obviously a user creates the accounts and sets their passwords, but in the end the account is controlled by the cloud provider and the cloud provider’s security policies are automatically applied to the user’s cloud identity.

Federated Identities

A Federated Identity is an identity that’s linked to an on-premises Active Directory Identity and this on-premises account is then the primary account for users. You can compare this to a resource forest in Active Directory where there’s one Active Directory forest containing the user accounts and another Active Directory forest containing all the resources. By using a trust relationship, users in the first Active Directory forest can access resources in the second Active Directory forest.

When using Federated Identities in a cloud solution, there’s a Federation Trust between the on-premises Active Directory and the cloud solution. This Federation Trust makes sure that users from the on-premises Active Directory are trusted and can access the cloud services.

The most important account, when it comes to federated identities, is the on-premises, Active Directory account. This is the ‘main’ account and so is the account that is used for authentication. If a user needs to change his password it is accomplished in the on-premises Active Directory. There’s no password policy in the cloud services since the account is fully managed on-premises. The location where the account is managed is also referred to as the ‘source of authority’.

For federation you need a Federation Trust between the on-premises Active Directory and the Office 365 environment, and this Federation Trust is using a Federation Infrastructure. When a user wants to access a cloud service, his authentication request needs to be routed to the on-premises Active Directory. After a successful authentication, a special token needs to be routed back to the cloud solution for accessing the solution. This is also referred to as ‘claims-based authentication’. A common standard for this are SAML (Security Assertion Markup Language) tokens, an open-standards XML based standard for exchanging authorization and authentication data.

The interesting thing is that claims based authentication is vendor independent. Every cloud solution vendor can build his own federation platform and as long as a common federation gateway is used, Federated Identities can be used to access the cloud solution.

How does this relate to Office 365?

In a typical small environment Cloud Identities are used as the primary identity. These are created in the Office 365 Online Portal and are fully managed through this portal. All properties are set in the portal and when a user wants to access Lync Online or Exchange Online he needs to enter his username and password for this cloud identity and his request is authenticated against Office 365 Domain Controllers. Microsoft uses a 90-day password policy, so after 90 days the user need to change the password for this cloud identity. While this works fine it can be confusing for users, especially when they also have a username and password for their on-premises environment which uses a different password policy.

Related to this are Synced Identies. These are also cloud identities, but the accounts are replicated from an on-premises Active Directory, including their passwords, using a Directory Synchronization tool. Accounts are created and managed in the on-premises Active Directory, but authentication is still taking place against the Office 365 Domain Controllers since they are still normal Cloud Identities. To overcome password issues with Synced Identities, the password policy in Office 365 is set to ‘never expire’ when the Directory Synchronization is setup. This way the password policy is following the on-premises Active Directory password policy when using Synced Identities and the user can use the same username and password for both on-premises services as well as Office 365 services.

Again, when users want to access Lync Online or Exchange Online, the user needs to enter his username and password to access the service; but since the passwords are identical to the on-premises Active Directory password this causes less confusion for the users.

Federated Identities in Office 365 are built on top of Synced Identities, but need a federation infrastructure through the use of Active Directory Federation Services (ADFS). When you build an ADFS infrastructure a Federation Trust is setup using the Microsoft Federation Gateway (MFG). This federation trust will make sure that the accounts in the on-premises Active Directory are trusted for use with the accounts in Office 365.

The ADFS infrastructure consists of two parts:

• The ADFS servers in the internal network. These are normal Windows 2008 R2 or higher servers joined to the Active Directory domain;
• The ADFS proxy servers in the DMZ. This are normal Windows 2008 R2 or higher server running as stand-alone servers.

When a user tries to access one of the services in Office 365 the service request credentials. This request is then routed to the ADFS servers in the on-premises DMZ which will proxy the request to the internal ADFS servers. The ADFS servers will return a SAML token via the ADFS proxy servers to Office 365. This SAML token is used to finalize the authentication to Office 365.

The user only has one username and password and these constitute his on-premises Active Directory credentials. In this way a Single Sign-On (SSO) environment can be created.

There are a couple of  ‘gotcha’s though:

• The ADFS infrastructure needs to be highly available and redundant. If the ADFS infrastructure is not available the users will not be able to login into the Office 365 services.
• Since the ADFS infrastructure uses SSL certificates extensively, it can quickly become complex, especially when the on-premises Active Directory consists of multiple domains.
• Single Sign-On means that the user uses one set of credentials. When a user logs on to an Active Directory domain using his domain credentials, he can logon to Lync Online or Outlook Web App (OWA) for example, using Internet Explorer without being asked for credentials. But when using an Outlook client authentication still takes place using Basic Authentication via SSL, and thus a username/password window is presented when starting Outlook. The November 2014 update for Outlook 2013 introduced a new authentication model which suppresses this password prompt, but older clients still need to logon additionally.

Summary

When using Office 365 there are three types of identities that can be used:

• Cloud Identities – Managed fully in the Office 365 portal without any interaction with an on-premises Active Directory.
• Synced Identities – Managed in the on-premises Active Directory, synchronized to Office 365, including the user’s passwords.
• Federated Identities – Fully managed in the on-premises Active Directory, authentication takes place against the on-premises Active Directory. Federated Identities offer the opportunity to implement true Single Sign-On.

Although Federated Identities seem to be the preferred way of managing identities when using Office 365 as it provides true single sign-on, the complexity of implementing an ADFS infrastructure can be challenging. The ADFS infrastructure needs to be highly available and redundant, as unexpected outages will cause users to be unable to logon.

In my next articles I will explain more about the different identities in Office 365 and Exchange Online and how to move your on-premises Exchange environment to them.