SPNEGO authentication

Sergei Tikhomirov

SPNEGO (Simple and Protected GSS API Negotiation Mechanism) is a mechanism that is used to negotiate the security technology to be used for a safe connection. In particular, it is used when neither client nor server knows what security protocols the other end supports. SPNEGO uses a protocol to find out what GSS API mechanisms are available, selects one, and delegates all the security operations to it.

When a server receives a request from a browser, it can ask the latter to use SPNEGO for authentication. This protocol performs a Kerberos authentication over HTTP. In detail, the process goes as follows:

  1. A server returns the 401 Unauthorized code to a request with the WWW-Authorization: Negotiate header.

  2. A browser communicates with a TGS to get a ticket.

  3. An obtained ticket is converted to a base64 SPNEGO token and sent to a server with an authentication request.

  4. A token is unpacked and a server authenticates a ticket.

Browser configuration

Some browsers need additional tweaking for the SPNEGO Kerberos authentication. You can find instructions for the most popular browsers below.

  • Mozilla Firefox

  • Google Chrome

  1. In the search bar, enter the about:config command and run it.

  2. Change the following parameters with the according values:

    • network.negotiate-auth.trusted-uris — your Kerberos-protected domain (e.g. .ru-central1.internal).

    • network.automatic-ntlm-auth.trusted-uris — your Kerberos-protected domain (e.g. .ru-central1.internal).

    • network.auth.use-sspi — false.

  3. Reopen the browser and continue to a protected resource.

You need to add several browser policies in order for the authentication to function correctly.

  • In Windows, open registry editor and go to HKEY_LOCAL_MACHINE → SOFTWARE → Google → Chrome. To add these policies, right click the empty space, select New → String value and enter the policy name and value for each policy:

    • AuthSchemes — digest,ntlm,negotiate.

    • AuthServerAllowlist — <domain>. If this setting is skipped, Google Chrome will check if the server is in intranet. If it is, the authentication will continue, and if it’s not — Google Chrome will ignore the authentication requests from that server.

    • AuthNegotiateDelegateAllowlist — <domain>. If this setting is skipped, Google Chrome will not pass user credentials to servers even if they are in intranet.

      In the descriptions above, <domain> is your Kerberos-protected domain (e.g. .ru-central1.internal).

      Note that the Windows host must be within the domain, while for Linux — it’s not a necessity.

  • In Linux, go to /etc/opt/chrome/policies/managed (create missing folders if any) and create a policy file (e.g. test_policy.json) with the following contents:

    {
  "AuthServerAllowlist": "<domain>",
  "AuthNegotiateDelegateAllowlist": "<domain>",
  "AuthSchemes": "digest,ntlm,negotiate"
}

You can check if the policies are added correctly by running the chrome://policy command in the search bar.

Google Chrome policies for SPNEGO
Google Chrome policies for SPNEGO
Google Chrome policies for SPNEGO
Google Chrome policies for SPNEGO

If the tweaking is correct, you will be able to authenticate with a Kerberos ticket that was issued on your system. Otherwise, you will keep getting the 401 Unauthorized error.

Supported services

The following ADH services support the authentication on web UIs with SPNEGO:

  • Flink

  • HDFS

  • Hive

  • HUE

  • Impala

  • Kyuubi

  • Spark/Spark 3

  • SSM

  • YARN

To activate the SPNEGO mechanism for them (unless a separate instruction is provided), you need to enable the Authentication on WEB UIs flag during the Kerberos activation.

The Authentication on WEB UIs parameter
The "Authentication on WEB UIs" parameter
Found a mistake? Seleсt text and press Ctrl+Enter to report it