Entra Connect Seamless SSO: Silent Sign-In for Domain-Joined Users

Domain-joined users sign in to Windows in the morning, hit a Microsoft 365 URL in the browser, and… get prompted for their password. Why? They’re already authenticated on this machine; the browser knows it; the cloud should know too. The fix is Seamless SSO — an Entra Connect feature that uses the user’s existing Windows Kerberos ticket to silently authenticate to Entra ID. No password prompt; no extra clicks; one Windows login unlocks every cloud app. This post walks the configuration end-to-end across four phases: firewall, Entra Connect wizard, Group Policy, and testing.

How Seamless SSO actually works

Five steps under the hood:

User signs in to Windows on a domain-joined PC. Windows issues a Kerberos TGT.
User opens a browser, navigates to a Microsoft 365 URL.
Browser checks: is the URL in the Local Intranet zone? (You configure this via GPO — Phase 3.) If yes, the browser will silently send Kerberos tickets.
Browser silently requests a Kerberos service ticket for the cloud’s SSO endpoint, gets one (because the on-prem AD trusts the AZUREADSSOACC computer object in its directory), sends it to the cloud.
Cloud receives the Kerberos ticket, decrypts it using keys it shares with the AZUREADSSOACC object, identifies the user, issues a cloud sign-in token. Browser uses the token. User is signed in.

All transparent. No password ever leaves the device; the user never sees a prompt.

Important: Seamless SSO is an ADD-ON to Password Hash Sync (PHS) or Pass-through Authentication (PTA). It’s not a replacement; you must already have one of those configured. SSO sits on top to silence the password prompt at sign-in time.

Who benefits

Domain-joined PCs on the corporate network. Full silent SSO. The dream scenario.
Domain-joined PCs OFF the corporate network (e.g. WFH, no VPN). Browser can’t reach a DC to get a Kerberos service ticket; falls back to a regular password prompt.
Personal / non-domain-joined devices. No Kerberos ticket; falls back to password prompt. Use Entra Joined or Hybrid Joined for those.
Mobile / iOS / Android. Different SSO path (Authenticator app + conditional access). Not what this post covers.

If most of your workforce is on domain-joined corporate PCs in offices, SSO is high-value. If you’re mostly on personal devices or remote, the benefit is smaller.

Phase 1 — firewall

The Entra Connect server (or any client doing SSO) needs outbound HTTPS to *.msappproxy.net. This is where the cloud retrieves the Kerberos decryption keys for the AZUREADSSOACC computer account.

Open your firewall config.
Add *.msappproxy.net to the outbound allow-list on TCP 443.

Critical: if your firewall does SSL inspection (breaks open encrypted traffic to scan it), you MUST exclude this URL. Inspection breaks the certificate pinning and key retrieval fails.

Phase 2 — enable in Entra Connect

This is a wizard reconfiguration on the existing EC server — you don’t reinstall.

Microsoft Entra Connect wizard main page after launching the Azure AD Connect application from the EC server desktop with the Configure button highlighted as the entry point for changing settings post-install — Step 2.1 — on the EC server, launch the Azure AD Connect (now branded Microsoft Entra Connect) wizard from the desktop. Click **Configure**.

Launch the Azure AD Connect wizard from the EC server desktop. Click Configure.

Tasks page of the EC wizard showing all configuration tasks listed with Change user sign-in selected as the path to enable Seamless SSO — Pick **Change user sign-in**. This is the path that adds Seamless SSO to an existing install — you don’t reinstall, you reconfigure.

From the Tasks page, pick Change user sign-in. Next.

Change user sign-in page with Next button highlighted, advancing to the authentication step — Click Next to advance through the user-sign-in selection page.

Click Next on the Change user sign-in page.

Authentication credentials dialog with Global Administrator credentials being entered to authorize the SSO configuration change — Authenticate with Global Administrator credentials when prompted. The wizard verifies you have permission to change cloud-side settings.

Authenticate with Global Administrator (or Hybrid Identity Admin) credentials when prompted.

User sign-in page with Enable single sign-on checkbox ticked alongside the existing sign-in method (Password Hash Sync) selected — On the User sign-in page, locate the **Enable single sign-on** checkbox and tick it. **Important:** this is an ADD-ON to your existing sign-in method (PHS or PTA). Don’t change the radio buttons; just add the SSO checkbox.

On the User sign-in page: tick Enable single sign-on. Don’t change the radio buttons for the existing sign-in method (PHS or PTA) — SSO is additive. Click Next.

Ready to configure summary with Start the synchronization process when configuration completes ticked and the Configure button highlighted — Ready to configure summary. Tick **Start the synchronization process when configuration completes**. Click Configure.

Ready to Configure summary. Tick Start the synchronization process when configuration completes. Click Configure.

Configuration Complete page with Exit button highlighted, the wizard has finished applying the SSO change — Configuration Complete. The wizard has updated the local EC server, registered the AZUREADSSOACC computer object in AD, and notified the cloud tenant. Click Exit.

Configuration Complete. Click Exit. SSO is now enabled at the EC level.

Verification 1 — cloud check

Microsoft Entra admin centre Connect Sync dashboard now showing Seamless single sign-on with status Enabled — Verification step 1 (cloud) — Entra admin centre > Hybrid management > Microsoft Entra Connect > Connect Sync. Look for Seamless single sign-on status.

Sign into the Entra admin centre. Hybrid management > Microsoft Entra Connect > Connect Sync.

Connect Sync dashboard zoomed in on the Seamless single sign-on row showing the Enabled status and a clickable details link — Status reads **Enabled**. Click the link for details.

Status now shows Seamless single sign-on: Enabled. Click the link for details.

Seamless single sign-on details page showing the local AD domain name listed under Configured domains — Details page shows the configured domain (your local AD domain). If the domain isn’t listed, the registration didn’t complete — re-run the wizard.

Configured domains list should include your local AD domain (e.g. infotechninja.local).

Same details page expanded showing the Kerberos decryption keys metadata and rotation history — Expanded view shows Kerberos decryption keys metadata. The keys auto-rotate; you don’t need to do anything with them, but knowing they exist helps when troubleshooting.

Expanded view shows Kerberos key metadata. Keys rotate automatically; you don’t manage them directly.

Verification 2 — on-prem check

Open ADUC. Navigate to the default Computers container.

Active Directory Users and Computers MMC navigated to the default Computers container with the AZUREADSSOACC computer object visible — Verification step 2 (on-prem) — Active Directory Users and Computers > Computers container. The new AZUREADSSOACC computer object is here.

You should see a new computer object named AZUREADSSOACC.

AZUREADSSOACC computer object Properties dialog showing the description Computer account for Azure AD SSO and a warning to never delete it — **NEVER DELETE THIS OBJECT.** It holds the Kerberos decryption keys that allow the cloud to talk to your on-prem AD via SSO. Deleting it breaks SSO immediately for every user. The description field warns about this; respect it.

This object is critical. NEVER DELETE IT. It holds the Kerberos decryption keys that link your on-prem AD to the cloud SSO endpoint. Deleting it breaks SSO immediately for every user; recovery requires re-running Phase 2.

Phase 3 — GPO to trust the SSO endpoint

For browsers to silently send Kerberos tickets, the SSO URL must be in the Local Intranet zone. Otherwise the browser treats it as Internet and refuses to send credentials.

Create the GPO

Group Policy Management on a DC.
Right-click your domain (or a target OU) > Create a GPO in this domain, and Link it here.
Name: Policy – SSO.
Edit.

Policy 1: Site to Zone Assignment List

Group Policy Management Editor open at User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page with the Site to Zone Assignment List policy highlighted” /><figcaption>Phase 3 GPO setup — navigate to User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone Assignment List.</figcaption></figure>
<p>Navigate: User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page. Double-click <strong>Site to Zone Assignment List</strong>.</p>
<figure class= — Set policy to Enabled. Click Show to expose the URL list.

Site to Zone Assignment List policy Enabled state with the Show button highlighted to expose the URL list — Set policy to Enabled. Click Show to expose the URL list.

Set to Enabled. Click Show.

Show Contents dialog with empty URL list ready for Add to populate it with the SSO endpoint — Show Contents dialog — empty by default.

Empty list. Click Add.

Enter:

Value Name: https://autologon.microsoftazuread-sso.com
Value: 1 (Zone 1 = Local Intranet)

OK confirmation after the URL is added with the policy now enforcing the Intranet zone assignment for the SSO endpoint — OK to apply. The policy is now configured.

OK, OK, OK. Policy applied.

Policy 2: Allow status-bar updates (optional)

Allow updates to status bar via script policy under Internet Control Panel > Security Page > Intranet Zone with Enabled selected” /><figcaption>Optional: enable <strong>Allow updates to status bar via script</strong> in the Intranet Zone properties. Helps older browsers and specific script paths complete the SSO handshake smoothly. Skip if you’re only targeting modern Edge / Chrome.</figcaption></figure>
<p>Same path, dive into Intranet Zone > <strong>Allow updates to status bar via script</strong> > Enabled. Helps older browsers and certain script paths during the SSO handshake. Skip if your fleet is modern Edge / Chrome.</p>
<h3>Link the GPO</h3>
<figure class= — Link the GPO at an appropriate scope. For SSO that should benefit everyone, link at the domain root. For testing first, link at a specific OU like “IT Users”.

GPO Management Console showing the new Policy - SSO GPO with the Link Enabled status and OU scope visible — Link the GPO at an appropriate scope. For SSO that should benefit everyone, link at the domain root. For testing first, link at a specific OU like “IT Users”.

If not already linked, link the new Policy – SSO GPO at an appropriate scope. Domain root = everyone benefits. Specific OU = test first. Since this is User Configuration, the scope follows the USER, not the computer.

Domain link confirmation showing the GPO is linked at the domain root level for fleet-wide application — Confirm the link at the domain root. Since this is a User Configuration policy, scope = users; computer placement doesn’t matter.

Confirm the link.

Domain Controller view of the new GPO in the Group Policy Objects container with all settings configured — DC view of the new Policy – SSO GPO with all the configured settings visible in the Settings tab.

DC view of the new GPO with all settings visible.

Domain Controller validation view showing the GPO has applied to the AZUREADSSOACC computer account context — DC validation showing the GPO is being processed correctly — useful for confirming GPO replication completed before users start hitting the policy.

Validate that GPO is being applied via gpresult or Group Policy Modeling.

Validate end-to-end on EC server

EC server view confirming the SSO feature is enabled and reporting healthy status to the cloud — EC server side — the SSO feature is enabled and reporting healthy status to the cloud. Both ends are now configured and aligned.

Back on the EC server, confirm the SSO feature is healthy and reporting to the cloud.

EC server admin centre showing the sync engine still running normally alongside the new SSO feature — EC sync engine continues to run normally with SSO as an additional feature on top — nothing about the existing PHS or PTA sync changes.

EC sync engine continues running normally; SSO is an additive feature alongside PHS / PTA.

Phase 4 — testing

Test on a domain-joined Windows 10 / 11 client.

Domain-joined Windows 10 client login screen with a domain user signing in via their normal credentials — Phase 4 testing — sign into a domain-joined client (Windows 10 / 11) with a normal domain user account.

Same client desktop after login with the user logged into Windows using their domain account, the prerequisite state for testing browser SSO — After login, the user has a Windows session with a Kerberos TGT. This is the credential that browsers will silently exchange for a cloud token.

Confirm the user has a Kerberos TGT after sign-in. (Optional check: klist at a command prompt.) The Kerberos credential is what the browser will silently exchange.

Test 1: MyApps portal

Microsoft Edge address bar showing https://myapps.microsoft.com/[tenant].onmicrosoft.com being entered, the first SSO test target — Open Edge or Chrome and navigate to `myapps.microsoft.com/[your-tenant].onmicrosoft.com` — replace `[your-tenant]` with your actual tenant name. The tenant-scoped URL hints to Microsoft which directory to look up.

Open Edge or Chrome. Navigate to https://myapps.microsoft.com/[your-tenant].onmicrosoft.com — replace [your-tenant] with your actual tenant name (e.g. infotechninja.onmicrosoft.com). The tenant-scoped URL hints to Microsoft which directory to look up.

Browser brief loading state during the SSO handshake as the Kerberos ticket is exchanged for a cloud token — Brief loading spin as the browser sends the Kerberos ticket and the cloud verifies it. Should complete in <2 seconds.

Browser does a brief loading spin (the Kerberos exchange).

MyApps portal loaded showing the user signed in without ever seeing a password prompt, the green-light visual confirmation — MyApps portal loads. **No password prompt.** If you see one, the GPO didn’t apply or the AZUREADSSOACC object is missing — troubleshoot back to those steps.

MyApps loads. No password prompt. If you saw one, troubleshoot back to GPO application (gpupdate /force then re-test) or AZUREADSSOACC object existence.

MyApps app launcher showing all the apps assigned to the signed-in user, full SSO success — MyApps app launcher with the user’s assigned apps. The user is fully signed in; clicking any app opens it without a fresh prompt.

App launcher with all the user’s assigned apps. Clicking any app opens it without a fresh prompt.

Test 2: portal.office.com

Microsoft Edge navigating to portal.office.com as the second SSO test target — Test 2 — navigate to `portal.office.com`. Same expected behaviour: silent sign-in.

Navigate to portal.office.com. Same expected behaviour.

Office portal loaded with the user signed in to Microsoft 365 without a password prompt — Office portal loads with the user signed in. M365 dashboard accessible.

Office portal loads.

Microsoft 365 dashboard view confirming all SSO services are accessible from the same browser session via the single Kerberos-derived token — M365 dashboard. SSO is working end-to-end — one Kerberos ticket from the on-prem AD log-in unlocks every cloud service the user has access to.

M365 dashboard accessible. SSO is working end-to-end.

Things that bite people

Browser still prompts for password

The most common failure. Causes:

GPO not applied. Run gpupdate /force on the client. Confirm with gpresult /h C:\g.html — the report should show Policy – SSO under Applied GPOs.
Browser cache. Some browsers cache the “is this URL in Intranet zone?” decision. Close all browser windows, reopen.
Wrong URL. The Site to Zone Assignment must be the EXACT URL https://autologon.microsoftazuread-sso.com. No trailing slash. No variations.
Browser doesn’t honour Intranet zone for credentials. Firefox needs additional configuration (about:config > network.negotiate-auth.trusted-uris); Edge / Chrome use Windows’ Internet Settings.

AZUREADSSOACC missing or deleted

SSO breaks for everyone. The wizard re-creates the object if you re-run Phase 2 (Configure > Change user sign-in > untick Enable SSO > Apply > re-run with Enable SSO ticked). This rotates the keys; expect a brief sign-in glitch during rotation.

Off-network users get prompted

This is by design. Seamless SSO requires the browser to reach a DC for a Kerberos service ticket. WFH users without VPN to the corporate network can’t do that; they get the regular password prompt. Solution: combine with Entra Joined / Hybrid Joined for off-network device sign-in, or use VPN.

Multi-domain forests

If your AD forest has multiple domains, you need to enable SSO per domain. The Entra Connect wizard handles this; the AZUREADSSOACC object gets created in each enabled domain.

Kerberos key rotation

Microsoft recommends rotating the AZUREADSSOACC keys every 30 days. There’s a PowerShell module (AzureAdSSO) for this. Forgetting to rotate is technically a security gap but practically harmless — the keys are long-lived and not easily extracted.

SSL inspection breaks key retrieval

Enterprise firewalls that do SSL inspection on outbound traffic break the certificate pinning Microsoft uses for key retrieval. Excluding *.msappproxy.net from inspection is mandatory.

SSO not working for one specific user

The user has a UPN that doesn’t match the verified domain. SSO requires the on-prem UPN to align with the cloud UPN; if a user is still on jdoe@infotechninja.local while the cloud has them as jdoe@infotechninja-tenant.onmicrosoft.com, SSO can’t link them. Fix: do the UPN suffix work from Part 4.

Conditional Access policy blocking SSO

If you have a Conditional Access policy that requires MFA for everything, SSO succeeds but the user still gets prompted for MFA. That’s usually desired (SSO doesn’t bypass MFA), but if you specifically want SSO + no-MFA for trusted networks, configure CA exclusions for the corporate IP range.

What’s next

SSO is one of the more impactful Entra Connect add-ons — user-visible improvement with no extra licensing required. Subsequent posts cover OU filtering changes (post-install reconfiguration of which users sync), in-place upgrades, and migrating EC to a new server. Series in the Hybrid Identity pathway.

Tags: #Entra Connect #Group Policy #Hybrid Identity #Kerberos #Microsoft Entra ID #Single Sign-On