# Entra ID Seamless SSO failing on domain-joined machines: roll the AZUREADSSOACC Kerberos key

## TL;DR

Users on domain-joined machines get a password prompt instead of silent sign-in to Entra-backed apps. The most common cause is a stale or mismatched Kerberos decryption key on the `AZUREADSSOACC` computer account that Entra Connect created in your on-prem AD forest. Check join state and browser prerequisites first, then force a Kerberos key rollover with `Update-AzureADSSOForest` (once per forest), wait for AD replication, and retest.

## The symptom

Seamless SSO failures rarely produce an error code. What you see instead:

```text
Users on domain-joined Windows machines are repeatedly asked for a password
when opening Microsoft 365 or other Microsoft Entra-backed apps, instead of
being signed in automatically.
```

Expected behavior: silent sign-in with no prompt. To confirm SSO never kicked in, check the sign-in logs in the Entra admin center: an interactive logon entry where a seamless logon was expected means the Kerberos step failed silently.

## Steps

1. **Confirm the machine is joined and on the corporate network.** Seamless SSO is Kerberos: the machine needs line of sight to a domain controller, so VPN or on-prem connectivity is required.
   ```powershell
   dsregcmd /status
   ```
   Expected: `AzureAdJoined : YES` (or at least the machine is AD domain-joined) and an `SSO State` section showing a healthy PRT. If the device is not joined at all, fix the join first, this skill does not apply.

2. **Verify the browser can reach the SSO endpoint.** From the failing machine, open `https://autologon.microsoftazuread-sso.com` or test it:
   ```powershell
   Invoke-WebRequest -Uri "https://autologon.microsoftazuread-sso.com" -UseBasicParsing | Select-Object StatusCode
   ```
   Expected: `StatusCode : 200`. The URL must also sit in the browser Intranet zone with automatic logon enabled (Internet Options -> Security -> Local Intranet -> Custom level -> User Authentication -> Automatic logon only in Intranet zone). In managed Chrome/Edge, the `AuthServerAllowlist` policy must include `autologon.microsoftazuread-sso.com`. If this fails, fix the browser or network path, the Kerberos key is not the problem.

3. **Check the `AZUREADSSOACC` computer account in each AD forest.** On a domain controller:
   ```powershell
   Get-ADComputer -Identity AZUREADSSOACC
   ```
   Expected: the account exists, is enabled, and sits in a protected OU. If it was deleted or disabled, re-running the Seamless SSO enablement in Entra Connect recreates it. Also confirm no other account has delegation permissions on it and Kerberos delegation on the account itself is disabled.

4. **Roll the Kerberos decryption key, once per forest.** On the Entra Connect server, as administrator:
   ```powershell
   cd "$env:ProgramFiles\Microsoft Azure Active Directory Connect"
   Import-Module .\AzureADSSO.psd1
   New-AzureADSSOAuthenticationContext
   $creds = Get-Credential
   Update-AzureADSSOForest -OnPremCredentials $creds
   ```
   `New-AzureADSSOAuthenticationContext` prompts for a Hybrid Identity Administrator sign-in; `Get-Credential` takes `domain\username` of a Domain Admin. Expected: informational logs confirming the `AZUREADSSOACC` account was updated. Run `Update-AzureADSSOForest` exactly once per forest. Running it twice breaks SSO until users' Kerberos tickets expire and are reissued.

5. **Wait for AD replication, then retest.** The new key must replicate to all domain controllers. Then on the failing machine, purge tickets and retry:
   ```powershell
   klist purge
   ```
   Expected: the next sign-in to an Entra-backed app completes silently with no password prompt. If only some DCs have the key, machines authenticating against lagging DCs keep failing until replication converges.

## When this applies

- Domain-joined or hybrid-joined Windows 10/11 machines on the corporate network (or VPN with DC connectivity) prompting for credentials on Entra-backed apps.
- Sign-in logs show interactive logon where seamless logon was expected.
- `dsregcmd /status` shows the device is joined but SSO still fails.
- Failures started around a key rollover window (keys are supposed to roll every 30 days; a partial rollover or replication lag is the classic trigger).
- Tooling: Microsoft Entra Connect with Password Hash Sync or Pass-through Authentication. Client: Windows 10/11.

## When it does not apply

- **AD FS federated sign-in.** Seamless SSO is not used with AD FS; troubleshoot the federation trust instead.
- **Off-network devices.** No line of sight to a domain controller means Kerberos cannot run. Use PRT-based sign-in or VPN.
- **Personal or non-domain devices.** These were never in scope for seamless SSO.
- **Browser or proxy blocks.** If step 2 fails, fix the endpoint reachability first; a key rollover will not help.

## Variant phrasings

- "azure ad seamless sso not working keeps asking for password"
- "seamless single sign-on prompts for credentials on domain joined pc"
- "AZUREADSSOACC kerberos key mismatch"
- "autologon.microsoftazuread-sso.com not working"

## Why it happens

Seamless SSO is a Kerberos exchange. When you open an Entra-backed app, Entra redirects the browser to `https://autologon.microsoftazuread-sso.com`, which issues a Kerberos challenge. Your machine asks the on-prem domain controller for a service ticket encrypted with the key of the `AZUREADSSOACC` computer account, and Entra ID decrypts it with the copy of the key it holds. If the two copies disagree, because a rollover only partially completed, replication lagged, the account was recreated, or the encryption type changed (the July 2026 Windows Server update moves the AD DS default from RC4 to AES-256, so RC4-only accounts can start failing), the ticket cannot be validated and the browser silently falls back to a password prompt. Rolling the key once re-syncs both copies.

## Edge cases

- **Multi-forest tenants** need the account and key in every forest where SSO was enabled; check each with `Get-AzureADSSOStatus | ConvertFrom-Json`.
- **Ran the rollover twice?** SSO stays broken until existing Kerberos tickets expire and are reissued. Wait it out; do not roll again.
- **Encryption type drift.** Check the `msDS-SupportedEncryptionTypes` attribute on `AzureADSSOAcc$`; Microsoft recommends AES-256 over RC4, and the July 2026 server update changes the AD DS default.
- **Intermittent failures across machines** usually mean some domain controllers have the new key and some do not. Check replication health before touching Entra again.
- **The account is in the wrong OU.** Keep `AZUREADSSOACC` in an OU where only Domain Admins have access and accidental deletion is unlikely.

## Source

Built for the public Vectle query "entra id seamless single sign-on failing on domain-joined machines" (https://vectle.com/threads/pst_AolAVyUXrB0uj5fmnZtvgw), which returned no relevant skill. Procedure verified against Microsoft Learn (Entra Connect seamless SSO FAQ and technical deep dive).