Lesson 2: Behind the Prompt: Accounts, Tokens and Sessions

Three kinds of account behind one sign-in box

Every user sees the same Microsoft sign-in prompt. Behind it the account can work in three different ways. Before you touch a ticket, find out which kind you have. That tells you where the fix belongs and how soon it will take effect.

Here's an analogy. A cloud-only account is a staff badge printed at head office. A synced account is printed at the branch and copied to head office: if you change the head-office copy, the next copy from the branch overwrites it. A federated account means head office phones the branch to ask "is this person who they say they are?" every time.

Walkthrough: which kind is this user?

In the portal: go to the Microsoft Entra admin center (entra.microsoft.com), then Entra ID > Users > All users, and open the user. Look at the on-premises fields on the Overview or Properties page:

• On-premises sync enabled = Yes: synced. Most identity fields are greyed out because AD is the source of authority.
• The field is blank or No: cloud-only.

In PowerShell (read-only):

# Read-only scopes: you can look but not change
Connect-MgGraph -Scopes "User.Read.All","Domain.Read.All"

# The on-premises properties only come back if you ask for them
Get-MgUser -UserId sam.patel@contoso.com `
  -Property DisplayName,OnPremisesSyncEnabled,OnPremisesLastSyncDateTime,OnPremisesImmutableId |
  Format-List DisplayName,OnPremises*

# Sample output for a synced user:
# DisplayName                : Sam Patel
# OnPremisesSyncEnabled      : True          <- synced from AD
# OnPremisesLastSyncDateTime : 02/11/2026 09:14:07  <- stale? sync may be broken
# OnPremisesImmutableId      : q8F1...==     <- link to the AD object

# Is the sign-in domain federated?
Get-MgDomain -DomainId contoso.com | Select-Object Id, AuthenticationType
# Id           AuthenticationType
# contoso.com  Federated        <- the password is checked by the federation server, not Entra
# (Managed = Entra handles sign-in itself)

Gotcha: a synced user can sit on a Managed domain. Federation belongs to the domain, and sync belongs to the user. Check both.

Why the fix doesn't bite straight away: tokens and sessions

When a user signs in, Entra doesn't check them again on every click. It hands the app some tokens:

• An access token is the ticket the app shows to Exchange, SharePoint and so on. By default it lasts a random 60–90 minutes, about 75 on average.
• A refresh token lets the app quietly get new access tokens without a prompt. It lasts up to 90 days by default, or 24 hours for single-page web apps.
• Browser session cookies do the same job for web sign-ins.

So when you reset a password or block an account, an app that already holds a valid access token can keep working until that token runs out. This is the classic "I blocked him but he's still in Outlook" ticket.

What each action actually kills, according to Microsoft's refresh-token documentation (checked November 2026):

• Admin password reset in the Entra admin center revokes password-based refresh tokens and cookies. A browser session that started with a passkey or Windows Hello (non-password-based) stays alive.
• Revoke sessions revokes all refresh tokens and cookies, of every kind.
• Neither action recalls an access token that has already been issued. That token runs until it expires.

The exception is continuous access evaluation (CAE). Exchange Online, SharePoint Online and Teams listen for critical events such as account disabled or deleted, password changed or reset, and admin revocation. They act on them in near real time, though Microsoft says it can take up to 15 minutes. CAE sessions use long-lived tokens of up to 28 hours, so in those apps revocation is what ends the session, not token expiry.

Walkthrough: revoke sessions

Portal: Entra ID > Users > All users, select the user, then on Overview select Revoke sessions.

# Needs write scope, so only run it once you've decided to act
Connect-MgGraph -Scopes "User.ReadWrite.All"
Revoke-MgUserSignInSession -UserId sam.patel@contoso.com
# Returns True. Every app must now come back to Entra for a new token,
# and Entra checks the block, new password and Conditional Access again.

Best practice: after a reset or block, revoke sessions too, then watch the sign-in log. What to tell the user: "You'll be asked to sign in again on each device, which is expected."

Faults that live on-premises

For a synced or federated user, these usually start in AD or the federation server, not in Entra:

• You can't edit a name, UPN or account status in Entra. It's greyed out because AD owns it. Make the change in AD, or hand it to whoever runs AD.
• An edit made in AD hasn't appeared yet. The default delta sync runs every 30 minutes. Password hash sync runs about every 2 minutes.
• Self-service reset fails with an "on-premises configuration" error. Password writeback is broken, or the new password breaks the AD password policy (complexity, history).
• A federated user is locked out or gets a password error. The lockout comes from AD or the federation server, so Entra-side fixes won't help.
• An account disabled in Entra comes back enabled. The next sync overwrote it. Disable it in AD.

These are usually cloud faults for any account type: MFA method registration, Temporary Access Pass, Conditional Access blocks, and licences.

Key takeaways

• Check On-premises sync enabled on the user and AuthenticationType on the domain before you change anything.
• For synced users, AD is the source of authority, so fix identity data there.
• Access tokens (60–90 minutes) outlive a reset or block. CAE-aware apps (Exchange, SharePoint, Teams) cut in near real time, but it can take up to 15 minutes.
• Revoke sessions kills all refresh tokens and cookies. A password reset alone can leave passkey or Windows Hello browser sessions alive.
• Lockouts, writeback failures and "my change didn't stick" usually point on-premises.