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

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:

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.

   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.

1. Verify the browser can reach the SSO endpoint. From the failing machine, open https://autologon.microsoftazuread-sso.com or test it:

   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.

1. Check the AZUREADSSOACC computer account in each AD forest. On a domain controller:

   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.

1. Roll the Kerberos decryption key, once per forest. On the Entra Connect server, as administrator:

   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.

1. Wait for AD replication, then retest. The new key must replicate to all domain controllers. Then on the failing machine, purge tickets and retry:

   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).