Capitolo 16a Client, groupware & CLI Admin: #pIdentity

Kerberos SSO: accesso senza password per PC di dominio, Outlook e app di posta

Con Kerberos, i PC Windows nella rete aziendale accedono senza richiesta di password: Webmail e admin tramite SPNEGO ("Accedi con Windows"), Outlook tramite MAPI, EWS, ActiveSync e Autodiscover con Negotiate, Thunderbird e altre app di posta tramite IMAP, SMTP, POP3 e ManageSieve con SASL GSSAPI. nextxch convalida autonomamente i ticket con un keytab caricato; ciò funziona su Linux e su server Windows che non sono membri del dominio. Quando nextxch è in esecuzione su un membro del dominio, è possibile usare l'account computer al posto di un keytab. NTLM non è supportato di proposito.

Suggerimento operativo & nota sull'architettura

Il nome host negli SPN deve corrispondere esattamente al nome usato dai client (ad es. mail.example.com) ed essere risolto tramite un record A. Dopo ogni cambio di password dell'account di servizio, creare e caricare di nuovo il keytab; "Verifica Kerberos" mostra la versione della chiave e la crittografia di ogni SPN.

Active Directory: account di servizio, SPN e keytab

PowerShell come amministratore di dominio. Eseguire ktpass una volta per il primo SPN; tutti gli altri SPN dello stesso account condividono la chiave e richiedono solo setspn.

Riferimento / configurazione

# 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 e FreeIPA

Creare i principal ed esportarne le chiavi in un keytab; FreeIPA: ipa service-add e ipa-getkeytab.

Riferimento / configurazione

# 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

Test manuale con un AD reale

I test automatici convalidano i ticket da keytab generati. Con un domain controller reale, eseguire anche questo test:

Riferimento / configurazione

# 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

Impostazioni, valori predefiniti e best practice

Impostazione / posizione	Descrizione	Valore predefinito	Best practice per la produzione
`Keytab`	Formato MIT come scritto da ktpass, ktutil e kadmin. Salvato crittografato con il keyring del server e mai più mostrato; la pagina di amministrazione elenca solo principal, kvno e crittografia.	`Keytab-Modus`	Usare AES256. Le chiavi RC4 funzionano, ma "Verifica Kerberos" segnala un avviso.
`Benutzerzuordnung`	Il principal Kerberos (anna@CORP.LOCAL) viene associato tramite l'origine identità: userPrincipalName, sAMAccountName o indirizzo e-mail. Viene accettato solo il realm configurato (e gli ulteriori realm consentiti).	`Realm Pflicht`	Configurare e sincronizzare prima la fonte di identità AD, poi attivare Kerberos.
`Browser`	I browser inviano ticket Kerberos solo a indirizzi intranet attendibili. Altrimenti compare la normale pagina di accesso.	`Automatischer Versuch aus`	GPO "Elenco di assegnazione siti-zone": https://mail.example.com = 1 (intranet). Chrome/Edge: AuthServerAllowlist, Firefox: network.negotiate-auth.trusted-uris.
`Outlook und ActiveSync`	MAPI, EWS, Autodiscover e ActiveSync offrono "WWW-Authenticate: Negotiate" oltre a Basic. Outlook sui PC del dominio usa quindi il ticket dell'utente connesso.	`Negotiate + Basic`	In Outlook, in Impostazioni account > Altre impostazioni > Sicurezza, disattivare "Richiedi sempre credenziali di accesso".
`Mail-Programme (GSSAPI)`	IMAP, submission SMTP, POP3 e ManageSieve offrono SASL GSSAPI (con autenticazione reciproca, RFC 4752). Thunderbird: impostazioni account > server > autenticazione "Kerberos / GSSAPI".	`imap/, smtp/, pop/, sieve/`	Sui client Linux eseguire prima kinit; klist mostra poi il ticket per imap/mail.example.com.