Capítulo 16a Clientes, groupware & CLI Admin: #pIdentity

Kerberos SSO: login sem senha para PCs do domínio, Outlook e apps de e-mail

Com Kerberos, PCs Windows na rede da empresa entram sem solicitação de senha: webmail e admin via SPNEGO ("Entrar com Windows"), Outlook via MAPI, EWS, ActiveSync e Autodiscover com Negotiate, Thunderbird e outros apps de e-mail via IMAP, SMTP, POP3 e ManageSieve com SASL GSSAPI. O próprio nextxch valida os tickets com um keytab enviado; isso funciona no Linux e em servidores Windows que não são membros do domínio. Quando o nextxch roda em um membro do domínio, a conta de máquina pode ser usada em vez de um keytab. O NTLM deliberadamente não é suportado.

Dica operacional & nota de arquitetura

O nome de host nos SPNs deve ser exatamente o nome que os clientes usam (por exemplo, mail.example.com) e ser resolvido por um registro A. Após cada troca de senha da conta de serviço, crie e envie o keytab novamente; "Verificar Kerberos" mostra a versão da chave e a criptografia de cada SPN.

Active Directory: conta de serviço, SPNs e keytab

PowerShell como administrador do domínio. Execute ktpass uma vez para o primeiro SPN; todos os demais SPNs da mesma conta compartilham a chave e só precisam de setspn.

Referência / configuração

# 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

Crie os principals e exporte suas chaves para um keytab; FreeIPA: ipa service-add e ipa-getkeytab.

Referência / configuração

# 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

Teste manual com um AD real

Os testes automatizados validam tickets a partir de keytabs gerados. Com um controlador de domínio real, teste também assim:

Referência / configuração

# 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

Configurações, valores padrão e boas práticas

Configuração / local	Descrição	Valor padrão	Boa prática para produção
`Keytab`	Formato MIT, como gravado por ktpass, ktutil e kadmin. Armazenado criptografado com o keyring do servidor e nunca mais exibido; a página de administração lista apenas principal, kvno e criptografia.	`Keytab-Modus`	Use AES256. Chaves RC4 funcionam, mas o "Verificar Kerberos" emite um aviso sobre elas.
`Benutzerzuordnung`	O principal Kerberos (anna@CORP.LOCAL) é mapeado pela fonte de identidade: userPrincipalName, sAMAccountName ou endereço de e-mail. Somente o realm configurado (e outros realms permitidos) é aceito.	`Realm Pflicht`	Configure e sincronize primeiro a fonte de identidade do AD e depois ative o Kerberos.
`Browser`	Os navegadores enviam tickets Kerberos apenas para endereços de intranet confiáveis. Sem isso, aparece a página de login normal.	`Automatischer Versuch aus`	GPO "Lista de atribuições de site para zona": https://mail.example.com = 1 (intranet). Chrome/Edge: AuthServerAllowlist, Firefox: network.negotiate-auth.trusted-uris.
`Outlook und ActiveSync`	MAPI, EWS, Autodiscover e ActiveSync oferecem "WWW-Authenticate: Negotiate" além de Basic. O Outlook em PCs do domínio passa então a usar o ticket do usuário conectado.	`Negotiate + Basic`	No Outlook, em Configurações da conta > Mais configurações > Segurança, desative "Sempre solicitar credenciais de logon".
`Mail-Programme (GSSAPI)`	IMAP, submissão SMTP, POP3 e ManageSieve oferecem SASL GSSAPI (com autenticação mútua, RFC 4752). Thunderbird: configurações da conta > servidor > autenticação "Kerberos / GSSAPI".	`imap/, smtp/, pop/, sieve/`	Em clientes Linux, execute primeiro kinit; o klist então mostra o ticket para imap/mail.example.com.