Conceptos básicos del cliente Kerberos en Linux: krb5.conf, kinit/klist/kdestroy y keytabs

Objetivo

Obtener, inspeccionar y eliminar un ticket de concesión de tickets (TGT, ticket-granting ticket) de Kerberos en un cliente Linux con MIT Kerberos (krb5), y usar un keytab en un proceso que debe autenticarse sin contraseña interactiva.

Requisitos previos

Tener instalado el paquete krb5-user/krb5-workstation; que /etc/krb5.conf esté configurado al menos con un default_realm en [libdefaults]; que, salvo que los registros DNS SRV lo proporcionen, exista una sección [realms] que asocie el realm con su KDC; normalmente también una sección [domain_realm] que asocie los dominios DNS con el realm; y que haya conectividad de red con el KDC (normalmente TCP/UDP 88).

Pasos

1. Confirmar la configuración: default_realm en /etc/krb5.conf debe coincidir exactamente con el nombre del realm, incluidas las mayúsculas y minúsculas. Por convención, los nombres de realm de Kerberos se escriben en mayúsculas y se tratan como cadenas sensibles a mayúsculas, de modo que EXAMPLE.COM y example.com son realms distintos para la biblioteca, aunque DNS no distinga entre mayúsculas y minúsculas.
2. Obtener un ticket de forma interactiva: kinit user@EXAMPLE.COM, que solicita la contraseña y, si la autenticación tiene éxito, almacena un TGT en la cache de credenciales predeterminada. kinit documenta la opción -k -t <keytab> para autenticarse con un keytab en lugar de una contraseña, que es la forma necesaria para el uso desatendido, por ejemplo kinit -k -t /etc/svc.keytab svc@EXAMPLE.COM (sin indicar un principal, se usa por defecto el principal local host/).
3. Inspeccionar la cache: klist muestra el principal, los indicadores del ticket y las horas de emisión y caducidad, sin necesidad de autenticarse de nuevo.
4. Listar el contenido de un keytab (de un principal de servicio o de automatización) sin extraer secretos: klist -k -t -e /etc/krb5.keytab, que muestra los principales, las marcas de tiempo de las claves y (con -e) los tipos de cifrado que contiene el keytab; el keytab del sistema solo puede leerlo root.
5. Descartar los tickets en cache al terminar o antes de cambiar de identidad: kdestroy.

Resultado esperado

Tras un kinit correcto, klist muestra un TGT válido con una hora de caducidad en el futuro; una llamada posterior a un servicio con Kerberos (SSH con GSSAPI, un bind LDAP SASL/GSSAPI) se completa sin pedir contraseña. Después de kdestroy, klist indica que no hay credenciales en la cache.

Límites y base de verificación

Los fallos más habituales en el cliente son el desfase de reloj y la discrepancia de mayúsculas y minúsculas en el nombre del realm entre krb5.conf y lo que espera el KDC. En el primer caso, Kerberos rechaza los tickets cuando los relojes del cliente y del KDC difieren más de la tolerancia configurada (clockskew en [libdefaults], 300 segundos por defecto), y se notifica con el error "clock skew too great". Ninguno de los dos es un problema de red ni de contraseña, así que comprobar primero chronyc tracking/timedatectl y la cadena exacta del realm ahorra tiempo. Un archivo keytab permite a cualquiera que pueda leerlo obtener tickets para su principal, por lo que sus permisos de archivo (lectura solo para el propietario) importan tanto como su ubicación.