Fixing Thunderbird / dovecot Kerberos/GSSAPI login

Usually I’m using a web based mail tool, however for some tasks a full-featured mail client comes in handy. So after quite some idle time I started up my thunderbird today just to find that the GSSAPI/Kerberos authentication fails.

Since the last time I used it I re-installed the mail server, so it is not that obvious whether it is a client or a server problem.

So we’ll need to check both sides – here’s how it went:

Client

First of all: my client is (as usual) an Ubuntu LTS machine (24.04) and this doesn’t come with a native thunderbird app. Instead it uses a snap packaged version:

linux # snap list
<…>
thunderbird 128.10.2esr-1 734 latest/stable canonical✓ –

In my case the configuration for GSSAPI/Kerberos was already in place but during first connection attempt all I got was:

Thunderbird
Ther Kerberos/GSSAPI ticket was not accepted by the IMAP server imap.mydomain.de. Please check that you are logged in to the Kerberos/GSSAPI realm.

So as I did a kinit before, I was quite sure but checked anyway:

linux # klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: marcel@MYDOMAIN.DE

Valid starting       Expires              Service principal
25.05.2025 12:52:43  25.05.2025 22:52:43  krbtgt/MYDOMAIN.DE@MYDOMAIN.DE
	renew until 26.05.2025 12:52:40

Ok, so I got my TGT (Ticket Granting Ticket) however there was no clue about the service ticket required to log into the imap server. So there seems to be something fishy on the client side (usual suspects being something like DNS or the Kerberos client config). However I didn’t recall any relevant changes here. Anyway, after searching around in the web I had two main suspects:

The security framework apparmor and the location of the Kerberos credential cache.

As deactivating apparmor is no longer possible during runtime but requires a reboot I went for the location of the credential cache first. As seen above the location is /tmp/krb5cc_%{euid} by default. But it can be set in /etc/krb5.conf:

linux # vi /etc/krb5.conf
[libdefaults]
<...>
# Add line in this section:
  default_ccache_name = FILE:/run/user/%{euid}/krb5cc
<...>

After that, stop thunderbird execute kdestroy and re-login with kinit. Nothing changed with thunderbird – no service ticket either. So I tried another path option:

linux # vi /etc/krb5.conf
[libdefaults]
<...>
# Add line in this section:
  default_ccache_name = FILE:/home/%{username}/krb5cc
<...>

After repeating the above procedure the error shown by thunderbird stayed the same, however I could now see the imap service ticket appear:

linux # klist
Ticket cache: FILE:/home/marcel/krb5cc
Default principal: marcel@MYDOMAIN.DE

Valid starting       Expires              Service principal
25.05.2025 12:45:41  25.05.2025 22:45:41  krbtgt/MYDOMAIN.DE@MYDOMAIN.DE
	renew until 26.05.2025 12:45:39
25.05.2025 12:45:55  25.05.2025 22:45:41  imap/imap.mydomain.de@MYDOMAIN.DE
	renew until 26.05.2025 12:45:39

One thing I’d like to mention here is, that the above path for the keytab may be a solution for a typical home environment, for larger deployments this solution will cause problems (e.g. if not all user homes are located at /home/<username>). Unfortunately there’s no %{homedir} option available for krb5.conf.

Time to switch to the server side (as I didn’t see something suspicous in the apparmor logs – and I don’t like to reboot Linux machines for nothing 🙂 ).

Server (dovecot)

As a first thing I took a look at /var/log/mail.log:

linux # tail -f /var/log/mail.log
dovecot: imap-login: Disconnected: Connection closed (auth failed, 1 attempts in 2 secs): user=<>, method=GSSAPI, rip=192.168.1.154, lip=192.168.1.10, TLS, session=<xC38GPQ1nrvAqAGa>
dovecot: auth: gssapi(?,192.168.1.154,<y3gTGfQ1rLvAqAGa>): While processing incoming data: No credentials were supplied, or the credentials were unavailable or inaccessible
dovecot: auth: gssapi(?,192.168.1.154,<y3gTGfQ1rLvAqAGa>): While processing incoming data: Key table entry not found

Ok, so “Key table entry not found” looked most suspicious to me. Checked that out (using ktutil from krb5-utils):

linux # ktutil
ktutil:  rkt /etc/dovecot/krb5.keytab
ktutil:  list -e
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2        smtp/mail.linux-ng.de@LINUX-NG.DE (aes256-cts-hmac-sha1-96) 
   2    2        smtp/mail.linux-ng.de@LINUX-NG.DE (aes128-cts-hmac-sha1-96) 
   3    2        smtp/mail.linux-ng.de@LINUX-NG.DE (arcfour-hmac) 
   4    2        imap/imap.linux-ng.de@LINUX-NG.DE (aes256-cts-hmac-sha1-96) 
   5    2        imap/imap.linux-ng.de@LINUX-NG.DE (aes128-cts-hmac-sha1-96) 
   6    2        imap/imap.linux-ng.de@LINUX-NG.DE (arcfour-hmac) 

So the correct tickets are in the keytab – what else could cause this? And that’s where my memory kicked in: While re-installing the server I had copied a bunch of old configs from the backup. After taking a close look, dovecot’s krb5.keytab had some odd numeric owner (“120”, most likely the one of the dovecot system user on the old machine). A simple chown fixed the whole problem:

linux # ls -l /etc/dovecot/krb5.keytab
-rw------- 1 120 root 514 Okt 31 2022 /etc/dovecot/krb5.keytab
linux # chown dovecot /etc/dovecot/krb5.keytab

linux # ls -l /etc/dovecot/krb5.keytab
-rw------- 1 dovecot root 514 Okt 31 2022 /etc/dovecot/krb5.keytab

Once done thunderbird connected as before – problem solved.