Microsoft 365: why an account cannot sign in, and how to repair it

The Microsoft 365 module connects each customer tenant to the console and answers one concrete question: why that account cannot sign in. The diagnostic runs ten checks against Microsoft and expresses what it finds through a catalogue of 21 findings, each with a fixed severity and a recommendation written in advance. When a finding has a repair, the action that fixes it sits right next to it. The result appears on screen and in a PDF report under your MSP brand.

The module opens from the customer record, next to the rest of their information. There is nothing to install in the tenant and no customer credentials to store: the link is established once, with the consent of that customer administrator, and it can be revoked from the console whenever you want. The console reads without restrictions and writes only what that administrator consented to and a technician confirmed.

Tenant connection and synchronised inventory

The connection is made tenant by tenant, one per MSP customer, with the consent of that customer administrator. The application authenticates with a certificate, so there is no shared secret to rotate by hand in every tenant.

Every synchronisation brings in the tenant inventory: users with their account status, their last sign-in and the licenses assigned to them, plus the devices managed by Intune.

On every synchronisation the console also probes what it can read in that tenant: whether there is Entra ID P1, whether there is Intune and whether there is Defender. When Microsoft denies a permission, the console names it on screen instead of leaving the value blank.

A license expiry reaches you before the customer call does

The license table shows, per product, how many units were purchased, how many are assigned, how many are available, the renewal date, the days left and the status of the subscription. An available count of zero is flagged, and a negative one is shown with its sign instead of being dressed up as a zero.

Microsoft internal service subscriptions are split from the purchased ones and grouped at the end of the table, under a heading that says what they are. Microsoft provisions free subscriptions of its own with quotas of hundreds of thousands of units, and added to the total they bury what the customer actually pays for. They are not hidden, which would deny a value that exists: they are separated.

Detection runs on top of that table, and it raises four alerts: the license about to expire, with steps at 30, 15, 7 and 1 day and rising severity; the subscription Microsoft left suspended; the product that ran out of free seats; and the one with more people assigned than licenses contracted. Every alert lands in the same alert inbox as the rest of the console, resolves on its own when the condition disappears, and can be silenced without ceasing to exist.

That is the concrete value: the MSP finds out that a customer license expired, or that people are hanging off a suspended subscription, before the customer calls because email stopped working. The three cases that hurt today, the already expired license, the suspended one and the negative seat count, also open a ticket in the help desk. The expiry steps stay as an alert and an email: if every step opened a ticket, in a month the desk would be all licenses.

In the user list, every person shows which license they have assigned under its commercial name and not under the Microsoft internal identifier: Microsoft 365 Business Premium instead of SPB. An identifier the catalogue does not have is neither hidden nor shown blank, it comes out with its raw value and a note saying the commercial name is not catalogued.

Ten checks per diagnostic and 21 catalogued findings

Every diagnostic runs ten checks against Microsoft, in this order: service health, account existence and status, licenses and service plans, mailbox, password status, registered authentication methods, latest sign-ins, conditional access policies, user risk and mailbox forwarding rules.

What those checks find is expressed through the catalogue: 21 findings, of which 13 are critical, 6 need attention and 2 are informational. Every code carries its severity and its recommendation written before the case ever exists, so two technicians read exactly the same criteria.

Entra ID sign-in error codes are translated into readable text: the console has 16 of them catalogued. A code that is not in the table is neither hidden nor discarded, it comes out with its raw number and a note saying it is not catalogued.

The diagnostic downloads as a PDF under your MSP brand: your logo and your company heading. The KairosLink name appears nowhere in the document, so the report can be forwarded to the customer exactly as it downloads.

Repair from where the problem is visible

The diagnostic does not end in a report. When a finding has a repair, the action that fixes it appears next to the finding, on the same line where the problem is read, and also in the menu of each account in the user list. There is nothing to memorise about where each thing gets fixed and no need to leave the diagnostic to go looking for it.

There are three corrective actions on a tenant account, and they are the ones written in the code: revoke active sessions, which invalidates the issued tokens and forces the person to sign in again on every device and application; enable a disabled account, so the person can get back into the Microsoft 365 services; and force a password change, which requires setting a new password at the next sign-in.

None of them runs on a single click. Each one goes through a confirmation that names the account, the tenant and the customer being acted on, and describes the concrete effect on the person: that they will have to sign in again, down to the mail app on their phone, or that their current password stops working as soon as they change it. It is not an are-you-sure prompt, it is the consequence written out before it happens.

Every attempt is recorded, whether it succeeds or fails, with the technician who triggered it, the account affected, the date and the result. The history is read per customer, newest first, and rejected attempts appear alongside successful ones: a history that only showed what went well would audit nothing. The action also writes its event into the console security audit log.

When a consented permission is missing, the action does not run and the console names the exact permission to consent in the Microsoft portal, along with the broad permission that also enables it. The console never adds permissions on its own: it neither reads nor modifies the application registration in Entra ID. The decision about what the provider may do inside the tenant always stays on the customer side, and it is made in the Microsoft portal.

Not being able to see is not the same as having found nothing

This is the core of the module. When a tenant license, a consented permission or a capability is missing, the console says so in those words and names the concrete reason. A missing value is never presented as a negative value.

The clearest case is the sign-in history, which requires Entra ID P1. If the tenant does not have it, the module emits an informational finding that explains it and excludes from the diagnostic the findings that depended on that history: nothing is asserted about what could not be looked at.

For the same reason, a check that could not run is never counted as a check that passed. The diagnostic has its own section for that, and every unexecuted check appears there with its reason written out: the license the check requires is missing, a permission that gets named is not consented, or the Microsoft report came back with no data for the period.

The summary also separates tenant context from account findings. An incident or a service advisory published by Microsoft comes out identical in the diagnostic of every person in that tenant, so it is shown above and apart, and it does not count in the account counters.

The criteria live in the code, not in a language model

The second differentiator is reproducibility. The evaluation is written in the console code: the same data always produces the same findings, with the same severity and the same text. No artificial intelligence takes part in the criteria, neither to classify nor to write.

Those criteria can be audited without opening the source code: a console screen lists the 21 catalogue checks, each with its severity, its recommendation and the link to the Microsoft documentation where one exists, along with the table of sign-in error codes.

The scope is declared plainly: the console reads without restrictions whatever the tenant lets it read, and writes only what the customer administrator consented to and a technician confirmed. The three corrective actions are the only part of the module that writes to Microsoft. The diagnostic and the synchronisation query and display, and every diagnostic is triggered by a person on an account that person picked.

Frequently asked questions