Kerberos: el abuelo de la autenticación empresarial que aún late en Active Directory
Kerberos es el protocolo de autenticación de red basado en tickets y criptografía simétrica que lleva casi cuarenta años sosteniendo las redes corporativas. Resolvió el problema de autenticar sujetos en entornos hostiles sin enviar contraseñas por la red, y sigue siendo el núcleo silencioso de Active Directory. Entenderlo es imprescindible para cualquier arquitectura que conviva con sistemas empresariales heredados.
Hay pocas tecnologías con la edad y la vigencia de Kerberos. Nació cuando la red no se llamaba todavía Internet, sobrevivió a tres generaciones de protocolos y hoy sigue autenticando al usuario cada vez que alguien abre sesión en un dominio de Active Directory. Este artículo forma parte de la serie La evolución de la seguridad en aplicaciones modernas.
El problema que Kerberos vino a resolver
A mediados de los años ochenta, el MIT puso en marcha el proyecto Athena: una red de estaciones de trabajo distribuidas por todo el campus donde cualquier estudiante podía sentarse en cualquier máquina y acceder a sus ficheros, impresoras y servicios. El modelo clásico de autenticación local se derrumbaba: no se podía exigir una cuenta por máquina ni confiar en la red, que era completamente hostil. Se necesitaba que un servicio remoto confirmara la identidad del usuario sin que la contraseña viajara por la red y sin que cada servidor tuviera que guardar credenciales individuales.
La solución se inspiró en el trabajo previo de Roger Needham y Michael Schroeder, que en 1978 publicaron el protocolo que lleva sus nombres: un esquema basado en un tercero de confianza, criptografía simétrica y nonces para evitar ataques de replay. Kerberos aplicó esas ideas con pragmatismo de ingenieros: lo llamaron así por el perro de tres cabezas que guardaba el inframundo en la mitología griega, una metáfora de los tres actores del protocolo (cliente, servicio y KDC).
Kerberos v4 se usó durante los noventa, pero tenía limitaciones criptográficas y de diseño que llevaron a Kerberos v5, publicado finalmente como estándar en RFC 4120 (The Kerberos Network Authentication Service V5) en julio de 2005, con RFC 4121 para GSSAPI y una familia de RFCs complementarios para extensiones posteriores. Esa versión es la que todavía corre bajo el capó de cada inicio de sesión corporativo.
Cómo funciona: el baile de los tickets
La pieza central es el KDC (Key Distribution Center). El KDC no es un único servicio monolítico, sino dos servicios lógicos que comparten una base de datos de principales y claves: el AS (Authentication Server) y el TGS (Ticket Granting Server). El AS autentica al usuario al inicio de la sesión. El TGS emite tickets para servicios concretos dentro del realm. La separación existe para que la contraseña del usuario se utilice una sola vez al día y nunca vuelva a estar en juego durante las sucesivas solicitudes.
El flujo en tres actos
Cuando el usuario inicia sesión, el cliente envía al AS una petición con su nombre de principal. El AS responde con dos piezas: un TGT (Ticket Granting Ticket), cifrado con una clave que solo el TGS conoce, y una clave de sesión, cifrada con una clave derivada de la contraseña del usuario. El cliente descifra la clave de sesión con su contraseña, demostrando así que la conoce sin haberla transmitido. El TGT queda almacenado en la caché de credenciales del cliente.
Cuando el usuario quiere acceder a un servicio (un recurso compartido, una base de datos, una web corporativa), el cliente envía al TGS el TGT más un autenticador cifrado con la clave de sesión. El TGS devuelve un service ticket para ese servicio concreto, junto con una nueva clave de sesión específica para esa conversación. El cliente presenta el service ticket y un autenticador al servicio. El servicio descifra el ticket con su propia clave de larga duración, verifica el autenticador y establece la sesión.
Todo el flujo se apoya en criptografía simétrica. No hay certificados en el camino crítico ni infraestructura de clave pública, lo que diferencia a Kerberos de PKI (Public Key Infrastructure) y de TLS en su operación nuclear. La extensión PKINIT, estandarizada en RFC 4556, permite que la autenticación inicial use certificados X.509, y es lo que habilita el inicio de sesión con smart cards en entornos Windows modernos.
Por qué exige sincronización temporal
Los autenticadores incluyen una marca de tiempo para frenar ataques de replay. Si la hora del cliente y la del servicio (o del KDC) difieren más de unos minutos (cinco por defecto en la mayoría de implementaciones), el ticket se rechaza. Esta es la causa más frecuente de fallos en entornos Kerberos y la razón por la que cualquier dominio AD bien gestionado tiene políticas estrictas de NTP. No es una manía: es la forma en que Kerberos compensa la falta de estado compartido entre el emisor y el verificador de un ticket.
Principales, SPN y UPN
En Kerberos todo lo que se autentica es un principal: usuarios, servicios y máquinas. Un principal se representa como nombre@REALM. Microsoft introdujo dos variantes sintácticas en Active Directory: el UPN (User Principal Name), que se parece a una dirección de correo y se usa para identificar usuarios, y el SPN (Service Principal Name), que identifica un servicio concreto corriendo en un host concreto (por ejemplo HTTP/portal.empresa.local). La correcta gestión de SPN es una de las fuentes clásicas de errores de autenticación integrada en aplicaciones web corporativas.
Kerberos dentro de Active Directory
Cuando Microsoft lanzó Windows 2000, reemplazó NTLM como protocolo de autenticación principal y adoptó Kerberos v5 con extensiones propietarias. Un controlador de dominio es, entre otras cosas, un KDC con una base de datos integrada en el directorio LDAP. Cada estación de trabajo que se une al dominio obtiene un principal de máquina y una clave de larga duración almacenada localmente.
La extensión más visible de Microsoft fue el PAC (Privilege Attribute Certificate), un campo dentro del ticket que transporta información de autorización (grupos, SIDs, privilegios). Gracias al PAC, una aplicación que valida un ticket Kerberos obtiene no solo la identidad sino también la pertenencia a grupos, lo que permite tomar decisiones de autorización sin volver a consultar al directorio. Esto acopla autenticación y autorización de una forma que en los entornos modernos se evita, pero que explica por qué Kerberos se percibe como un “SSO empresarial completo”.
El puente entre Kerberos y el mundo HTTP lo hace SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism), definido en RFC 4178. SPNEGO permite que un navegador y un servidor negocien automáticamente Kerberos sobre HTTP mediante la cabecera Authorization: Negotiate. Por debajo, todo el ecosistema habla GSSAPI (Generic Security Services API), la abstracción que encapsula el protocolo para que las aplicaciones no tengan que implementarlo directamente.
Cuándo Kerberos sigue teniendo sentido y cuándo no
La respuesta honesta es que Kerberos sigue vivo porque es el lenguaje nativo de las redes empresariales. Cualquier organización con más de diez años de TI tiene Active Directory, y Active Directory habla Kerberos. Migrar todo a OIDC para sistemas internos que nunca salen del perímetro corporativo es un ejercicio académico con coste alto y beneficio difuso.
Kerberos sigue teniendo sentido cuando el universo de identidades es cerrado (empleados de una organización), cuando los servicios viven en la misma red o en redes federadas por trusts entre dominios, cuando los clientes pueden tener conectividad directa con el KDC y cuando las aplicaciones ya están integradas con Windows o con bibliotecas GSSAPI.
Deja de tener sentido en el momento en que la aplicación vive en internet público, cuando se necesita federar con terceros que no tienen trust con el AD corporativo, cuando los clientes son móviles o navegadores fuera de la red corporativa, o cuando el modelo de autorización requiere granularidad más allá de grupos de AD.
Limitaciones estructurales
Kerberos fue diseñado para una LAN de campus, no para internet. Exige conectividad directa con el KDC, lo que en arquitecturas móviles o cloud-first es un problema. No fue pensado para flujos delegados entre aplicaciones (aunque las extensiones S4U2Self y S4U2Proxy lo permiten con cierta complejidad). Los tickets crecen con el número de grupos del usuario, y en dominios grandes el tamaño del PAC puede reventar las cabeceras HTTP. Y cualquier compromiso de la cuenta krbtgt (la clave raíz del KDC) habilita ataques devastadores como el Golden Ticket, que permite emitir tickets arbitrarios sin tocar el AS.
Rotar la clave
krbtgtcon regularidad no es una buena práctica opcional, es la única defensa estructural contra ataques Golden Ticket tras una intrusión.
Migración hacia identidad moderna
La estrategia habitual en organizaciones que adoptan la nube no es sustituir Kerberos sino ponerle un puente. Un IdP moderno (Keycloak, Okta, Entra ID) se federa con Active Directory como fuente de verdad, traduciendo tickets Kerberos a tokens OIDC o aserciones SAML para las aplicaciones externas. El usuario ve un único single sign-on y la organización conserva su inversión en AD mientras abre la puerta a flujos modernos.
El patrón “Kerberos dentro, OIDC fuera” es la arquitectura de identidad dominante en grandes empresas: no es legado, es pragmatismo.
Los equipos cloud-native necesitan entender Kerberos aunque jamás lo configuren directamente, porque la federación con AD aparece en cuanto hay una aplicación corporativa interna, y porque muchos problemas aparentemente modernos (tokens que no se renuevan, relojes desincronizados entre nodos, fallos esporádicos con ciertos navegadores) son patologías kerberianas disfrazadas.
Artículos relacionados en esta serie
Referencias
- Needham, R. M. y Schroeder, M. D. (1978). Using Encryption for Authentication in Large Networks of Computers.
- RFC 4120 (julio 2005). The Kerberos Network Authentication Service (V5).
- RFC 4121 (julio 2005). The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism.
- RFC 4178 (octubre 2005). The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO).
- RFC 4556 (junio 2006). Public Key Cryptography for Initial Authentication in Kerberos (PKINIT).
- MIT. Kerberos Documentation.
- Microsoft. MS-KILE: Kerberos Protocol Extensions.