We’ll cover token types and lifetimes first, then explore how Conditional Access policies influence them, the ties to MFA and authentication strengths, resource and application access patterns, and finally, who (or what) can end a token’s life—think admin revocations or even a simple laptop hibernation.

Token Types in Entra ID: The Building Blocks

Entra ID issues several token varieties, each serving a distinct role in the authentication and authorization flow. They primarily follow OAuth 2.0 and OpenID Connect standards, with JSON Web Tokens (JWTs) as the common format for portability and verifiability.

Here’s a quick comparison table of the core token types:

Access tokens are the workhorses for resource calls—clients send them to APIs, which validate claims like audience (aud) and issuer (iss) against OpenID Connect metadata. ID tokens, meanwhile, are client-facing proofs of auth, packed with user claims but unsuitable for authorization. Refresh tokens keep sessions alive by trading themselves for fresh pairs, while PRTs supercharge device SSO, embedding compliance info for Conditional Access checks.

Scenario: Building a Multi-Tenant App
Imagine developing a SaaS tool that integrates with Microsoft 365. You request an authorization code flow, yielding an ID token for user login (verifying aud matches your app ID) and an access token scoped to Mail.Read. A refresh token handles token rotation every 90 days. For device users, a PRT enables silent SSO across tenants.

Token Lifetimes: Defaults, Configurability, and Variability

Token lifetimes balance security (short-lived = less exposure) with usability (no constant re-auth). Entra ID defaults are randomized for resilience, but you can tweak them via policies.

• Access Tokens: 60-90 minutes (avg. 75 min), variable to avoid thundering herd issues. With Conditional Access Sign-in Frequency (SIF), add the interval (e.g., 1-hour SIF + 75-min token = up to 2.5-hour sessions). Configurable: 10 min to 1 day via Token Lifetime Policies (TLPs).
• ID Tokens: Fixed 1 hour. Configurable: 10 min to 1 day, controlling app session expiry.
• Refresh Tokens: 24 hours (SPAs, due to cookie restrictions) or 90 days (others). Self-renewing; max inactive period is 90 days. Not configurable—use SIF instead.
• PRTs: 90 days, renewed every 4 hours on Windows (or on reconnect). Limited by SIF controls.

Configurable Token Lifetimes (CTL): Apply organization-wide or per-app/service principal via Microsoft Graph (e.g., New-MgPolicyTokenLifetimePolicy). Requires Entra ID P1. Can’t override for refresh/PRT; SAML tokens get 1-hour default + 5-min skew.

Table: Lifetime Impacts by Feature

Scenario: Enforcing Shorter Lifetimes for High-Risk Apps
For a finance app, set a TLP to 15-min access tokens. Users re-auth every 15 min, but a 90-day refresh token minimizes prompts—until SIF kicks in for weekly interactive MFA.

Conditional Access Policies: Shaping Token Behavior

Conditional Access (CA) policies dynamically evaluate signals like user risk, location, and device compliance to grant/deny access, directly influencing tokens.

• Session Lifetime Controls: Use “Sign-in frequency” to cap sessions (e.g., every 8 hours), overriding token expiry for re-eval. “Persistent browser session” extends via PRT for compliant devices.
• Token Protection: A CA session control binding refresh tokens to devices (via PRT) to thwart replay attacks. Enforced for Exchange/Teams/SharePoint; blocks unbound tokens with errors like 1002 (no device state).
• Continuous Access Evaluation (CAE): Extends access tokens to 28 hours while monitoring real-time events (e.g., account disable). Revokes via claim challenges on policy violations, integrated with CA for IP/location checks.

Scenario: CA for Remote Workers
Policy: Require compliant device + MFA for VPN access. On violation (e.g., risky IP), CAE revokes the 28-hour token instantly, forcing re-auth. Token Protection ensures only the bound device succeeds.

MFA Correlation, Authentication Strengths, and Auth Types

MFA ties deeply to tokens: Entra requires MFA satisfaction for tokens with MFA claims, embedding proofs in ID/access tokens. Authentication strengths refine this in CA, specifying method combos (e.g., password + Authenticator app).

Built-in Strengths (non-editable):

• MFA Strength: Password + any “something you have” (e.g., Authenticator push).
• Passwordless MFA: FIDO2 key or Windows Hello (no password).
• Phishing-Resistant MFA: FIDO2/CBA (multi-factor certs) for proof-of-possession.

Custom strengths allow tailoring (e.g., FIDO2 + biometrics). Evaluated post-initial auth; unsatisfied prompts registration.

Auth Types Covered:

• OAuth 2.0: For access tokens (delegated/implicit flows).
• OpenID Connect: Layers ID tokens on OAuth for auth.
• SAML: Federated tokens (1-hour default).

Scenario: Risk-Based MFA
High-risk sign-in? CA policy requires Phishing-Resistant MFA strength. User taps FIDO2 key; token issues with claims proving resistance. Without it, access denied—correlating MFA directly to token validity.

Table: MFA Methods by Strength

Resource and Application Access: Tokens in Action

Tokens drive access: Access tokens scope permissions (e.g., User.Read) for APIs; ID tokens bootstrap app sessions. Apps validate via metadata endpoints (e.g., /v2.0/.well-known/openid-configuration). For applications, PRTs enable SSO; refresh tokens support background access.

Sample Flow (OAuth 2.0 + OIDC):

1. User auths → ID token issued (1-hour life).
2. App requests access token for Graph API → Scoped to resource.
3. Expiry? Refresh token swaps for new pair.
   CA might interject: “Require MFA strength” → Token only if satisfied.

Scenario: API Access in a Web App
A React SPA uses MSAL.js: On login, gets ID token for UI, access token for backend proxy to Graph. CA policy blocks if from untrusted IP, revoking via CAE.

Terminating Tokens: Revocation, Actions, and Scenarios

Tokens don’t last forever—revocation ensures security. Who can terminate? Admins (via roles like Global Admin) revoke all refresh/PRTs per user (Revoke-MgUserSignInSession). Users self-revoke via portal. Apps enforce based on policies.

Actions/Scenarios:

• Admin Revoke: Instant for refresh/PRTs; access tokens expire naturally (1 hour). Impacts: New tokens blocked; sessions end on expiry.
• Password Change/SSPR: Invalidates non-password-based tokens; PRTs require re-issue.
• Account Disable/Delete: PRTs/tokens invalidated; cached sessions may linger until detection.
• Network Disconnect: PRTs cached for offline SSO (up to 90 days); no termination, but renewal waits for reconnect (every 4 hours on Windows).
• System Hibernation: No direct termination—PRT remains valid. Renewal delayed until wake + internet; if >90 days inactive, expires. TPM issues (e.g., post-hibernation failure) trigger recovery, invalidating PRT.
• CAE Event: High risk? Policy revokes mid-session via claim challenge.

Scenario: Emergency Revocation
Suspected compromise: Admin disables account + revokes sessions. User on hibernated laptop wakes to expired PRT; network reconnect fails renewal due to disable—forced re-auth reveals block.

Table: Termination Triggers

In summary, Entra ID tokens are a symphony of security and convenience—tune them wisely with CA and strengths. For hands-on, check the Graph API for TLPs or test CA policies in report-only mode.

References

• Microsoft Docs on Access Tokens.
• ID Tokens.
• Refresh Tokens.
• Configurable Lifetimes.
• PRT Overview.
• CAE.
• Token Protection.
• Auth Strengths.
• Revoke Access.
• Auth Strength How-To.

I had a similar problem with a newly promoted domain controller which I previously blogged about here.

Scenarios where this problem typically occurs:

• Replication was moved  from FRS to DFSR
• Demoting an old domain controller in the environment
• When there is a problem with the DFS replication of the SYSVOL folder

To solve this problem, I had to manually perform an authoritative synchronization between the domain controllers.

I am including steps for authoritative and non-authoritative synchronization, but before we get started we need to see the state of the replication.

Steps:

1. Find the state of the replication state. Typically the problem DCs will be at 0 or 2. The goal is to get to state 4.
2. Get to State 2
3. Get to State 4

Find the state of the replication of all DCs

For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state

The states should translate as below

0 = Uninitialized
1 = Initialized
2 = Initial Sync
3 = Auto Recovery
4 = Normal
5 = In Error

Non-authoritative synchronization of DFSR-replicated SYSVOL

• Stop the DFS Replication service (net stop dfsr).
• In the ADSIEDIT.MSC tool modify the following distinguished name (DN) value and attribute on each of the domain controllers that you want to make non-authoritative:
  CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
  msDFSR-Enabled=FALSE
  
• Force Active Directory replication throughout the domain  (repadmin /syncall primary_dc_name /APed )
• Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:
  DFSRDIAG POLLAD 
• You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated (Open up event viewer and navigate to Applications and Services Logs -> DFS Replication).
• On the same DN from Step 1, set:
  msDFSR-Enabled=TRUE
  
• Force Active Directory replication throughout the domain (repadmin /syncall primary_dc_name /APed).
• Start the DFS Replication service (net start dfsr).
• Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:

  DFSRDIAG POLLAD

• You will see Event ID 4614 and 4604 in the DFSR event log indicating SYSVOL has been initialized. That domain controller has now done non-authoritative sync of SYSVOL.
• Run Wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicationgroupname,replicatedfoldername,stat and make sure the state is at 4. If it is at 2, it may take some time to reach state 4. Wait a few minutes and try again until all DCs are at state 4.

Authoritative synchronization of DFSR-replicated SYSVOL

1. Find the PDC Emulator (Elevated Command Prompt: netdom query fsmo ) – which is usually the most up to date for SYSVOL contents. Or the server holding all the policies and scripts. Consider this the primary server.
2. Stop the DFS Replication service (net stop dfsr) on the primary server.
3. On the primary server, In the ADSIEDIT.MSC tool, modify the following DN and two attributes to make authoritative:
   CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
   msDFSR-Enabled=FALSE
   msDFSR-options=1
   
4. Modify the following DN and single attribute on all other domain controllers in that domain:
   CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>
   msDFSR-Enabled=FALSE
   
5. Force Active Directory replication throughout the domain and validate its success on all DCs (repadmin /syncall primary_dc_name /APed). Probably need to run the same command 3-4 times.
6. Start the DFSR service set as authoritative (net start dfsr) on the primary DC.
7. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated (Open up event viewer and navigate to Applications and Services Logs -> DFS Replication).
8. On the same DN from Step 1, set:
   msDFSR-Enabled=TRUE
   
9. Force Active Directory replication throughout the domain and validate its success on all DCs (repadmin /syncall primary_dc_name /APed ). Probably need to run the same command 3-4 times.
10. Run the following command from an elevated command prompt on the same server that you set as authoritative (primary server):
    DFSRDIAG POLLAD 
11. Wait a few minutes you will see Event ID 4602 in the DFSR event log (Open up event viewer and navigate to Applications and Services Logs -> DFS Replication) indicating SYSVOL has been initialized. That domain controller has now done an authoritative sync of SYSVOL.
12. Start the DFSR service on the other non-authoritative DCs (net start dfsr). You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated on each of them.
13. Modify the following DN and single attribute on all other domain controllers in that domain:
    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>
    msDFSR-Enabled=TRUE
    
14. Run the following command from an elevated command prompt on all non-authoritative DCs (i.e. all but the formerly authoritative one):

    DFSRDIAG POLLAD

15. Verify you see Event ID 2002 and 4602 on all other domain controllers.
16. Run Wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicationgroupname,replicatedfoldername,stat and make sure the state is at 4. If it is at 2, it may take some time to reach state 4. Wait a few minutes and try again until all DCs are at state 4.

[su_note note_color=”#f9f4ca” text_color=”#000000″ radius=”2″]If setting the authoritative flag on one DC, you must non-authoritatively synchronize all other DCs in the domain. Otherwise, you will see conflicts on DCs, originating from any DCs where you did not set auth/non-auth and restarted the DFSR service. For example, if all logon scripts were accidentally deleted and a manual copy of them was placed back on the PDC Emulator role holder, making that server authoritative and all other servers non-authoritative would guarantee success and prevent conflicts. If making any DC authoritative, the PDC Emulator as authoritative is preferable, since its SYSVOL contents are usually most up to date. The use of the authoritative flag is only necessary if you need to force synchronization of all DCs. If only repairing one DC, simply make it non-authoritative and do not touch other servers. This article is designed with a 2-DC environment in mind, for simplicity of description. If you had more than one affected DC, expand the steps to includeALL of those as well. It also assumes you have the ability to restore data that was deleted, overwritten, damaged, etc. previously if this is a disaster recovery scenario on all DCs in the domain.[/su_note]

After these actions, all problems with GPO processing and SYSVOL replication disappeared.