Sala 1 · Garantía, credenciales y directorios

El nivel de garantía de autenticador de un trámite se decide por el daño que causaría un error: lo que sale mal si alguien entra sin ser quien dice. Una vez fijado el nivel, el autenticador que de verdad está configurado debe poder cumplirlo; un nivel alto con un autenticador de uno más bajo es una promesa que la configuración no sostiene.

Para saberlo hay que contrastar, trámite por trámite, el nivel exigido con lo que cada autenticador puede dar según la política de identidad. Un autenticador que cumple de sobra no es hallazgo.

Guardar una contraseña no es cifrarla para recuperarla: es derivar una huella lenta que resista a quien se lleve la base de datos. Los algoritmos rápidos, o los que no tienen derivación de clave, dejan que una base robada se descifre en horas; un costo bajo en un algoritmo adecuado acorta el tiempo de la misma manera.

La política fija qué se admite y con qué parámetros. Cada sistema declara su algoritmo, su parámetro y cuántos usuarios dependen de él. Interesa el alcance del problema, no el número de sistemas.

Un enlace simple al directorio envía el nombre y la contraseña de la cuenta de enlace dentro de la conexión. Si el canal no está cifrado, cualquiera que pueda ver ese tramo de red las lee. Por eso lo que importa del registro no es el tipo de enlace por sí solo, sino el tipo de enlace junto con el cifrado del canal en que se hizo.

Un enlace simple por un canal cifrado cumple la política. Un fallo de autenticación en un canal sin cifrar sigue siendo un intento por el canal equivocado.

Cuando un cliente pide un ticket de servicio, el evento 4769 deja escrito con qué tipo de cifrado se emitió. El tipo cifra el ticket con una clave derivada de la contraseña de la cuenta del servicio: un tipo viejo permite que quien capture el ticket pruebe contraseñas sin conexión, y por eso la política retira RC4 y deja solo los tipos AES.

El evento no dice «inseguro»: dice un código, y el código se interpreta con lo que la política declara admitido. La cuenta que importa es la del servicio, no la del cliente que pidió el ticket.

NTLM sigue vivo donde alguien no lo ha retirado, y su registro cuenta cuántas autenticaciones hizo cada equipo, hacia qué servidor y con qué versión. La política distingue dos situaciones: una versión que no se admite en ningún caso y otra que solo se admite con una excepción registrada. Para la primera no hay excepción posible, así que cada autenticación cuenta.

La cifra útil para planear una retirada es el total de la semana de la versión prohibida, sumando todos los equipos y servidores.