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

Kerberos-SSO: Anmeldung ohne Passwort für Domänen-PCs, Outlook und Mail-Programme

Mit Kerberos melden sich Windows-PCs im Firmennetz ohne Passwortabfrage an: Webmail und Admin per SPNEGO ("Mit Windows-Anmeldung anmelden"), Outlook über MAPI, EWS, ActiveSync und Autodiscover per Negotiate, Thunderbird und andere Mail-Programme über IMAP, SMTP, POP3 und ManageSieve per SASL GSSAPI. nextxch prüft die Tickets selbst mit einer hochgeladenen Keytab; das funktioniert unter Linux und auf Windows-Servern, die nicht in der Domäne sind. Läuft nextxch auf einem Domänenmitglied, kann statt der Keytab das Maschinenkonto genutzt werden. NTLM wird bewusst nicht unterstützt.

Praxis-Tipp & Architektur-Hinweis

Der Hostname in den SPNs muss genau der Name sein, den die Clients aufrufen (z. B. mail.firma.de), und per A-Record (kein CNAME-Ziel mit anderem Namen) auflösen. Nach jeder Kennwortänderung des Dienstkontos die Keytab neu erzeugen und hochladen; "Kerberos prüfen" zeigt Schlüsselversion und Verschlüsselung jedes SPNs.

Active Directory: Dienstkonto, SPNs und Keytab

PowerShell als Domänen-Admin. ktpass einmal für den ersten SPN; alle weiteren SPNs desselben Kontos teilen den Schlüssel und brauchen nur setspn.

Referenz / Konfiguration

# 1. Dienstkonto (Kennwort läuft nicht ab, nur AES)
New-ADUser -Name svc-nextxch -AccountPassword (Read-Host -AsSecureString) `
  -Enabled $true -PasswordNeverExpires $true -KerberosEncryptionType AES256

# 2. Service-Principals registrieren (Hostname = Name, den die Clients verwenden)
setspn -S HTTP/mail.firma.de  FIRMA\svc-nextxch
setspn -S imap/mail.firma.de  FIRMA\svc-nextxch
setspn -S smtp/mail.firma.de  FIRMA\svc-nextxch
setspn -S pop/mail.firma.de   FIRMA\svc-nextxch
setspn -S sieve/mail.firma.de FIRMA\svc-nextxch

# 3. Keytab erzeugen (setzt das Kennwort des Kontos neu)
ktpass -princ HTTP/mail.firma.de@FIRMA.LOCAL -mapuser FIRMA\svc-nextxch `
  -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass * -out nextxch.keytab

# 4. nextxch Admin > Identitätsquellen > Kerberos
#    Realm FIRMA.LOCAL, SPNs wie oben, Keytab hochladen, "Kerberos prüfen"

# Maschinenkonto-Modus (nextxch auf Domänenmitglied MAILSRV, keine Keytab):
setspn -S HTTP/mail.firma.de FIRMA\MAILSRV$
setspn -S imap/mail.firma.de FIRMA\MAILSRV$

MIT Kerberos, Heimdal und FreeIPA

Principals anlegen und die Schlüssel in eine Keytab exportieren; FreeIPA: ipa service-add und ipa-getkeytab.

Referenz / Konfiguration

# 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

Manueller Test mit einem echten AD

Die automatischen Tests prüfen Tickets aus generierten Keytabs. Mit einem echten Domänencontroller zusätzlich so testen:

Referenz / Konfiguration

# 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

Einstellungen, Standardwerte & Best Practices

Einstellung / Ort	Funktion	Standardwert	Best Practice im Betrieb
`Keytab`	MIT-Format, wie ktpass, ktutil und kadmin sie schreiben. Wird mit dem Server-Schlüsselbund verschlüsselt gespeichert und nie wieder angezeigt; die Admin-Seite zeigt nur Principal, kvno und Verschlüsselung.	`Keytab-Modus`	AES256 verwenden. RC4-Schlüssel funktionieren, "Kerberos prüfen" warnt aber davor.
`Benutzerzuordnung`	Der Kerberos-Principal (anna@FIRMA.LOCAL) wird über die Identitätsquelle zugeordnet: userPrincipalName, sAMAccountName oder Mailadresse. Nur der eingetragene Realm (und weitere freigegebene Realms) wird akzeptiert.	`Realm Pflicht`	Zuerst die AD-Identitätsquelle einrichten und abgleichen, dann Kerberos einschalten.
`Browser`	Browser senden Kerberos-Tickets nur an vertrauenswürdige Intranet-Adressen. Ohne Freigabe erscheint einfach die normale Anmeldeseite.	`Automatischer Versuch aus`	GPO "Liste der Site zu Zonenzuweisungen": https://mail.firma.de = 1 (Intranet). Chrome/Edge: AuthServerAllowlist, Firefox: network.negotiate-auth.trusted-uris.
`Outlook und ActiveSync`	MAPI, EWS, Autodiscover und ActiveSync bieten zusätzlich zu Basic "WWW-Authenticate: Negotiate" an. Outlook auf Domänen-PCs nutzt dann das Ticket des angemeldeten Benutzers.	`Negotiate + Basic`	In Outlook unter Kontoeinstellungen > Weitere Einstellungen > Sicherheit "Immer zur Eingabe von Anmeldeinformationen auffordern" ausschalten.
`Mail-Programme (GSSAPI)`	IMAP, SMTP-Submission, POP3 und ManageSieve bieten SASL GSSAPI an (mit gegenseitiger Authentifizierung, RFC 4752). Thunderbird: Kontoeinstellungen > Server > Authentifizierung "Kerberos / GSSAPI".	`imap/, smtp/, pop/, sieve/`	Unter Linux-Clients vorher kinit ausführen; klist zeigt danach das Ticket für imap/mail.firma.de.