Si ha estado investigando sobre Active Directory (AD), es probable que se encuentre con el concepto de Kerberos para la autenticación de usuarios y otras funcionalidades relacionadas con la solicitud de servicios.
Merece la pena examinar el protocolo Kerberos en profundidad y, a su vez, apreciar la dependencia de AD de Kerberos. Dado que es un estándar de la industria, verá que se ha convertido en el protocolo de autenticación de red más utilizado en todos los entornos Windows con sistemas operativos 2000 y posteriores. Estar familiarizado con la autenticación Kerberos es vital para entender mejor este protocolo.
En los términos más simples, se puede pensar en la autenticación Kerberos como el mecanismo de autenticación predeterminado y más fundamental utilizado por los entornos Windows AD.
La autenticación Kerberos se basa en el concepto de tickets y claves de sesión que, en última instancia, conforman lo que comúnmente describimos como credenciales. Estas credenciales se utilizan para autenticar a los usuarios en cualquier dominio requerido.
Posteriormente, realizan solicitudes de servicio para establecer una conexión segura y cifrada con un servidor de destino, a través de cualquier red no segura. Kerberos se asegura de que todos los clientes que interactúan proporcionen una prueba de identidad con los servidores, a veces mutuamente si es necesario, para permitir un proceso de autenticación perfecto.
Kerberos, LDAP y su intersección: Conceptos que suelen confundirse
A menudo existe cierta confusión sobre las diferencias y similitudes entre el funcionamiento del protocolo ligero de acceso a directorios (LDAP) y lo que ofrece Kerberos.
Para resolver esta confusión, se puede pensar que Kerberos proporciona un servicio de autenticación de inicio de sesión único para que los clientes accedan a múltiples aplicaciones y servicios. Y puede pensar en LDAP, en relación con AD, como un protocolo de comunicación para buscar, consultar y modificar los datos de AD.
El LDAP también autentifica a los usuarios con un procedimiento de dos pasos. Primero comprueba el nombre de usuario y la contraseña que el cliente proporciona con la información almacenada en la base de datos LDAP. La autenticación LDAP y la posterior autorización permiten a los clientes acceder a la base de datos de AD para recuperar y gestionar los datos de AD de forma rápida y eficaz.
Normalmente Kerberos y LDAP se utilizan juntos para garantizar que se aprovechan las funciones individuales que ofrecen ambos cuando se configura el entorno de AD.
El modelo de autenticación Kerberos
El mecanismo Kerberos es análogo al perro de tres cabezas, Cerbero, de la mitología griega. El modelo de funcionamiento de este protocolo está diseñado en base a tres partes:
- El usuario, o el cliente, que solicita un determinado servicio
- La aplicación, o el servidor de destino, que proporciona el servicio requerido
- El servidor de confianza de terceros, llamado centro de distribución de claves (KDC). Suele estar instalado en los controladores de dominio de cualquier entorno de AD.
El KDC se identifica lógicamente además por tres componentes principales:
- La base de datos (Db)
- El servidor de concesión de tickets (TGS)
- El servidor de autorización (AS)
Mediante varios pasos, que incluyen la concesión de tickets, y las comprobaciones de cifrado y descifrado, los tickets Kerberos ayudan en el proceso de autenticación.
Este flujo de protocolos explica el proceso de autenticación Kerberos a grandes rasgos:
- Cualquier usuario o cliente que requiera autenticación durante el proceso de inicio de sesión introduce una contraseña como parte del proceso de inicio de sesión. Esta se procesa para obtener un hash que se deriva a través de un algoritmo de hash de contraseña.
- El cliente solicita un ticket de concesión (TGT) indicando su nombre de usuario principal (UPN) al KDC. El comando Kerberos utilizado aquí es KRB_AS_REQ.
- Este hash de contraseña se comprueba, se procesa y, a continuación, el AS del KDC lo utiliza para generar una clave secreta de cliente/usuario.
- En esta fase, el AS también genera una clave secreta de TGS tras confirmar la disponibilidad del TGS.
- El AS procesa una clave de sesión 1 (SK1), que pasa a formar parte del TGT cifrado que se entrega al cliente para demostrar su identidad inicial.
- El TGT se envía al cliente desde el KDC después de buscar el UPN del cliente en la base de datos del KDC. El comando Kerberos utilizado aquí es KRB_AS_REP.
- El TGT contiene el ID del cliente, la dirección de red del cliente, la marca de tiempo, el valor de vida y la SK1. Aquí es importante señalar que el cifrado de la información en el TGT se completa utilizando tanto la clave secreta del cliente o usuario como la clave secreta del TGS.
- Tras recibir esta respuesta, el cliente utiliza el hash de su clave para extraer la SK1.
- Cada vez que el cliente requiera un servicio o el acceso a algún recurso de red en particular, se deberá renovar el TGT después de caducado desde el KDC.
Esto completa la primera etapa de establecimiento de la identidad primaria del cliente, que prepara el camino para los pasos posteriores de autenticación.
Para acceder a un servicio concreto, como un inicio de sesión remota en una nueva estación de trabajo, o acceder a un navegador web o a un sistema de archivos, se requieren pasos de autenticación posteriores para demostrar que el cliente tiene permiso para acceder a ese servicio. Estos pasos son:
- El cliente procesa el TGT en posesión, añade el nombre de principal de servicio (SPN) del servicio requerido, y envía al TGS un autentificador cifrado con la SK1 y posteriormente por la clave secreta del TGS. El comando Kerberos utilizado aquí es KRB_TGS_REQ.
- Se contacta con el TGS para solicitar el inicio de sesión entre el cliente y el servidor de destino mediante una clave de sesión de servicio (SK2).
- El servidor de TG utiliza la clave secreta del TGS para descifrar el autentificador y extraer la SK1. Una vez comprobada la validez del TGT y la concordancia entre la información del cliente en el TGT y en el autentificador, el TGS crea la SK2.
- El KDC incluye la SK2 junto con el ID del cliente, la dirección de red, la marca de tiempo, etc. en un ticket de servicio y lo envía al cliente. El comando Kerberos utilizado aquí es KRB_TGS_REP.
- Este ticket se encripta utilizando una clave secreta del servidor que la Db proporciona. Se vuelve a cifrar doblemente con la SK1 y se envía al cliente. Este ticket también tiene el certificado de atributos de privilegio (PAC) que indica que los privilegios de usuario para el cliente son “encriptado y firmado por el KDC”.
- El cliente sólo puede descifrar este ticket de servicio para extraer la SK1, generar un nuevo mensaje autenticador, cifrarlo con la SK2 y enviarlo al servidor de destino para el descifrado final y la autenticación para acceder al servicio. El comando Kerberos utilizado aquí es KRB_AP_REQ.
- El servidor de destino, con su clave secreta, descifra el ticket de servicio. Accede a la SK2 y descifra el autentificador. Primero puede identificarse, es decir, autenticarse con el cliente con un comando Kerberos opcional KRB_AP_REP, en los casos en los que la autenticación mutua es necesaria para mejorar la seguridad.
- Si el ID del cliente y otros datos del ticket de servicio y el PAC coinciden con los del autentificador, se establece una conexión segura y autentificada entre el cliente y el servidor de destino para ofrecer el servicio requerido.
Estos pasos se siguen para determinar si la autenticación puede considerarse un éxito o un fracaso entre el cliente y el servidor utilizando el protocolo Kerberos.
Una de las ventajas más notables de utilizar este modelo de autenticación es que las contraseñas nunca se almacenan en texto plano, ni se transfieren por la red en su forma nativa. Sin embargo, Kerberos no es infalible. Para entender este protocolo por completo, tendrá que prestar la debida atención a las limitaciones del flujo del protocolo, así como a las vulnerabilidades asociadas al mismo. ¡Continúe en sintonía para más información!
