Federación y sincronización

Una cuenta sincronizada desde el directorio local existe en los dos mundos: lo que le pase en el directorio local, como una clave comprometida o un atributo cambiado, afecta a la nube. Por eso la guía de Microsoft recomienda que las cuentas con roles de administración en la nube sean solo de la nube, separadas de las cuentas de uso diario y sin vínculo con el directorio local.

Para el equipo de detección esto tiene una consecuencia práctica: una cuenta sincronizada con un rol de administración hace que un cambio en el directorio local sea también un cambio de superficie de la nube, y las dos fuentes hay que mirarlas juntas. La tabla roles_en_la_nube muestra el origen de cada cuenta.

Cruza roles_en_la_nube buscando los roles de administración global. Hay dos cuentas con ese rol: una es solo de la nube y otra viene del directorio local. Esa última es la que une las dos superficies.

El servicio de federación registra cada intento de inicio de sesión, con usuario, origen, aplicación y resultado. Muchos fallos de distintos usuarios desde un mismo origen externo, uno cada pocos segundos, es el patrón de una prueba de una misma clave contra muchas cuentas. Una persona despistada deja fallos de un solo usuario. El registro da el patrón y no la intención.

La federación firma sus tokens con un certificado, y las aplicaciones confían en esa firma. Si el certificado vence sin renovarse, nadie entra por la federación; si se cambia sin aviso, es una señal que merece mirarse. Una detección útil avisa antes del vencimiento. Con la fecha del informe y el vencimiento en configuracion_federacion, calcula el margen.

Tienes tres hechos: cinco usuarios con un fallo cada uno desde una misma dirección externa y, dos minutos después, un acceso correcto de uno de ellos sin que se pidiera el segundo factor; un dominio federado nuevo agregado de madrugada sin ticket; y una exigencia de segundo factor solo para administradores. No tienes confirmación de ninguna persona.