Microsoft 365: por qué una cuenta no puede iniciar sesión, y cómo repararla

El módulo de Microsoft 365 conecta el tenant de cada cliente al panel y responde una pregunta concreta: por qué esa cuenta no puede entrar. El diagnóstico ejecuta diez controles contra Microsoft y expresa lo que encuentra con un catálogo de 21 hallazgos, cada uno con severidad fija y recomendación escrita de antemano. Cuando el hallazgo tiene reparación, la acción que lo corrige aparece al lado. El resultado sale en pantalla y en un informe PDF con la marca de tu MSP.

El módulo se abre desde la ficha del cliente, junto al resto de su información. No hay nada que instalar en el tenant ni credenciales del cliente que guardar: el vínculo se establece una sola vez, con el consentimiento del administrador de ese cliente, y se puede revocar desde el panel cuando quieras. El panel lee sin restricciones y escribe solo lo que ese administrador consintió y un técnico confirmó.

Conexión al tenant e inventario sincronizado

La conexión se hace tenant por tenant, uno por cada cliente del MSP, con el consentimiento del administrador de ese cliente. La aplicación se autentica con certificado, así que no hay un secreto compartido que haya que rotar a mano en cada tenant.

Cada sincronización trae el inventario del tenant: los usuarios con su estado de cuenta, su último acceso y las licencias que tienen asignadas, y los dispositivos gestionados por Intune.

En cada sincronización el panel sondea además qué puede leer en ese tenant: si hay Entra ID P1, si hay Intune y si hay Defender. Cuando Microsoft rechaza un permiso, el panel lo nombra en pantalla en lugar de dejar el dato en blanco.

El vencimiento de una licencia te llega antes que el llamado del cliente

La tabla de licencias muestra, por producto, cuántas unidades hay compradas, cuántas asignadas, cuántas disponibles, la fecha de vencimiento, los días restantes y el estado de la suscripción. Un cupo disponible en cero se marca, y uno negativo se muestra con su signo en lugar de maquillarse a cero.

Las suscripciones de servicio interno de Microsoft se separan de las compradas y se agrupan al final de la tabla, bajo un encabezado que dice lo que son. Microsoft aprovisiona por su cuenta suscripciones gratuitas con cupos de cientos de miles de unidades, y sumadas al total tapan lo que el cliente paga de verdad. No se ocultan, que sería negar un dato que existe: se separan.

Sobre esa tabla corre la detección, y son cuatro los avisos que abre: la licencia que está por vencer, con escalones a 30, 15, 7 y 1 día y severidad creciente; la suscripción que Microsoft dejó suspendida; el producto que se quedó sin cupos libres; y el que tiene más personas asignadas que licencias contratadas. Cada aviso entra en la misma bandeja de alertas del panel, se resuelve solo cuando la condición desaparece y se puede silenciar sin dejar de existir.

Ese es el valor concreto: el MSP se entera de que a un cliente se le venció una licencia, o de que hay gente colgada de una suscripción suspendida, antes de que el cliente llame porque dejó de andar el correo. Los tres casos que duelen hoy, la licencia ya vencida, la suspendida y el cupo negativo, abren además un ticket en la mesa de ayuda. Los escalones de vencimiento quedan como alerta y correo: si cada uno abriera ticket, en un mes la mesa sería toda de licencias.

En el listado de usuarios, cada persona muestra qué licencia tiene asignada con su nombre comercial y no con el identificador interno de Microsoft: Microsoft 365 Business Premium en lugar de SPB. Un identificador que el catálogo no tiene no se oculta ni se muestra en blanco, sale con su valor crudo y la aclaración de que el nombre comercial no está catalogado.

Diez controles por diagnóstico y 21 hallazgos catalogados

Cada diagnóstico ejecuta diez controles contra Microsoft, en este orden: salud del servicio, existencia y estado de la cuenta, licencias y planes de servicio, buzón, estado de la contraseña, métodos de autenticación registrados, últimos inicios de sesión, directivas de acceso condicional, riesgo del usuario y reglas de reenvío del buzón.

Lo que esos controles encuentran se expresa con el catálogo: 21 hallazgos, de los cuales 13 son críticos, 6 son de atención y 2 son informativos. Cada código lleva su severidad y su recomendación escritas desde antes de que exista el caso, así que dos técnicos leen exactamente el mismo criterio.

Los códigos de error de inicio de sesión de Entra ID se traducen a texto legible: el panel tiene 16 de ellos catalogados. Un código que no está en la tabla no se esconde ni se descarta, sale con su número y con la aclaración de que no está catalogado.

El diagnóstico se descarga en PDF con la marca de tu MSP: tu logo y el encabezado de tu empresa. El nombre de KairosLink no aparece en ninguna parte del documento, así que el informe se puede reenviar al cliente tal como se descarga.

Reparar desde donde se ve el problema

El diagnóstico no termina en un informe. Cuando un hallazgo tiene reparación, la acción que lo corrige aparece al lado del hallazgo, en el mismo renglón donde se lee el problema, y también en el menú de cada cuenta del listado de usuarios. No hay que memorizar dónde se arregla cada cosa ni salir del diagnóstico para ir a buscarlo.

Son tres las acciones correctivas sobre una cuenta del tenant, y son las que están escritas en el código: revocar las sesiones activas, que invalida los tokens emitidos y obliga a la persona a iniciar sesión de nuevo en todos sus dispositivos y aplicaciones; habilitar la cuenta que está deshabilitada, para que la persona vuelva a poder entrar a los servicios de Microsoft 365; y forzar el cambio de contraseña, que exige definir una contraseña nueva en el próximo inicio de sesión.

Ninguna se ejecuta con un clic. Cada una pasa por una confirmación previa que nombra la cuenta, el tenant y el cliente sobre los que se va a actuar, y describe el efecto concreto sobre la persona: que va a tener que volver a iniciar sesión hasta en el correo del teléfono, o que su contraseña actual deja de servir apenas la cambie. No es un aviso de estás seguro, es la consecuencia escrita antes de que ocurra.

Cada intento queda registrado, salga bien o salga mal, con el técnico que lo disparó, la cuenta afectada, la fecha y el resultado. El historial se consulta por cliente, de lo más reciente a lo más antiguo, y los intentos rechazados figuran igual que los exitosos: un historial que solo mostrara lo que salió bien no serviría para auditar nada. La acción escribe además su evento en el registro de auditoría de seguridad del panel.

Cuando el permiso que una acción necesita no está consentido, la acción no se ejecuta y el panel nombra el permiso exacto que hay que consentir en el portal de Microsoft, junto con el permiso amplio que también la habilita. El panel nunca agrega permisos por su cuenta: no consulta ni modifica el registro de aplicación en Entra ID. La decisión sobre qué puede hacer el proveedor dentro del tenant queda siempre del lado del cliente, y se toma en el portal de Microsoft.

No poder ver no es lo mismo que no haber encontrado nada

Este es el eje del módulo. Cuando falta una licencia del tenant, un permiso consentido o una capacidad, el panel lo dice con esas palabras y nombra el motivo concreto. Un dato ausente nunca se presenta como un dato negativo.

El caso más claro es el historial de inicios de sesión, que requiere Entra ID P1. Si el tenant no lo tiene, el módulo emite un hallazgo informativo que lo explica y excluye del diagnóstico los hallazgos que dependían de ese historial: no se afirma nada sobre lo que no se pudo mirar.

Por el mismo motivo, un control que no se pudo ejecutar jamás se cuenta como control aprobado. El diagnóstico tiene una sección propia para eso, y cada control sin ejecutar aparece ahí con su motivo escrito: falta la licencia que el control requiere, falta consentir un permiso que se nombra, o el informe de Microsoft llegó sin datos del período.

El resumen separa además el contexto del tenant de los hallazgos de la cuenta. Un incidente o un aviso de servicio publicado por Microsoft sale idéntico en el diagnóstico de todas las personas de ese tenant, así que se muestra arriba y aparte, y no cuenta en los contadores de la cuenta.

El criterio vive en el código, no en un modelo de lenguaje

El segundo diferencial es la reproducibilidad. La evaluación está escrita en el código del panel: los mismos datos producen siempre los mismos hallazgos, con la misma severidad y el mismo texto. Ninguna inteligencia artificial interviene en el criterio, ni para clasificar ni para redactar.

Ese criterio se puede auditar sin abrir el código fuente: una pantalla del panel lista los 21 controles del catálogo, cada uno con su severidad, su recomendación y el enlace a la documentación de Microsoft cuando existe, junto con la tabla de códigos de error de inicio de sesión.

El alcance se declara sin vueltas: el panel lee sin restricciones lo que el tenant le deja leer, y escribe solo lo que el administrador del cliente consintió y un técnico confirmó. Las tres acciones correctivas son la única parte del módulo que escribe en Microsoft. El diagnóstico y la sincronización consultan y muestran, y cada diagnóstico lo dispara una persona sobre una cuenta que esa persona eligió.

Preguntas frecuentes