Microsoft Entra ID Sign-In & Authentication Errors, Complete Fix Guide 2026
Why This Is Happening
You opened the Microsoft Entra admin center, tried to pull sign-in logs, and something's off. Maybe your AD FS sign-in report is blank. Maybe your help desk is getting flooded with calls from users who can't authenticate. Or, and this one catches a lot of admins off guard, you updated Microsoft Entra Connect to version 1.4.xx.x and suddenly a chunk of your Windows devices vanished from the directory. I know exactly how that last scenario feels: it's the kind of thing that makes your stomach drop at 9 AM on a Monday.
Here's the reality: Microsoft Entra ID sign-in and authentication errors don't have a single cause. They sit at the intersection of on-premises Active Directory, Azure cloud sync, AD FS federation, device registration, and Conditional Access policies. When any one of those layers misbehaves, users get blocked, and the error messages they see rarely tell you where the actual problem lives.
Let me break down the three most common root causes I've seen in enterprise environments in 2025 and 2026:
1. The Microsoft Entra Connect 1.4.xx.x device cleanup, the one that surprises everyone. Starting with version 1.4.xx.x of Microsoft Entra Connect, the sync engine became far stricter about which Windows 10 devices it will synchronize to the cloud. Older versions of the connector were sloppy about this: they'd happily sync Windows 10 device objects that didn't have the specific userCertificate attribute value required for genuine Microsoft Entra hybrid join. Those devices landed in Entra ID in a perpetual "pending" state, never actually usable for Conditional Access, but sitting there taking up space. Version 1.4.xx.x cleans house. It removes those phantom pending objects. It also stops syncing down-level Windows devices (Windows 7, Windows 8.1) entirely, because Entra Connect was never supposed to handle those in the first place, they register directly via AD FS or Seamless SSO.
2. AD FS sign-in data not appearing in Connect Health reports. Connect Health correlates sign-in events directly from your AD FS servers, matching them against the AD FS schema. If the data feed hasn't started yet, because the feature was just enabled, prerequisites aren't fully met, or the health agent isn't properly installed, your report shows nothing. Admins assume the worst. Usually, it just needs time and a quick health agent check.
3. Misconfigured or missing device registration prerequisites. When devices aren't correctly set up for hybrid join, they can't authenticate through Conditional Access device compliance policies. Users get cryptic access-denied errors, and IT can't figure out why some machines work and others don't.
The frustrating part is that Entra's error messages at the user-facing level, things like AADSTS50020, AADSTS70011, or a generic "We couldn't sign you in", give you almost no useful direction. You have to know where to dig. That's what this guide is for.
The Quick Fix, Try This First
If users are suddenly locked out and you've recently updated Microsoft Entra Connect, the first thing to do is verify whether the device disappearance is actually a problem, or the system working exactly as designed.
Open the Microsoft Entra admin center (entra.microsoft.com), navigate to Identity > Devices > All Devices, and filter by Join Type: Hybrid Azure AD joined. If you're seeing devices in "Pending" state, or seeing a large drop in device count, you're almost certainly looking at the 1.4.xx.x cleanup in action.
Before you panic or try to roll back the connector version, run this check: open Synchronization Service Manager on your Entra Connect server and look at the Export step for the Azure AD connector. If deletions exceeded your configured Export Deletion Threshold, the sync engine will have stopped automatically to protect you. You'll see an error in the connector's export run that says something like "stopped-deletion-threshold-exceeded."
If that's what you're seeing, here's the fast path: those deletions are intentional and safe to allow through. Microsoft is clear about this. The devices being removed were never properly registered, they were in a broken "pending" state and couldn't be used by Conditional Access anyway. To let the deletions proceed, open PowerShell on your Entra Connect server and run:
Enable-ADSyncExportDeletionThreshold -DeletionThreshold 500
Start-ADSyncSyncCycle -PolicyType DeltaAdjust the threshold number to match or exceed the number of objects being deleted. After the cycle completes, the phantom devices are gone, and your legitimate hybrid-joined devices will remain exactly where they were.
If the issue is specifically with AD FS sign-in data missing from Connect Health reports, check that the AD FS health agent is running on each federation server. Open Services (services.msc) and confirm that Microsoft Azure AD Connect Health Agent for AD FS is in a Running state. A quick restart often gets data flowing within 15–30 minutes.
The Microsoft Entra Connect Health agent for AD FS is what feeds sign-in event data into the portal reports. Without it running correctly on every AD FS server in your farm, the sign-in report will be incomplete or completely empty, and you'll have no visibility into authentication failures happening at the federation layer.
Start by navigating to the Microsoft Entra admin center at entra.microsoft.com. Go to Identity > Monitoring & health > Connect Health, then select AD FS Services. You'll see each server listed with a health status badge. A green checkmark means the agent is reporting in. Any yellow warning or red error badge means the agent on that specific server isn't communicating properly.
On any server showing a problem, RDP in and open an elevated PowerShell prompt. Run:
Get-Service -Name "AdHealthAdfs*" | Select-Object Name, Status
Restart-Service -Name "Microsoft Azure AD Connect Health Agent for AD FS"Wait about 60 seconds, then re-check the portal. If the agent won't start, check the Windows Event Log under Applications and Services Logs > Microsoft > AzureADConnect > HealthAgent for specific failure codes.
One thing to verify: Connect Health for AD FS has prerequisites around TLS 1.2 and outbound connectivity to Azure endpoints. Specifically, the agent needs to reach *.blob.core.windows.net, *.servicebus.windows.net, and *.adhybridhealth.azure.com on port 443. If your perimeter firewall is blocking any of these, the agent will silently fail. Check with your network team and test with Test-NetConnection -ComputerName adhybridhealth.azure.com -Port 443 from the AD FS server itself.
Once the agent is healthy, the sign-in report in Connect Health will populate with correlated events pulled directly from your AD FS servers, matched against the AD FS event schema automatically. You don't have to do anything else to make data appear; it flows in once connectivity is established and prerequisites are satisfied.
If you've connected your AD FS sign-in data to Log Analytics, which I strongly recommend doing, especially if you're running Microsoft Sentinel, you can query sign-in events directly without relying solely on the Connect Health portal UI. This gives you much more flexibility for filtering, alerting, and cross-correlating with other log sources.
In the Azure portal (portal.azure.com), navigate to your Log Analytics workspace, then open Logs. Paste the following Kusto query, which pulls from the Connect Health AD FS sign-in data across both West Europe and West US clusters:
union cluster('Idsharedweu').database('ADFSConnectHealth').SignInEvent,
cluster('Idsharedwus').database('ADFSConnectHealth').SignInEvent
| where env_time > ago(2d)
| where tenantId == "YOUR-TENANT-ID-HERE"
| take 15Replace YOUR-TENANT-ID-HERE with your actual Microsoft Entra tenant ID, you can find this in Entra admin center > Identity > Overview > Tenant ID. The query pulls events from the last 48 hours across both regional clusters and limits results to 15 rows as a starting point.
From here, you can expand the time range, filter by specific users, or look for patterns in failed authentications. To filter for only failed sign-in attempts, add:
| where ResultType != 0A ResultType of 0 means success. Non-zero values map to specific AD FS error codes, you can cross-reference these against the Microsoft error code documentation to identify exactly what's going wrong for affected users.
If you're seeing no results at all from this query, double-check that Log Analytics integration is actually enabled for AD FS sign-ins. In the Entra admin center, go to Connect Health > Settings and confirm the Log Analytics workspace is linked. If it isn't, enabling it takes about two minutes and data will start flowing within 15–30 minutes after that.
This step is critical if you're dealing with the Entra Connect 1.4.xx.x device cleanup and you want to know exactly what got removed, or what's about to be removed before you allow deletions to proceed. I've talked to admins who blindly approved the deletion threshold override and then spent two days trying to figure out which specific machines needed to be re-registered. Don't do that. Run the report first.
Microsoft provides a PowerShell certificate report script specifically for this purpose. It inspects userCertificate attributes on Active Directory computer objects and identifies which ones have the proper Microsoft Entra hybrid join certificate versus which ones are missing it (and will therefore be deleted from Entra ID).
To run it, open an elevated PowerShell session on a machine with the Active Directory PowerShell module installed (any domain controller works, or any machine with RSAT installed). Import the module if needed:
Import-Module ActiveDirectoryThen run the Microsoft-provided script. You can find it in the official Entra Connect documentation under the section "PowerShell certificate report script." The script generates a CSV-style output listing every computer object in AD, its userCertificate status, and whether the certificate was issued by the Microsoft Workplace Join service.
The output tells you three things: which devices have a valid hybrid join certificate and will be kept, which devices have no certificate at all and will be removed, and which devices have a certificate that wasn't issued by the correct service. That third category is the one to pay attention to, those are devices where something went wrong during the original hybrid join registration process and they need to be re-registered from scratch.
Save this report before you allow any deletions. It's your before-state baseline and you'll thank yourself later if anyone asks "which machines were affected?"
Once you've reviewed the PowerShell report and confirmed the devices flagged for deletion are genuinely the orphaned pending objects, not legitimate hybrid-joined machines, you can safely approve the deletions and let the Entra Connect sync engine do its work.
On your Microsoft Entra Connect server, open Synchronization Service Manager from the Start menu. Click the Connectors tab, select the Windows Azure Active Directory connector, and look at the most recent Export operation. If it shows stopped-deletion-threshold-exceeded, note the exact count of objects pending deletion.
Then open an elevated PowerShell session and run the following, substituting the count you just noted (or a slightly higher number for safety):
Enable-ADSyncExportDeletionThreshold -DeletionThreshold 300This temporarily raises the deletion threshold. Then trigger a full sync cycle:
Start-ADSyncSyncCycle -PolicyType InitialWatch the Synchronization Service Manager as the cycle runs. The Export step should now complete with a status of success rather than stopping. After the cycle finishes, I recommend lowering the threshold back to a more conservative value, typically 10% of your total directory object count is a reasonable baseline:
Enable-ADSyncExportDeletionThreshold -DeletionThreshold 50After the sync completes, go back to Entra admin center > Devices > All Devices and verify that the "Pending" state devices are gone while your legitimately registered hybrid-joined devices remain, showing a status of Registered with a recent activity timestamp. If any machines that should be hybrid-joined are now missing, those need to go through the re-registration process described in Step 5.
If the cleanup removed devices that should have been properly registered, or if you have down-level Windows devices (Windows 7/8.1) that were previously syncing through Entra Connect incorrectly and need to be set up the right way, you need to re-register those machines through the correct channel.
For Windows 10 and Windows 11 machines, the process is straightforward. On each affected device, open an elevated Command Prompt and run:
dsregcmd /leave
dsregcmd /joinAfter that completes, restart the machine and wait for the next Entra Connect sync cycle (by default, sync runs every 30 minutes). Then on the affected machine, run:
dsregcmd /statusLook at the output under Device State. You want to see AzureAdJoined : YES and DomainJoined : YES, that's the confirmation of a successful hybrid join. If you see WorkplaceJoined : NO in the SSO State section, the device successfully re-registered. If the join still fails, check that the device can reach enterpriseregistration.windows.net and that your AD FS or Seamless SSO configuration is correct for your domain.
For down-level Windows devices (Windows 7, Windows 8.1), the correct registration path is not through Entra Connect at all. These devices register using the Microsoft Workplace Join for non-Windows 10 computers MSI package, which goes through AD FS directly, or via Seamless SSO. Refer to the hybrid join planning guide in the Microsoft documentation for the step-by-step setup for each path, as the exact process differs depending on whether you're using managed or federated domains.
For large-scale re-registration across many machines, consider deploying the dsregcmd /join command via a Group Policy startup script or an Intune remediation script, much faster than touching every machine manually.
Advanced Troubleshooting
When the basic steps don't resolve the Microsoft Entra ID sign-in and authentication errors you're seeing, it's time to go deeper. Here's where enterprise environments tend to get complicated.
Event Viewer Analysis on AD FS Servers
Open Event Viewer on your AD FS server and navigate to Applications and Services Logs > AD FS > Admin. Enable auditing if it isn't already: in the AD FS Management console, go to Service > Edit Federation Service Properties > Events and check both Success and Failure audits. Then look for Event ID 342 (account validation failures), 411 (token issuance failures), and 1021 (device authentication failures). These event IDs give you the specific error sub-code that tells you exactly which part of the authentication chain broke.
Conditional Access Policy Conflicts
If devices that are correctly hybrid-joined are still being denied access, the problem is almost always a Conditional Access policy requiring device compliance that the device doesn't meet. In the Entra admin center, go to Protection > Conditional Access > Sign-in logs and filter by the affected user. Look at the Conditional Access tab in any failed sign-in entry, it will show exactly which policy applied and which condition failed. The most common mismatch is a policy requiring "Compliant" device state, but the device is only "Hybrid Azure AD Joined" without an Intune compliance policy assigned to it.
Group Policy Settings for Hybrid Join
The automatic device registration that enables hybrid join is triggered by a scheduled task called Automatic-Device-Join in Task Scheduler, under Microsoft > Windows > Workplace Join. This task is configured by Group Policy. In your GPO editor, check Computer Configuration > Administrative Templates > Windows Components > Device Registration and confirm the setting Register domain joined computers as devices is set to Enabled. If this policy isn't applying, run gpresult /r on affected machines to see which GPOs are actually being applied and trace the inheritance chain.
Microsoft Sentinel Integration for Sign-In Monitoring
If you've enabled Log Analytics for AD FS sign-ins, you can feed that data directly into Microsoft Sentinel for automated threat detection. The Connect Health sign-in data becomes a first-class log source in Sentinel, and you can build analytic rules around it, for example, alerting on high-volume authentication failures from a single source IP, or detecting impossible travel between sign-in locations. This doesn't fix authentication errors, but it turns your sign-in log data into an active security tool rather than a passive audit trail.
Registry-Level Troubleshooting for Device Registration
On machines where dsregcmd /status shows unexpected states, check the registry key at:
HKLM\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfoThis key stores the device's current join state. If the key is missing entirely on a machine that should be hybrid-joined, the initial join process never completed. If it exists but shows stale data, the leave-and-rejoin sequence (dsregcmd /leave followed by dsregcmd /join) should clear it and trigger a fresh registration.
Prevention & Best Practices
Once you've stabilized Microsoft Entra ID sign-in and authentication errors in your environment, the goal is to not be here again in six months. Here's what actually works in production environments.
Keep Microsoft Entra Connect updated deliberately, not automatically. I know that sounds counterintuitive, staying current is generally good practice. But Entra Connect updates can have significant behavioral changes, like the device cleanup we've been discussing throughout this guide. Before any version update, read the release notes in detail, test in a staging environment if you have one, and run the PowerShell certificate report against your production directory so you have a baseline. That way, if the update triggers a large deletion, you already know what to expect and have documentation ready.
Set a sensible Export Deletion Threshold. The default threshold in many environments is embarrassingly low, sometimes as low as 500 objects. For a directory with tens of thousands of device objects, that can trip during routine operations. Calculate your threshold as roughly 5–10% of your total object count and document why you set it where you did. Review it quarterly as your directory grows.
Monitor Connect Health proactively. Don't wait for users to call the help desk to find out that your AD FS sign-in data stopped flowing. Set up alert rules in the Azure portal for Connect Health agent health status changes. A failing agent on a single AD FS server in a farm is easy to miss but means you're flying blind on sign-in analytics for that server's traffic.
Plan and document your hybrid join topology before you need it. Know which devices are supposed to be hybrid-joined, which are registered via AD FS, and which are using Seamless SSO. Keep a current record of which Windows versions are in your fleet. Down-level devices need a completely different registration path than Windows 10/11, and mixing them up is one of the most common causes of the device sync issues this guide covers.
- Schedule a monthly review of Entra admin center > Devices > All Devices, filter by "Pending" state and investigate anything sitting there longer than two weeks
- Enable diagnostic settings on your Entra ID tenant to route sign-in logs to Log Analytics; it costs almost nothing and gives you months of searchable sign-in history
- Run
dsregcmd /statusas part of your endpoint health check scripts, pipe the output to a central log source so you can spot hybrid join failures across the fleet before users notice - Review your Conditional Access policies after every major Entra Connect update, new device cleanup behavior can shift the compliance state of endpoints in ways that trigger policy mismatches you didn't expect
Frequently Asked Questions
What data is actually displayed in the AD FS sign-in report in Connect Health?
The Connect Health sign-in report for AD FS shows correlated sign-in events pulled directly from your AD FS servers, matched against the AD FS event schema. This includes the user principal name, authentication timestamp, result (success or failure), the relying party application the user was trying to reach, the client IP address, and the specific error code on failed attempts. The data appears automatically once the Connect Health agent is healthy and prerequisites are met, you don't have to configure any custom logging. If you've enabled Log Analytics integration, this same data is also queryable in your Log Analytics workspace using Kusto queries, and it can be piped into Microsoft Sentinel for alerting and threat detection.
How can I verify which devices will be deleted by the Microsoft Entra Connect 1.4.xx.x update?
Microsoft provides a dedicated PowerShell certificate report script that examines the userCertificate attribute on every computer object in your Active Directory. It identifies which devices have a valid Microsoft Entra hybrid join certificate (and will be kept), which have no certificate (and will be removed), and which have certificates issued by the wrong service. Run this script before you allow any large-batch deletions to proceed through the Export Deletion Threshold, it gives you a clear, exportable list of exactly which machines are in scope. You can find the script referenced in the official Entra Connect documentation under the device disappearance troubleshooting section. Running it on a domain controller with the Active Directory PowerShell module takes only a few minutes.
My devices disappeared from Entra ID after updating Entra Connect, did something go wrong?
Almost certainly not. After updating to version 1.4.xx.x, Microsoft Entra Connect enforces a stricter rule: it only syncs Windows 10 devices that have the specific userCertificate attribute value set by the Microsoft Entra hybrid join process. Devices that were previously synced without this attribute, typically ending up in a permanent "pending" state, get cleaned out. These pending-state devices were never usable by Conditional Access authorization to begin with, so their removal doesn't affect any working functionality. Your correctly registered hybrid-joined devices won't be touched. If you've lost devices that were actually working for users, check whether they had a valid hybrid join certificate using the PowerShell report script, and re-register them using dsregcmd /leave followed by dsregcmd /join.
Why isn't my AD FS sign-in data showing up in the Connect Health report?
There are three common reasons for a blank or empty sign-in report. First, the Connect Health agent for AD FS may not be running on one or more of your AD FS servers, check Services (services.msc) and look for "Microsoft Azure AD Connect Health Agent for AD FS." Second, the feature may have been recently enabled and hasn't had time to populate data yet, reports can take up to 30–60 minutes to start showing events after the agent is healthy. Third, your AD FS server may not have outbound access to the required Azure health endpoints on port 443. Test connectivity from the AD FS server itself using Test-NetConnection -ComputerName adhybridhealth.azure.com -Port 443 and engage your network team if it fails.
Should down-level Windows devices (Windows 7, Windows 8.1) be synced through Microsoft Entra Connect?
No, and this is explicitly called out in Microsoft's official documentation. Microsoft Entra Connect should never synchronize down-level Windows devices. Those devices are designed to register directly with Azure AD through either Active Directory Federation Services (AD FS) or Seamless Single Sign-On, not through the Connect sync engine. If your version 1.4.xx.x update deleted down-level device objects that were previously syncing incorrectly through Entra Connect, that's the expected and correct behavior. To get those devices properly registered, use the Microsoft Workplace Join MSI package for non-Windows 10 computers, which handles the correct AD FS-based registration path for older Windows versions.
The deletion count in Entra Connect is way higher than I expected, how do I safely allow it to go through?
First, run the PowerShell certificate report script against your Active Directory to confirm the deletion scope matches what you'd expect from the 1.4.xx.x device cleanup, specifically, devices without a valid userCertificate and down-level Windows devices that were syncing incorrectly. If the numbers align with that report, the deletions are safe to approve. On your Entra Connect server, open PowerShell and run Enable-ADSyncExportDeletionThreshold -DeletionThreshold [count] with a value matching or slightly exceeding your deletion count, then trigger a sync with Start-ADSyncSyncCycle -PolicyType Initial. Watch the Synchronization Service Manager to confirm the export completes successfully. If the deletion count is significantly larger than what the certificate report accounts for, stop and open a Microsoft Support case before proceeding, something else may be going on.