SSO does not work and users are getting prompted for credentials

Looks like you are expecting SSO to work but users are getting prompted for credentials. Let's do a quick check of the browser settings to ensure you can leverage SSO from browsers. Log into the client machine where the issue is happening.

Internet Options settings

Open Internet Options in the control panel

• Under Advanced, check the state of Enable Integrated Windows Authentication. Ensure that the option is enabled or checked.
• Go to the Security tab
  • Go to Local Intranet > Sites > Advanced, check that the AD FS URL is listed. For example, if your AD FS service FQDN is fs.contoso.com, you must see an entry for fs.contoso.com in the list of websites.
  • Click 'Custom Level' button, under User Authentication section, find 'Automatic logon only in Intranet Zone'. Ensure that it is selected.

Usually group policy is utilized to ensure these settings are set as required on all the domain joined machines.

Log into the AD FS server and open PowerShell under Administrator privileges. Import the AD FS module using Import-Module ADFS

• Validate WindowsIntegratedFallback configuration
• Run Get-ADFSGlobalAuthenticationPolicy in the PowerShell window
• Observe the Boolean value in the WindowsIntegratedFallbackEnabled attribute. If TRUE, then FBA can be an expected behavior. In case the user agent string of the browser is not configured in AD FS, authentication will fall back on forms based authentication in such cases.
• Validate WIASupportedAgents configuration
• Run Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents in the PowerShell window
• Observe the UserAgentString values in the WIASupportedUserAgents attribute of the Properties output
  • Determine if the Browser UserAgent string in question is included in configuration
  • If the UserAgentString is not included in the existing list, you will need to add it
• Add missing UserAgentString to ADFS Properties (ref: Configure browsers to use Windows Integrated Authentication (WIA) with AD FS)
  • First, identify the UserAgentString. You can use http://useragentstring.com/pages/useragentstring.php and locate the appropriate string if needed
  • Set the correct strings
    • $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    • $wiaStrings = $wiaStrings+"NewString" (Example: $wiaStrings = $wiaStrings+"=~Windows\s*NT.*Edge"+"Mozilla/5.0")
    • Set-ADFSProperties -WIASupportedUserAgents $wiaStrings

At this point, the client side settings and AD FS configuration have been confirmed to be correct as required for IWA to work. Next step would be to check if the request coming to AD FS is explicitly requesting a particular authentication mechanism and in turn is suppressing SSO via IWA.

Check for Forms Based Authentication parameters in the SAML Message. Does the incoming request have query string parameters and/or message context controlling authentication method:

1. WS Federation request parameter

   Check the WSIGNIN request for the WAUTH parameter: wauth= urn:oasis:names:tc:SAML:1.0:am:password

2. SAML Protocol request parameter

   Use the following request protocol element for SAML 2.0 requests: samlp:AuthnContextClassRef with value urn:oasis:names:tc:SAML:2.0:ac:classes:Password

If the relying party is Microsoft Online Services (O365 federation trust), forms based authentication may be enforced by the PromptLoginBehavior settings from on the federated domain. Refer to Active Directory Federation Services prompt=login parameter support for more details on how it impacts login with AD FS. If you want to suppress the value being passed from Azure AD in the request, use the below command:

Set-MsolDomainFederationSettings –DomainName <your domain name> -PromptLoginBehavior Disabled

Congratulations! Your SSO issue has been solved.

We are sorry that the problem persists. We'd appreciate it if you can provide feedback with details of your issue so that we can improve the troubleshooting guide.