Entra Seamless SSO Not Working: A Read-First Intranet Zone, Kerberos Ticket, and AZUREADSSOACC Triage

Helpdesk: "Outlook on the web used to just open on my desk PC. Now it asks for my password every morning." A second ticket from the same floor: the sign-in page takes the username, pauses, then wants a password, and only for people on the older domain-joined laptops. Someone has already proposed "turn Seamless SSO off and on again," running the key rollover a second time to be safe, or adding autologon.microsoftazuread-sso.com to Trusted sites for everyone.

Don't reset anything yet. Microsoft Entra Seamless SSO is opportunistic: when any link fails, the user silently falls back to a normal password prompt, so the only symptom is "it asks for my password." It only works when the whole chain holds: the device actually uses Seamless SSO (not PRT-based SSO) → the feature is enabled on the tenant for this user's AD forest → the browser or Office client treats https://autologon.microsoftazuread-sso.com as Local intranet and is allowed to send Kerberos to it → the device can reach a domain controller with a sane clock and gets a ticket for the AZUREADSSOACC computer account → that ticket is small enough and encrypted with a key Microsoft Entra ID still holds → Entra ID can map the ticket's SID to a synced cloud user. In 2026 a new link fails more often than it used to: domain controllers patched in April and July 2026 stop assuming RC4 for accounts without an explicit encryption type, and Microsoft calls out the AzureADSSOAcc$ account by name.

If the device is Windows 10 or 11 and Microsoft Entra hybrid joined, Seamless SSO isn't what signs the user in at all. Microsoft says SSO on hybrid joined, Entra joined, and registered devices runs on the Primary Refresh Token, so start with the AzureAdPrt: NO triage or the Hybrid Azure AD join pending triage. If the password the user types is rejected, that's not Seamless SSO either: see the password hash sync triage. If the sign-in completes and then gets blocked, read the AADSTS53003 Conditional Access triage. This post covers Seamless SSO (Kerberos to AZUREADSSOACC) on domain-joined devices, set up through Entra Connect Sync (Cloud Sync tenants enable the same feature with the same PowerShell module).

TL;DR

• Confirm the device should be using Seamless SSO. Run dsregcmd /status. If AzureAdJoined : YES on Windows 10/11, the PRT does SSO and Seamless SSO isn't used. Microsoft recommends PRT-based SSO for Windows 10, Windows Server 2016, and later. Fix the PRT, not Seamless SSO.
• Read the sign-in error code before touching AD. In the Entra sign-in logs, 81001 = Kerberos ticket too large (too many groups); 81007 = tenant not enabled; 81010 = ticket expired or invalid; 81011 / 81013 = no cloud user matches the ticket's SID; 81012 = a different user is signed in to the device; 81002/81003/81004/81008/81009 = Microsoft's troubleshooting checklist.
• The URL must be in Local intranet (zone 1), not Trusted sites. Microsoft states Trusted sites blocks sign-in. The intranet zone also needs Allow updates to status bar via script. If you override Edge/Chrome AuthServerAllowlist or AuthNegotiateDelegateAllowlist, the URL has to be in those lists too.
• The client needs line of sight to a DC. Run klist and look for a ticket for the AZUREADSSOACC account. Clock within five minutes. Corporate network or VPN. Kerberos tickets usually live 10 hours, so a disable/re-enable or key change only reaches users after old tickets expire or you run klist purge.
• Check AZUREADSSOACC in every enabled forest: present, enabled, out of any quarantine OU, delegation off, and its msDS-SupportedEncryptionTypes. Moving from RC4 to AES is a two-step job: roll over the Kerberos key first, then change the encryption type. Microsoft warns that doing it the other way round stops Seamless SSO.
• Run Update-AzureADSSOForest once per forest, never twice. Microsoft says a second run breaks the feature until users' tickets expire and are reissued.

Where in the chain did it break?

Write down the user's UPN, the device name and join state, the browser (and whether it was InPrivate), the network (office, VPN, home), the time with time zone, and the Correlation ID from the sign-in page before you change anything.

Step 1: Is this device even using Seamless SSO?

Microsoft's overview is explicit: Seamless SSO needs a domain-joined device, but it isn't used on Windows 10 Microsoft Entra joined or hybrid joined devices. Those get SSO from the Primary Refresh Token (PRT). When a device is both registered and domain-joined, Microsoft says SSO from Entra join takes precedence. The user sees a sign-in tile that says "Connected to Windows."

Read the join state on the user's device (read-only, normal user prompt):

dsregcmd /status | Select-String -Pattern 'AzureAdJoined', 'DomainJoined', 'AzureAdPrt', 'WorkplaceJoined' 

Two more scope checks from Microsoft's known-issues list: Seamless SSO doesn't work on mobile browsers on iOS and Android, and Microsoft's FAQ notes Chrome needs a browser extension to use PRT-based SSO on Entra joined devices. A "Seamless SSO broke on my phone" ticket is a different feature.

Step 2: Is the feature enabled for this user's forest? (read-only)

Portal. Microsoft Entra admin center > Entra ID > Entra Connect > Connect Sync. Seamless single sign-on should read Enabled. Click through to see the AD forests that are enabled.

PowerShell, on the Entra Connect server, elevated. This is Microsoft's own sequence from the FAQ; Get-AzureADSSOStatus only reads:

Import-Module "$env:ProgramFiles\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1" Set-Location "$env:ProgramFiles\Microsoft Azure Active Directory Connect" Import-Module .\AzureADSSO.psd1 New-AzureADSSOAuthenticationContext # prompts for a Hybrid Identity Administrator Get-AzureADSSOStatus | ConvertFrom-Json # look at the "Domains" list 

Seamless SSO pairs with password hash sync or pass-through authentication only. Microsoft says it doesn't apply to AD FS federated domains, and the test URL in Step 4 must use a verified, non-federated domain. It's free: no Entra ID P1/P2 needed for the feature itself.

Step 3: Read the sign-in error code

Microsoft's troubleshooting page (it says this view needs a Premium license) maps the Sign-in error code on the user's sign-in event: Entra admin center > Entra ID > Monitoring & health > Sign-ins > the user's sign-in. Because the feature is opportunistic, the failed Seamless SSO attempt and the later password sign-in can show up as separate events. Look at the minute the user says it prompted.

Optional Graph read of the same events (GET only; the sign-in log API generally needs Entra ID P1/P2 on the tenant):

Connect-MgGraph -Scopes 'AuditLog.Read.All', 'Directory.Read.All' $upn = 'user@contoso.com' Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$upn'" -Top 50 | Where-Object { $_.Status.ErrorCode -ge 81001 -and $_.Status.ErrorCode -le 81013 } | Select-Object CreatedDateTime, AppDisplayName, ClientAppUsed, CorrelationId, @{n = 'Code'; e = { $_.Status.ErrorCode }}, @{n = 'Reason'; e = { $_.Status.FailureReason }} 

No 81xxx event at all while the user still gets a password prompt usually means the browser never attempted Kerberos (Step 4), the device isn't on the Seamless SSO path (Step 1), or the app sent the user to the common endpoint without a domain hint. Microsoft's FAQ lists which URLs give a silent sign-in, for example https://myapps.microsoft.com/contoso.com, https://outlook.office365.com/contoso.com, and https://www.office.com?domain_hint=contoso.com.

Step 4: Is the browser allowed to send Kerberos to the autologon URL?

Microsoft explains why this step exists: browsers don't send Kerberos tickets to a cloud endpoint unless you explicitly add it to the intranet zone. Rollout uses Group Policy (locked) or Group Policy preferences (user-editable):

Read what the user actually got (read-only, as the user):

# GPP-style mapping (HKCU) Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon' -ErrorAction SilentlyContinue # Policy-delivered Site to Zone Assignment List (policy hive; check HKLM too if you assign it per computer) Get-ItemProperty 'HKCU:\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey' -ErrorAction SilentlyContinue Get-ItemProperty 'HKLM:\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey' -ErrorAction SilentlyContinue # Edge / Chrome allowlist overrides, if your org sets them Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Edge' -Name AuthServerAllowlist, AuthNegotiateDelegateAllowlist -ErrorAction SilentlyContinue Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Google\Chrome' -Name AuthServerAllowlist, AuthNegotiateDelegateAllowlist -ErrorAction SilentlyContinue gpresult /r /scope user 

Office desktop apps follow a different path: they query a WS-Trust MEX endpoint and an integrated authentication endpoint used only by Seamless SSO. Microsoft requires Microsoft 365 apps 16.0.8730.xxxx or later (older builds prompt for the username only) and modern authentication on the tenant. OneDrive needs its silent config setting for a silent sign-in. If you have an outbound HTTP proxy, Microsoft says to allowlist autologon.microsoftazuread-sso.com explicitly, because a wildcard might not be accepted.

Test cleanly. Microsoft's test: in a new private session on a supported browser, open https://myapps.microsoft.com/contoso.com (your verified, non-federated domain). If the user lands in My Apps without typing anything, Seamless SSO works end to end.

Step 5: Does the client get a usable Kerberos ticket?

Microsoft's checklist for the device: joined to the AD domain, user signed in with an AD domain account, on the corporate network (wired, wireless, or VPN with DC reachability), and the device clock within five minutes of the DCs. Then check the tickets (read-only):

klist # look for a ticket whose Server line names the autologon SPN w32tm /query /status # time source and last successful sync nltest /dsgetdc:contoso.com # can this device locate a DC right now? 

The service tickets you want are for the SPNs on the AZUREADSSOACC computer account. Microsoft says "a number of SPNs" are created and doesn't list them on the Learn pages used here. In practice the one browsers request is HTTP/autologon.microsoftazuread-sso.com; confirm against setspn -L AZUREADSSOACC in Step 6. Read the KerbTicket Encryption Type line on that ticket too: AES-256 versus RC4 matters in Step 6.

Raising the client's MaxTokenSize doesn't lift Entra ID's 50 KB header limit. Group cleanup is the fix Microsoft names for 81001.

Step 6: AZUREADSSOACC in each forest, and the 2026 RC4 change

When you enable the feature, Entra Connect creates an AZUREADSSOACC computer account in each synced AD forest, adds SPNs, and shares that account's Kerberos decryption key with Entra ID (each forest has its own key). Read it, per forest (read-only):

Import-Module ActiveDirectory $forestDomain = 'contoso.com' # repeat for every forest in Get-AzureADSSOStatus Get-ADComputer -Filter "Name -eq 'AZUREADSSOACC'" -Server $forestDomain `  -Properties Enabled, CanonicalName, PasswordLastSet, 'msDS-SupportedEncryptionTypes', TrustedForDelegation, TrustedToAuthForDelegation, servicePrincipalName | Select-Object Name, Enabled, CanonicalName, PasswordLastSet, @{n = 'EncTypes'; e = { $_.'msDS-SupportedEncryptionTypes' }}, TrustedForDelegation, TrustedToAuthForDelegation, @{n = 'SPNs'; e = { $_.servicePrincipalName -join '; ' }} setspn -L AZUREADSSOACC 

Encryption type. Microsoft supports AES256_HMAC_SHA1, AES128_HMAC_SHA1, and RC4_HMAC_MD5 for Seamless SSO, recommends AES for the AzureADSSOAcc$ account, and says the value lives in msDS-SupportedEncryptionTypes:

The Seamless SSO "how it works" page now warns that starting with the July 2026 Windows Server update, the default Kerberos encryption type in AD DS changes from RC4 to AES-256, and that organizations still on RC4 may experience Seamless SSO issues. Microsoft's KB5073381 timeline for the same hardening (CVE-2026-20833): January 2026 audit events, April 14, 2026 enforcement with manual rollback, and July 2026 enforcement with the RC4DefaultDisablementPhase rollback removed.

If the tickets started failing (81002/81008/81009, or prompts for everyone in one forest) right after DC patching, read the DC side (read-only, on a DC, with success auditing for Kerberos service ticket operations enabled):

# Seamless SSO service tickets: who asked, result, and encryption (0x12 = AES256, 0x17 = RC4) $xpath = "*[System[EventID=4769] and EventData[Data[@Name='ServiceName']='AZUREADSSOACC`$']]" Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 25 -ErrorAction SilentlyContinue | ForEach-Object { $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' } [pscustomobject]@{ Time = $_.TimeCreated; User = $d.TargetUserName; Status = $d.Status TicketEncType = $d.TicketEncryptionType; Client = $d.IpAddress } } # KDC RC4-hardening audit/enforcement events (System log, IDs 201-209 per KB5073381) Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 201..209; StartTime = (Get-Date).AddDays(-7) } -ErrorAction SilentlyContinue | Where-Object { $_.ProviderName -match 'Kdc|Kerberos-Key-Distribution' } | Select-Object TimeCreated, Id, LevelDisplayName, @{n = 'Msg'; e = { ($_.Message -split "`r?`n")[0] }} 

The AES move, in Microsoft's order (a change, not a read): if AzureADSSOAcc$ is on RC4_HMAC_MD5 and you want AES, first roll over the Kerberos decryption key (Update-AzureADSSOForest, once per forest), then change msDS-SupportedEncryptionTypes to an AES value. Microsoft says skipping the rollover first can stop Seamless SSO from working. Learn doesn't spell out why the order matters. The likely reason is that Entra ID needs a key matching the new ticket encryption, so treat that as reasoning rather than documentation.

Step 7: Can Entra ID map the ticket to a synced user?

Microsoft's feature notes: Seamless SSO finds the user by the securityIdentifier claim in the Kerberos ticket, which is why it works with userPrincipalName or an Alternate ID. So 81011 / 81013 means "no cloud user has this SID." Compare both sides (read-only):

# AD side (Get-ADUser jdoe -Properties SID, UserPrincipalName | Select-Object SamAccountName, UserPrincipalName, @{n = 'SID'; e = { $_.SID.Value }}) # Cloud side (User.Read.All is enough) Connect-MgGraph -Scopes 'User.Read.All' Get-MgUser -UserId 'user@contoso.com' -Property displayName, onPremisesSyncEnabled, onPremisesSecurityIdentifier, onPremisesDomainName, onPremisesSamAccountName | Select-Object displayName, onPremisesSyncEnabled, onPremisesSecurityIdentifier, onPremisesDomainName, onPremisesSamAccountName 

Timing: when "still broken" is just waiting

When a change is justified

Finding	Prefer	Avoid
Windows 10/11 hybrid joined device prompting	Fix the PRT / hybrid join	Pushing more Seamless SSO GPOs at devices that don't use it
URL in Trusted sites or missing	Map https://autologon.microsoftazuread-sso.com to 1 plus status-bar scripting	Trusted sites (Microsoft: blocks sign-in) or broad wildcard zone entries
Edge/Chrome allowlist overridden	Append the autologon URL to AuthServerAllowlist / AuthNegotiateDelegateAllowlist	Deleting the org's allowlist policy to "let it work"
81001	Reduce the user's group memberships	Raising MaxTokenSize and hoping (Entra's 50 KB limit still applies)
81011 / 81013	Sync the user (or fix the AD-to-cloud match)	Treating it as a Kerberos fault
AZUREADSSOACC missing or deleted	Microsoft's manual reset in a change window: Disable-AzureADSSOForest then Enable-AzureADSSOForest per forest, then Enable-AzureADSSO -Enable $true	Hand-creating a computer object with the same name
Account on RC4, DCs patched for 2026	Update-AzureADSSOForest once per forest, then set an AES value on msDS-Sup...Source：https://dev.to/adminpackstudio/entra-seamless-sso-not-working-a-read-first-intranet-zone-kerberos-ticket-and-azureadssoacc-3j2g My favorites PreviousThe 44% ProblemNextO contexto virou perímetro de segurança: por que agentes corporativos não podem receber acesso antes de receber critérios Related posts I Had a Perfect Sprint Board. 18 AI Subagents Still Wrecked the Repo. Cross-post of Insights #13. Canonical: https://sheikhwasim.com/insights/perfect-sprint-board-ai-subagents/ I lost most o 0dev.to GitHub What Is Attribution? AI Music Needs a Trail Back to the People Who Made the Work What Is Attribution? AI Music Needs a Trail Back to the People Who Made the Work A new AI-generated track can feel detac 0dev.to News A Free Google Alerts Alternative: Monitoring Global News With the GDELT DOC API Disclosure: I'm Ben, and I built the Apify Actor mentioned later in this post. I charge per result for it. Everything in 0dev.to News Butter Scraped Over Too Much Bread Everyone I know is tired. Not "I stayed up too late" tired. The other kind. The kind where you open your laptop on Monda 0dev.to Discuss From Six Seven to Six Zeros to What Next? Besides 6-9 and 6-7, I've noticed that 6-0 has become the internet's favorite number over the past couple of years. Engi 0dev.to Discuss When a document assistant refuses: quota, context, and the missing model call An assistant over your documents needs a useful answer when the documents cannot help. In my ASP.NET Core sample, that m 0dev.to C#