There are some great resources on this topic (link, link2) and it is supposed to be an easy task – but why not overcomplicate it? So I thought I share my experiences.
TL;DR
– Seamless SSO is a nice convenience feature, with some drawbacks. It is easy and recommended to disable it, even if it causes minimal inconvenience
– The documentation was not clear enough for me, so I tried to track the SSO flow from the beginning
– I tried to cover some scenarios (browsers) to prepare the transition to PRT based SSO – but keep in mind, that domain-only clients will not benefit from Seamless SSO (which doesn’t necessarily mean that users will be overwhelmed by authentication prompts)
– After disabling the feature, some extra steps may be needed for a complete removal (GPO, monitoring, documentation)
Seamless SSO on a web browser
The documentation (link) provides a detailed explanation on the behaviour, but it does not make easy to connect the dots – so I share my interpretation:
User tries to access a web application, gets redirected to the Entra sign-in page
After entering the username, the GetCredentialType endpoint (https://login.microsoftonline.com/common/GetCredentialType?mkt=en-US) returns the EstsProperties which contains a “DesktopSsoEnabled” node with “true” value:
This triggers a connection to the tenant specific autologon URL (SSOprobe): https://autologon.microsoftazuread-sso.com/<upnsuffix>/winauth/ssoprobe?<parameters>
The endpoint returns a 401 Unauthorized response, challenging the browser to provide a Kerberos ticket. The browser needs to be configured to trust this endpoint enough to provide a Kerberos ticket (eg. by adding the site to the intranet zone)
The client will attempt to find the SPN for HTTP/autologon.microsoftazuread-sso.com in AD. This SPN is registered to the AZUREADSSOACC computer account:
The client requests the ticket for this service, sends this ticket to the ssoprobe. Entra verifies the ticket. This results in an HTTP 200 OK request to the ssoprobe endpoint:
The next step is a request to the sso endpoint which returns the dssoToken: https://autologon.microsoftazuread-sso.com/<upnsuffix>/winauth/sso?<parameters>
This is followed by a POST to the https://login.microsoftonline.com/common/instrumentation/dssostatus endpoint, which returns some additional cookies (fpc) used during authentication:
Next the “actual login” is performed on the https://login.microsoftonline.com/common/login endpoint, using the dssoToken and the cookies received:
From an admin standpoint, at this stage it’s like the user entered the password. If additional controls are in place (like MFA requirement or other Conditional Access policies), these are evaluated and access is granted (or not).
The flow described above assumes that the user is not signed into Edge and no other settings are in place that automates that sign-in process.
Seamless SSO on a client application
The same logic applies in this scenario: the docs are a bit shady, so I try to understand what is happening in the background. Fiddler + OneDrive login is used here:
The user is not signed in, “the native application retrieves the username of the user from the device’s Windows session” – this one is very interesting. First I thought that it uses the UserPrincipalName and sends the UPN suffix (see next step), but this is may not true. As it is stated in another doc:
Sign-in username can be either the on-premises default username (userPrincipalName) or another attribute configured in Microsoft Entra Connect (Alternate ID). Both use cases work because Seamless SSO uses the securityIdentifier claim in the Kerberos ticket to look up the corresponding user object in Microsoft Entra ID.
My guess is that if the UPN suffix corresponds to a verified custom domain, then the common endpoint is queried (see below) – if Alternate_id is used, then the client is configured with a DomainHint which determines the tenant to be used.
The client issues an HTTP GET to the following endpoint (no authentication):
https://login.microsoftonline.com/common/UserRealm/?user=f12.hu&api-version=1.0&checkForMicrosoftAccount=false&fallback_domain=ftwelvehu.onmicrosoft.comThis request in itself does not return the MEX endpoint, but inserting the following header to the request does the job:
"tb-aad-env-id" = "10.0.26100.5074"The result:
It even works with the on-premises domain name – just replace the URL’s ?user=<domain> with ?user=<on-premises domain> – the only difference here is that the domain will be replaced by the fallback domain*, eg.:
{"ver":"1.0","account_type":"Federated","domain_name":"ftwelvehu.onmicrosoft.com","federation_protocol":"WSTrust","federation_metadata_url":"https://autologon.microsoftazuread-sso.com/ftwelvehu.onmicrosoft.com/winauth/trust/mex?client-request-id=9c122fb5-263b-46af-a2fc-508ffab7bf3c","cloud_instance_name
":"microsoftonline.com","cloud_audience_urn":"urn:federation:MicrosoftOnline"}*in case of the on-premises domain, the fallback_domain needs to be specified in the URL. I didn’t find any trace of how this information is fetched, but it is an easy task so I didn’t investigate that part (any verified domain’s fallback domain can be queried).
So now we have the MEX endpoint, the next step is a request to the MEX endpoint which returns a lot of information – I guess this is the step described in the documentation as follows:
The app then queries the WS-Trust MEX endpoint to see if integrated authentication endpoint is available.
Integrated authentication endpoint is available, so a Kerberos challenge is issued (HTTP 401 at first):
Since the autologon URL is added to the intranet zone list, the client requests a ticket for HTTP/autologon.microsoftazuread-sso.com, then this ticket is passed to Entra and a SAML token (including the DesktopSsoToken) is returned (POST to https://autologon.microsoftazuread-sso.com/f12.hu/winauth/trust/2005/windowstransport?client-request-id=<id>) :
The SAML token is then presented to the OAuth2 endpoint and we have a refresh token, access token and id token.
Now that I’ve come to understand how the feature works, let’s get rid of it 🙃
Prepairing for the non-DSSO world
On domain joined devices you don’t have a PRT (Primary Refresh Token), so you have to either Hybrid Join the computers affected or accept that SSO will not work here (users will be prompted for authentication when accessing cloud resources). Microsoft is a bit more professional on this:
Seamless SSO is an opportunistic feature. If it fails for any reason, the user sign-in experience goes back to its regular behavior – that is, the user needs to enter their password on the sign-in page.
DesktopSSO login does not provide information on the device identity in Entra. This makes sense on a domain-only device, but may cause some headaches on Hybrid Joined devices
Example: if you require a compliant device to access a resource, but DSSO is used (hence no device identity is provided) the user will get blocked.
To overcome this issue, the client browsers need to be instructed to use the PRT (Primary Refresh Token) for the authentication process. Microsoft provided some guidance here.
Let’s start with 3rd party browsers:
– Chrome: enable CloudAPAuth as described in the previous link (same logic applies to other Chromium based browsers)
– Firefox: the Microsoft guidance says “Allow Windows single sign-on for Microsoft, work, and school accounts”. If you use group policy to configure the setting, import the Firefox ADMX and look for Windows SSO setting under Mozilla/Firefox
Edge: the docs state that Edge 85+ requires the user to be signed in to the browser to properly pass device identity:
This is the official and supported scenario – however, since the new Edge is Chromium based, you can also enable CloudAPAuth. Enforcing signing into Edge combined with implicit sign-in may probably fit for standard scenarios, but in my case it just resulted in more questions than answers (overcomplicating, as usual 🙃).
So as an alternative, I used the following setting:
Either setting will make the browser skip the DSSO flow and use the signed-in user’s credentials.
Unfortunately, I don’t have experience with native clients. Microsoft apps automatically use the user’s cloud identity on a hybrid joined device (or at least they transition when disabling DSSO)
Detecting DSSO usage
This topic was greatly covered by Nathan McNulty and Daniel Bradley. One thing to overcomplicate this topic: if you happen to have Defender for Endpoint on your devices, you can use the DeviceNetworkEvents table to find which process is connecting to autologon.microsoftazuread-sso.com
DeviceNetworkEvents
| where RemoteUrl == @"autologon.microsoftazuread-sso.com"
| project TimeGenerated,DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, InitiatingProcessParentFileName, DeviceId, InitiatingProcessCommandLine
| sort by TimeGenerated desc This will return an enormous amount of events that I wasn’t able to process – but revealed some funny circumstances (like computer accounts that didn’t successfully finish the hybrid join process; or that Edge attempts to reach this URL when running as a network service [probably some update mechanism])
Most of these events will disappear when DSSO is “deactivated”.
Disabling DSSO
Microsoft provides a detailed guidance on disabling the feature. I opted for the Powershell approach:
The state can be verified under the Connect Sync menu
At this point, the configuration is not removed so it can be re-enabled if needed. On the client side, DSSO will still be attempted, but the SSO endpoint will not return any data (no dssotoken is received):
This means that users/applications will transition to other modern authentication flows (which also means that DSSO will be phased out, will not be tried again). I think 1-2 weeks is enough to wait for user feedback. If everything is okay, the feature can be completely removed:
Disable-AzureADSSOForest -DomainFqdn <on-premises domain>
Then finally, the AZUREADSSOACC computer account can be deleted from AD.
Some additional cleanup
Entra SSSO does not work out of the box – the autologon URLs need to be added to the intranet zone settings (docs). This may be implemented via GPO or Intune, but my point is that for a complete removal, you may want to remove these settings as well.
If you set up some automation to remind you for the Kerberos decryption key rotation (eg. by monitoring the AZUREADSSOACC computer account’s password age), don’t forget to remove it.
And update your documentation 😉