Google Chrome

Configuring Chrome to work with Kerberos on Windows can be done in more than one way.
By default, Chrome on Windows uses the same registry settings as Edge/Internet Explorer to determine if sending Kerberos tickets to a site is allowed.
This means that you usually don't need to configure Chrome explicitly if the site has been added to the Local Intranet Zone list according to the Edge/Internet explorer guide.

Alternatively, Chrome can also be configured to use its own list of URLs that it will respond with Kerberos ticket to.
AuthServerAllowlist (earlier called AuthServerWhitelist) is deployed through Active Directory Group Policy and will override Internet Explorer settings for Chrome. A guide from Google describes how to configure this here: https://support.google.com/chrome/a/answer/9023663?hl=en&visit_id=638082609671794139-3380636327&ref_topic=7649835&rd=1 . See especially the Step 2. Set policies in this guide. You will according to this guide set up similar Group Policies for Google Chrome as described in the Edge/Internet explorer guide:

Chrome policy

To check whether your Chrome uses the AuthServerAllowlist, take a look at URL: chrome://policy

If Chrome policies state No policies set, Chrome on Windows will instead use Local Intranet Zone. Your site must be added to that list for Chrome to work with Kerberos on Windows. Chrome on other operating systems requires policies to work with Kerberos.

When defined, Chrome policies override the Windows Local Intranet Zone List.
Refer to https://www.chromium.org/developers/design-documents/http-authentication and https://www.chromium.org/administrators/policy-list-3#HTTPAuthentication for details.

On OS X you may run commands below with your domain names in a terminal window to configure Chrome. Restart Chrome afterward. The first command removes the deprecated name AuthServerWhitelistthat was replaced by AuthServerAllowlistin 2020:
defaults delete com.google.Chrome AuthServerWhitelist
defaults write com.google.Chrome AuthServerAllowlist ".example.com,.otherexample.com"

Policies that may affect how Chrome and Kerberos works:

AuthSchemes: Specifies which HTTP authentication schemes are supported by Google Chrome. Possible values are 'basic', 'digest', 'ntlm' and 'negotiate'. Kerberos requires 'negotiate.' If this policy is left unset, all four schemes will be available.
AuthServerAllowlist: Specifies which servers should be whitelisted for integrated authentication. Integrated authentication is only enabled when Google Chrome receives an authentication challenge from a proxy or from a server that is in this permitted list, e.g., *.example.com or serversjira.example.com,confluence.example.com must be added. Separate multiple server names with commas. When unset, Chrome will try to detect if a server is on the Intranet, and only then will it respond to IWA requests. IWA requests from non-intranet servers will be ignored by Chrome.

When you believe you have configured the correct group policy to have Kerberos working and also have followed guide to set up Kerberos support in Kantega SSO, please navigate to Kerberos test page verify all is set up correctly. You will on the Kerberos test page get help on what may be remaining to have your setup work:

Using short-form URLs

Note that when accessing the application using the short format URL (http://issues), browsers will still look for an SPN in the FQDN format (issues.example.com)

By default, Internet Explorer treats short format URLs and sites as they were in Local Intranet Zone with the "Include all local (intranet) sites not listed in other zones" checked. In this case, sites do not have to be added to IE Local Intranet Zone for Kerberos to work with Internet Explorer.

Chrome will need to have the site added to AuthServerAllowList to work with Kerberos.