Seamless SSO in 2026: the legacy Entra feature your former admin may still hold the key to

If your Entra Connect deployment was set up before about 2020, there is a good chance Seamless SSO (SSSO) is enabled, and a very good chance nobody has rotated its key since the day it was switched on. That combination is the worst kind of legacy shortcut. It is invisible from the inside, advertised on the outside, and still trusted by your cloud tenant for any synced user.

This post is for the CISO whose external attack-surface review just came back with “Seamless SSO enabled” against their tenant. It explains what the flag means, why the risk is structural rather than theoretical, and one angle the existing write-ups skim past: any administrator who has ever had Domain Admin rights on your AD, including former employees and contractors, may already be holding a working key.

What Seamless SSO is

Seamless SSO is a 2016-era convenience feature. It lets a domain-joined Windows machine sign in to Entra-protected applications without prompting the user for a password. It does this by storing a shared Kerberos key in two places: in your on-prem Active Directory under a computer account called AZUREADSSOACC$, and in Microsoft’s cloud.

The sign-in flow looks like this:

%%{init: {'theme':'default','themeVariables':{'actorBkg':'#cce5ff','actorBorder':'#004085','actorTextColor':'#212529','noteBkgColor':'#f8d7da','noteBorderColor':'#dc3545','noteTextColor':'#212529'}}}%%
sequenceDiagram
    autonumber
    actor User as User on domain-joined PC
    participant Entra as Entra sign-in
    participant DC as On-prem DC
    participant Auto as autologon endpoint

    User->>Entra: Sign in to cloud app
    Entra-->>User: 401, provide a Kerberos ticket
    User->>DC: Request TGS for autologon SPN
    DC-->>User: TGS encrypted with AZUREADSSOACC$ key
    User->>Auto: Forward TGS
    Note over DC,Auto: AZUREADSSOACC$ key held on prem AND in cloud<br />Never auto-rotates
    Auto-->>User: Access token issued<br />No MFA, no CA, no device proof

The trust between your AD and your Entra tenant collapses down to a single shared symmetric secret. That secret will mint a token for any synced user without invoking the MFA prompts or Conditional Access policies you have built around every other sign-in path.

What the key unlocks

Forge a Kerberos ticket for a synced user, encrypt it with the AZUREADSSOACC$ key, present it to autologon.microsoftazuread-sso.com from your laptop on the public internet, and Entra returns an OAuth access token for Microsoft Graph, AAD Graph, or Azure Resource Manager. The synced user can be anyone in your directory. If any of those accounts hold the Global Administrator role (an antipattern covered in the next section), that is the obvious target. From a GA token, the path to subscription Owner on every Azure subscription in your tenant is two API calls.

The Kerberos assertion bypasses every other control in the path. No MFA prompt fires because Entra trusts the ticket. Conditional Access policies do not match because the request comes from the attacker’s IP and a forged user agent, not from a managed device on a corporate network. The Entra sign-in log does record the event, but with empty appId and a generic resource ID that makes it indistinguishable from legitimate Seamless SSO use without a targeted KQL hunt that most tenants are not running.

Microsoft’s own technical documentation puts it in the same paragraph that recommends rotating the key every 30 days: “the Kerberos decryption key on a computer account, if leaked, can be used to generate Kerberos tickets for any synchronized user.”

The synced-admin antipattern

Seamless SSO is one of several paths from on-prem AD compromise to tenant compromise. They all rely on the same antipattern: the cloud admin account lives in your on-prem AD.

If a Global Administrator, Privileged Role Administrator, User Administrator, or Application Administrator role assignment sits on an account synced from your on-prem Active Directory, the cloud identity is derived from the on-prem one. Whoever can read or write that on-prem account controls the cloud one: DCSync against the user, a password reset by a tier-1 helpdesk admin, Kerberoasting if the account has an SPN, or an Entra Connect server compromise. The SSSO silver-ticket flow is one abuse path. A compromised Entra Connect server can rotate the AZUREADSSOACC$ key from underneath you, write to the MSOL_* account, or replay PHS-synced password hashes. A compromised AD CS template can mint an authentication certificate for the synced GA. A federated trust takeover via Golden SAML bypasses MFA on the same population. All of them land in the same place because the cloud admin and the on-prem account are the same identity.

Microsoft’s privileged access strategy has been explicit about this for years: privileged roles belong on cloud-only accounts, with phishing-resistant MFA, separate from any day-job productivity identity. Two cloud-only break-glass accounts excluded from all Conditional Access policies, with credentials sealed and stored physically, complete the pattern. None of those accounts should ever appear in your on-prem AD.

One Graph query tells you where you stand: pull every principal assigned to a privileged role definition and filter for onPremisesSyncEnabled eq true. Privileged roles belong on cloud-only identities, so this list should be empty. Anything that comes back is a gap more important to close than any SSSO-specific control, because the other on-prem to cloud pivot paths land in the same place.

Retiring Seamless SSO closes one path; moving privileged roles to cloud-only accounts closes the class.

What the offensive community calls it (and ships)

Red teamers have been shipping dedicated tooling against AZUREADSSOACC$ for years, with operator vocabulary to match.

The standard operator phrase is “silver ticket to the cloud” or “Entra silver ticket”, by analogy with the classic on-prem silver ticket against a service account. TrustedSec’s Pivoting to the Cloud post coined the phrasing back in 2019; the technique has only become more accessible since.

Recent activity from the offensive ecosystem:

Malcrove released SeamlessPass, a tool whose author describes it as “particularly useful in red team scenarios where cleartext passwords are unavailable, but other forms of credentials, such as NTLM hashes or TGTs, are in hand.” Bishop Fox’s 2025 red team tools roundup lists it as current operator kit. The tool’s headline feature is bypassing weak Conditional Access by tampering with the user agent and source IP on the cloud-side token request, since the cloud has no other signals to evaluate.
SpecterOps shipped EntraSSSOHound in 2025, a dedicated BloodHound collector that models AZUREADSSOACC abuse as a first-class graph edge between AD-synced users and Entra resources. Their accompanying blog post (Azure Seamless SSO: When Cookie Theft Doesn’t Cut It, December 2025) is explicit that the appeal is riding a legitimate identity flow rather than stealing session cookies, which gets caught by browser-extension defences.
Dirk-jan Mollema presented Advanced Active Directory to Entra ID lateral movement techniques at Black Hat USA 2025 and DEF CON 33. Beyond the standard silver-ticket flow, his work demonstrated that an attacker who reaches the AZUREADSSOACC account can inject their own attacker-controlled key alongside the legitimate one, producing persistence that survives the defender rotating the key. Rotation alone is not sufficient if the attacker had a window to write back.
Claranet’s red team blog (Cloudy with a chance of persistence, January 2025) puts the persistence framing plainly: “If the AZUREADSSOACC$ machine account doesn’t have the NTLM hash rotated, we will continue to have persistent access to the cloud environment.”
Echelon Risk + Cyber documents the engagement-level pattern: “During an internal penetration test, domain administrator privileges are often achieved and abused to perform DCSync attacks to get NTLM hashes for other high-privileged accounts, including the AZUREADSSOACC$ machine account.” It is a default play, not a specialised one.

The publicly attributable IR record beyond Microsoft’s Storm-0501 writeup is thinner than the red team output, partly because incident response firms tend to keep the precise pivot generic in their reports. But the offensive side is loud about it, and the gap between “red teams routinely abuse this” and “blue teams routinely audit it” is wider than it should be.

The angle that does not get enough attention

Microsoft does not rotate the AZUREADSSOACC$ key automatically. The vendor documentation tells you to rotate it manually every 30 days using the Update-AzureADSSOForest cmdlet. In practice this rotation rarely happens, and the HackTricks Cloud playbook for SSSO abuse states it bluntly: “The password of the user AZUREADSSOACC$ never changes.” That assumption underpins every published abuse technique. The offensive community is comfortable assuming you have not rotated it.

Consider who has had read access to a domain controller over the years your Entra Connect has been running.

Every administrator who has ever held DA, every contractor who was given DA for a project, every service account with backup or replication rights, every backup admin who could restore a domain controller into a sandbox and dump NTDS.dit, every Veeam or Commvault operator who could mount a snapshot, every developer who at some point had read access to an unencrypted system state backup. Any one of those people could have run secretsdump against a domain controller or against a backed-up ntds.dit and walked away with the AZUREADSSOACC$ hash. They did not need to do anything noisy. DCSync rights look like normal replication traffic. Reading a backup file looks like a backup operator doing their job. There is no event that records “someone extracted the Seamless SSO key.” If you have never rotated the key, the hash they pulled in 2021 is the same hash that mints tokens for your tenant today.

The set of people who could be holding a working tenant key for your organisation is the cumulative set of everyone who has ever had Domain Admin or backup-equivalent rights, or read access to a DC backup, going back to the day Entra Connect was first installed. For most enterprises that list is long, and it includes people you have offboarded, fired, or lost touch with entirely.

Nothing in a standard offboarding playbook addresses this. Disabling the user’s AD account does not invalidate the key they extracted. Rotating their personal passwords does not invalidate the key. Removing them from privileged groups does not invalidate the key. Only rotating the AZUREADSSOACC$ key invalidates it.

That rotation has to be performed twice (same hygiene pattern as krbtgt), and the two rotations must be spaced apart so users’ existing Kerberos tickets can expire between them. Read the safety note in the rotation guidance below before you act on this in production.

What modern Entra does instead

The reason Seamless SSO still exists in 2026 is inertia. Microsoft positions it now as the legacy fallback for Windows 7 and 8.1 only. Every modern endpoint has a better path.

%%{init: {'theme':'default','themeVariables':{'actorBkg':'#cce5ff','actorBorder':'#004085','actorTextColor':'#212529','noteBkgColor':'#d4edda','noteBorderColor':'#28a745','noteTextColor':'#212529'}}}%%
sequenceDiagram
    autonumber
    actor User as User on Entra-joined PC with TPM
    participant Entra as Entra sign-in

    User->>Entra: First sign-in
    Entra-->>User: Request password + MFA<br />+ TPM-signed device proof
    User->>Entra: Submit credentials<br />+ TPM-signed nonce
    Note over Entra: Conditional Access<br />evaluated at PRT issuance
    Entra-->>User: PRT bound to this device<br />Session key wrapped to TPM
    User->>Entra: App sign-in: present PRT<br />+ TPM-signed request
    Note over Entra: CA evaluated again<br />at every access-token mint
    Entra-->>User: Access token<br />MFA satisfaction signed into PRT

Windows 10 and 11 endpoints that are Entra-joined or Hybrid-joined use a Primary Refresh Token. The trust anchor is a per-device asymmetric key pair held in the TPM. The private key never leaves the chip. MFA satisfaction is bound into the PRT as a signed claim. Conditional Access evaluates at PRT issuance and at every access-token mint. If the device is wiped or stolen, the blast radius is one device.

macOS uses the Microsoft Enterprise SSO extension. iOS and Android use the Authenticator broker. Hybrid users that still need SSO to on-prem AD resources get it via Entra Cloud Kerberos Trust, which uses a separate, properly managed Kerberos server object. None of these paths use AZUREADSSOACC$.

PRT delivers the same “no prompts after sign-in” experience as Seamless SSO, without the shared-secret failure mode, and it produces the signals Conditional Access needs to function. The population of endpoints in a 2026 fleet that needs Seamless SSO is approximately the population of machines that should already have been decommissioned.

How to confirm if you’re exposed

Two checks tell you most of what you need.

Externally, anyone can run AADInternals’ Invoke-AADIntReconAsOutsider against your tenant domain and see whether Seamless SSO is enabled. No authentication required. External reviewers, threat-intel teams, and attackers all use the same lookup to triage your tenant before investing further effort.

Internally, ask whoever runs your Entra Connect server two questions. Is the AZUREADSSOACC$ computer account present in AD? When was its password last set? You can check this with one line of PowerShell against any DC:

# Returns the password-last-set date for the AZUREADSSOACC$ account
Get-ADComputer AZUREADSSOACC -Properties PasswordLastSet |
    Select-Object Name, PasswordLastSet

If PasswordLastSet is the day Entra Connect was first deployed, then everyone who has ever had the rights to extract that hash since then may still hold a working copy. That date tells you most of what you need to know about your exposure.

What to do

Retire Seamless SSO. Disabling it in Entra Connect is reversible and low-risk if your Windows fleet is already PRT-capable, which any current Windows 10/11 estate should be. Before flipping the switch, pull 30 days of non-interactive Entra sign-in logs and confirm that real users have moved off the SSSO path. The signature in sign-in logs is an empty appId plus a resource ID of 00000002-0000-0000-c000-000000000000. Nathan McNulty’s August 2025 post on finding Seamless SSO usage has the exact KQL.

Once you have confirmed nobody is using it, disable it via Entra Connect or via Disable-AzureADSSOForest, then delete the AZUREADSSOACC$ computer account from AD. Disabling the feature stops new tickets from being issued and removes the cloud-side trust, but leaving the AD object intact means that if anyone re-enables the feature later, the existing key (which historical holders may still have) can be re-uploaded.

If retirement is blocked for legitimate reasons, the interim must include a key rotation, performed twice (same hygiene pattern as krbtgt), and then repeated every 30 days.

Safety note before you run this: Do not perform the two rotations back-to-back. Microsoft’s SSSO FAQ explicitly warns against running Update-AzureADSSOForest more than once per forest before users’ existing Kerberos tickets have expired and reissued. Wait at least the maximum TGT lifetime (10 hours by default, longer if your domain policy says so) between the two rotations, or Seamless SSO will break for users holding cached tickets until those tickets cycle out. The same constraint applies to krbtgt for the same reason.

The first rotation invalidates every historical copy of the key, including the ones held by people you do not know about. That single action does more for your tenant security posture than a year of monitoring rules. Be aware of Mollema’s 2025 finding that an attacker with prior write access to the account can stage a backup key that survives one rotation cycle, so the two-rotation pattern matters, and the rotation should ideally be performed from a tier-0 PAW rather than the everyday Connect host.

In a previous IT role about ten years ago I ran two scheduled Freshservice tickets that auto-opened on a recurring cadence. One carried the step-by-step procedure for rotating the krbtgt hash twice in succession, following the Microsoft-recommended approach using the PowerShell script that was published on TechNet Gallery at the time. The other carried the same procedure for the AZUREADSSOACC$ Kerberos key. Each ticket included the exact PowerShell, the rollback steps, a verification command, and a sign-off field.

Whichever path you take, also tier-0 the Entra Connect server itself. It holds the same blast radius as a domain controller. Same JEA, same PAW, same monitoring. Most environments still treat the Connect host as a “utility server” and that is how attackers reach the key without ever touching a DC.

A note on framing

Seamless SSO works exactly as designed. The design belongs to 2016, when the typical fleet was Windows 7 desktops and the security model predated Conditional Access, modern MFA, and hardware-bound device identity. It survives in your environment because nobody owns the question “should we still be running this?”

If you have it enabled, treat it the same way you would treat a domain controller you forgot you had. The hash is portable, the trust is symmetric, and the people who could already be holding it are not all on your payroll.