I85PREP
⌘ K
AZ-802 Windows Server Hybrid Administrator study materials
AZ-802 Windows Server Hybrid Administrator study resources

Hybrid Identity Sign-In Failures After a Stale Sync

AZ-802 Windows Server Hybrid Administrator · Put your knowledge to work in context.

All case studies

Hybrid Identity Sign-In Failures After a Stale Sync

Fabrikam runs a single AD DS forest (fabrikam.com) synchronized to Microsoft Entra ID with Entra Connect on a server named SYNC01. Password hash synchronization and seamless single sign-on are enabled. There are 14 domain controllers; the PDC emulator is DC01 in the primary site.

On Friday, a disk failure takes SYNC01 offline. It is restored from a two-week-old backup on Monday and the service is started. On Tuesday, users report that passwords changed in the last ten days work on-premises but fail against Microsoft 365. Newly created users cannot sign in to Microsoft 365 at all, and a handful of users see repeated sign-in prompts on domain-joined laptops even though their credentials are correct. The team also reports that a user disabled in AD DS last week can still access SharePoint.

1. Explain why passwords changed in the last ten days and new users fail in the cloud, and describe the recovery sequence.

Read the worked answer

Cause. Restoring SYNC01 from a two-week-old backup reverted the connector's watermark and its local copy of the metaverse. The sync engine believes it has already exported changes up to the backup date, so it will not re-export objects and password hashes that changed in the ten days after that point. Password hash sync is an export of a hash value; if the export is skipped, Entra ID keeps the old hash. New users created after the backup date have no cloud object at all, which is why they cannot sign in.

Recovery sequence.

  1. Do not run a full import/export blindly. First confirm the state: check the Synchronization Service Manager for the last successful export watermark and compare with the backup date.
  2. Force a full import and a full synchronization on both the AD DS connector and the Entra ID connector. This re-reads all on-premises objects and re-evaluates them against the metaverse.
  3. Run a full export to Entra ID. This re-pushes password hashes for every user whose hash differs from what the cloud holds and creates the missing user objects.
  4. Verify with a sample of affected users: Get-ADSyncConnectorRunStatus for run state, and confirm in Entra ID that the onPremisesSyncEnabled and lastPasswordChangeTimestamp values are current.
  5. Re-enable and confirm the password hash sync configuration and seamless SSO (the device Kerberos ticket scenario depends on the SSO computer object in AD DS being intact).

Prevention. SYNC01 should be a paired deployment or at minimum have a documented recovery procedure that includes a full import/sync/export cycle after any restore, because restoring the sync server is not a neutral operation - it rewinds the engine's view of what has been exported.

2. The disabled user still has SharePoint access. What is the likely cause and what should be checked?

Read the worked answer

Most likely cause. The disable was made in AD DS after the backup date, so the export that would have set accountEnabled = false in Entra ID never happened. Entra ID still holds the object as enabled. SharePoint Online authorizes against the Entra ID token, so the user keeps access until the cloud object is updated or the token is revoked.

What to check, in order.

  1. In Entra ID, confirm the user's accountEnabled value and onPremisesSyncEnabled. If the object is still enabled, the sync gap is confirmed and the full export described above will correct it.
  2. If the object is already disabled in Entra ID, the remaining access is a token-lifetime issue. Revoke refresh tokens for the user (Revoke-AzureADUserAllRefreshToken or the equivalent Microsoft Graph action) so existing sessions cannot renew.
  3. Check SharePoint site-level permissions separately. A disabled account can remain in a SharePoint group or have a direct grant; group membership is not automatically cleaned up by disabling the account, and site collection administrators may have granted access directly.
  4. Check for a second identity path - for example, an external account or a B2B guest object with the same UPN - that would survive the disable.

Judgement. The exam-relevant distinction is that disabling an account in AD DS does not immediately end cloud sessions. The fix has two independent parts: correct the directory state (sync) and invalidate live sessions (token revocation), and neither substitutes for the other.