Dispositivos y registros de inicio de sesión

El registro de inicio de sesión de Entra ID anota cada acceso al tenant: quién, con qué cliente y a qué recurso. Hay cuatro tipos: inicios de usuarios interactivos, inicios de usuarios no interactivos (un token que se renueva sin que la persona haga nada), inicios de principales de servicio y de identidades administradas. Las entradas las genera el sistema y no se pueden cambiar ni borrar.

Lo que sí caduca es el registro mismo. Con la licencia gratuita de Entra ID se conserva siete días; con P1 o P2, treinta. Para conservar más hay que enviarlo a una cuenta de almacenamiento o a una herramienta de análisis, y eso hay que configurarlo antes del incidente, porque lo vencido no se recupera.

Un dispositivo tiene identidad en el directorio de tres maneras. Registrado (BYOD, teléfonos y tablets personales): la persona lo registra y sigue usando una cuenta local o personal. Unido a Entra: equipos Windows de la empresa que inician sesión con la cuenta de Entra. Unido de forma híbrida: equipos unidos al Active Directory local y registrados también en Entra, considerado un paso intermedio hacia la unión directa.

En la propiedad deviceTrustType esos tres casos se escriben así: Workplace es registrado, AzureAD es unido a Entra y ServerAD es unido de forma híbrida. Aparte está la conformidad: el gestor de dispositivos evalúa el equipo con las reglas de la empresa y lo marca como conforme o no; una política puede exigir ese resultado. Un dispositivo sin identidad no puede ser conforme, porque ni existe para el directorio.

Contabilidad reclama un inicio de sesión sospechoso del 2026-08-20. La revisión es del 2026-10-05, y retencion.txt dice qué licencia tiene el tenant y si el registro se archivó en algún sitio. El que investiga necesita saber primero si la evidencia existe todavía; y si no, por cuánto se pasó el plazo.

Calcula cuántos días hay entre el 2026-08-20 y el 2026-10-05, y réstale lo que la licencia del tenant conserva. El resultado es cuántos días de más tiene el evento respecto del máximo que se guarda.

El modo solo informe evalúa la política en cada inicio de sesión y registra el resultado, pero no aplica los controles. En el registro, cada política que se evaluó lleva un resultado: success, failure y notApplied para las activas, y reportOnlySuccess, reportOnlyFailure y reportOnlyNotApplied para las que están en solo informe. Un reportOnlyFailure quiere decir que se cumplieron las condiciones de la política pero no sus controles: si estuviera activa, ese acceso no habría pasado como pasó. Cuando el control exige una acción del usuario, como contestar un aviso de MFA, el informe no puede saber si la cumpliría y lo anota aparte.

La política CA-04 exige un dispositivo conforme para el ERP y está en solo informe. En inicios-de-sesion.txt cada fila trae el resultado de CA-04. Cuenta los inicios de sesión que no cumplirían CA-04 si ya estuviera activa.

La condición aplicaciones cliente distingue los clientes modernos (navegador, aplicaciones móviles y de escritorio) de los antiguos: Exchange ActiveSync clients y Other clients. Los antiguos no soportan MFA, y por eso se bloquean con una política propia. Por defecto, una política nueva se aplica a todos los tipos de cliente.

Para saber quién usa clientes antiguos se filtra el registro por la columna Client App, y se mira también la pestaña de inicios no interactivos. En la semana de inicios-de-sesion.txt una persona entró al correo con uno de esos clientes, y la política que lo habría bloqueado todavía no está activa.