Chromium Kerberos and NTLM Authentication in Enterprises

This article provides an overview of how the Chromium web browser processes Kerberos and NTLM authentication challenges within enterprise intranet environments. It covers the initial HTTP challenge-response mechanism, the browser's integration with underlying operating system security libraries, the protocol negotiation process, and the specific enterprise policies required to enable seamless Single Sign-On (SSO) while maintaining security boundaries.

The HTTP 401 Challenge-Response Flow

When a user attempts to access a protected intranet resource, the authentication process begins at the HTTP layer.

  1. Initial Request: Chromium sends a standard HTTP GET request to the intranet web server.
  2. Server Challenge: The server rejects the unauthenticated request and returns an HTTP 401 Unauthorized status code. Included in this response is the WWW-Authenticate header, which specifies the supported authentication schemes—typically Negotiate, NTLM, or both.
  3. Browser Selection: Chromium’s network stack parses the WWW-Authenticate headers and selects the most secure protocol available. It always prioritizes Negotiate over standalone NTLM.

SPNEGO and Protocol Negotiation

When the server responds with WWW-Authenticate: Negotiate, Chromium utilizes SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism). SPNEGO acts as a wrapper that allows the browser and the server to agree on a shared authentication protocol.

Under SPNEGO, Chromium always attempts to use Kerberos first. The browser tries to obtain a Kerberos service ticket for the requested server's Service Principal Name (SPN), which is constructed using the server's Fully Qualified Domain Name (FQDN).

Chromium will automatically fall back to NTLM within the SPNEGO wrapper if any of the following occur:

  • The user is accessing the server via an IP address rather than an FQDN.
  • The server's SPN is not registered in Active Directory.
  • The client machine cannot reach the Key Distribution Center (KDC) or Domain Controller.
  • The client machine is not joined to the domain.

Operating System Integration

Chromium does not manage Kerberos tickets or store local OS login passwords directly. Instead, it offloads cryptographic operations and credential retrieval to the host operating system.

  • Windows: Chromium interfaces with the Windows Security Support Provider Interface (SSPI). Through SSPI, Chromium accesses the Local Security Authority Subsystem Service (LSASS) to retrieve the currently logged-in user's Kerberos Ticket Granting Ticket (TGT) or cached NTLM hashes. This allows silent, zero-prompt Single Sign-On.
  • macOS and Linux: On POSIX systems, Chromium relies on the Generic Security Services Application Program Interface (GSSAPI). For Kerberos to function, the host system must have a properly configured krb5.conf file, and the user must have an active TGT initialized (typically via the kinit command or an enterprise identity management tool).
  • Cross-Platform NTLM: While Windows handles NTLM via SSPI, Chromium uses its own built-in, portable NTLM v2 implementation on macOS, Linux, and ChromeOS. Because these platforms do not natively cache Windows NTLM hashes, Chromium must prompt the user via a browser dialog box to enter their username and password when NTLM is triggered.

Executing the Handshakes

Once the protocol and credentials are determined, Chromium completes the authentication exchange.

For Kerberos:

  1. Chromium requests a service ticket from the KDC using the user's TGT.
  2. Chromium encodes the service ticket into Base64 and sends it back to the web server in a new HTTP request under the header Authorization: Negotiate <token>.
  3. The server validates the ticket and grants access, returning an HTTP 200 OK.

For NTLM:

  1. Type 1 (Negotiate): Chromium sends an Authorization header containing a Type 1 message, establishing supported features (such as NTLMv2 and encryption).
  2. Type 2 (Challenge): The server responds with another HTTP 401 containing a Type 2 message, which includes a cryptographic nonce (challenge).
  3. Type 3 (Authenticate): Chromium uses the user's NTLM hash to encrypt the server's nonce. It sends this result back in a Type 3 message. The server validates the hash response and returns an HTTP 200 OK. Keep-alive connections are strictly maintained during this three-way handshake, as NTLM authenticates the underlying TCP connection rather than individual HTTP requests.

Enterprise Policies and Security Restrictions

To prevent credential theft and NTLM reflection attacks, Chromium enforces strict rules on when it will silently hand over OS credentials. By default, Chromium will not perform automatic authentication unless the target server is explicitly trusted.

Enterprise administrators control this behavior using specific Chromium policies:

  • AuthServerAllowlist: This policy defines which URLs or domain patterns are permitted to receive integrated authentication. If a server requests Negotiate or NTLM and is not on this list (or in the Local Intranet zone on Windows), Chromium will disable silent SSO and force a manual login prompt.
  • AuthNegotiateDelegateAllowlist: If a backend intranet web server needs to impersonate the user to access a secondary resource (such as a SQL database) via Kerberos Constrained Delegation, the server must be listed in this policy. Otherwise, Chromium strips the delegation flag from the Kerberos ticket.
  • AuthSchemes: Administrators can use this policy to explicitly disable NTLM (ntlm) entirely, forcing the browser to only use negotiate (though NTLM must also be disabled at the OS or Active Directory level to prevent SPNEGO fallback).
  • NtlmV2Enabled: On non-Windows platforms using Chromium's internal NTLM implementation, this policy ensures that legacy, insecure NTLMv1 challenges are rejected.