Microsoft 365: por que uma conta não consegue entrar, e como reparar

O módulo Microsoft 365 conecta cada tenant de cliente ao console e responde a uma pergunta concreta: por que aquela conta não consegue entrar. O diagnóstico roda dez verificações contra a Microsoft e expressa o que encontra por um catálogo de 21 apontamentos, cada um com severidade fixa e uma recomendação escrita de antemão. Quando um apontamento tem reparo, a ação que o corrige fica bem ao lado dele. O resultado aparece na tela e em um relatório PDF com a marca do seu MSP.

O módulo abre a partir do cadastro do cliente, junto com o resto das informações dele. Não há nada para instalar no tenant nem credenciais do cliente para armazenar: o vínculo é estabelecido uma vez, com o consentimento daquele administrador do cliente, e pode ser revogado pelo console quando você quiser. O console lê sem restrições e grava apenas o que aquele administrador consentiu e um técnico confirmou.

Conexão do tenant e inventário sincronizado

A conexão é feita tenant a tenant, um por cliente do MSP, com o consentimento daquele administrador do cliente. O aplicativo se autentica com um certificado, então não há segredo compartilhado para rotacionar à mão em cada tenant.

Cada sincronização traz o inventário do tenant: usuários com o status da conta, o último login e as licenças atribuídas a eles, além dos dispositivos gerenciados pelo Intune.

A cada sincronização o console também sonda o que consegue ler naquele tenant: se há Entra ID P1, se há Intune e se há Defender. Quando a Microsoft nega uma permissão, o console dá o nome dela na tela em vez de deixar o valor em branco.

Um vencimento de licença chega até você antes da ligação do cliente

A tabela de licenças mostra, por produto, quantas unidades foram compradas, quantas estão atribuídas, quantas estão disponíveis, a data de renovação, os dias restantes e o status da assinatura. Um número de disponíveis igual a zero é sinalizado, e um negativo é mostrado com o sinal dele em vez de ser maquiado como zero.

As assinaturas de serviços internos da Microsoft são separadas das compradas e agrupadas no fim da tabela, sob um título que diz o que elas são. A Microsoft provisiona assinaturas gratuitas próprias com cotas de centenas de milhares de unidades e, somadas ao total, elas enterram o que o cliente de fato paga. Elas não são escondidas, o que negaria um valor que existe: elas são separadas.

A detecção roda em cima dessa tabela e levanta quatro alertas: a licença perto de vencer, com degraus em 30, 15, 7 e 1 dia e severidade crescente; a assinatura que a Microsoft deixou suspensa; o produto que ficou sem licenças disponíveis; e o que tem mais pessoas atribuídas do que licenças contratadas. Cada alerta cai na mesma caixa de alertas do resto do console, se resolve sozinho quando a condição desaparece e pode ser silenciado sem deixar de existir.

Esse é o valor concreto: o MSP descobre que uma licença do cliente venceu, ou que há pessoas penduradas em uma assinatura suspensa, antes de o cliente ligar porque o e-mail parou de funcionar. Os três casos que doem hoje, a licença já vencida, a suspensa e a contagem negativa de licenças, também abrem um chamado no service desk. Os degraus de vencimento ficam como alerta e e-mail: se cada degrau abrisse um chamado, em um mês o service desk seria só licenças.

Na lista de usuários, cada pessoa mostra qual licença tem atribuída pelo nome comercial e não pelo identificador interno da Microsoft: Microsoft 365 Business Premium em vez de SPB. Um identificador que o catálogo não tem não é escondido nem mostrado em branco, ele sai com o valor bruto e uma nota dizendo que o nome comercial não está catalogado.

Dez verificações por diagnóstico e 21 apontamentos catalogados

Cada diagnóstico roda dez verificações contra a Microsoft, nesta ordem: saúde do serviço, existência e status da conta, licenças e planos de serviço, caixa de correio, status da senha, métodos de autenticação registrados, últimos logins, políticas de acesso condicional, risco do usuário e regras de encaminhamento da caixa de correio.

O que essas verificações encontram é expresso pelo catálogo: 21 apontamentos, dos quais 13 são críticos, 6 requerem atenção e 2 são informativos. Cada código carrega a sua severidade e a sua recomendação escritas antes de o caso existir, então dois técnicos leem exatamente o mesmo critério.

Os códigos de erro de login do Entra ID são traduzidos para texto legível: o console tem 16 deles catalogados. Um código que não está na tabela não é escondido nem descartado, ele sai com o número bruto e uma nota dizendo que não está catalogado.

O diagnóstico é baixado como PDF com a marca do seu MSP: o seu logo e o cabeçalho da sua empresa. O nome KairosLink não aparece em lugar nenhum do documento, então o relatório pode ser encaminhado ao cliente exatamente como é baixado.

Repare a partir de onde o problema está visível

O diagnóstico não termina em um relatório. Quando um apontamento tem reparo, a ação que o corrige aparece ao lado dele, na mesma linha em que o problema é lido, e também no menu de cada conta na lista de usuários. Não há nada para decorar sobre onde cada coisa se conserta, nem necessidade de sair do diagnóstico para procurar.

São três ações corretivas em uma conta do tenant, e são as que estão escritas no código: revogar sessões ativas, o que invalida os tokens emitidos e obriga a pessoa a entrar de novo em cada dispositivo e aplicativo; habilitar uma conta desabilitada, para a pessoa voltar a acessar os serviços do Microsoft 365; e forçar a troca de senha, que exige definir uma senha nova no próximo login.

Nenhuma delas roda com um clique só. Cada uma passa por uma confirmação que nomeia a conta, o tenant e o cliente sobre os quais a ação é feita, e descreve o efeito concreto na pessoa: que ela vai ter que entrar de novo, até no aplicativo de e-mail do celular, ou que a senha atual dela para de funcionar assim que for trocada. Não é um aviso de "tem certeza?", é a consequência escrita antes de acontecer.

Cada tentativa fica registrada, com sucesso ou com falha, com o técnico que a disparou, a conta afetada, a data e o resultado. O histórico é lido por cliente, do mais recente para o mais antigo, e as tentativas recusadas aparecem ao lado das bem-sucedidas: um histórico que só mostrasse o que deu certo não auditaria nada. A ação também grava o evento dela no log de auditoria de segurança do console.

Quando falta uma permissão consentida, a ação não roda e o console dá o nome exato da permissão a consentir no portal da Microsoft, junto com a permissão ampla que também a habilita. O console nunca adiciona permissões por conta própria: ele não lê nem modifica o registro do aplicativo no Entra ID. A decisão sobre o que o provedor pode fazer dentro do tenant fica sempre do lado do cliente, e é tomada no portal da Microsoft.

Não conseguir ver não é a mesma coisa que não ter encontrado nada

Este é o núcleo do módulo. Quando falta uma licença do tenant, uma permissão consentida ou uma capacidade, o console diz isso com essas palavras e dá o motivo concreto. Um valor ausente nunca é apresentado como um valor negativo.

O caso mais claro é o histórico de logins, que exige Entra ID P1. Se o tenant não tem, o módulo emite um apontamento informativo que explica isso e exclui do diagnóstico os apontamentos que dependiam desse histórico: nada é afirmado sobre o que não pôde ser olhado.

Pelo mesmo motivo, uma verificação que não pôde rodar nunca é contada como verificação aprovada. O diagnóstico tem uma seção própria para isso, e toda verificação não executada aparece ali com o motivo escrito: falta a licença que a verificação exige, uma permissão que é nomeada não está consentida, ou o relatório da Microsoft voltou sem dados para o período.

O resumo também separa o contexto do tenant dos apontamentos da conta. Um incidente ou um aviso de serviço publicado pela Microsoft sai idêntico no diagnóstico de cada pessoa daquele tenant, então é mostrado acima e à parte, e não conta nos contadores da conta.

Os critérios vivem no código, não em um modelo de linguagem

O segundo diferencial é a reprodutibilidade. A avaliação está escrita no código do console: os mesmos dados sempre produzem os mesmos apontamentos, com a mesma severidade e o mesmo texto. Nenhuma inteligência artificial participa dos critérios, nem para classificar nem para escrever.

Esses critérios podem ser auditados sem abrir o código-fonte: uma tela do console lista as 21 verificações do catálogo, cada uma com a sua severidade, a sua recomendação e o link para a documentação da Microsoft onde houver, junto com a tabela de códigos de erro de login.

O escopo é declarado com todas as letras: o console lê sem restrições tudo o que o tenant deixa ler, e grava apenas o que o administrador do cliente consentiu e um técnico confirmou. As três ações corretivas são a única parte do módulo que grava na Microsoft. O diagnóstico e a sincronização consultam e exibem, e cada diagnóstico é disparado por uma pessoa em uma conta que essa pessoa escolheu.

Perguntas frequentes