I help teams fix systemic engineering issues: processes, architecture, and clarity.
→ See how I work with teams.
Most Hadoop Web UIs rely on SPNEGO (Simple and Protected GSSAPI Negotiation) to authenticate users through Kerberos. When a browser accesses a Kerberos-protected endpoint such as:
http://namenode-host:9870http://rm-host:8088http://oozie-host:11000/oozie
the server expects the browser to negotiate Kerberos credentials automatically. If the browser is not configured correctly, the user will see repeated login prompts or 401: Unauthorized.
Prerequisites
- You must have a valid Kerberos ticket:
kinit your_user@YOUR.REALM - DNS and reverse DNS for the Hadoop services must be correct
- The SPN for the UI must match:
HTTP/hostname@REALM - The browser must allow SPNEGO negotiation for the target domain
Configuring Modern Firefox
Open about:config and set:
- network.negotiate-auth.trusted-uris: domains where SPNEGO is allowed
namenode.company.com, .company.com - network.negotiate-auth.delegation-uris: domains allowed for credential delegation
.company.com - network.negotiate-auth.allow-non-fqdn: set to
falseunless explicitly needed
Firefox on Linux and macOS uses the system Kerberos libraries and respects /etc/krb5.conf.
Configuring Chrome or Microsoft Edge (Modern Policy-Based Setup)
Modern Chrome and Edge no longer rely on command-line flags for SPNEGO. Instead, they use enterprise policies.
Linux or macOS: JSON policy files
Create (or update) a file:
/etc/opt/chrome/policies/managed/kerberos.json
with content:
{
"AuthServerWhitelist": "*.company.com",
"AuthNegotiateDelegateWhitelist": "*.company.com"
}
Windows: Group Policy Editor
Navigate to:
Computer Configuration →
Administrative Templates →
Google →
Google Chrome →
Authentication
Set:
- AuthServerWhitelist =
*.company.com - AuthNegotiateDelegateWhitelist =
*.company.com
Configuring Internet Explorer (Legacy Environments)
- Ensure “Windows Integrated Authentication” is enabled.
- Add the Hadoop UI domain to Local Intranet sites.
- Kerberos will only negotiate automatically for intranet zones.
Common Causes of SPNEGO Failure
- No valid Kerberos ticket (run
kinit) - Browser not configured to trust the domain
- DNS mismatch between hostname and Kerberos principal
- Clock skew between client and KDC
- Service principal missing:
HTTP/hostname@REALM
When SPNEGO Is Not Required
Modern Hadoop deployments often sit behind Apache Knox, identity-aware proxies or SSO systems. These provide access via:
- SAML or OIDC (Okta, Azure AD, Auth0)
- JWT-based authentication
- Token-based API access
In such cases, browser-side Kerberos configuration is unnecessary.
If you need help with distributed systems, backend engineering, or data platforms, check my Services.