entra id seamless single sign-on failing on domain-joined machines

TL;DR

Seamless SSO works by the browser handing Entra a Kerberos ticket for the AZUREADSSOACC computer account. When machines prompt for a password anyway, the usual culprits are a missing or stale AZUREADSSOACC account, the Kerberos key rolled without updating it, or the sign-in URL not being in the browser's Local Intranet zone. Check those three in order and the prompts go away.

Steps

1. On a failing machine, open a private browser window and go to the Microsoft 365 sign-in page. Expected: silent sign-in with no password prompt. If it prompts, SSO is broken on this machine.
2. Verify the machine is domain-joined and can reach a domain controller with fresh credentials. Expected: the logon server resolves to a real DC and the machine has line of sight to it (VPN users included).
3. In on-prem AD, confirm the AZUREADSSOACC computer account exists. This account holds the Kerberos decryption key. Expected: exactly one AZUREADSSOACC account in the Computers container.
4. Confirm Seamless SSO is enabled in Entra Connect and the Kerberos key has not been rolled without updating the account. Expected: Seamless SSO shows enabled for the domain. A key rollover after "it worked yesterday" is the classic pattern.
5. Check the browser: the sign-in URL must be in the Local Intranet zone (Edge or Chrome policy) so the browser attempts Kerberos. Expected: the autologon sign-in URL is listed in the intranet zone. Without it, the browser never sends the ticket.

Use this when

• Domain-joined machines get password prompts on Microsoft 365 or Azure sign-in pages
• SSO worked before and broke after an Entra Connect change or key rollover
• Some domain-joined machines work and others do not

Not for this skill when

• The device is not domain-joined (Seamless SSO only applies to domain-joined machines)
• Personal or BYOD devices prompt for passwords (expected behavior)
• The prompt appears for non-Microsoft apps (check that app's own SSO config)

Compatibility

• Entra Connect Sync or Entra Cloud Sync with Seamless SSO enabled
• Windows 10/11 domain-joined, Edge or Chrome with intranet zone policy

Variants

Works on some machines in the same office

Per-machine issue. Check that machine's domain trust relationship and clock skew: more than 5 minutes off breaks Kerberos.

Fails only over VPN

The VPN client may not provide DC connectivity at logon. Check split-tunnel config and DNS resolution for the AD domain.

Why it happens

The browser fetches a Kerberos ticket for AZUREADSSOACC and hands it to Entra instead of a password. If the account is missing, the key is stale, the browser is not configured to attempt Kerberos, or the machine cannot reach a DC, the handshake silently falls back to a password prompt with no useful error.

Edge cases

• Multiple forests: each forest needs its own AZUREADSSOACC account.
• After a Kerberos key rollover, allow time for AD replication before declaring it broken.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AolAVyUXrB0uj5fmnZtvgw