The Enabling Technologies Blog

Our team of Cloud Strategy Advisors, Solution Architects, Engineers and former C-Suite Executives work diligently to provide our vistors with the most pressing information.

Andy Nelson /

Understanding Office 365 Identities

Which one is right for you?

Your identity model is how you choose to integrate your Office 365 user directory with your existing corporate directory. When moving your organization to Office 365, this is one of the most important decisions you can make, because it determines how your users will log in—a major impact on the user experience.

In this article we’ll review the 3 major identity models, how they impact the user experience, and when each one makes sense. Before we do that, let’s do some quick level setting to understand the basic technical components. If you’re an IT professional already familiar with Office 365, you can probably skip this part.

An identity platform serves as an organization’s corporate directory; it manages users’ credentials (think usernames and passwords), and allows them to log in to corporate resources, like their computers, email, etc. The very large majority of all organizations use Active Directory as their identity platform—that’s what we’ll cover in this article. To help avoid ambiguity, we’ll refer to this by its full name, Windows Server Active Directory, or on-premises Active Directory.

Office 365 has its own identity platform called Azure Active Directory, which runs in the cloud, just like the rest of Office 365. When choosing your identity model, you’re choosing how (if at all) to integrate Azure Active Directory with your existing Windows Server Active Directory.


This is the simplest of the three identity models—it has no integration between Azure Active Directory and Windows Server Active Directory. This means if a user resets their password in Office 365, it does not affect their on-premises password in Windows Server Active Directory, and vise versa. The two environments are completely mutually exclusive; nothing that happens in either identity environment will impact the other.

If you are not using Windows Server Active Directory at all, this will be the choice for you. Many small organizations also choose this model for its simplicity—there is no setup or infrastructure required.

The major impact of this model is that users will have to memorize a separate Office 365 password. A benefit is that, since there is no integration with your Windows Server Active Directory, that means there is also no dependency on any other system. For this reason, I always recommend that organizations keep one cloud admin account; in the case of some catastrophic problem with your Windows Server Active Directory, having a cloud only account will ensure you will always be able to log in to Office 365. (Note: even if you standardize around one of the other identity models, you can always set specific accounts to be cloud-only.)


In the synchronized identity model (whichever of the two varieties you choose below), a software utility called Azure AD Connect runs in your on-premises environment and synchronizes the user accounts and their attributes from Windows Server Active Directory up to Azure Active Directory in the cloud for Office 365. This will still allow your administrators to manage accounts on-premises, because the changes they make to the Windows Server Active Directory accounts will be synchronized with the Office 365 Azure Active Directory on a regular replication cycle. This replication provides users a consistent experience on-premises and in the cloud and prevents the need for them to remember yet another password (they will log in with their on-premises Windows Server Active Directory password). If a user resets their password on-premises, there is nothing else they have to do to change their Office 365 password. Likewise, if you are licensed for Azure Active Directory Premium (available as an add-on license, and also part of the Enterprise Mobility and Security suite), users will even be able to change their passwords directly from the cloud, and have it automatically update their on-premises password as well. This provides an excellent, consistent user experience.

This model is often referred to as “Directory Sync” or “DirSync”—these are previous names of the Azure AD Connect tool; don’t let that confuse you. You may also hear it referred to as “Seamless Sign-On” or “Seamless Single Sign-On.” The major advantage of this model is that users when users are logged in to their devices with their on-premises Windows Server Active Directory credentials, they are automatically signed in when they access Office 365—that’s a great user experience!

The choice you need to make when opting for the synchronized model is whether the authentication occurs in the cloud, or on-premises. More details on these two scenarios below. Notice that both of the two configurations below are “Seamless Single-Sign On,” so you will need to identify which type is in question when you hear that term.

Password Hash Sync with Seamless Single Sign-On

This is often referred to as “Password Sync.” In this scenario, the users’ password are synchronized from the on-premises Windows Server Active Directory to Office 365’s Azure Active Directory in the cloud. This allows the authentication to occur in the cloud, on the Office 365 side. Don’t worry—the password itself isn’t actually stored in the cloud. Rather, it’s an encrypted hash of the password; the actual passwords themselves are never sent to Azure Active Directory or stored in plain text.

A major advantage of having the authentication occur in the cloud is that users’ access to Office 365 is not dependent on your on-premises environment; even if your Windows Server Active Directory blew up, your users could still log in to Office 365.

Pass-Through Authentication with Seamless Sign-On

This is often referred to as “Pass-through Authentication.” Just like in the above scenario, this configuration also uses the Azure AD Connect tool to synchronize users’ accounts and attributes from the on-premises Active Directory to the Office 365 Azure Active Directory in the cloud. Also just like the above scenario, users login to Office 365 using their on-premises credentials, and can even reset their on-premises password from the cloud in Office 365.

Where these two scenarios differ, however, is where the authentication occurs—with password sync it occurs in the cloud, and with pass-through authentication it occurs on-premises. This is a great option for organizations that require authentications to occur on-premises because of strict business requirements or compliance regulations. The federated model (below), also satisfies that requirement, but requires significantly more infrastructure and complexity.


This model is also commonly referred to as “AD FS,” referring to the Active Directory Federated Services technology that enables it.

Just like the Synchronized model, this model also uses the Azure AD Connect tool to synchronize the user accounts and attributes, and just like the Pass-Through option, the authentications occur in on-premises Windows Server Active Directory. However, this model requires a significant and complex infrastructure to operate according with best practices.

This model works by forming a partnership, known as a federation, between your on-premises Windows Server Active Directory and Office 365’s Azure Active Directory in the cloud. To get this up and running it only takes two servers—“Wait, Andy, you said there was a significant amount of infrastructure to get this working?”

While it only requires two servers to get this going (one AD FS server and one AD FS Proxy server), we have to remember that the authentication occurs in your on-premises Windows Server Active Directory in this model. This means that users’ access to Office 365 depends on your environment, so to ensure these business critical services are available, we now have to make sure your AD FS setup is highly available. Now we’re talking about at least two AD FS servers and two AD FS Proxy servers, to ensure that neither become a single point of failure. We would also have to plan for an AD FS infrastructure in a disaster recovery site, in case something happened with your primary site. Now we’re talking about at least six servers when you add the AD FS and AD FS Proxy server in the disaster recovery site. You can see how this balloons quickly.

Another thing to consider is that one of the main benefits of moving to the cloud is the highly available nature of the SaaS solutions without dependency on your environment, and the additional overhead that comes with managing on-premises infrastructure; this model takes those benefits away.

The reason that you might consider this solution is if you had more complex login requirements, such as smartcard-based authentication, a third-party multifactor-authentication provider, or another authentication requirement that is not supported by Azure Active Directory. If the only reason you are considering this model is to ensure authentications occur in your on-premises environment, the pass-through authentication with seamless sign-on option could satisfy that requirement with less complexity.

The options in the synchronized model are most often the best choice for the majority of organizations. Note that both options in this model require Windows Server Active Directory.


In summation, most organizations will find the best fit with a synchronized model, which has duplicated the majority of benefits from the federated model, with significantly less risk and complexity. Cloud only will likely be a good fit for very small organizations, and for emergency administrator accounts for enterprises.



Work with our team of Cloud Computing Consultants who have done this so many times they know all of the “minefields” to prevent missteps.