Capítulo 16a Clientes, groupware & CLI Administración: #pIdentity

Kerberos SSO: inicio de sesión sin contraseña para PC del dominio, Outlook y apps de correo

Con Kerberos, los PC con Windows de la red corporativa inician sesión sin solicitud de contraseña: Webmail y administración mediante SPNEGO ("Iniciar sesión con Windows"), Outlook mediante MAPI, EWS, ActiveSync y Autodiscover con Negotiate, Thunderbird y otras aplicaciones de correo mediante IMAP, SMTP, POP3 y ManageSieve con SASL GSSAPI. nextxch valida los tickets por sí mismo con un keytab cargado; esto funciona en Linux y en servidores Windows que no son miembros del dominio. Cuando nextxch se ejecuta en un miembro del dominio, puede utilizarse la cuenta de equipo en lugar de un keytab. NTLM no se admite deliberadamente.

Consejo operativo y nota de arquitectura

El nombre de host en los SPN debe ser exactamente el nombre que usan los clientes (p. ej., mail.example.com) y resolverse mediante un registro A. Tras cada cambio de contraseña de la cuenta de servicio, vuelva a crear y cargar el keytab; "Comprobar Kerberos" muestra la versión de la clave y el cifrado de cada SPN.

Active Directory: cuenta de servicio, SPN y keytab

PowerShell como administrador del dominio. Ejecute ktpass una vez para el primer SPN; todos los demás SPN de la misma cuenta comparten la clave y solo necesitan setspn.

Referencia / configuración

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

Cree los principals y exporte sus claves a un keytab; FreeIPA: ipa service-add e ipa-getkeytab.

Referencia / configuración

# 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

Prueba manual con un AD real

Las pruebas automatizadas validan tickets a partir de keytabs generados. Con un controlador de dominio real, pruebe además así:

Referencia / configuración

# 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

Configuración, valores predeterminados y buenas prácticas

Ajuste / ubicación	Descripción	Valor predeterminado	Buena práctica de producción
`Keytab`	Formato MIT tal como lo escriben ktpass, ktutil y kadmin. Se almacena cifrado con el llavero del servidor y no se vuelve a mostrar nunca; la página de administración solo muestra el principal, kvno y el cifrado.	`Keytab-Modus`	Utilice AES256. Las claves RC4 funcionan, pero "Check Kerberos" advierte sobre ellas.
`Benutzerzuordnung`	El principal de Kerberos (anna@CORP.LOCAL) se asigna a través de la fuente de identidad: userPrincipalName, sAMAccountName o dirección de correo. Solo se acepta el realm configurado (y los demás realms permitidos).	`Realm Pflicht`	Configure y sincronice primero la fuente de identidad de AD y después active Kerberos.
`Browser`	Los navegadores solo envían tickets Kerberos a direcciones de intranet de confianza. Sin eso, aparece la página de inicio de sesión normal.	`Automatischer Versuch aus`	GPO "Lista de asignaciones de sitio a zona": https://mail.example.com = 1 (intranet). Chrome/Edge: AuthServerAllowlist, Firefox: network.negotiate-auth.trusted-uris.
`Outlook und ActiveSync`	MAPI, EWS, Autodiscover y ActiveSync ofrecen "WWW-Authenticate: Negotiate" además de Basic. Outlook en los PC del dominio utiliza entonces el ticket del usuario que ha iniciado sesión.	`Negotiate + Basic`	En Outlook, en Configuración de la cuenta > Más configuraciones > Seguridad, desactive "Solicitar siempre las credenciales de inicio de sesión".
`Mail-Programme (GSSAPI)`	IMAP, el envío SMTP, POP3 y ManageSieve ofrecen SASL GSSAPI (con autenticación mutua, RFC 4752). Thunderbird: configuración de la cuenta > servidor > autenticación "Kerberos / GSSAPI".	`imap/, smtp/, pop/, sieve/`	En clientes Linux, ejecute primero kinit; klist muestra después el ticket para imap/mail.example.com.