Are you new to Office 365? Wondering how to create users and where to store user passwords, or how the main Office 365 identity models work?
Don’t worry—this article will help you understand all the three Office 365 identity models and the major differences between them so you can choose which one is best for you and your organization.
Are you managing multiple Office 365 tenants? If yes, read our guide, 15 Tricks to Succeed in Managing Multiple Office 365 Tenants to help you save time. Click here to learn how.
Office 365 Identity Model 1: In Cloud – Managed user type
This is the simplest and most basic identity used in Office 365.
In this model, users are created and managed completely in the cloud through Office 365 (Azure Active Directory). The user’s identity—usernames and passwords—will be stored in Azure Active Directory, and the authentication will take place from there. All applications they access will be completely in the cloud.
There is no on-premises infrastructure in this model. An admin can manage users directly from the Office 365 admin portal, Azure Active Directory portal, or Windows Azure Active Directory PowerShell by connecting to Microsoft Online Services using the Connect-MsolService cmdlet.
This model is mostly used when you either have a small organization with few users or want your users to be completely in the cloud without any intervention or additional on-premises infrastructure requirements.
The figure below represents the general authentication flow for In Cloud users.
*Image courtesy of Microsoft
Learn how to sell Office365 the right way with our FREE Sales Guide
Office 365 Identity Model 2: Synced with Active Directory – Managed user type
This is the second identity model for Office 365. It’s used when you have an existing on-premises environment with Active Directory and want to either migrate your existing users to Office 365 Cloud or access services from Office 365 while keeping the same users in both your on-premises Active Directory (AD) and Office 365.
Under this model, users and their attributes are synchronized from your on-premises AD to Office 365 (Azure AD) using a tool known as Azure Active Directory Connect. You can install this tool on either a domain controller or a member server in your on-premises AD.
Users are created, managed, and deleted only from your on-premises AD. Any changes to a user’s attributes are made in your on-premises AD and synchronized with Office 365 after an automatic or manual Delta Sync or Full Sync.
In order for a user to synchronize with Office 365, they must have three attributes populated in your AD: Display Name, User Principal Name, and Primary email address. Also, in order to correctly sync a user with Office 365, you need to make sure the user’s UPN suffix in your on-premises AD is of an Internet-routable domain (.com, .net, or .org) rather than .local or .internal.
When synchronizing these users with Office 365 using Azure AD Connect, the source anchor that is stamped with these users is the ObjectGUID from your on-premises AD. It uniquely identifies the user in your on-premises AD, as the ObjectGUID is unique for each object in an Active Directory forest. When viewed in Office 365, the same ObjectGUID attribute is known as an Immutable ID, which is stamped with the Synced with AD users in Office 365.
Authentication for these users can either be done from your on-premises AD or Azure AD, depending on the configuration selected. You can use Azure AD Connect’s password synchronization feature to synchronize the hash of the password from your on-premises AD to Office 365. This hash is stored in Azure Active Directory.
You can also configure Pass-through Authentication in Azure AD Connect to authenticate your users in Office 365 through your on-premises AD instead of sending the password hash from AD to Office 365.
Only certain attributes (e.g., phone number) can be managed and changed by the admin from Office the 365 portal for these user accounts. All other attributes can only be managed through your on-premises AD.
This model allows admins to manage users from a single place. Users also benefit from being able to use the same set of credentials to access their on-premises machines and Office 365 applications instead of storing multiple credentials for different services and applications.
The diagrams below show the general authentication flow for Synced with AD users:
*Images courtesy of Microsoft
Sherweb makes Office 365 easy so you can focus on your business
Office 365 Identity Model 3: Federated user type
This is the third and final identity for Office 365 users.
Federated users are also considered to be Synced with Active Directory user accounts. These are the same user accounts that are synchronized from your on-premises AD to Office 365. However, the difference is in the authentication process when signing in to Office 365.
There are times when some organizations don’t even want the hash of a user’s password to leave their internal network due to their own security and compliance policies; they may want their users to get authenticated from their on-premises AD instead. In such cases, you can use a federated identity to essentially build a trust relationship between your on-premises AD and Office 365.
Microsoft’s federation provider is Active Directory Federation Services (ADFS).
Under this model, users are synchronized with Office 365 and managed from an organization’s on-premises AD. But whenever they try to log in to Office 365, their authentication is done through the on-premises AD with the help of ADFS.
In the domain environment where ADFS is setup, a relying party trust is created on the ADFS server for Microsoft Office 365. At the same time, a claims provider trust is created on the Office 365 end when the domain is federated.
In order to ensure high availability, it’s recommended that your on-premises environment have at least two ADFS Servers—one primary and one secondary—as well as two WAPs (Web Application Proxy servers).
Apart from costs associated with setting up additional on-premises infrastructure, there are other additional costs that come with setting up ADFS and federating a domain, for example SSL certificates and your public IP address.
The diagram below represents the authentication flow of ADFS:
*Images courtesy of Microsoft
Summary
Which Office 365 identity model is right for your business?
*Image courtesy of Microsoft
Cloud identity: Everything is done in the cloud, so there is no need for on-premises servers. This is the simplest option to manage.
Synchronized identity: Sync on-premises directory objects with Office 365 and then manage users on premises. You can synchronize users’ passwords for the cloud and on premises, but they will have to sign in again to use Office 365.
Federated identity: Sync on-premises directory objects with Office 365 and then manage users on premises. Users keep the same password for the cloud and on premises and will not have to sign in again to use Office 365. This is sometimes referred to as single sign-on.
