Outlook fragt ständig nach dem Passwort, obwohl es korrekt ist: Ursachen und konkrete Schritte zur Behebung

Warum Outlook trotz korrektem Passwort erneut fragt: typische Mechanismen und Fehlerbilder bei Exchange, OAuth und MFA

Wenn Outlook wiederholt ein Anmeldefenster einblendet, obwohl das Kennwort korrekt ist, liegt die Ursache häufig nicht im Kennwort selbst. Outlook muss sich gegenüber Exchange Online, Exchange Server oder hybriden Umgebungen in mehreren Schritten authentifizieren und autorisieren: Zuerst wird eine Identität bestätigt (Anmeldung), danach werden Zugriffstoken ausgestellt (Autorisierung), die für MAPI/HTTP, EWS oder REST-Dienste gelten. Scheitert einer dieser Schritte, wirkt das Fehlerbild wie ein „Passwortproblem“, obwohl tatsächlich veraltete Tokens, widersprüchliche Dienstendpunkte oder ein beschädigter lokaler Sicherheitskontext die Anmeldung blockieren.

Besonders häufig tritt das Verhalten in Übergangsphasen auf: Umstellungen auf Modern Authentication (OAuth 2.0), Aktivierung von MFA, Änderungen an Conditional-Access-Richtlinien oder eine Migration von Postfächern. In diesen Situationen kann Outlook zwar weiterhin einen Anmeldedialog anzeigen, aber die eigentliche Störung liegt im Zusammenspiel zwischen Windows-Anmeldeinformationen, Office-Konto-Cache, Autodiscover und den vom Tenant erzwungenen Authentifizierungsverfahren.

Was Outlook beim „Kennwortabfragen“ tatsächlich versucht

Outlook verwendet je nach Kontotyp und Umgebung unterschiedliche Protokolle und Auth-Stacks. Für Exchange ist heute überwiegend Modern Auth relevant: Outlook bezieht über Azure AD (Microsoft Entra ID) Token, die zeitlich begrenzt sind und erneuert werden müssen. Für ältere oder falsch konfigurierte Konten kann Outlook jedoch noch Basic Auth erwarten oder versuchen, einen NTLM/Kerberos-Handshake gegen lokale Endpunkte durchzuführen. Der sichtbare Anmeldedialog ist dabei oft nur die UI-Schicht; im Hintergrund kann die eigentliche Ablehnung aus einem Token-Fehler, einem falschen Dienstendpunkt oder einem lokalen Credential-Cache stammen.

Typisch ist ein Kreislauf: Outlook fordert Anmeldeinformationen an, die Anmeldung gelingt scheinbar, danach scheitert der Zugriff auf die Mailbox oder auf Autodiscover, woraufhin Outlook erneut fragt. Dieses Muster passt zu Situationen, in denen zwar ein Kennwort akzeptiert wird, aber keine gültige Autorisierung für den angefragten Dienst entsteht (falsches Token-Audience, fehlende Claims durch Richtlinien, Token kann nicht gespeichert/erneuert werden).

Fehlerbilder, die wie ein Passwortproblem aussehen, aber keines sind

Mehrere Mechanismen können zu wiederholten Prompts führen, ohne dass das Kennwort falsch ist. Die häufigsten Ursachen liegen in zwischengespeicherten Anmeldeinformationen, widersprüchlichen Autodiscover-Antworten oder in einem inkonsistenten Office-Anmeldezustand. Auch MFA verstärkt die Wahrnehmung, weil tokenbasierte Sitzungen strenger ablaufen und bei Störungen schneller in interaktive Anmeldung zurückfallen.

• Veraltete Windows-Anmeldeinformationen: Im Windows-Anmeldeinformationsmanager liegen alte Einträge für MicrosoftOffice16_Data:ADAL, MicrosoftOffice16_Data:SSPI, Outlook, MS.Outlook oder generische Einträge zu autodiscover/outlook.office365.com; Outlook greift darauf zu und erhält reproduzierbar einen nicht mehr passenden Kontext.
• Beschädigter Token- und Identitätscache: Ein defekter WAM-/AAD-Broker-Status oder ein inkonsistenter Office-Konto-Cache verhindert Token-Erneuerung; interaktive Anmeldung startet immer wieder, obwohl die Eingabe korrekt ist. Relevante Komponenten sind u. a. Microsoft.AAD.BrokerPlugin und Office-Identitätsdaten, die mit dem angemeldeten Windows-Profil verknüpft sind.
• Modern Auth vs. Alt-Konfiguration: Ein Konto oder ein Profil erzwingt noch Basic/Legacy-Methoden oder enthält alte Servernamen; wenn der Tenant Basic Auth blockiert, führt das zu endlosen Kennwortabfragen, weil Outlook weiterhin „Benutzername/Kennwort“ anbietet, aber der Server nur OAuth akzeptiert.
• Autodiscover-Inkonsistenzen: Autodiscover liefert je nach Netzwerkpfad, DNS, Proxy oder SCP (bei Hybrid/On-Prem) unterschiedliche Endpunkte; Outlook wechselt zwischen Zielsystemen und fordert erneut Anmeldedaten an, besonders wenn https://autodiscover.domain.tld/autodiscover/autodiscover.xml und https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml widersprüchliche Ergebnisse liefern.
• MFA- und Conditional-Access-Effekte: MFA ist nicht „noch ein Passwort“, sondern ein zusätzlicher Faktor; wenn Richtlinien eine erneute Interaktion verlangen oder Token als nicht konform bewerten (Gerätestatus, Risiko, Standort), fällt Outlook in wiederholte Dialoge zurück, ohne dass die Kennworteingabe der Engpass wäre.

Warum Exchange, OAuth und MFA die Symptome verändern

Bei Exchange Online basiert die Anmeldung in aktuellen Microsoft-365-Apps typischerweise auf OAuth 2.0. Outlook benötigt dabei Token für konkrete Ressourcen. Wenn Outlook für einen Endpunkt ein Token mit falscher Zielgruppe erhält oder ein Refresh Token nicht genutzt werden kann, erscheint erneut ein Prompt. Der Benutzer sieht nur die Oberfläche, nicht jedoch, ob der Fehler beim Abruf von Autodiscover, beim Aufbau von MAPI/HTTP oder beim Zugriff auf Free/Busy-, OAB- oder EWS-Dienste ausgelöst wurde.

In hybriden Szenarien (On-Prem Exchange mit Exchange Online) verschärfen Weiterleitungen und gemischte Identitäten die Lage: UPN, primäre SMTP-Adresse und Anmeldeidentität können auseinanderlaufen. Outlook kann dann wiederholt versuchen, den falschen Realm anzusprechen, insbesondere wenn alte Profileinträge noch On-Prem-Endpunkte referenzieren, während die Authentifizierung bereits über Entra ID erfolgt.

Abgrenzung: Kennwort stimmt, Anmeldung scheitert trotzdem

Ein korrektes Kennwort kann trotzdem zu wiederholten Abfragen führen, wenn der Server oder die Richtlinien eine andere Anmeldeform erzwingen. Seit der Deaktivierung von Basic Auth in Exchange Online für die meisten Protokolle ist der „klassische“ Kennwortdialog besonders irreführend: Er kann erscheinen, obwohl der Dienst Kennwortanmeldung gar nicht mehr akzeptiert. In solchen Fällen hilft eine saubere Einordnung: Handelt es sich um einen lokalen Cachefehler, einen Profildefekt oder um eine tenantseitige Authentifizierungsanforderung, die nur über Modern Auth/MFA erfüllt werden kann?

Auch Sperrungen durch Identitätsschutz (z. B. riskante Anmeldung) oder fehlende Gerätekonformität können zu Prompts führen, ohne dass eine Fehlermeldung im Outlook-Dialog verständlich wird. Dann ist der Prompt ein Symptom dafür, dass Outlook keine verwertbaren Token erhält oder die Token vom Dienst verworfen werden. Die eigentliche Entscheidung fällt serverseitig in Entra ID/Conditional Access oder in der Exchange-Authentifizierungskette.

Häufige Ursachen sauber eingrenzen: Windows-Anmeldeinformationsmanager, Autodiscover, Modern Auth vs. Altkonfiguration und Token-Probleme

Wenn Outlook wiederholt ein Kennwort abfragt, obwohl das Passwort nachweislich stimmt, liegt der Auslöser häufig nicht in der Zeichenfolge selbst, sondern in der Authentifizierungskette. Outlook greift dabei auf mehrere Schichten zu: lokal gespeicherte Anmeldeinformationen (Windows-Anmeldeinformationsmanager), das Outlook-Profil inklusive Cache- und Kontodaten, die Dienstermittlung über Autodiscover sowie die tatsächliche Authentifizierung gegenüber Exchange Online oder Exchange Server (Modern Authentication/OAuth bzw. Legacy/Basic). Störungen in einer dieser Schichten erzeugen denselben Effekt: ein Anmeldefenster in Endlosschleife oder intermittierend.

Für eine saubere Eingrenzung ist entscheidend, welches Symptombild vorliegt: Wird das Fenster sofort nach dem Start angezeigt oder erst beim Senden/Empfangen? Tritt es nur in Outlook auf, während Outlook on the Web stabil funktioniert? Erscheint ein klassischer Benutzername/Passwort-Dialog oder ein modernes Microsoft-Anmeldefenster? Diese Beobachtungen bestimmen, ob zuerst lokale Credential-Artefakte, Autodiscover oder Token/MFA betrachtet werden sollten.

Windows-Anmeldeinformationsmanager: veraltete oder konkurrierende Einträge

Outlook verwendet gespeicherte Anmeldeinformationen aus Windows, um Verbindungen zu Exchange, Autodiscover und Proxy-Endpunkten herzustellen. Häufig bleiben nach Kennwortwechsel, Konto-Migration, UPN-Änderung (Anmeldename) oder nach der Umstellung auf Modern Auth Einträge zurück, die zwar „passen“, aber nicht mehr zum erwarteten Authentifizierungsverfahren oder zum Zielhost. Outlook versucht dann wiederholt, mit falschen Artefakten zu verbinden, verwirft sie und fordert erneut zur Anmeldung auf.

Typisch sind mehrere Einträge für denselben Benutzer, aber unterschiedliche Zielnamen (z. B. MicrosoftOffice16_Data:ADAL vs. outlook.office365.com) oder veraltete Alias-/UPN-Kombinationen. Auch „generische“ Anmeldeinformationen zu Proxy-, VPN- oder Security-Produkten können den Authentifizierungsfluss stören, wenn sie TLS-Inspection oder eine zwischengeschaltete Anmeldung erzwingen.

• Relevante Speicherorte in Windows: control /name Microsoft.CredentialManager (Windows-Anmeldeinformationsverwaltung) und dort insbesondere „Windows-Anmeldeinformationen“ sowie „Generische Anmeldeinformationen“
• Typische Outlook-/Office-Zielnamen: MicrosoftOffice16_Data:ADAL, MicrosoftOffice16_Data:SSPI, outlook.office365.com, autodiscover-s.outlook.com, MS.Outlook
• Woran konkurrierende Einträge erkennbar sind: identische Konten mit unterschiedlichen Benutzernamenformaten (z. B. vorname.nachname@firma.tld und FIRMA\vnname) oder Einträge, die auf alte Domains/Tenants verweisen

Autodiscover: inkonsistente Antworten, falsche Weiterleitungen, Altlasten

Autodiscover entscheidet, welche Server und URLs Outlook für Postfach, Offlineadressbuch, Frei/Gebucht und EWS verwendet. Wenn Autodiscover widersprüchliche Informationen liefert, entsteht ein „Anmelde-Pingpong“: Outlook erreicht einen Endpunkt, erhält eine Authentifizierungsaufforderung, wechselt zur nächsten Autodiscover-Variante und landet erneut bei einer Abfrage. Ursachen sind häufig DNS-Fehlkonfigurationen, veraltete SCP-Einträge (bei hybriden/On-Prem-Umgebungen) oder eine Split-Brain-DNS-Situation, bei der intern andere Ergebnisse als extern ausgeliefert werden.

In Microsoft-365-Szenarien fällt besonders ins Gewicht, wenn lokale Autodiscover-Antworten noch auf einen alten Exchange-Server oder eine nicht mehr gültige Proxy-URL zeigen. Outlook kann dann zwar die Anmeldung anstoßen, erhält aber kein verwertbares Token-Ziel (Resource) oder keine passende Verbindungskette, was wieder in eine erneute Abfrage mündet.

Modern Auth vs. Altkonfiguration: wenn OAuth erwartet wird, aber Legacy greift

Aktuelle Microsoft-365-Umgebungen setzen für Outlook grundsätzlich auf Modern Authentication (OAuth 2.0) mit interaktiver Anmeldung und Token. Wenn im Outlook-Profil oder durch Altsoftware noch Legacy-Mechanismen angestoßen werden (z. B. Basis-/Proxy-Dialoge oder alte Kontomethoden), entsteht eine Endlosschleife: Outlook versucht, sich mit einem Verfahren anzumelden, das der Dienst ablehnt oder das nicht zur Richtlinie passt. Das wirkt wie ein Passwortproblem, ist aber eine Protokoll- und Richtlinieninkompatibilität.

Das Risiko steigt nach Umstellungen wie: Deaktivierung von Basic Auth in Exchange Online, Aktivierung von Sicherheitsstandards oder Conditional Access, Wechsel des Primäranmeldenamens oder Migration von On-Prem zu Exchange Online. In solchen Phasen existieren oft noch Profileinstellungen, Add-ins oder zwischengeschaltete Komponenten, die Anmeldefenster im „alten Stil“ erzwingen.

• Hinweis auf Legacy-Flows: klassischer Dialog mit reiner Benutzername/Passwort-Abfrage statt Web-Login; häufige Zielangaben wie Microsoft Exchange ohne sichtbare Microsoft-Anmeldeseite
• Typischer Konfliktauslöser: Dienst verlangt OAuth/Conditional Access, Client oder Zwischenkomponente versucht Basic/NTLM; Ergebnis sind wiederholte Challenges ohne dauerhaft gültige Sitzung
• Saubere Abgrenzung im Umfeld: Test über https://outlook.office.com/ bzw. https://outlook.office365.com/ zeigt, ob Konto und MFA grundsätzlich funktionieren, während Outlook-Desktop weiterhin scheitert

MFA- und Token-Probleme: abgelaufene Refresh Tokens, fehlerhafte Broker-Integrationen

Mit Modern Auth hängt die Stabilität der Anmeldung an Token-Artefakten (Access/Refresh Tokens), die lokal zwischengespeichert werden. Nach Kennwortänderungen, MFA-Methodenwechsel, Gerätekonformitätsanforderungen oder Richtlinienänderungen kann ein Refresh Token ungültig werden. Outlook interpretiert die fehlgeschlagene Token-Erneuerung oft nicht als „Bitte neu anmelden und fertig“, sondern versucht wiederholt denselben Pfad, was als permanente Passwortabfrage sichtbar wird.

Auf Windows-Systemen nutzt Office je nach Konfiguration einen Anmelde-Broker (z. B. Web Account Manager). Wenn dort alte Konten, doppelte Arbeits-/Schulkonten oder ein inkonsistenter Gerätestatus (Azure AD/Entra ID Registrierung) vorliegen, können Token nicht korrekt ausgestellt oder gebunden werden. In der Praxis zeigt sich dann ein ständiger Wechsel zwischen „Anmeldung erforderlich“ und kurzfristiger Verbindung, gefolgt von erneuten Prompts.

• Typisches Muster nach Sicherheitsänderungen: Passwortabfrage startet nach Kennwortwechsel, neuer MFA-Methode oder aktivierter Conditional-Access-Richtlinie; OWA funktioniert, Outlook-Desktop fordert wiederholt an
• Lokale Indikatoren für Token-Konflikte: mehrere Einträge zum selben Arbeitskonto unter Windows „Zugriff auf Arbeits- oder Schulkonto“, sowie zugehörige Credentials im Manager (z. B. MicrosoftOffice16_Data:ADAL)
• Abgrenzung zu reinen Netzwerkproblemen: wenn die Abfrage auch bei stabiler Verbindung und ohne VPN auftritt, ist ein Token-/Broker-Problem wahrscheinlicher als Paketverlust oder reine DNS-Fehler

Die Einordnung dieser Ursachen entscheidet über die nächsten Schritte: Bei klaren Credential-Hinweisen steht die Bereinigung gespeicherter Einträge im Vordergrund; bei Autodiscover-Symptomen rücken DNS/SCP und Weiterleitungen in den Fokus; bei Modern-Auth-Konflikten und Token-Problemen ist die Trennung zwischen Kontozustand (OWA) und lokalem Outlook-Profil sowie der Office-Anmeldung die entscheidende Leitplanke.

Schritt-für-Schritt beheben: gespeicherte Anmeldedaten bereinigen, Office-Abmeldung, Test über Outlook im Web, Profil reparieren oder neu erstellen – und klare Grenzen für den IT-Support

Die Behebung sollte in einer festen Reihenfolge erfolgen, weil sich mehrere Ursachen gegenseitig überlagern können: veraltete Einträge im Windows-Anmeldeinformationsspeicher, abgelaufene oder widersprüchliche OAuth-Token, ein beschädigtes Outlook-Profil oder eine fehlerhafte Autodiscover-Erkennung. Ziel ist, die Anmeldekette zu „entwirren“, ohne in kurzer Folge Passwörter erneut einzugeben oder Profile mehrfach umzubauen.

1) Gespeicherte Windows-Anmeldedaten gezielt bereinigen (Credential Manager)

Outlook und die Office-Anmeldung verwenden neben dem aktuellen Kennwort häufig gespeicherte Anmeldeinformationen (Basic, Modern Auth, App-Kennwörter) und Token-Caches. Ein einzelner veralteter Eintrag genügt, um wiederkehrende Passwortabfragen auszulösen, obwohl das Kennwort korrekt ist. Entscheidend ist ein kontrolliertes Löschen der Outlook- und Microsoft-365-bezogenen Einträge, nicht das pauschale Entfernen aller Credentials.

• Anmeldeinformationsmanager öffnen: Systemsteuerung → Benutzerkonten → Anmeldeinformationsverwaltung oder direkt control /name Microsoft.CredentialManager
• Relevante Bereiche prüfen: In Windows-Anmeldeinformationen und Generische Anmeldeinformationen nach Einträgen mit Bezug zu MicrosoftOffice, Outlook, MSOID, ADAL, Exchange, MicrosoftAccount oder msteams suchen und nur diese entfernen.
• Besondere Aufmerksamkeit bei Exchange/Autodiscover: Einträge, die Hostnamen wie autodiscover.domain.tld, outlook.office365.com oder interne Exchange-Namen enthalten, können veraltete Kennwörter oder alte Endpunkte speichern; diese gezielt löschen.
• Neustart-Fenster einplanen: Nach dem Entfernen Outlook vollständig beenden (auch im Infobereich) und erst danach erneut starten, damit keine alten Token aus einem noch laufenden Prozess weiterverwendet werden.

Wenn anschließend unmittelbar wieder eine Passwortabfrage erscheint, sollte die Eingabe nur einmal erfolgen. Mehrfaches Wiederholen verschlechtert die Diagnose, weil es Lockout-Richtlinien oder MFA-Ratelimits auslösen kann und die Fehlerspur verwässert.

2) Kontrollierte Ab- und Anmeldung in Office-Apps (Token sauber neu aufbauen)

Ein häufiger Auslöser sind inkonsistente Anmeldestände: Outlook ist mit einem Konto verbunden, während Office als Lizenz-/Identitätskontext ein anderes Konto hält, oder es existieren alte Token nach Kennwortwechsel, MFA-Umstellung oder Geräte-Compliance-Änderungen. Eine kontrollierte Abmeldung zwingt Office, die Tokenkette neu zu erzeugen.

• Outlook schließen: Outlook beenden und prüfen, dass kein Prozess OUTLOOK.EXE mehr läuft (z. B. über den Task-Manager Strg+Umschalt+Esc).
• In einer Office-App abmelden: In z. B. Word → Datei → Konto bei Benutzerinformationen Abmelden durchführen, anschließend Office-Apps schließen.
• Windows „Arbeits- oder Schulkonto“ prüfen: Unter Einstellungen → Konten → Auf Arbeits- oder Schulkonto zugreifen sicherstellen, dass die erwartete Verbindung besteht; bei unerwarteten, veralteten Verknüpfungen Rücksprache mit IT halten statt blind zu trennen.
• Erneut anmelden: Office-App öffnen, unter Datei → Konto wieder anmelden; erst danach Outlook starten, damit Outlook die frisch erzeugten Tokens übernimmt.

Bei aktivierter MFA ist entscheidend, dass die MFA-Abfrage vollständig abgeschlossen wird. Abgebrochene Prompts oder parallele Anmeldefenster können Token in einen Zwischenzustand bringen, der in Outlook als „Passwort falsch“ erscheint, obwohl in Wahrheit eine unvollständige Autorisierung vorliegt.

3) Test über Outlook im Web (OWA) zur Eingrenzung: Konto vs. Gerät/Profil

Ein schneller Gegencheck trennt server- bzw. kontoseitige Probleme von lokalen Ursachen. Funktioniert die Anmeldung im Browser stabil, sind Kennwort, MFA und die Exchange-Postfachauthentifizierung in der Regel intakt. Bleiben Anmeldefehler auch dort bestehen, liegt der Fokus eher auf Kontorichtlinien, Sperren oder tenantseitigen Einstellungen.

Bei erfolgreichem OWA-Test sollte der Fokus lokal bleiben. Bei fehlgeschlagenem OWA-Test ist ein lokales Outlook-Profil als Ursache weniger wahrscheinlich; in diesem Fall sind weitere lokale Maßnahmen oft Zeitverlust.

4) Outlook-Profil reparieren oder neu erstellen (sauberer Autodiscover- und Kontostart)

Wenn Credentials bereinigt und Office-Token erneuert wurden, bleibt als häufigste lokale Ursache ein beschädigtes oder inkonsistentes Outlook-Profil. Das zeigt sich besonders nach Migrationen, Exchange-Hybrid-Umstellungen oder wenn Autodiscover zwischen internen und externen Antworten wechselt. Eine Reparatur kann genügen; oft ist ein neues Profil jedoch schneller und verlässlicher.

• Profilverwaltung öffnen: Systemsteuerung → Mail (Microsoft Outlook) → Profile anzeigen.
• Reparatur zuerst prüfen (wenn angeboten): In Outlook unter Datei → Kontoeinstellungen → Kontoeinstellungen das betroffene Konto markieren und je nach Kontotyp Reparieren verwenden; danach Outlook neu starten.
• Neues Profil erstellen: In Profile anzeigen → Hinzufügen, neues Profil benennen, Konto neu hinzufügen und anschließend Beim Start dieses Profils verwenden auf das neue Profil setzen.
• Altes Profil nicht sofort löschen: Das alte Profil zunächst bestehen lassen, bis Kalender, Delegationen, freigegebene Postfächer und Signaturen im neuen Profil verifiziert sind; erst dann bereinigen.

Bei Exchange Online mit Modern Authentication sollte die Kontoeinrichtung möglichst über die Standardkontoführung erfolgen. Manuelle Servereinträge umgehen zwar Symptome, verschärfen aber häufig Autodiscover-Konflikte und führen später zu erneuten Passwortprompts.

5) Klare Grenzen: Wann weiterer Aktionismus stoppen und IT-Support nötig ist

Mehrfache Passwortversuche oder wiederholtes Löschen von Profilen ist nicht immer sinnvoll. Bestimmte Auslöser liegen außerhalb des Einflussbereichs am Gerät und sollten gezielt an IT oder den Microsoft-365-Administrator eskaliert werden, idealerweise mit konkreten Beobachtungen (OWA-Ergebnis, Zeitpunkt, Fehlermeldungstext, ob MFA-Prompt erscheint).

• Conditional Access/Compliance greift: Hinweise auf „Zugriff blockiert“ oder wiederholte Umleitungen trotz korrekter MFA deuten auf Richtlinien; ohne Adminrechte keine nachhaltige Lösung.
• Konto gesperrt oder risikobehaftet: Häufige Prompts nach Kennwortänderung, Meldungen zu „zu vielen Anmeldeversuchen“ oder erzwungene Kennwortzurücksetzungen erfordern Entsperrung bzw. Risk-Review durch IT.
• Tenantseitige Authentifizierungsumschaltung: Umstellungen bei Modern Auth, deaktiviertes Basic Auth oder Änderungen an MFA-Methoden können alte Outlook-Stände brechen; hier helfen Logs und Richtlinienprüfung statt lokaler Workarounds.
• Autodiscover-/DNS-Inkonsistenz: Wenn das Problem mehrere Geräte betrifft oder nach Netzwechsel reproduzierbar ist, liegt die Ursache oft in DNS, Proxy oder Split-Brain-Konfiguration; das muss zentral korrigiert werden.