Chapter 16a Clients, Groupware & CLI Admin: #pIdentity

Kerberos SSO: sign-in without password for domain PCs, Outlook and mail apps

With Kerberos, Windows PCs on the company network sign in without a password prompt: webmail and admin through SPNEGO ("Sign in with Windows"), Outlook through MAPI, EWS, ActiveSync and Autodiscover with Negotiate, Thunderbird and other mail apps through IMAP, SMTP, POP3 and ManageSieve with SASL GSSAPI. nextxch validates the tickets itself with an uploaded keytab; this works on Linux and on Windows servers that are not domain members. When nextxch runs on a domain member, the machine account can be used instead of a keytab. NTLM is deliberately not supported.

Operational Tip & Architecture Note

The host name in the SPNs must be exactly the name clients use (e.g. mail.example.com) and resolve through an A record. After every password change of the service account create and upload the keytab again; "Check Kerberos" shows the key version and encryption of every SPN.

Active Directory: service account, SPNs and keytab

PowerShell as domain admin. Run ktpass once for the first SPN; all further SPNs of the same account share the key and only need setspn.

Reference / Configuration

# 1. Service account (password never expires, AES only)
New-ADUser -Name svc-nextxch -AccountPassword (Read-Host -AsSecureString) `
  -Enabled $true -PasswordNeverExpires $true -KerberosEncryptionType AES256

# 2. Register the service principals (host name = name clients use)
setspn -S HTTP/mail.example.com  CORP\svc-nextxch
setspn -S imap/mail.example.com  CORP\svc-nextxch
setspn -S smtp/mail.example.com  CORP\svc-nextxch
setspn -S pop/mail.example.com   CORP\svc-nextxch
setspn -S sieve/mail.example.com CORP\svc-nextxch

# 3. Create the keytab (resets the account password)
ktpass -princ HTTP/mail.example.com@CORP.LOCAL -mapuser CORP\svc-nextxch `
  -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass * -out nextxch.keytab

# 4. nextxch Admin > Identity sources > Kerberos
#    realm CORP.LOCAL, SPNs as above, upload the keytab, "Check Kerberos"

# Machine account mode (nextxch on domain member MAILSRV, no keytab):
setspn -S HTTP/mail.example.com CORP\MAILSRV$
setspn -S imap/mail.example.com CORP\MAILSRV$

MIT Kerberos, Heimdal and FreeIPA

Create the principals and export their keys into a keytab; FreeIPA: ipa service-add and ipa-getkeytab.

Reference / Configuration

# MIT / Heimdal
kadmin -q "addprinc -randkey HTTP/mail.firma.de@FIRMA.LOCAL"
kadmin -q "addprinc -randkey imap/mail.firma.de@FIRMA.LOCAL"
kadmin -q "addprinc -randkey smtp/mail.firma.de@FIRMA.LOCAL"
kadmin -q "ktadd -k /tmp/nextxch.keytab HTTP/mail.firma.de imap/mail.firma.de smtp/mail.firma.de"

# FreeIPA
ipa service-add HTTP/mail.firma.de
ipa service-add imap/mail.firma.de
ipa-getkeytab -s ipa.firma.local -p HTTP/mail.firma.de -k /tmp/nextxch.keytab
ipa-getkeytab -s ipa.firma.local -p imap/mail.firma.de -k /tmp/nextxch.keytab

# Test vom Client:
kinit anna && curl --negotiate -u : https://mail.firma.de/api/auth/kerberos

Manual test with a real AD

The automated tests validate tickets from generated keytabs. With a real domain controller also test like this:

Reference / Configuration

# Auf einem Domänen-PC als normaler Benutzer:
klist purge
Invoke-WebRequest https://mail.firma.de/api/auth/kerberos -UseDefaultCredentials
klist                     # zeigt Ticket für HTTP/mail.firma.de
# Erwartet: 200 {"ok":true,"email":"anna@firma.de"}

# IMAP mit GSSAPI (Linux-Client in der Domäne):
kinit anna@FIRMA.LOCAL
curl -v --login-options AUTH=GSSAPI --negotiate -u : imaps://mail.firma.de/INBOX

Settings, Default Values & Best Practices

Setting / Location	Description	Default Value	Production Best Practice
`Keytab`	MIT format as written by ktpass, ktutil and kadmin. Stored encrypted with the server keyring and never shown again; the admin page only lists principal, kvno and encryption.	`Keytab-Modus`	Use AES256. RC4 keys work, but "Check Kerberos" warns about them.
`Benutzerzuordnung`	The Kerberos principal (anna@CORP.LOCAL) is mapped through the identity source: userPrincipalName, sAMAccountName or mail address. Only the configured realm (and further allowed realms) is accepted.	`Realm Pflicht`	Set up and sync the AD identity source first, then switch on Kerberos.
`Browser`	Browsers send Kerberos tickets only to trusted intranet addresses. Without that, the normal sign-in page appears.	`Automatischer Versuch aus`	GPO "Site to Zone Assignment List": https://mail.example.com = 1 (intranet). Chrome/Edge: AuthServerAllowlist, Firefox: network.negotiate-auth.trusted-uris.
`Outlook und ActiveSync`	MAPI, EWS, Autodiscover and ActiveSync offer "WWW-Authenticate: Negotiate" in addition to Basic. Outlook on domain PCs then uses the signed-in user's ticket.	`Negotiate + Basic`	In Outlook under account settings > more settings > security switch off "Always prompt for logon credentials".
`Mail-Programme (GSSAPI)`	IMAP, SMTP submission, POP3 and ManageSieve offer SASL GSSAPI (with mutual authentication, RFC 4752). Thunderbird: account settings > server > authentication "Kerberos / GSSAPI".	`imap/, smtp/, pop/, sieve/`	On Linux clients run kinit first; klist then shows the ticket for imap/mail.example.com.