Kerberos Login Works in Curl but Not Chrome? Fixing Guide

Many developers and IT professionals encounter a puzzling problem when accessing Kerberos-protected web resources: the authentication works flawlessly with curl, but fails outright when using Google Chrome. This inconsistent behavior can be frustrating, especially in environments where Single Sign-On (SSO) and secure access are essential for productivity and security.

TL;DR: If Kerberos login works in curl but not in Chrome, the issue usually lies in browser configuration, missing ticket forwarding, or cross-origin limitations. Ensure Chrome is enabled for Negotiate authentication, your system Kerberos tickets are valid, and the site is added to the appropriate authentication policies. This guide provides step-by-step solutions to fix common configuration and compatibility issues.

Understanding the Problem

Kerberos is a secure authentication protocol widely adopted in enterprise environments. Tools like curl are often configured for programmatic access and can be easily adjusted to use Kerberos tickets. Browsers, on the other hand, impose additional restrictions and may not automatically send the Kerberos token unless explicitly set up to do so.

That’s why a resource protected by Kerberos might be accessible via a terminal command:

curl --negotiate -u : https://protected.example.com

…but the same URL fails or prompts for password in Chrome. The browser might not be authorized to send Kerberos tokens due to missing configuration or domain policy issues.

Step-By-Step Guide to Fix the Issue

1. Verify Kerberos Authentication is Working

Before diving into Chrome configuration, make sure that Kerberos is functional on the workstation itself.

• Open terminal and run: klist
• Check your Kerberos ticket is valid and not expired
• Access the URL using curl with Kerberos negotiation

If these steps succeed, then Kerberos is correctly set up at the OS level. The problem is likely within Chrome settings.

2. Enable Kerberos Authentication in Google Chrome

Google Chrome (and Chromium-based browsers) can support Kerberos, but only if certain flags and system policies are in place.

Follow these steps:

• In the Chrome address bar, enter: chrome://flags
• Search for Enable Negotiate or related options and ensure they are enabled
• Restart the browser to apply changes

Then, use the Enterprise Policy option to explicitly define URLs for which Kerberos authentication should be applied.

For Windows:

1. Open Group Policy Editor (gpedit.msc)
2. Navigate to Computer Configuration → Administrative Templates → Google → Google Chrome → Authentication
3. Double-click AuthServerWhitelist and add your domain, e.g., *.example.com
4. Set AuthNegotiateDelegateWhitelist similarly if delegation is needed

Alternatively, these can be configured via Windows Registry or JSON if using Linux or Mac:

{
 "AuthServerWhitelist": "*.example.com",
 "AuthNegotiateDelegateWhitelist": "*.example.com"
}

3. Confirm System Time Synchronization

Kerberos requires accurate time synchronization. Even a few minutes of time drift between the client and the server can result in authentication failure.

To ensure system clock consistency:

• Synchronize time with a Domain Controller or NTP server
• Use ntpdate or w32tm /resync depending on your OS

4. Check SPN and DNS Configurations

The browser resolves the SPN (Service Principal Name) based on DNS. If there’s a mismatch between hostname and Kerberos principal, authentication will fail.

• Ensure that the SPN is registered correctly on the server using: setspn -L HOSTNAME
• Avoid accessing the site via IP address as SPNs are tied to FQDNs

5. Use HTTPS and Default Ports

Kerberos authentication usually requires secure connections. Always use HTTPS to avoid challenges in the browser negotiating authentication protocols.

Also, be sure the server is responding on the default ports (like 443 for HTTPS) unless the browser is explicitly told to send credentials to non-default ports via policy.

6. Test in Other Browsers

If Chrome continues to refuse Kerberos authentication even after these configurations, it’s helpful to test in other browsers like Microsoft Edge or Firefox. Note that Firefox uses its own configuration files for SSO.

In Firefox:

about:config
network.negotiate-auth.trusted-uris = example.com

7. Review Browser Console & Network Logs

Open Chrome DevTools (F12), go to the Network tab, and observe the request to the protected resource.

• Check the Response Headers to see if a 401 with WWW-Authenticate: Negotiate is returned
• If a 401 is never upgraded to an SPNEGO token exchange, the browser never attempted Kerberos due to policy or misconfiguration

Recap: Key Elements to Check

• Browser is configured with correct authentication policies
• Kerberos ticket is pre-obtained and valid
• Domain, SPN, and DNS are correctly aligned
• System is synchronized with domain time
• Browser security settings support the authentication flow

Frequently Asked Questions (FAQ)

• Why does curl work but Chrome does not?
  curl directly uses your Kerberos ticket, while Chrome needs explicit configuration and permissions to use Kerberos. By default, Chrome does not send Kerberos tokens to arbitrary domains.
• How do I know if Chrome attempted Kerberos authentication?
  Use DevTools → Network panel, and check for 401 challenge with WWW-Authenticate: Negotiate. If Chrome sends an Authorization header with “Negotiate”, it’s trying Kerberos.
• Do I always have to use Group Policies to fix Chrome?
  Not necessarily. You can configure Chrome startup flags or use JSON policy files for more flexible deployment, especially on Linux and macOS.
• Can Kerberos authentication work on non-Windows OS with Chrome?
  Yes, but it may require configuration of krb5.conf and correct keytab or token availability, plus modifying Chrome’s policy files.
• Is Firefox better for Kerberos than Chrome?
  Firefox is more flexible out of the box and uses a preferences-based approach instead of enterprise policy. It may be a faster way to test SSO authentication.

When properly configured, Chrome can serve as a seamless tool for enterprise web authentication. All it takes is a series of correct policies, system readiness, and synchronizations. Following this guide will help eliminate most Kerberos-related browser authentication problems.