The Office 365 Partner Community is led by National Partner Technology Strategists from the Microsoft US Partner Team. Partner Community activities include blog posts, discussions on Yammer, newsletters, and community calls.
- Read the US Office 365 Partner Community blog posts, including the September series about FastTrack
- Join the US Office 365 Partners Group on Yammer
- Sign up for the US Office 365 Partner newsletter
- Register for the November 6 US Office 365 Partner Community call
As a partner involved in an Office 365 engagement, an important consideration in setting up the tenant is providing guidance about how to choose the right identity model for a given scenario for your customer.
This month, the Office 365 Partner Community is focusing on Identity Integration and User Management. Over the next few blog posts, leading up to our November 6 community call, we’ll take a look at the three identity management models for Office 365 as well as third-party federated options. By way of introduction, the three models include Cloud Identity, Synchronized Identity, and Federated Identity. You use one of these models to connect to Office 365.
With Cloud Identity, as the name suggests, all identities are in the cloud and there are zero on-premises servers. A user signs in with a user name a password which lives in Azure Active Directory (AAD) in the cloud. AAD will validate the user and sign him or her into Office 365.
Synchronized Identity Model
In this model, there is an on-premises Active Directory and your on-premises users (and optionally, their passwords) are synchronized with those that are in the cloud. There is traditionally one server that does the synching and sends changes. You could have none or a few more servers—we will explore how that is in an upcoming post in this series.
In the Federated Identity model, as with Synchronized Identity, you still have directory servers on-premises. However, in this model, Office 365 does not necessarily have the password. When a user signs in to the service with Federated Identity, he or she is presented with a login screen from the organization and is signed in with on-premises directory servers. If the user and password are valid, it provides a token back to Azure Active Directory and then is made available to Office 365 so the user can be signed in. Directory synchronization is still happening in the background—while Office 365 is not actually performing the authentication, it still needs to know if the user has a valid license it needs it for the Global Address List or GAL, and also for the SharePoint people picker so that permissions can be assigned.
I hope this was a helpful introduction to our current topic, and I’m looking forward to the November 6 community call, where we’ll talk about this in-depth. If you have questions about Identity Integration, or other Office 365 topics, ask me in the Office 365 Partners group on Yammer.