Microsoft Entra ID - The Definitive Guide - Authenticating Hybrid Users
In the INTRODUCTION of this series, we learned what Entra ID is & what it is not.
This section will serve as a guide to implement a hybrid identity architecture, the best practices, and what to look out for :
The objective
The main goal of this section is to connect together Entra ID and on-premises Active Directory Domain Services to unify the user experience and (kind of) centralize the administrator's.
The deployment models
Microsoft offers two different tools for the job :
- Entra ID Connect Sync (Often only referred to as Entra Connect)
- Entra ID Cloud Sync
There's an excellent table on the official documentation page comparing capabilities of both tools.
In this article, the primary focus will be on the authentication aspect behind Hybrid Identity Architectures, supposing we are running a free Entra ID tenant.
Entra ID Connect Deployment Model
Entra Connect is based on a self-orchestrated model where you provision and manage your own on-premises infrastructure, usually a simple VM, to install and configure the tool.
You basically take a VM that is joined to your ADDS domain, then download and install Entra Connect.
The standard best practice is to use a standalone VM with the single responsibility of running Entra Connect; especially since the VM will be connected to the internet.
Authentication Methods for Hybrid Users
One of the most important decisions you'll have to make when designing your hybrid identity architecture will be related to how hybrid users will be authenticated:
So first, what is exactly a Hybrid User ?
Very simple, 99.999..% of the time, it is a user synchronized from ADDS to Entra ID. (Although is some use-cases it could be the other way around)
Why does it matter ?
Suppose an on-premises (AD) user is attempting to access their Exchange-Online mailbox by going to outlook.office365.com. They will be automatically redirected for authentication against EntraID:
If that user is first created on EntraID, EntraID will possess their credentials and is therefore already able to authenticate them, no problem.
On the other hand, if the user is first created on ADDS, EntraID will not possess their credentials and will therefore need to somehow find another way to authenticate them.
This is exactly what this section is about, and you have 3 options:
- PHS - Password Hash Sync
Just as the name suggests, this is about Entra Connect synchronizing a hash of the password of the user to Entra ID, password that is stored in the NTDS database on ADDS Domain Controllers.
Although in reality, it is a synchronization of the hash of the hash (i.e. double hashing, hence the color difference below, more on that later).
- PTA - PassThrough Authentication
In this configuration, the idea is that for any authentication request received by Entra ID, if the user is known to be a hybrid user, the request will be forwarded to ADDS through EntraID Connect.
ADDS is the unique responsible for handling authentication for hybrid users.
- ADFS - Federation with AD Federation Services (or PingFederate)
What's important here, is to recall that federation stands for trust relationship.
ADFS (Active Directory Federation Services) was originally intended to manage trust relationships between organizations in the context of using web applications relying on SAML/WS-Fed authentication protocols.
A good example would be a company wanting to provide access to users from a partner organization on their public internal web application : i.e. on-premises Dynamics CRM, Sharepoint Server, Exchange OWA, etc...
Back to the context of hybrid authentication, it is here all about establishing and maintaining a trust relationship between EntraID, your ADFS, and by extension your ADDS :
What happens behinds the scenes :
- User Attempts to Authenticate to an Application using Entra ID as authentication mechanism (ex: Exchange Online)
- User is redirected to Entra ID for authentication
- Entra ID detects that it is a user from a federated ADDS
- Entra ID forwards the user to authenticate against ADFS
- ADFS receives the authentication request and validates against ADDS
- ADFS sends claim (token) to Entra ID allowing user to authenticate
What to choose, When, and Why ?
As it is always the case with architectural design decisions, it's all about comprise and trade-offs.
For instance, you might want to chose PTA for security concerns related to storing hashes of passwords in the cloud - especially in highly regulated environments such as banks, defense, etc.
But what happens if, for whatever reason, Entra ID loses line of sight with ADDS ?
(unreachable DC, unreachable Entra Connect VM, internet interruption, etc.)
→ No hybrid user can authenticate to any cloud service.
On the other hand, when choosing PHS, one might fear leaking hashes of passwords if Entra ID databases were compromised.
But since Entra ID stores hashes of passwords, authentication can always happen regardless of ADDS / Entra Connect reachability.
What about ADFS you say ?
ADFS architecture not only suffers from the same drawbacks as PTA, it is also a service that's relatively heavy to maintain.
In short :
|
|
|