2022-05-13 Kerberos, WWW, updated

Firefox and Brave SPNEGO Setup for Authentication with Kerberos

Updates

2023-05-22

Add Firejail config for sssd-krb5;

2022-11-24

Add Firejail configuration and k5tls requirement;

2022-12-07

Update Firejail information slightly.

2022-12-20

Use /run, not /var/run for Firejail.


Kerberos single sign-on authentication is a Good Thing,A cheer for each head!

including for use with web sites. The mechanism for that is SPNEGO,A Microsoft invention, which IANA quoth, “violates both HTTP semantics (being connection-oriented) and syntax (use of syntax incompatible with the WWW-Authenticate and Authorization header field syntax).”

a.k.a. ‘negotiate-auth’ — specifically the GSSAPI method to do Kerberos. The other one, NTLM, is insecure and should just be avoided even if the client supports it.

SPNEGO is supported by Firefox and Chromium derivatives like Brave (the only non-Firefox graphical browser I use). However, configuration for it is rather poorly-documented, with somewhat misleading instructions in various laces.I was recently looking at this for use with Fedora services after years of not having SPNEGO available locally, and getting confused.

Here’s (all) you need to do, at least assuming you’re using versions for Unixy systems, tested on GNU/Linux.

Kerberos configuration

Obviously you need a krb5.conf appropriate for the site(s) you want to access, specifically any foreign realm setup.

Less obviously, you may need to ensure dns_canonicalize_hostname is true.Debian’s default is false, unlike Red Hat’s.

That allows, for instance, the redirection done by the Fedora copr site (copr.fedoraproject.org) to work; it’s not clear whether it should be necessary or whether the site may be mis-configured as of now.

You need the MIT Kerberos TLS plugin from the krb5-k5tls package on Debian and Fedora-ish systems.

Browser configuration

Generally browsers need to be configured to use SPNEGO.

Firefox

Visit the pseudo-URL about:config and proceed despite the warning if you haven’t done that before. Type, say, negotiate into the search box. That should show, amongst others, network.negotiate-auth.trusted-uris. Select its ‘pen’ edit button and set its value to https:// to make SPNEGO generally available. If you’re using the packaged version of Firefox from a Fedora or RHEL-based system,But not Debian. I haven’t checked OpenSUSE.

that’s already set as the default.Nevertheless there are Red Hat/Fedora instructions to configure for specific domains.

If you really want to restrict it to specific sites, it seems you can specify either actual URLs or domain names, in which ‘.’ acts as a wildcard, e.g. .example.com for sub-domains. For a list of domains, the separator is a comma. You do want only to use https, so it’s presumably dangerous just to specify domains if you can’t be sure they redirect http to https.

If you want to delegate credentials — only to trusted sites! — set network.negotiate-auth.delegation-uris similarly.

Brave (and other Chromium derivatives?)

Start the browser on the command line like

brave-browser --auth-server-whitelist=https://*

to do SPNEGO generally. You can use a comma-separated list of specific URLs if you do want to restrict them for some reason. ‘*’ acts as a possible wildcard in them. Use --auth-negotiate-delegate-whitelist=... if you want to allow delegation to selected sites.

The same works with Chromium, and you can put the option in the CHROMIUM_FLAGS environment variable. There seems to be no such possibility for Brave. I had no luck setting that in the policies directory, as described in Fedora instructions, for either Brave or Chromium.

Non-browser

SPNEGO may be used other than in browsers. On the command line, appropriately-built curl supports it with the --negotiate option, but wget appears not to have support.

Python has a requests_negotiate module and Perl, if you must, has LWP::Authen::Negotiate. Doubtless similar things are available elsewhere. Otherwise there’s curl to call either via a sub-process or a binding for your chosen language.

Sandboxes (like Firejail)

Running the browser in some form of sandbox may stop GSSAPI working. That’s specifically the case with the current (version 0.9.70) browser profiles for Firejail. The Firejail configuration you need depends on your Kerberos credential cache;Potentially controllable per-application with the KRB5CCNAME environment variable.

I’ve tested with the default FILE: ccache location, for which adding the following to  /.config/firejail/firefox-common.local works on Debian (similarly for profiles for other browsers) and, presumably, non-browsers:As reported.

whitelist /etc/krb5.conf
whitelist /tmp/krb5cc_*
whitelist /etc/ssl

A Fedora-ish system needs /etc/pki instead of /etc/ssl. /etc/gss might be needed generally for GSSAPI using other mechanisms SPNEGO doesn’t support. A KCM: ccache with the default socket used by sssd-kcm and the original Heimdal KCM also needs

whitelist /run/.heim_org.h5l.kcm-socket

It was reported that

whitelist /var/lib/sss/pubconf/krb5.include.d/

needs to be added, presumably for use with sssd-krb5 which provides it.

The above are collected into whitelist-gssapi-common.inc for inclusion in profiles of applications supporting GSSAPI.

I don’t know about the KEYRING: ccache,Which anyway has disadvantages — see sssd-kcm(8).

but it seems at least to be blocked by seccomp. Running the program with KRB5_TRACE=/dev/stdout (say) in the environment may provide enlightening messages about GSSAPI failures and indicate what to whitelist if the above doesn’t work in another situation.

Security

The Firefox default to allow SPNEGO generally over HTTPS in Fedora et al was on the advice of experts (FreeIPA maintainers, I think) that it is safe.I don’t know whether it was unsafe in the past, but there is apparently-current advice around that it isn’t.

I guess that assumes that insecure NTLM can’t be chosen. I don’t know what would be required for NTLM to work with a non-MS Windows client, but the Firefox ...ntlm... configuration items indicate that it at least would need to be configured in the browser.

The implications of setting dns_canonicalize_hostname are unclear. Presumably it’s been OK’d by Red Hat experts, but I’ve seen suggestions that it can potentially allow impersonation to enable servers to obtain credentials for a service they don’t host.