Kerberos en el cable — errores y tickets

Para entrar, el equipo pide al controlador un ticket de entrada (la petición «AS») demostrando que conoce la clave de la cuenta. El controlador responde con un código cuando algo falla, y dos de ellos conviene saber distinguir. KDC_ERR_PREAUTH_FAILED dice que la cuenta existe pero lo que se presentó no coincide con su clave: contraseña equivocada. KDC_ERR_C_PRINCIPAL_UNKNOWN dice que la cuenta no existe en el dominio.

La diferencia no es de detalle: el primero confirma que el nombre es real, y el segundo descarta el nombre.

Hay dos formas de equivocarse muchas veces. Una es insistir sobre una cuenta con muchas contraseñas, que bloquea la cuenta y salta rápido. La otra es probar una sola contraseña sobre muchas cuentas, un intento por cuenta y con unos segundos entre uno y otro, que casi nunca bloquea nada. En el registro la segunda se reconoce por el origen: un solo equipo, muchos nombres distintos de cliente en una ventana corta.

Abre SELECT * FROM kerberos_log y mira la ráfaga de las 10:15.

En una ráfaga así lo que importa al final es si alguna cuenta cedió. El registro lo dice con la primera respuesta «OK» del mismo origen tras los fallos: ese nombre es la cuenta cuya contraseña coincidía con la que se probó. Es la cuenta a la que hay que ir primero: cambiar su clave, revisar qué hizo después y revisar si otras cuentas comparten esa clave.

Cuando alguien pide un ticket para un servicio (petición «TGS»), el controlador lo entrega cifrado con la clave de la cuenta que responde por ese servicio. Si esa cuenta es de una persona y tiene una contraseña corta o vieja, quien se lleve el ticket podría intentar adivinarla sin volver a tocar la red. Por eso importa el cifrado: en este dominio todo se entrega con aes256 salvo un dispositivo antiguo, y los tickets con rc4-hmac son los más fáciles de atacar fuera de línea.

Lo defensivo no es mirar el ticket, sino tres cosas: quién los pide, cuántos y de qué cuentas, y qué contraseña tiene cada cuenta de servicio (catalogo_servicios dice cuándo se cambió).

El dispositivo antiguo (el plotter) también pidió un ticket con rc4-hmac, y no por eso es sospechoso: pide un servicio, una vez, y el catálogo dice que su cifrado esperado es ese. Lo que separa los dos casos es el patrón, no el algoritmo. Cuenta los servicios distintos que pidió con rc4-hmac el equipo que los pidió en ráfaga, uno cada pocos segundos.