Dovecot GSSAPI: enable the mechanism and authenticate Thunderbird by ticket #291

New issue

Closed

opened 2026-08-07 22:55:10 +02:00 by dominik.polakovics · 0 comments

dominik.polakovics commented

2026-08-07 22:55:10 +02:00

Owner

BLOCKED BY #290 — do not start. That issue builds Dovecot with GSSAPI. Enabling the mechanism before the binary supports it is a fatal startup error, i.e. mail down. Deliberately left without ready-for-agent so it cannot be auto-claimed; add the label once #290 is merged and its verification steps 1 and 2 pass.

Part of #266. Enable the GSSAPI mechanism in Dovecot and let Thunderbird on nb authenticate to IMAP with the Kerberos ticket from the desktop login.

This is a deliberate experiment with known limits

Recorded so nobody later mistakes it for a general SSO story. All three are accepted:

On-VPN only. A service ticket requires a TGS request to the KDC, which the Hetzner firewall admits only from fw.
One account of five. A TGT is one identity. dominik.polakovics@cloonar.com can use it; office@cloonar.com, dominik@superbros.tv, office@scana11y.com and dominik.polakovics@epicenter.works cannot. A second mailbox would need Dovecot's master-user/authzid mechanism — out of scope.
Thunderbird does not fall back between auth methods. authMethod is one value per account, so an account set to GSSAPI fails outright off-VPN rather than reverting to password.

Because of the third point, do not change the primary account. Use one of the existing secondary Thunderbird profiles (cloonar / work) so everyday mail is untouched.

Scope — `hosts/mail/modules/dovecot.nix`

auth_mechanisms = plain gssapi. Keep plain — the other four accounts, every other tenant, and all off-VPN access depend on it.
auth_krb5_keytab pointing at a keytab under /var/lib/dovecot/, owned by the dovecot user, mode 0400. It sits inside borg's wholesale /var sweep.
Username mapping: the principal dominik.polakovics@CLOONAR.COM lowercases to dominik.polakovics@cloonar.com, exactly the mail attribute that user_filter keys on (dovecot.nix:18). Check Dovecot 2.3's default auth_username_format before setting it — it may already be %Lu, making the mapping free. If you do set it, note that it applies to plain as well; harmless, since those usernames are already lowercase email.

Nothing about the LDAP passdb, auth_bind, or userPassword changes. Kerberos stays additive per ADR-0022.

The service principal — hostname matters

The SPN derives from the host the client connects to. Thunderbird's IMAP host is imap.cloonar.com (hosts/nb/users/dominik.nix:410):

imap/imap.cloonar.com@CLOONAR.COM

Not imap/mail.cloonar.com. SMTP is a different host entirely (mail.cloonar.com:587) and would need its own smtp/ principal plus Postfix SASL changes — out of scope; sending keeps its stored password.

Out of scope

SMTP/submission GSSAPI and any Postfix change
Dovecot master-user / authzid for additional mailboxes
Any change to the LDAP passdb or userPassword
GSSAPI SSH

Human steps

On mail — it is the KDC, so the keytab is generated locally and there is nothing for sops:

kadmin.local -r CLOONAR.COM
  addprinc -randkey imap/imap.cloonar.com
  ktadd -k /var/lib/dovecot/dovecot.keytab imap/imap.cloonar.com
  quit
chown dovecot /var/lib/dovecot/dovecot.keytab && chmod 0400 /var/lib/dovecot/dovecot.keytab

ktadd once only — a second run rotates the key and silently invalidates the keytab.

On nb, in a secondary Thunderbird profile only: set that account's auth method to Kerberos/GSSAPI (authMethod = 5).

Verification

scripts/pre-commit dry-builds mail.

Human, after deploy:

systemctl status dovecot2 clean — a gssapi mechanism Dovecot cannot provide is fatal at startup, so a clean start is itself the first signal.
PLAIN still works. Send and receive on the four password accounts and confirm another tenant can still log in. This is the regression that matters and it should be checked before anything else.
On VPN, from the dominik.polakovics session with a valid TGT, the test profile authenticates with no password prompt.
klist shows a service ticket for imap/imap.cloonar.com@CLOONAR.COM.
Off-VPN, the test-profile account fails to authenticate (expected, per the third limit above) while the password accounts keep working.

Rollback is reverting the commit; the keytab and principal can stay, harmless, or be removed with delprinc.

> **BLOCKED BY #290 — do not start.** That issue builds Dovecot with GSSAPI. Enabling the mechanism before the binary supports it is a fatal startup error, i.e. mail down. Deliberately left without `ready-for-agent` so it cannot be auto-claimed; add the label once #290 is merged and its verification steps 1 and 2 pass. Part of #266. Enable the GSSAPI mechanism in Dovecot and let Thunderbird on `nb` authenticate to IMAP with the Kerberos ticket from the desktop login. ## This is a deliberate experiment with known limits Recorded so nobody later mistakes it for a general SSO story. All three are accepted: - **On-VPN only.** A service ticket requires a TGS request to the KDC, which the Hetzner firewall admits only from `fw`. - **One account of five.** A TGT is one identity. `dominik.polakovics@cloonar.com` can use it; `office@cloonar.com`, `dominik@superbros.tv`, `office@scana11y.com` and `dominik.polakovics@epicenter.works` cannot. A second mailbox would need Dovecot's master-user/authzid mechanism — out of scope. - **Thunderbird does not fall back between auth methods.** `authMethod` is one value per account, so an account set to GSSAPI fails outright off-VPN rather than reverting to password. Because of the third point, **do not change the primary account.** Use one of the existing secondary Thunderbird profiles (`cloonar` / `work`) so everyday mail is untouched. ## Scope — `hosts/mail/modules/dovecot.nix` - `auth_mechanisms = plain gssapi`. **Keep `plain`** — the other four accounts, every other tenant, and all off-VPN access depend on it. - `auth_krb5_keytab` pointing at a keytab under `/var/lib/dovecot/`, owned by the dovecot user, mode 0400. It sits inside borg's wholesale `/var` sweep. - Username mapping: the principal `dominik.polakovics@CLOONAR.COM` lowercases to `dominik.polakovics@cloonar.com`, exactly the `mail` attribute that `user_filter` keys on (`dovecot.nix:18`). **Check Dovecot 2.3's default `auth_username_format` before setting it** — it may already be `%Lu`, making the mapping free. If you do set it, note that it applies to `plain` as well; harmless, since those usernames are already lowercase email. Nothing about the LDAP passdb, `auth_bind`, or `userPassword` changes. Kerberos stays additive per ADR-0022. ## The service principal — hostname matters The SPN derives from the host the client connects to. Thunderbird's IMAP host is **`imap.cloonar.com`** (`hosts/nb/users/dominik.nix:410`): ``` imap/imap.cloonar.com@CLOONAR.COM ``` **Not** `imap/mail.cloonar.com`. SMTP is a different host entirely (`mail.cloonar.com:587`) and would need its own `smtp/` principal plus Postfix SASL changes — out of scope; sending keeps its stored password. ## Out of scope - SMTP/submission GSSAPI and any Postfix change - Dovecot master-user / authzid for additional mailboxes - Any change to the LDAP passdb or `userPassword` - GSSAPI SSH ## Human steps On `mail` — it is the KDC, so the keytab is generated locally and there is nothing for sops: ``` kadmin.local -r CLOONAR.COM addprinc -randkey imap/imap.cloonar.com ktadd -k /var/lib/dovecot/dovecot.keytab imap/imap.cloonar.com quit chown dovecot /var/lib/dovecot/dovecot.keytab && chmod 0400 /var/lib/dovecot/dovecot.keytab ``` `ktadd` **once only** — a second run rotates the key and silently invalidates the keytab. On `nb`, in a secondary Thunderbird profile only: set that account's auth method to Kerberos/GSSAPI (`authMethod = 5`). ## Verification - `scripts/pre-commit` dry-builds `mail`. Human, after deploy: 1. `systemctl status dovecot2` clean — a `gssapi` mechanism Dovecot cannot provide is fatal at startup, so a clean start is itself the first signal. 2. **PLAIN still works.** Send and receive on the four password accounts and confirm another tenant can still log in. This is the regression that matters and it should be checked before anything else. 3. On VPN, from the `dominik.polakovics` session with a valid TGT, the test profile authenticates with no password prompt. 4. `klist` shows a service ticket for `imap/imap.cloonar.com@CLOONAR.COM`. 5. Off-VPN, the test-profile account fails to authenticate (expected, per the third limit above) while the password accounts keep working. Rollback is reverting the commit; the keytab and principal can stay, harmless, or be removed with `delprinc`.

dominik.polakovics added the

ready-for-agent

label

2026-08-07 23:09:21 +02:00

dominik.polakovics referenced this issue from a pull request that will close it,

2026-08-08 01:02:18 +02:00

feat(mail): offer GSSAPI on dovecot IMAP #296

dominik.polakovics closed this issue

2026-08-08 01:08:13 +02:00

dominik.polakovics referenced this issue

2026-08-08 02:31:14 +02:00

ADR-0022: record what the Dovecot GSSAPI work actually cost, and the keytab invariant #297