Token Lifetime und Session-Probleme – warum sich alle ständig neu anmelden

Wenn die halbe Belegschaft stöhnt, sie müsse sich „gefühlt zehnmal am Tag" neu anmelden, greifen viele Admins reflexartig zur Token-Lebensdauer und drehen sie hoch. Falsche Schraube. Die nervigen Prompts kommen fast nie vom Access Token, sondern von der Sign-in Frequency in deinen Conditional-Access-Policies — und wer das verwechselt, macht den Tenant unsicherer, ohne das Problem zu lösen.

Drei Uhren, drei Lebensdauern — nur eine davon erzeugt die nervigen Neu-Anmeldungen.

Access Token, Refresh Token, Session: drei Uhren, die keiner auseinanderhält

Bei jeder Anmeldung in Entra ID (früher Azure AD) laufen drei verschiedene Zeitgeber, und genau hier entsteht die Verwirrung. Der Access Token ist bewusst kurzlebig — meist 60 bis 90 Minuten. Der Refresh Token lebt deutlich länger und holt im Hintergrund stillschweigend neue Access Tokens, solange er aktiv genutzt wird. Und die Sign-in Frequency ist eine Conditional-Access-Session-Control, die unabhängig von beidem eine Neu-Authentifizierung erzwingt.

Warum der stille Refresh meistens funktioniert — und wann nicht

Im Normalfall ist ein abgelaufener Access Token ein Nicht-Ereignis: Der Client löst im Hintergrund den Refresh Token ein, Entra ID prüft kurz, ob die Conditional-Access-Bedingungen noch erfüllt sind, und gibt einen frischen Access Token zurück. Der User tippt nichts, sieht nichts, merkt nichts. Erst wenn diese Hintergrundprüfung „Nein" sagt, wird eine sichtbare Neu-Anmeldung erzwungen.

Solange Conditional Access beim Refresh zustimmt, bleibt der User unbehelligt — sonst kommt der Prompt.

Die typischen Auslöser für ein „Nein" sind: Die Sign-in Frequency ist abgelaufen, Identity Protection meldet ein erhöhtes Risiko, oder ein Continuous-Access-Evaluation-Event (etwa ein deaktivierter Account oder ein gesperrtes Gerät) fordert eine sofortige Neubewertung. Alle drei stehen im Sign-in Log — und damit weißt du, an welcher Schraube du tatsächlich drehen musst.

Die richtige Schraube finden: Symptom zuerst, Hebel danach

Bevor du irgendeine Einstellung änderst, ordne das Symptom ein. „Ständig neu anmelden", „bleibe nie eingeloggt" und „plötzlich rausgeflogen" sind drei völlig verschiedene Probleme mit drei völlig verschiedenen Lösungen. Wer das Symptom überspringt und gleich an Einstellungen schraubt, behebt im besten Fall nichts und reißt im schlimmsten Fall ein Sicherheitsloch auf.

Erst das Symptom benennen, dann den passenden Conditional-Access-Hebel ziehen.

Die Lizenz-Ebene entscheidet mit, welche Hebel du überhaupt hast:

Konfigurierbare Token Lifetimes per PowerShell – mit Vorsicht

Für Sonderfälle (etwa eine streng regulierte App, die kürzere Sessions verlangt) lassen sich Token-Lebensdauern über eine Conditional-Access-Authentifizierungssitzungs-Policy steuern. Den Status deiner aktuellen Session-Policies prüfst du am schnellsten so:

Beispiel aus der Praxis

Die Sparfuchs & Partner Steuerberatungs GmbH (kleiner Dienstleister, knappes Budget, Entra ID P1) hatte ein klassisches Akzeptanzproblem: Mitten in der Hochsaison beschwerten sich die Steuerfachangestellten, sie müssten sich „den ganzen Tag" neu anmelden. Der erste Impuls der IT war, die Token-Lebensdauer auf zwölf Stunden hochzudrehen — ein Eingriff, der nichts gebracht hätte, weil das Access Token gar nicht das Problem war.

Ein Blick ins Sign-in Log mit Filter auf Conditional Access entlarvte den Übeltäter in zwei Minuten: Eine Policy „Test MFA stündlich", scharf geschaltet ein halbes Jahr zuvor, mit einer Sign-in Frequency von einer Stunde. Niemand hatte sie je wieder deaktiviert. Die Lösung war kein globaler Eingriff, sondern das Korrigieren dieser einen Session-Control auf realistische zwölf Stunden für vertrauenswürdige Geräte. Die Beschwerden waren am selben Nachmittag weg — ganz ohne die Sicherheit zu senken.

Verwandte Artikel

Häufige Fragen (FAQ)

Wie lange ist ein Access Token in Entra ID gültig?

Standardmäßig 60 bis 90 Minuten, mit einer eingebauten zufälligen Schwankung. Diese kurze Lebensdauer ist eine Sicherheitsmaßnahme und sollte normalerweise nicht verändert werden. Der Refresh Token erneuert den Access Token im Hintergrund, sodass der Nutzer von der kurzen Gültigkeit nichts mitbekommt.

Warum müssen sich meine Nutzer ständig neu anmelden?

In den allermeisten Fällen liegt das nicht an der Token-Lebensdauer, sondern an einer Conditional-Access-Session-Control namens Sign-in Frequency, die zu niedrig eingestellt ist. Ein Blick ins Sign-in Log mit Filter auf Conditional Access zeigt dir, welche Policy die Neu-Anmeldung erzwingt.

Sollte ich die Token Lifetime hochsetzen, damit weniger Anmeldungen nötig sind?

Nein. Das ist die häufigste Fehldiagnose. Eine längere Access-Token-Lebensdauer verbessert die gefühlte Situation kaum, schwächt aber die Sicherheit erheblich, weil gestohlene Tokens länger gültig bleiben. Stell stattdessen die Sign-in Frequency in der passenden CA-Policy richtig ein.

Was ist der Unterschied zwischen Sign-in Frequency und Token Lifetime?

Die Token Lifetime bestimmt, wie lange ein einzelner Access Token technisch gültig ist und wird im Hintergrund still erneuert. Die Sign-in Frequency ist eine Conditional-Access-Regel, die unabhängig davon nach einer festgelegten Zeit eine sichtbare Neu-Authentifizierung erzwingt. Die Prompts, die Nutzer nerven, kommen von Letzterer.

Warum fliegt ein Nutzer manchmal mitten in der Sitzung raus?

Das ist typischerweise ein Continuous-Access-Evaluation-Event oder eine Risiko-Erkennung durch Identity Protection. CAE bewertet kritische Ereignisse wie einen deaktivierten Account oder ein gesperrtes Gerät in nahezu Echtzeit und kann den Zugriff sofort beenden, ohne auf den Token-Ablauf zu warten. Der Auslöser steht im Sign-in Log.

Brauche ich eine Premium-Lizenz, um Session-Verhalten zu steuern?

Für Sign-in Frequency und Persistent Browser Session brauchst du Entra ID P1, da es sich um Conditional-Access-Session-Controls handelt. Risikobasierte Auslöser über Identity Protection setzen P2 voraus. Continuous Access Evaluation läuft für unterstützte Clients dagegen automatisch und ist nicht an eine P2-Lizenz gebunden.

Wie geht es weiter?