SSO not working through Chrome and ADFS

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. 

Kingston and above

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.

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