Cómo se pide y se usa un ticket

Cuando un usuario inicia sesión en una estación del dominio, el cliente envía un mensaje AS-REQ al KDC incluyendo datos de preautenticación cifrados con la clave derivada de su propia contraseña. El KDC valida el mensaje y responde con un mensaje AS-REP que contiene el Ticket Granting Ticket (TGT), cifrado con la clave secreta de la cuenta krbtgt, junto con una clave de sesión.

El algoritmo de cifrado negociado en el mensaje AS-REQ resulta crítico para la robustez criptográfica del proceso. El estándar moderno exige AES de 256 bits, mientras que implementaciones heredadas que aceptan RC4 exponen la sesión a debilidades estructurales.

Consulta la tabla tickets_as e identifica el algoritmo de cifrado seguro utilizado en las solicitudes legítimas de los administradores.

Una vez obtenido el TGT, el usuario solicita acceso a un recurso de red (como un servidor de archivos o una base de datos) enviando un mensaje TGS-REQ. El KDC responde con un TGS-REP que incluye el Ticket de Servicio cifrado con la clave del servicio destino (definido por su SPN).

Si el servicio destino soporta únicamente cifrado RC4_HMAC, el ticket de servicio se emite con dicho algoritmo, facilitando ataques de recuperación de clave fuera de línea si la contraseña del servicio es vulnerable.

Examina la tabla tickets_tgs y determina cuántos tickets de servicio fueron emitidos utilizando el algoritmo débil RC4_HMAC.

La política de Kerberos del dominio establece límites temporales estrictos para la validez de los tickets TGT y de servicio (típicamente 10 horas de duración máxima y hasta 7 días de ventana de renovación). Si un atacante compromete un ticket, su ventana de abuso queda acotada por estos parámetros temporales salvo que cuente con mecanismos de persistencia.

¿Cuál es la función principal de la clave de sesión incluida dentro del mensaje AS-REP?