Seamless SSO not working: the AZUREADSSOACC account, Kerberos and the intranet zone

Seamless single sign-on (Seamless SSO) lets users on domain-joined PCs reach Microsoft 365 with a Kerberos ticket instead of a password. When it breaks there's no error page; users just see the password prompt again. In this post I'll map the sign-in error codes to causes, then walk through a fix-and-verify routine built around the intranet zone, klist and the AZUREADSSOACC computer account.

Symptoms#

• Users on domain-joined PCs inside the corporate network or on VPN are asked for a password instead of seeing "Trying to sign you in" and landing in the app.
• It works for some users, browsers or PCs but not others, or it stopped after a Group Policy or AD clean-up change.
• Failed sign-ins in Entra ID › Monitoring & health › Sign-ins show one of these codes (this view needs Microsoft Entra ID P1 or P2):

Why it happens#

Seamless SSO is a Kerberos exchange in which Microsoft Entra ID plays the role of an on-premises service:

1. When you enable Seamless SSO for a forest, Entra Connect creates a computer account named AZUREADSSOACC and shares its Kerberos decryption key with Microsoft Entra ID. The account holds the SPN HTTP/autologon.microsoftazuread-sso.com.
2. During sign-in, the Entra page asks the browser to authenticate to https://autologon.microsoftazuread-sso.com. The browser only answers with Kerberos when that URL is in the Local intranet zone.
3. Windows requests a service ticket for that SPN from a domain controller, encrypted with the account's key.
4. Entra ID decrypts the ticket with its copy of the key and matches the identity in it to a synced user.

So the usual causes are: the URL isn't in the intranet zone (Trusted sites actively blocks sign-in); no domain controller is reachable or the clock is over five minutes off; the account was deleted, disabled or recreated; Entra ID's copy of the key no longer matches; the account's encryption types don't match what your domain controllers allow; or the ticket is too large.

How to fix it#

1. Confirm the feature covers the forest. In the Microsoft Entra admin center, open Entra ID › Entra Connect › Connect Sync and check that Seamless single sign-on is Enabled and lists the user's AD domain. A fresh enablement can take up to 30 minutes.
2. Check the client basics. Domain-joined device, a domain account from an enabled forest, a reachable domain controller and a clock within five minutes of it.
3. Fix the zone. Map https://autologon.microsoftazuread-sso.com to zone 1 (Local intranet) with Site to Zone Assignment List under User Configuration › Policies › Administrative Templates › Windows Components › Internet Explorer › Internet Control Panel › Security Page, and enable Allow updates to status bar via script under Security Page › Intranet Zone. Edge and Chrome on Windows honour these zone settings. Firefox needs the URL in network.negotiate-auth.trusted-uris and won't use Seamless SSO in private windows; mobile browsers aren't supported.
4. Test Kerberos directly on an affected PC with the klist commands below. If no ticket is issued, the problem sits between the client and the domain controller, not in Entra ID.
5. Inspect the account in every enabled forest. It must exist, be enabled and be the only object holding the SPN. PasswordLastSet shows when the key was last rolled over. Microsoft recommends AES256 for this account: msDS-SupportedEncryptionTypes = 16 means AES256 only, while 4 means RC4 only, which fails once your domain controllers stop issuing RC4 tickets.
6. Roll over the Kerberos decryption key from the active Entra Connect server if the key may be out of step (the account's password was reset, the object was restored, or nobody knows its history). Use a domain admin entered as DOMAIN\user that isn't in Protected Users, and run Update-AzureADSSOForest only once per forest; a second run invalidates tickets users already hold. If the account is RC4-only, roll over the key first, then switch it to AES; the reverse order breaks Seamless SSO.
7. 81001 or 81011/81013? Entra ID accepts request headers up to 50 KB, so users in very many groups need fewer memberships. "User not found" codes point to a sync problem; see my Connect Sync errors guide.
8. Last resort: reset the feature. In the same module, Disable-AzureADSSOForest -OnPremCredentials $creds removes the account, Enable-AzureADSSOForest recreates it and Enable-AzureADSSO -Enable $true switches the tenant feature back on. Users regain SSO once their cached tickets (typically valid for 10 hours) expire or are purged.

REM On an affected PC, as the user
klist purge
klist get HTTP/autologon.microsoftazuread-sso.com
klist

# Account health (RSAT Active Directory module)
Get-ADComputer -Identity AZUREADSSOACC -Properties Enabled, PasswordLastSet, 'msDS-SupportedEncryptionTypes' |
    Select-Object Enabled, PasswordLastSet, 'msDS-SupportedEncryptionTypes'
setspn -Q HTTP/autologon.microsoftazuread-sso.com

# Key rollover, on the active Entra Connect server
cd "$env:ProgramFiles\Microsoft Azure Active Directory Connect"
Import-Module .\AzureADSSO.psd1
New-AzureADSSOAuthenticationContext          # Hybrid Identity Administrator sign-in
Get-AzureADSSOStatus | ConvertFrom-Json      # forests where the feature is on
$creds = Get-Credential                      # CONTOSO\domainadmin
Update-AzureADSSOForest -OnPremCredentials $creds

# Only after the rollover, if the account was RC4-only
Set-ADComputer -Identity AZUREADSSOACC -KerberosEncryptionType AES256

Verify the fix#

• klist lists a ticket whose server is HTTP/autologon.microsoftazuread-sso.com with KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96.
• In a normal browser window, open https://myapps.microsoft.com and enter the UPN: you should see "Trying to sign you in" and arrive without a password prompt, with a successful entry in the sign-in log.
• With Kerberos service ticket success auditing on your domain controllers, each Seamless SSO sign-in logs event 4769 for AZUREADSSOACC$; ticket encryption type 0x12 means AES256. Filter with:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[EventData[Data[@Name='ServiceName'] and (Data='AZUREADSSOACC$')]]</Select>
  </Query>
</QueryList>

Prevent it next time#

• Roll over the key at least every 30 days, as Microsoft recommends; PasswordLastSet is your audit trail.
• Protect AZUREADSSOACC from accidental deletion and exclude it from stale-computer clean-ups. It never signs in like a real PC, so it always looks stale.
• Keep the account on AES256 before anyone removes RC4 from your domain controllers.
• Longer term, hybrid join your Windows devices so PRT-based SSO does the work and Seamless SSO only covers the leftovers.

References#

• Troubleshoot Microsoft Entra seamless single sign-on
• Migrate to cloud authentication using Staged Rollout (includes the Seamless SSO PowerShell steps)