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. IfAzureAdJoined : YESon 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
AuthServerAllowlistorAuthNegotiateDelegateAllowlist, the URL has to be in those lists too. -
The client needs line of sight to a DC. Run
klistand look for a ticket for theAZUREADSSOACCaccount. 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 runklist purge. -
Check
AZUREADSSOACCin every enabled forest: present, enabled, out of any quarantine OU, delegation off, and itsmsDS-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-AzureADSSOForestonce 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?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Right SSO path | Domain-joined device that Seamless SSO serves (not a hybrid joined Windows 10/11 device using its PRT) | "Fixing" Seamless SSO changes nothing; AzureAdPrt : NO
|
| 2. Feature on for this forest | Tenant shows Seamless single sign-on Enabled; the user's forest is in the Domains list |
81007; feature shows Disabled after a migration |
| 3. Browser / client allowed |
autologon URL in Local intranet; status-bar scripting allowed; allowlists include it; supported browser and Office build |
Username prompt then password prompt; no Kerberos attempt at all |
| 4. Kerberos ticket issued | DC reachable; clock within 5 minutes; ticket for AZUREADSSOACC in klist
|
Works in the office, fails off VPN; 81010
|
| 5. Ticket usable by Entra | Ticket under the header limit; encryption type matches the key Entra ID holds; key rolled once |
81001; 81002/81008/81009 after a key or encryption change |
| 6. User found | Ticket SID matches a synced user from an enabled forest |
81011 / 81013; 81012 on shared PCs |
| 7. Verify | User reaches the app without typing a password; DC logs a 4769 for AZUREADSSOACC$
|
Still prompts: go back to the first step that doesn't hold |
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'
| Result | Read it as |
|---|---|
DomainJoined : YES, AzureAdJoined : NO
|
Seamless SSO's territory. Continue with Step 2 |
AzureAdJoined : YES, AzureAdPrt : YES
|
PRT-based SSO. A password prompt here is usually a browser, account, or app issue, not Seamless SSO |
AzureAdJoined : YES, AzureAdPrt : NO
|
PRT problem. Use the PRT triage |
DomainJoined : NO |
Seamless SSO can't work. Microsoft's test conditions require a device joined to the AD domain |
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
| Finding | Read it as |
|---|---|
Feature disabled, or sign-in log shows 81007 (DesktopSsoTenantIsNotOptIn) |
The tenant isn't enabled. Someone disabled it (wizard or Enable-AzureADSSO -Enable $false) |
| Enabled, but the user's forest isn't in Domains | Microsoft: the user's account must come from a forest where Seamless SSO is set up. Forests with a forest trust share it: enabling one enables the trusted forests |
| You sync 30 or more forests | Microsoft: the wizard can't enable it; enable it manually with PowerShell |
| Very large forest list | The enabling policy has a 25,600-character limit. With trusted forests, enabling one is enough |
| Disabled with PowerShell, wizard still shows enabled | Expected. Microsoft notes a PowerShell disable doesn't change the state shown on the wizard's Change user sign-in page |
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.
| Code | Microsoft's meaning (error-code name) | Go to |
|---|---|---|
81001 |
User's Kerberos ticket is too large | Step 5: group memberships |
81002, 81003, 81008, 81009 (81009 = DesktopSsoAuthorizationHeaderValueWithBadFormat) |
Unable to validate the user's Kerberos ticket | Steps 5–6: key and encryption type |
81004 (DesktopSsoIdentityInTicketIsNotAuthenticated) |
Kerberos authentication attempt failed | Steps 4–5 |
81005 / 81006
|
Authentication package not supported / no authorization header found | Step 4: the browser never sent Kerberos |
81007 (DesktopSsoTenantIsNotOptIn) |
Tenant isn't enabled for Seamless SSO | Step 2 |
81010 (DesktopSsoAuthTokenInvalid) |
Ticket expired or invalid | Microsoft: sign in from a domain-joined device inside the corporate network |
81011 (DesktopSsoLookupUserBySidFailed), 81013
|
Can't find the user object from the ticket | Step 7: sync the user |
81012 (DesktopSsoMismatchBetweenTokenUpnAndChosenUpn) |
User signing in isn't the user signed in to the device | Expected on shared PCs; sign in from the user's own device |
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):
| Setting | Microsoft's value |
|---|---|
| User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone Assignment List | Value name https://autologon.microsoftazuread-sso.com, value 1 (Local intranet) |
| ... > Security Page > Intranet Zone > Allow updates to status bar via script | Enabled |
GPP alternative: registry Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon
|
Value https, REG_DWORD 1
|
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
| Finding | Read it as |
|---|---|
| URL mapped to 2 (Trusted sites) | Microsoft: adding it to Trusted sites instead of Local intranet blocks users from signing in |
| URL mapped to 4 (Restricted) | Deliberate: Microsoft documents value 4 as the way to keep kiosk or shared-PC users off Seamless SSO |
| No mapping at all | The GPO doesn't reach this user (filtering, OU, loopback). gpresult shows which GPOs applied |
AuthServerAllowlist set without the autologon URL |
Microsoft: if you override these Edge/Chrome policies, add the URL to them |
| Firefox | Add the URL to the SPNEGO section of the Authentication policy. Private browsing needs the PrivateBrowsing option; Microsoft lists it as not working by default |
| Edge InPrivate / Guest | Works by design per Microsoft; you might need AmbientAuthenticationInPrivateModesEnabled
|
| IE 11 with Enhanced Protected Mode, or legacy Edge | Not supported |
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.
| Finding | Read it as |
|---|---|
| No ticket for the autologon SPN after a fresh attempt | The browser never asked (Step 4), or the DC couldn't issue one (DC reachability, clock, missing account) |
Ticket present, still 81010
|
Expired or invalid ticket. Microsoft: klist purge, then retry from the corporate network |
Ticket present, 81001
|
Ticket too large. Microsoft: Entra HTTPS requests allow headers up to 50 KB, and the ticket must leave room for 2–5 KB of other artifacts. Reduce the user's group memberships |
| Works in the office, fails at home | No DC line of sight. Seamless SSO needs a direct connection or VPN |
Works for one user on a PC, 81012 for the next |
A different account is signed in to Windows than the one typing at the sign-in page |
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
| Finding | Read it as |
|---|---|
| No object returned | Account deleted or never created in this forest. Microsoft: re-create it with the PowerShell cmdlets (manual reset, see "When a change is justified") |
Enabled = False |
Microsoft's checklist: the account must be present and enabled in each forest |
CanonicalName in a quarantine or "stale computers" OU |
Microsoft warns that Pass-the-Hash / credential-theft-mitigation designs must not move it into a Quarantine container, and says to store it in an OU safe from accidental deletion that only Domain Admins manage |
TrustedForDelegation / TrustedToAuthForDelegation = True
|
Microsoft: Kerberos delegation on this account must be disabled. Security issue first, SSO issue second |
PasswordLastSet months old |
Probably no recent key rollover. Microsoft recommends rolling the key at least every 30 days (inference: the rollover resets this account's secret, so the date should move when you roll) |
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:
EncTypes value |
Meaning (Microsoft's bit-flag table) |
|---|---|
empty / 0
|
Not defined. The KDC falls back to DefaultDomainSupportedEncTypes. Microsoft's table still says this defaults to RC4. KB5073381 says DCs with the April 14, 2026 or later update assume AES-SHA1 (0x18) instead |
4 |
RC4 only |
16 (0x10) |
AES-256 |
24 (0x18) |
AES-128 + AES-256 |
28 (0x1C) |
RC4 + AES-128 + AES-256 |
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] }}
| Finding | Read it as |
|---|---|
4769 for AZUREADSSOACC$ with Status 0x0, users still fail with 81002/81008/81009
|
The DC issued the ticket; Entra ID couldn't validate it. Suspect a key/encryption mismatch or a recent double rollover |
4769 with failure code 0xE (KDC_ERR_ETYPE_NOTSUPP) |
Encryption type mismatch at the KDC (Microsoft's RC4 remediation page) |
KDCSVC 201–209 naming AZUREADSSOACC$
|
The account is caught by the RC4 hardening. Plan the AES move below |
No 4769 for AZUREADSSOACC$ at the failing time |
The client never asked. Go back to Steps 4–5 |
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
| Finding | Read it as |
|---|---|
onPremisesSyncEnabled empty / False
|
Cloud-only user. Microsoft's fix for 81011/81013: sync the user with Entra Connect |
| SIDs differ | Cloud user is matched to a different AD account (migration, re-created user, other forest). Fix the match in sync, not in Seamless SSO |
| User synced from a forest missing from Domains (Step 2) | Enable Seamless SSO for that forest |
Timing: when "still broken" is just waiting
| Event | Microsoft's timing / rule |
|---|---|
| Enabling Seamless SSO | Can take up to 30 minutes in a few cases |
| Disable and re-enable | Users don't get SSO until their cached Kerberos tickets expire, typically 10 hours (klist purge to test sooner) |
| Kerberos ticket lifetime | Typically 10 hours; your AD settings may differ |
| Key rollover cadence | Microsoft recommends at least every 30 days with Update-AzureADSSOForest
|
Running Update-AzureADSSOForest twice for a forest |
The feature stops working until users' tickets expire and are reissued |
| Clock skew | Device, AD, and DCs within five minutes |
| GPO change to the zone list | Arrives with the next user policy refresh; gpupdate /force plus sign-out/in to test |
| DC patch level (KB5073381) | Apr 14, 2026: AES-SHA1 default for accounts without an explicit type (manual rollback possible). July 2026: rollback removed |
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-SupportedEncryptionTypes, then klist purge on a pilot device |
Changing the encryption type first; re-enabling RC4 for the whole domain via DefaultDomainSupportedEncTypes (KB5073381: leaves every account exposed) |
| Rollover just run twice | Wait out the ticket lifetime or klist purge test devices |
Running it a third time |
Feature disabled (81007) |
Re-enable through the wizard's Change user sign-in page (Domain Admin per forest) |
Enable-AzureADSSO -Enable $true with no forests configured |
| Kiosk / shared PCs | Zone 4 for those users, per Microsoft | Leaving 81012 noise in your sign-in logs |
Microsoft's notes for any change that touches the account: the Domain Admin credentials go in SAM format (contoso\admin), that admin mustn't be in Protected Users, rolling a forest other than the Entra Connect one needs global catalog ports TCP 3268/3269, and staging servers don't need the rollover.
FAQ
Why is Seamless SSO not working on Windows 10 or 11?
On Windows 10/11 devices that are Microsoft Entra hybrid joined or Entra joined, Seamless SSO isn't used. Microsoft says SSO there runs on the Primary Refresh Token, and SSO from Entra join takes precedence over Seamless SSO on domain-joined devices that are also registered. Run dsregcmd /status: if AzureAdJoined : YES and AzureAdPrt : NO, fix the PRT. Seamless SSO only covers domain-joined devices that aren't on the PRT path.
Why is Seamless SSO not working in Edge or Chrome?
Check three things. The URL https://autologon.microsoftazuread-sso.com must be in the Local intranet zone (value 1), not Trusted sites, with Allow updates to status bar via script enabled. If your organization overrides AuthServerAllowlist or AuthNegotiateDelegateAllowlist, the URL must be in those lists. And the device must reach a DC. Microsoft supports Chromium Edge, including InPrivate and Guest by design (you may need AmbientAuthenticationInPrivateModesEnabled). Legacy Edge and IE with Enhanced Protected Mode don't work.
How do I check if Seamless SSO is enabled?
In the Entra admin center, Entra ID > Entra Connect > Connect Sync shows Seamless single sign-on: Enabled and the enabled forests. On the Entra Connect server, import AzureADSSO.psd1, run New-AzureADSSOAuthenticationContext, then Get-AzureADSSOStatus | ConvertFrom-Json and read the Domains list. In AD, confirm the AZUREADSSOACC computer account exists and is enabled in each forest.
Did the 2026 Kerberos RC4 changes break Seamless SSO?
They can. Microsoft's Seamless SSO page warns that from the July 2026 Windows Server update the AD DS default encryption type moves from RC4 to AES-256, and that RC4-configured setups may see Seamless SSO issues. KB5073381 puts the default change on DCs at April 14, 2026, with the rollback removed in July. Read msDS-SupportedEncryptionTypes on AZUREADSSOACC and the 4769 events for AZUREADSSOACC$. To move to AES, roll over the key with Update-AzureADSSOForest once per forest first, then set the AES encryption type.
How often should I roll over the AZUREADSSOACC Kerberos key, and what if I run it twice?
Microsoft recommends at least every 30 days with Update-AzureADSSOForest, using Domain Admin and Hybrid Identity Administrator credentials, once per forest. Running it more than once per forest stops the feature until users' Kerberos tickets expire and are reissued (typically 10 hours). If that just happened, don't run it again. klist purge lets test devices pick up fresh tickets sooner.
Related posts
- AzureAdPrt: NO in dsregcmd /status (SSO for hybrid joined and Entra joined Windows 10/11)
- Hybrid Azure AD Join Pending (getting devices onto the PRT path)
- Entra Connect Password Hash Sync Not Working (when the typed password itself is rejected)
- AADSTS53003 Blocked by Conditional Access (sign-in succeeded, policy blocked it)
- A Tier-1 helpdesk card for "Outlook keeps asking for my password" (the desktop-client side of the same complaint)
Free checklist
Retiring Seamless SSO prompts usually means moving devices onto hybrid join and PRT-based SSO, and that's the point where teams start requiring compliant or hybrid joined devices in Conditional Access. Before you enforce, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the identity and Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=entra-seamless-sso-not-working
Admin Pack Studio; not affiliated with Microsoft. Steps 1–7 only read: dsregcmd, klist, w32tm /query, nltest, setspn -L, gpresult, registry and event-log reads, Get-AzureADSSOStatus, `Get-AD cmdlets, and GET-only Graph calls. klist purge, key rollover, changing msDS-SupportedEncryptionTypes`, zone-list GPO edits, and disabling/re-enabling Seamless SSO are deliberate changes. Take them in a change window, pilot on one device and one forest, and check current Microsoft Learn for portal labels and dates.*
Top comments (0)