Microsoft Entra Hybrid Identity: MFA, SSO, Conditional Access, and User Management Guide 2026
Why This Is Happening
You've just been handed a hybrid identity project , or maybe you're already neck-deep in one and something broke. Either way, Microsoft Entra Hybrid Identity is one of those technologies where the architecture makes perfect sense on a whiteboard and then completely fights back in production. I've seen this exact frustration on dozens of enterprise deployments: users can't sign in with their on-premises passwords, the provisioning agent silently stops syncing, or MFA prompts loop endlessly because Conditional Access is misconfigured. The error messages you get back are rarely helpful. "Sync failed" tells you nothing. Neither does "Authentication error 80070525."
At its heart, Microsoft Entra Hybrid Identity is Microsoft's framework for bridging your on-premises Active Directory with Microsoft Entra ID (formerly Azure Active Directory). The goal is straightforward: your users get one identity that works everywhere , signing into cloud services like Microsoft 365 with the same password they use to log into their workstation each morning. But getting that bridge to actually work requires four moving pieces to align: the right synchronization tool, correct network prerequisites, properly configured authentication policies, and a tenant that's set up for hybrid scenarios.
When any one of those pieces is off, the whole chain breaks. The problem is that Microsoft has three distinct sync tools right now, Microsoft Entra Cloud Sync, Microsoft Entra Connect (formerly Azure AD Connect), and Microsoft Identity Manager, and picking the wrong one for your scenario is one of the most common root causes of hybrid identity headaches. A new customer setting up their first hybrid environment doesn't need MIM. But an organization with 300,000 directory objects absolutely cannot use Cloud Sync without hitting hard limits. More on that in the steps below.
Microsoft Entra hybrid identity sync issues also often trace back to server prerequisites that were almost-but-not-quite met. Windows Server 2019 installed, but TLS 1.2 not explicitly enabled. .NET Framework at version 4.6.2 instead of the required 4.7.1. The PowerShell execution policy left at Restricted instead of RemoteSigned. Each of these produces different failure behaviors, and none of them produce an obvious error message pointing you back to the prerequisite.
I know this is frustrating, especially when it's blocking users from getting into their email or blocking a whole merger integration from going forward. The good news is that every one of these problems has a known fix. Let's work through them. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If your hybrid identity sync has suddenly stopped working and users are reporting they can't sign in, the fastest thing to check is the health of your Microsoft Entra provisioning agent. This single check resolves the majority of "sync just broke" situations without needing to dig into logs or reconfigure anything.
On the Windows Server running your provisioning agent, open Services (press Win + R, type services.msc, hit Enter). Look for the service named Microsoft Azure AD Connect Provisioning Agent. If its status is anything other than Running, that's your culprit right there.
Right-click the service and select Restart. Wait 60 seconds, then check the Microsoft Entra admin portal at entra.microsoft.com → Identity → Hybrid management → Microsoft Entra Connect → Cloud sync → Agents. You should see your agent listed with a green Active status. If it flips back to Active, you're done, watch it for 10 minutes to confirm the next sync cycle completes.
If the service won't stay running, check the Windows Event Log before doing anything else. Open Event Viewer, navigate to Windows Logs → Application, and filter by Source AAD.Connect.ProvisioningAgent. Error Event IDs in the 1000–1099 range typically point to TLS or .NET issues. Event ID 1016 specifically means the agent can't reach the Entra endpoint, that's almost always a firewall or proxy block on outbound port 443 to *.msappproxy.net and login.microsoftonline.com.
For Connect sync (the older on-premises application), the equivalent check is the Microsoft Azure AD Sync service in Services, and the logs live under Applications and Services Logs → Microsoft → AzureADConnect in Event Viewer.
This is the step most people skip, and it causes more rework than anything else in a hybrid identity deployment. Microsoft currently offers four synchronization tools, and they are not interchangeable. Picking the wrong one means you'll hit hard walls later.
Microsoft Entra Cloud Sync is the current recommended starting point for new hybrid customers. It uses a lightweight provisioning agent that you install on your domain-joined Windows Server, and configuration happens entirely through the Entra portal, no on-premises management UI. It handles the most common scenarios: syncing users, groups, and contacts from on-premises AD to Entra ID, Exchange hybrid, and SSO with on-premises passwords. But it has a limit: domains with more than 250,000 objects are not supported.
Microsoft Entra Connect sync (the on-premises application) is the right choice when you need Microsoft Entra hybrid join, Windows Hello for Business, user accounts in one forest with mailboxes in a resource forest, or large domains that exceed Cloud Sync's object limit. It also supports filtering directory objects by attribute values, something Cloud Sync cannot do today.
Microsoft Identity Manager (MIM) with the Graph Connector handles advanced scenarios: mergers and acquisitions with disconnected forests, high-availability/low-latency requirements, and synchronizing from cloud back down to on-premises Active Directory. MIM is being slowly deprecated, so you should only reach for it when Cloud Sync and Connect sync genuinely can't cover your case.
The ECMA Host connector is specifically for provisioning users from the cloud into on-premises applications like SQL databases and LDAP directories, not for the standard AD-to-cloud sync direction.
Microsoft provides a wizard at their "Choosing the right sync tool" page to help you select, run through it before installing anything. If you've already installed the wrong tool, don't panic. Migrating from Connect sync to Cloud Sync is a supported scenario in both tools' documentation. You should see a wizard option for that under Microsoft Entra Connect → Tasks in the on-premises Connect sync application.
I can't stress this enough: skipping the prerequisites check costs you hours later. Run through every item on this list on the server you're planning to use as your provisioning agent host before you download a single installer.
Operating system: You need Windows Server 2016, 2019, or 2022. Nothing older. If you're running Server 2012 R2, stop here and plan a server upgrade first.
Hardware: Minimum 4 GB of RAM. This sounds low but the agent is genuinely lightweight, the 4 GB floor is mostly for the OS overhead.
.NET Framework version: Must be 4.7.1 or higher. Check this with PowerShell:
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full").ReleaseA value of 461308 or higher means you have 4.7.1+. Anything below that, install the update from Microsoft's .NET download page before proceeding.
TLS 1.2: Must be explicitly enabled. Many Server 2016 builds have it available but not active by default. Enable it with these registry entries:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /fReboot after this change, it doesn't take effect until the server restarts.
PowerShell execution policy: Must be RemoteSigned or Undefined. Check with Get-ExecutionPolicy and set it with Set-ExecutionPolicy RemoteSigned if needed.
Domain join: The server must be domain-joined to your on-premises AD. The agent needs to read your directory.
Active Directory forest functional level: Must be 2003 or higher. Virtually any live AD environment meets this, but it's worth a quick check in Active Directory Domains and Trusts → right-click your domain → Properties.
If everything checks out, you'll see a clean install with no warnings. If something was missed, the installer will often fail silently or partially, leaving you with an agent that shows up in the portal as Inactive with no clear explanation.
With prerequisites confirmed, you're ready to get the provisioning agent onto your server. You need a Domain Administrator or Enterprise Administrator account to run this installation, the agent creates a Group Managed Service Account (gMSA) during setup, and that requires elevated AD permissions.
Sign into the Microsoft Entra admin center at entra.microsoft.com with a Hybrid Identity Administrator or Global Administrator account. Navigate to Identity → Hybrid management → Microsoft Entra Connect → Cloud sync. Click Download agent and save the installer to your server. The file will be named something like AADConnectProvisioningAgentSetup.exe.
Run the installer on your domain-joined server. The setup wizard walks through:
- License agreement
- Service account configuration, accept the default gMSA unless you have a specific reason to use a custom account
- Sign in with your Hybrid Identity Administrator credentials to register the agent with your Entra tenant
- Select the Active Directory domain(s) you want to sync
After installation completes, go back to the Entra admin center under Cloud sync → Agents. Your server should appear within 2–3 minutes with an Active status. If it shows Inactive, the most common cause is an outbound firewall rule blocking HTTPS to Microsoft's service endpoints. The agent needs outbound port 443 to *.servicebus.windows.net, *.msappproxy.net, and login.microsoftonline.com. Check with your network team and add exceptions as needed.
Once the agent is active, configure your sync scope in Cloud sync → New configuration. You'll pick the domain, set the scope (all users, specific OUs, or attribute-based filtering), and define how attributes map to Entra ID properties. Click Save and then Enable. The first sync cycle runs within 30 minutes.
Getting users synced to the cloud is only half the job. The authentication experience, how users actually sign in, needs to be configured separately, and this is where most of the SSO and MFA problems I see originate.
Single Sign-On (SSO) with on-premises passwords means your users sign into Microsoft 365, Teams, and other cloud services using the same credentials they use at their Windows workstation, no second password to remember, no re-authentication prompt if they're already logged into their domain-joined machine. Both Cloud Sync and Connect sync support this. The method you choose affects whether password hashes ever leave your network:
- Password Hash Sync (PHS): A one-way hash of the password hash is synced to Entra ID. Sign-in works even if your on-premises infrastructure goes down. This is the default and works with both Cloud Sync and Connect sync.
- Pass-Through Authentication (PTA): Passwords are never stored in the cloud. Authentication requests are validated against your on-premises AD in real time via the provisioning agent. Supported with Connect sync. If your security policy says "no password hashes in the cloud," this is your answer.
- Federation (AD FS): A dedicated federation server handles all authentication. Supported only with Connect sync. This is the only option that also supports smartcard authentication for your users.
To configure the sign-in method in Connect sync, open the Microsoft Entra Connect application on your server, click Change user sign-in, and walk through the wizard. To change it in Cloud Sync, the sign-in method is configured in the Entra admin center under Identity → Hybrid management → Microsoft Entra Connect → Connect sync → User sign-in.
For MFA in hybrid identity environments: Cloud-based MFA through Microsoft Entra ID works across all three sync tool options. On-premises MFA (using your own MFA server infrastructure) is only supported with Connect sync, Cloud Sync does not support on-premises MFA solutions. If you have an existing on-premises MFA deployment and are migrating to Cloud Sync, plan for migrating to Entra ID cloud MFA as part of that project.
Conditional Access policies are configured entirely in the Entra admin center under Protection → Conditional Access. A common misconfiguration I see: a "Require MFA for all users" policy that doesn't have a proper exclusion for break-glass administrator accounts. When that policy is active and your MFA method has an issue, you can lock every admin out of the tenant. Always exclude at least one break-glass account from your MFA Conditional Access policies.
Don't assume sync is working just because the agent shows Active. Walk through these verification steps before you tell stakeholders the deployment is done.
Check sync status in the Entra admin center: Navigate to Identity → Hybrid management → Microsoft Entra Connect. The dashboard shows your last sync time, sync method, and whether the sync is enabled. The "Last synced" timestamp should update every 30 minutes for Cloud Sync and every 30 minutes by default for Connect sync.
Verify a specific user synced correctly: In the Entra admin center, go to Identity → Users → All users. Search for a test user by their on-premises UPN. Open their profile and look at the On-premises sync enabled field, it should show Yes. Also verify that their Source shows Windows Server AD, not Microsoft Entra ID (which would mean the account was created directly in the cloud rather than synced).
Run a PowerShell sync check with Connect sync:
Import-Module ADSync
Get-ADSyncSchedulerThis returns the scheduler status, sync cycle interval, and whether a sync is currently running. If SyncCycleEnabled shows False, your scheduled sync is disabled, run Set-ADSyncScheduler -SyncCycleEnabled $true to re-enable it.
Force a delta sync to test immediately:
Start-ADSyncSyncCycle -PolicyType DeltaFor a full sync (resync everything): Start-ADSyncSyncCycle -PolicyType Initial, only run a full sync when needed, as it's resource-intensive on large directories.
Test SSO end-to-end: On a domain-joined machine, sign in as a test user with their on-premises AD credentials. Open a browser in InPrivate/Incognito mode and navigate to portal.office.com. If SSO is working correctly, they should be signed in automatically (or after entering their UPN with no password prompt, if using Pass-Through Authentication). If they get a password prompt, check your Seamless SSO configuration under Microsoft Entra Connect → User sign-in → Enable single sign-on and ensure the AZUREADSSOACC computer account exists in your on-premises AD.
Advanced Troubleshooting
When the basic steps haven't resolved your Microsoft Entra Hybrid Identity sync problems, it's time to go deeper. Here's what I pull up when standard restarts and portal checks don't surface the issue.
Event Viewer Analysis for Hybrid Identity Sync Errors
The most useful logs for Cloud Sync are under Event Viewer → Applications and Services Logs → Microsoft → Windows → AADConnect.ProvisioningAgent. For Connect sync, check Applications and Services Logs → Microsoft → AzureADConnect. Key event IDs to know:
- Event ID 1000: Agent started successfully
- Event ID 1001: Agent stopped, look at the description for whether this was planned or an error
- Event ID 1016: Cannot connect to Entra service endpoint, firewall/proxy issue
- Event ID 1023: gMSA account authentication failure, the service account may need its password refreshed or its permissions re-verified
- Event ID 6001 / 6003 (in Application log, Source: Directory Synchronization): Attribute sync errors, an on-premises AD attribute value is violating an Entra ID constraint (often a duplicate ProxyAddress or UPN)
Diagnosing Duplicate UPN or ProxyAddress Conflicts
One of the most common sync errors I see in production: an on-premises user won't sync because their UserPrincipalName or email address (ProxyAddress) is already taken by a different cloud-only account. The sync engine logs this as an AttributeValueMustBeUnique error. Find it fast with the Microsoft Entra admin center under Identity → Monitoring & health → Provisioning logs. Filter by Status = Failure. The error description will name the conflicting attribute and the conflicting account's object ID.
To resolve: either update the on-premises AD attribute, or soft-match the cloud account to the on-premises user using the ImmutableID. The ImmutableID is the base64-encoded ObjectGUID from on-premises AD:
$user = Get-ADUser -Identity "jsmith" -Properties ObjectGUID
$immutableId = [System.Convert]::ToBase64String($user.ObjectGUID.ToByteArray())
Write-Host $immutableIdThen set it on the cloud account: in the Entra admin center, the ImmutableID is set under the user's Properties → On-premises tab, or via PowerShell with the MSOnline or Graph PowerShell module.
Microsoft Entra Hybrid Join Troubleshooting
Hybrid join (where your on-premises domain-joined Windows 10/11 machines also register with Entra ID) requires Connect sync, Cloud Sync doesn't support this scenario. If devices aren't completing hybrid join, run dsregcmd /status on the affected machine and look at the output:
dsregcmd /statusCheck AzureAdJoined, DomainJoined, and WorkplaceJoined. If AzureAdJoined : NO, check that the userCertificate attribute is populated on the computer object in AD (this is set by the Workplace Join process) and that the Service Connection Point (SCP) is correctly configured in AD. Verify SCP with:
$scp = New-Object System.DirectoryServices.DirectoryEntry "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=yourdomain,DC=com"
$scp.KeywordsGroup Policy and Conditional Access Conflicts
If users are getting MFA prompts they shouldn't be getting (or vice versa), the cause is almost always a Conditional Access policy with overly broad scope. Open Protection → Conditional Access → Policies and check each enabled policy's Users and Cloud apps scope. Use the What If tool (button in the top bar of the Conditional Access section) to simulate what policies apply to a specific user signing into a specific app, this is the fastest way to diagnose unexpected MFA behavior without changing anything.
Prevention & Best Practices
A hybrid identity environment that breaks once will break again if the underlying habits don't change. Here's how to set it up to stay healthy.
Always run the sync wizard before deploying, not after. Microsoft's "Choosing the right sync tool" wizard exists for a reason. The number of tickets I've seen where someone migrated 80% of the way through a Connect sync deployment before realizing they actually needed Cloud Sync, or needed MIM for a disconnected forest acquisition, is genuinely depressing. Five minutes in the wizard saves days of rework.
Deploy at least two provisioning agents for high availability. A single-agent deployment is a single point of failure. Cloud Sync supports multiple agents per configuration, add a second one on a different server in the same domain. If your primary agent goes down, sync continues automatically. Under Cloud sync → Agents, you can see the health status of all registered agents at a glance.
Keep your gMSA account healthy. The Group Managed Service Account that the provisioning agent runs under needs regular health checks. In particular, after domain controller changes, password rotations, or AD schema updates, verify the gMSA is still valid with Test-ADServiceAccount -Identity "provAgentgMSA$". A broken gMSA is the silent killer of hybrid identity sync, the agent service stops, no obvious error shows up in the portal, and users start calling the helpdesk about password issues.
Document your attribute mapping customizations. If you've done any custom attribute mapping in Cloud Sync or Connect sync, document what you changed and why, in a runbook, a SharePoint page, anywhere that survives staff turnover. Default attribute maps are recoverable; custom ones that exist only in someone's memory are not.
Test Conditional Access policy changes in report-only mode first. Every Conditional Access policy has a Report-only mode that logs what the policy would have done without actually enforcing it. Turn this on for any new policy for at least 48 hours before switching to On. Check the sign-in logs under Identity → Monitoring & health → Sign-in logs and filter by Conditional Access = Report-only. This catches unintended blocks before they lock anyone out.
- Set up Entra ID alerts for agent health, go to Monitoring & health → Alerts and enable the provisioning agent health alert so you get an email before users start calling
- Keep a documented break-glass admin account excluded from all MFA and Conditional Access policies, stored securely, tested quarterly
- Schedule a quarterly review of your sync scope: remove any OUs or users who no longer need cloud access to keep your synced object count clean
- After any AD schema extension or domain controller OS upgrade, re-verify the provisioning agent health and run a manual delta sync to confirm nothing broke
Frequently Asked Questions
What is hybrid identity in Microsoft Entra ID and why do I need it?
Microsoft Entra Hybrid Identity is the configuration that bridges your on-premises Active Directory with Microsoft's cloud identity service, Entra ID. When it's set up, your users get a single identity that works for both on-premises resources and cloud services like Microsoft 365, Teams, and Azure, they sign in once with one password and access everything. You need it any time you have an on-premises AD and you want users to access cloud services without managing two separate accounts. Without hybrid identity, your IT team ends up manually creating and syncing accounts in two places, which is both time-consuming and a significant security risk from accounts getting out of sync.
What is Microsoft Entra Cloud Sync and how is it different from Microsoft Entra Connect?
Microsoft Entra Cloud Sync is Microsoft's newer, lighter-weight hybrid identity sync tool. It runs as a small provisioning agent on your Windows Server and is fully configured through the Entra web portal, no on-premises management interface needed. Microsoft Entra Connect (sometimes still called Azure AD Connect) is the older, more feature-rich on-premises application that handles scenarios Cloud Sync can't, like Microsoft Entra hybrid join, Windows Hello for Business, user accounts in one AD forest with mailboxes in a resource forest, and domains with more than 250,000 objects. For most new deployments, Cloud Sync is the recommended starting point; Connect sync is the right choice when your scenario specifically requires one of its exclusive features.
What is the Microsoft Entra provisioning agent and what does it actually do?
The Microsoft Entra provisioning agent is a lightweight Windows service you install on a domain-joined Windows Server. It acts as the secure bridge between your on-premises Active Directory and Microsoft's cloud services. The agent reads user, group, and contact objects from your on-premises AD and sends them up to Entra ID, keeping the two directories in sync. It also handles authentication pass-through in Pass-Through Authentication deployments, validating cloud sign-in requests against your on-premises AD without your passwords ever leaving your network. The agent communicates outbound over HTTPS to Microsoft's endpoints, you don't need to open any inbound firewall ports, which is one of its security advantages over older federation approaches.
How do I set up SSO so users don't get prompted for passwords when accessing Microsoft 365?
The feature you want is called Seamless Single Sign-On (Seamless SSO), and it's available with both Cloud Sync and Connect sync when using Password Hash Sync or Pass-Through Authentication. To enable it with Connect sync, open the Microsoft Entra Connect application, click Change user sign-in, and enable the Enable single sign-on option in the wizard. With Cloud Sync, configure it in the Entra admin center under Microsoft Entra Connect → User sign-in. After enabling, you also need to add the Entra ID URL to the Intranet Zone in Internet Explorer/Edge Group Policy (or push it via GPO) so the browser sends Kerberos tickets automatically. Without that GPO step, users on domain-joined machines will still get a prompt on their first access from a new browser session.
Can I use Microsoft Entra Cloud Sync if I have a disconnected forest or acquired company with no trust?
Yes, mergers and acquisitions with disconnected forests (no AD trust between the two organizations) is one of the scenarios specifically supported by Cloud Sync. You install a provisioning agent in each separate forest, and both agents sync their respective users up to the same Entra ID tenant. This is actually one area where Cloud Sync has an advantage over Connect sync: connect sync does not support mergers and acquisitions with disconnected forests. Microsoft Identity Manager (MIM) with the Graph Connector also supports this scenario, but MIM is being deprecated and should only be used when the MIM-specific advanced features are genuinely needed.
My on-premises MFA solution is not working with Cloud Sync, what are my options?
On-premises MFA solutions (dedicated MFA server infrastructure running in your data center) are only supported with Microsoft Entra Connect sync, not Cloud Sync. If you're on Cloud Sync and need MFA, your option is Microsoft Entra ID cloud-based MFA, which is supported by all three sync tools. Cloud-based Entra MFA covers authenticator app, SMS, voice call, and FIDO2 hardware keys. If migrating away from your on-premises MFA server is a blocker, that's one of the legitimate reasons to stay on Connect sync rather than migrating to Cloud Sync. Plan the MFA server migration alongside any sync tool migration, not as an afterthought, trying to swap both at the same time on a live tenant is how you end up with a 2 AM incident.