Seamless SSO troubleshooting checklist

Symptoms to confirm

• 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):

Likely causes

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

• 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.
• 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.
• Windows requests a service ticket for that SPN from a domain controller, encrypted with the account's key.
• Entra ID decrypts the ticket with its copy of the key and matches the identity in it to a synced user.

Note: On Microsoft Entra joined or hybrid joined Windows devices, SSO normally comes from the Primary Refresh Token, which takes precedence over Seamless SSO (users see a "Connected to Windows" tile). If dsregcmd /status shows AzureAdPrt : YES, start with my PRT troubleshooting guide. Seamless SSO matters mostly for devices that are only domain-joined.

Checklist

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

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

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

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

Verify

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