Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
SSO not working through Chrome and ADFS - Support and Troubleshooting
  • >
  • Knowledge Base
  • >
  • Support and Troubleshooting (Knowledge Base)
  • >
  • SSO not working through Chrome and ADFS
KB0759249

SSO not working through Chrome and ADFS


53259 Views Last updated : Apr 7, 2024 public Copy Permalink English (Original)
  • English (Original)
  • Japanese
KB Summary by Now Assist

Issue

If you have SSO setup through ADFS server and having issues with Google Chrome passing the authentication all the way through. The redirect happens when you to navigate to one of our instances (ex: https://instance.service-now.com) and will land on the ADFS server login page. When using the same URL through IE, SSO takes over with no issues and logs a user in completely. 

Release

Kingston and above

Cause

By default, Windows Integrated Authentication (WIA) is enabled in Active Directory Federation Services (AD FS) in Windows Server 2012 R2 for authentication requests that occur within the organization’s internal network (intranet) for any application that uses a browser for its authentication. For example, these can be browser-based applications that use WS-Federation or SAML protocols and rich applications that use the OAuth protocol. WIA provides end users with seamless logon to the applications without having to manually entering their credentials. However, some devices and browsers are not capable of supporting WIA and as a result authentication requests from these devices fail. Also, the experience on certain browsers that negotiate to NTLM is not desirable. The recommended approach is to fallback to forms-based authentication for such devices and browsers.

Resolution

AD FS in Windows Server 2016 and Windows Server 2012 R2 provides the administrators with the ability to configure the list of user agents that support the fallback to forms-based authentication. The fallback is made possible by two configurations:

  • The WIASupportedUserAgentStrings property of the Set-ADFSProperties commandlet
  • The WindowsIntegratedFallbackEnabled property of the Set-AdfsGlobalAuthenticationPolicy commandlet

The WIASupportedUserAgentStrings defines the user agents which support WIA. AD FS analyzes the user agent string when performing logins in a browser or browser control. If the component of the user agent string does not match any of the components of the user agent strings that are configured in WIASupportedUserAgentStrings property, AD FS will fall back to providing forms-based authentication, provided that the WindowsIntegratedFallbackEnabled flag is set to True.

By default, a new AD FS installation has a set of user agent string matches created. However, these may be out of date based on changes to browsers and devices. Particularly, Windows devices have similar user agent strings with minor variations in the tokens. The following Windows PowerShell example provides the best guidance for the current set of devices that are on the market today that support seamless WIA:

 

 

 

Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents) + "Mozilla/5.0 (Windows NT)"


You can add Chrome or other user agents to the AD FS configuration that supports WIA. This enables seamless logon to applications without having to manually enter credentials when you access resources protected by AD FS. Follow the steps below to enable WIA on Chrome:

In AD FS configuration, add a user agent string for Chrome on Windows-based platforms:

Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents) + "Mozilla/5.0 (Windows NT")

And similarly for Chrome on Apple macOS, add the following user agent string to the AD FS configuration:

Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents) + "Mozilla/5.0 (Macintosh; Intel Mac OS X")

Confirm that the user agent string for Chrome is now set in the AD FS properties:

Get-AdfsProperties | Select -ExpandProperty WIASupportedUserAgents

configure auth

 Note:

As new browsers and devices are released, it is recommended that you reconcile the capabilities of those user agents and update the AD FS configuration accordingly to optimize the user’s authentication experience when using said browser and devices. More specifically, it is recommended that you re-evaluate the WIASupportedUserAgents setting in AD FS when adding a new device or browser type to your support matrix for WIA.


The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.