Choosing an Identity model for Office 365

Posted on August 25, 2015

The following identity models are support in Office 365 and depend on our requirement these models will be used,

1. Office 365 Cloud Identity
2. Office 365 Synchronized Identity
3. Office 365 Federated Identity

Overview

Office 365 Cloud Identity: If you are new starter to Office 365 and you don’t have requirements to use your on-premises Active Directory identity store, then this model is right for you .In this model a user is created and managed in Office 365 and stored in Azure Active Directory, and the password is verified by Azure Active Directory. Azure Active Directory is the cloud directory that is used by Office 365. There is no equivalent user account on-premises, and there is nothing that needs to be configured to use this other than to create users in the Office 365 admin center.

Office 365 Synchronized Identity: In this model the user identity is managed in an on-premises server and the accounts and password hashes are synchronized to the cloud. The user enters the same password on-premises as they do in the cloud, and at sign-in the password is verified by Azure Active Directory. This model uses the Microsoft Azure Active Directory Sync Tool (DirSync).

Note: Most of the organisation has restriction on storing the password in cloud/ external store. If you these restriction use/implement the Office 365 Federated Identity.

Office 365 Federated Identity: This model requires a synchronized identity but with one change to that model: the user password is verified by the on-premises identity provider. This means that the password hash does not need to be synchronized to Azure Active Directory. This model uses Active Directory Federation Services (AD FS) or a third- party identity provider.

When to choose the Cloud Identity model

Choosing cloud-managed identities enables you to implement the simplest identity model, because there is no on-premises identity configuration to do. All you have to do is enter and maintain your users in the Office 365 admin center. This is likely to work for you if you have no other on-premises user directory, and I have seen organizations of up to 200 users work using this model.

You may also choose the Cloud Identity model if you have a very complex on-premises directory and simply want to avoid the work to integrate with it. These complexities may include a long-term directory restructuring project or complex governance in the directory. If you have an existing on-premises directory, but you want to run a trial or pilot of Office 365, then the Cloud Identity model is a good choice, because we can match users when you want to connect to your on-premises directory.

It is most common for organizations with an existing on-premises directory to want to sync that directory to the cloud rather than maintaining the user directory both on-premises and in Office 365. In that case, either password synchronization or federated sign-in are likely to be better options, because you perform user management only on-premises.

To sum up, you would choose the Cloud Identity model if you have no on-premises directory, if you have a very small number of users, if your on-premises directory is undergoing significant restructuring, or if you are trialing or piloting Office 365.

When to use the Synchronized Identity model

The Synchronized Identity model is also very simple to configure. It requires you to have an on-premises directory to synchronize from, and it requires you to install the DirSync tool and run a few other consistency checks on your on-premises directory. This is described in my recent blog post Synchronizing your directory with Office 365 is easy. Before June 2013 this model did not include password synchronization and users provisioned using synchronized identity had to create new cloud passwords for Office 365. This was a strong reason for many customers to implement the Federated Identity model. Now that password synchronization is available, the Synchronized Identity model is suitable for many customers who have an on-premises directory to synchronize with and their users will have the same password on-premises and in the cloud.

In addition to leading with the simplest solution, we recommend that the choice of whether to use password synchronization or identity federation should be based on whether you need any of the advanced scenarios that require federation. I’ll talk about those advanced scenarios next. However if you don’t need advanced scenarios, you should just go with password synchronization. You can also use the Synchronized Identity model when you ultimately want federated identity, but you are running a pilot of Office 365 or for some other reason you aren’t ready to dedicate time to deploying the AD FS servers yet.

To sum up, you would choose the Synchronized Identity model if you have an on-premises directory and you don’t need any of the specific scenarios that are provided for by the Federated Identity model.

When to use the Federated Identity model

As mentioned earlier, many organizations deploy the Federated Identity model just so that their users can have the same password on-premises and in the cloud. With the addition of password hash synchronization to the Synchronized Identity model in July 2013, fewer customers are choosing to deploy the Federated Identity model, because it’s more complex and requires more network and server infrastructure to be deployed.

All of the configuration for the Synchronized Identity model is required for the Federated Identity model. Because of this, we recommend configuring synchronized identity first so that you can get started with Office 365 quickly and then adding federated identity later.

The following scenarios are good candidates for implementing the Federated Identity model. If none of these apply to your organization, consider the simpler Synchronized Identity model with password synchronization.