## 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