Categories
Kerberos Linux SSO

Fun with Kerberos – WIP

Today I changed some things regarding authentication in my local setup and (once again) was curious about enabling more services to user kerberos logins.

And – as always – I ended up in an extensive debug session in order to make (some) things work. To spare some of you some of your precious time I’ll try to write down my findings.

Basics

Kerberos does rely on quite some components in order to work proberly. To get a basic idea about where to look for problems and solutions here’s how kerberos works (basic version):

There are 3 components involved:

  • Kerberos KDC (key distribution center) holding user and service credentials
  • Server (e.g. an apache web server, configured to use kerberos)
  • Client (e.g. chrome browser, configured to use kerberos)

Let’s start with the KDC: The KDC does hold (authentication) information about users and available services. There are several implementations both open source (MIT, Heimdal) or commercial (MS Active Directory). The MS version contains some modifications required for Windows clients, so if you need to support those too (but are an open source guy): maybe have a look at the samba implementation.

The clients needs to be told to try kerberos authentication (descriptions often use the related terms GSSAPI oder SPNEGO for negotiating kerberos between client and server). This configuration often involves a list of hosts or domains for which the client will attempt this negotiation.

The server needs a so called keytab file in order to offer a kerberized service. This is basically an export of its identity from the kdc. Tools to create those keytab usually ship with the KDC (kadmin in the open source world, ktpass in the Windows world but there are other tools too (e.g. msktutil)).

Checklist

  1. DNS correct? (Reverse lookups and CNAMEs)
  2. /etc/krb5.conf correct? (Test with kinit + kvno)
  3. keytab (readable, not too much permissions, only matching entries)

Debugging

While looking for problems involved it’s sometimes easier to use command line tools (instead of graphical ones like browsers) to check basic functionality. So while testing Kerberos for websites I used curl to to that. However you need to make sure that your version of curl supports GSSAPI/SPNEGO/kerberos:

linux > curl -V
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.18
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

If your version of curl is compiled against MIT kerberos libraries you can also use the environment variable KRB5_TRACE to get more information about library calls:

linux > KRB5_TRACE=/dev/stderr curl --negotiate -u :  <... your options and URL here ...>

Errors and solutions

[auth_gssapi:error] [pid 1570222] [client 192.168.1.154:44672] GSS ERROR gss_acquire_cred[_from]() failed to get server creds: [No credentials were supplied, or the credentials were unavailable or inaccessible ( SPNEGO cannot find mechanisms to negotiate)]

Was caused by wrong permissions of apache’s keytab file. Apache reads this file during runtime (after dropping root privileges), so it needs to be readable by the apache user (www-data on Ubuntu systems). Fixed by:

linux > sudo chown www-data:www-data /etc/apache2/http.keytab
linux > sudo chmod 640 /etc/apache2/http.keytab