Beheben Sie den RDP-Fehler 'Anmeldeversuch fehlgeschlagen' unter Windows

Sie geben Ihre Anmeldedaten ein, die Windows-Sicherheitsabfrage blitzt kurz auf, und eine rote Zeile erscheint: Der Anmeldeversuch ist fehlgeschlagen. Die Sitzung öffnet sich nie. Ich bin diesem Problem in Heimlabors, auf Client-Rechnern und Servern gleichermaßen begegnet. Und der Fehler sieht identisch aus, ganz gleich, ob die Ursache eine fehlende Gruppenrichtlinienberechtigung, ein veralteter Eintrag in der Anmeldeinformationsverwaltung, ein Windows-Update, das CredSSP außer Funktion gesetzt hat, oder ein Domänencontroller ist, der kurzzeitig nicht erreichbar war.

In diesem Artikel führe ich Sie durch die häufigsten bestätigten Ursachen und erprobten Korrekturen für den RDP-Fehler Anmeldeversuch fehlgeschlagen.

Inhaltsverzeichnis

Der Anmeldeversuch ist fehlgeschlagen ist die generische Windows-Meldung für eine Ablehnung von Anmeldeinformationen irgendwo in der RDP-Authentifizierungskette. Sie wird als Text innerhalb der RDP-Anmeldeaufforderung angezeigt, bevor die Remotedesktopverbindung hergestellt wird. Das Problem ist, dass Windows dieselbe Zeichenfolge für Fehler an mehreren unterschiedlichen Stellen zurückgibt.

Das Windows-Sicherheitsprotokoll auf dem Zielcomputer protokolliert dies als Ereignis-ID 4625, und der Status- oder Unterstatuscode innerhalb dieses Ereignisses ist das, was den eigentlichen Fehlerpunkt identifiziert.

Dies behebt einen großen Teil der Fälle, in denen die Zugangsdaten korrekt sind, die Verbindung jedoch fehlschlägt. Damit fange ich an, bevor ich irgendetwas anderes anfasse.

Auf dem Zielcomputer drücken Sie die Windows-Taste + R, geben Sie secpol.msc ein und drücken Sie die Eingabetaste, um die Lokale Sicherheitsrichtlinie zu öffnen.
Erweitern Sie Lokale Richtlinien und wählen Sie Zuweisen von Benutzerrechten aus.
Doppelklicken Sie im rechten Bereich auf Anmeldung über Remotedesktopdienste zulassen.
Klicken Sie auf Benutzer oder Gruppe hinzufügen und geben Sie den genauen Benutzernamen des Kontos ein, mit dem Sie die Verbindung herstellen.
Klicken Sie auf OK und schließen Sie die Lokale Sicherheitsrichtlinie.
Öffnen Sie eine Eingabeaufforderung mit erhöhten Rechten und führen Sie gpupdate /force aus, um die Änderung ohne einen Neustart anzuwenden.

Überprüfen Sie in der Computerverwaltung außerdem, ob das Konto Mitglied der Gruppe Remotedesktopbenutzer unter Lokale Benutzer und Gruppen ist. Dies ersetzt nicht die Richtlinienberechtigung, gehört jedoch zur erwarteten Konfiguration. Standardmäßig gewährt die Mitgliedschaft in der Gruppe Remotedesktopbenutzer dieses Recht in der Regel, sofern sie nicht durch lokale oder domänenweite Gruppenrichtlinien außer Kraft gesetzt wird. Wenn jedoch eine Gruppenrichtlinie dies ausdrücklich außer Kraft setzt, müssen Sie das Konto möglicherweise direkt zu dieser Richtlinienberechtigung hinzufügen, selbst wenn die Gruppenmitgliedschaft bereits besteht.

Führen Sie diesen Fix unmittelbar nach Fix 1 aus, wenn der Fehler weiterhin besteht, insbesondere nach einer Passwortänderung auf dem Zielrechner.

Auf dem Computer, der die Verbindung herstellt, öffnen Sie das Start-Menü und suchen Sie nach Anmeldeinformationsverwaltung.
Wählen Sie Windows-Anmeldeinformationen aus.
Suchen Sie nach Einträgen, die mit TERMSRV/ beginnen, gefolgt von der IP-Adresse oder dem Hostnamen des Zielrechners.
Erweitern Sie jeden übereinstimmenden Eintrag und klicken Sie auf Entfernen.
Schließen Sie die Anmeldeinformationsverwaltung.
Öffnen Sie Remotedesktopverbindung, geben Sie die Anmeldedaten manuell ein und verbinden Sie sich.

Verhindern Sie, dass die Remotedesktopverbindung während der Diagnose die Anmeldeinformationen erneut speichert. Deaktivieren Sie vor dem Herstellen der Verbindung das Kontrollkästchen Zulassen, dass ich Anmeldeinformationen speichere, damit Windows nicht erneut einen veralteten Eintrag anlegt.

Für den Win11-zu-Win11-Fall unter Build 26100.6584 berichtet in Microsoft Q&A, behebt das manuelle Hinzufügen der Anmeldeinformationen des Zielcomputers über Systemsteuerung > Anmeldeinformationsverwaltung > Windows-Anmeldeinformationen > Windows-Anmeldeinformationen hinzufügen ebenfalls Fälle, in denen die Richtlinie zur Delegierung von Anmeldeinformationen stört.

Hinzufügen einer Windows-Anmeldeinformation in der Anmeldeinformationsverwaltung

Testen Sie außerdem mit einem neuen RDP-Profil, indem Sie mstsc starten, auf Optionen anzeigen klicken und keine gespeicherten Verbindungsprofile verwenden. Beschädigte oder veraltete RDP-Konfigurationsdateien (.rdp) können ungültige Parameter oder Anmeldeinformationen wiederverwenden.

NLA authentifiziert die Sitzung vorab mit Ihren Anmeldeinformationen, bevor der Remotedesktop geladen wird. Wenn der Zielcomputer den Domänencontroller nicht erreichen kann, wenn eine CredSSP-Versionsinkompatibilität vorliegt oder wenn der Kontotyp mit dem NLA-Handshake nicht kompatibel ist, kann NLA den Authentifizierungs-Handshake scheitern lassen und auf der Clientseite dieselbe Meldung logon attempt failed anzeigen. Das vorübergehende Deaktivieren von NLA bestätigt, ob es die Ursache ist.

Auf dem Zielcomputer drücken Sie die Windows-Taste + Pause, um die Systemeigenschaften zu öffnen, und klicken Sie dann im linken Bereich auf Remote-Einstellungen.
Auf der Registerkarte Remote deaktivieren Sie das Kontrollkästchen Verbindungen nur von Computern zulassen, auf denen Remotedesktop mit Authentifizierung auf Netzwerkebene ausgeführt wird.
Klicken Sie auf Übernehmen.
Versuchen Sie, die Verbindung vom Client-Computer aus herzustellen.

Wenn die Verbindung mit deaktiviertem NLA erfolgreich ist, liegt das Problem in der NLA-Authentifizierungskette, und Sie können ohne Raten weiter diagnostizieren. Für registrierungsbasierten Zugriff ist die NLA-Einstellung unter folgendem Pfad gespeichert:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Der Wertname lautet UserAuthentication. Setzen Sie ihn auf 0, um NLA zu deaktivieren, oder auf 1, um es zu erzwingen. Der Wert SecurityLayer am selben Pfad steuert die umfassendere Sicherheitsebene: 0 für nur RDP-Sicherheit, 1 für Aushandlung, 2 für SSL.

Ändern der Werte für SecurityLayer und UserAuthentication im Registrierungs-Editor

Der Vorauthentifizierungsschritt von NLA ist genau das, was in den Support-Szenarien, mit denen IT-Techniker am häufigsten konfrontiert sind, scheitert:

Remote-Rechner außerhalb des Unternehmensnetzwerks
Endpunkte, bei denen der Domänencontroller nicht erreichbar ist
Rechner, auf denen keine IT-Konfiguration durchgeführt wurde

Wenn Ihr Anwendungsfall Remote-Support statt Selbstzugriff auf Ihre eigenen Rechner ist, eliminiert HelpWire diese Ebene vollständig aus dem Prozess. Der Endbenutzer öffnet einen Sitzungslink und stellt eine ausgehende Verbindung her, ohne NLA, ohne Anforderungen an die Erreichbarkeit der Domäne und ohne jegliche Kontenkonfiguration auf seiner Seite.

Microsoft-Konten können für RDP verwendet werden, aber die Authentifizierung kann fehlschlagen, wenn Windows Hello oder eine PIN anstelle des Kontokennworts verwendet wird, das Format des Benutzernamens falsch ist (z. B. die Verwendung der E-Mail-Adresse statt MicrosoftAccount\email in einigen Konfigurationen), oder Konflikte beim Zwischenspeichern von Anmeldeinformationen auftreten. In diesen Fällen kann die explizite Verwendung des Kontokennworts oder eines lokalen Kontos eine zuverlässigere Umgehungslösung sein:

Öffnen Sie auf dem Zielgerät die Einstellungen und gehen Sie zu Konten, dann Andere Benutzer.
Klicken Sie auf Konto hinzufügen, und dann auf Ich kenne die Anmeldeinformationen dieser Person nicht.
Wählen Sie Benutzer ohne Microsoft-Konto hinzufügen aus.
Erstellen Sie einen Benutzernamen und ein starkes Passwort für das lokale Konto.
Nachdem das Konto erstellt wurde, klicken Sie es unter Andere Benutzer an, wählen Sie Kontotyp ändern und setzen Sie es auf Administrator.
Kehren Sie zu Fix 1 zurück und gewähren Sie diesem lokalen Konto in der Lokalen Sicherheitsrichtlinie das Recht Anmelden über Remotedesktopdienste zulassen.
Verwenden Sie beim Herstellen einer Verbindung über RDP den Benutzernamen und das Kennwort des lokalen Kontos.

In vielen Fällen behebt der Wechsel zu einem lokalen Administratorkonto das Problem zuverlässiger, insbesondere wenn kennwortlose oder PIN-basierte Authentifizierung aktiviert ist.

Zwei aktualisierungsbezogene Szenarien wurden als Ursache für diesen Fehler gemeldet. Das erste ist die CredSSP-Encryption-Oracle-Problembehebung, die mit dem Update vom Mai 2018 (KB4103727 und verwandte) eingeführt wurde. Das zweite ist KB5065426 unter Windows 11 24H2 und 25H2, das die RDP-Authentifizierung auf Maschinen mit doppelten SIDs aus unsachgemäß syspreppten Abbildern unterbricht.

Für den CredSSP-Fehler (An authentication error has occurred. The function requested is not supported) besteht die korrekte Abhilfe darin, sicherzustellen, dass sowohl der Client als auch das Zielsystem vollständig aktualisiert sind, sodass ihre CredSSP-Versionen kompatibel sind. Nur als vorübergehende Umgehungslösung wenden Sie Folgendes auf dem verbindenden Computer an:

Drücken Sie die Windows-Taste + R, geben Sie gpedit.msc ein, und drücken Sie die Eingabetaste.
Navigieren Sie zu Computerkonfiguration > Administrative Vorlagen > System > Anmeldeinformationsdelegierung.
Öffnen Sie Encryption Oracle Remediation und setzen Sie es auf Aktiviert.
Setzen Sie die Schutzstufe auf Verwundbar.
Führen Sie gpupdate /force in einer erhöhten Eingabeaufforderung aus.

Dies ist nur eine Notlösung. Die dauerhafte Lösung besteht darin, den Zielcomputer zu aktualisieren, sodass beide Seiten eine kompatible CredSSP-Version ausführen.

Für die Regression KB5065426 unter Windows 11 24H2 und 25H2 versucht ein von der Community gemeldeter Registry-Workaround, das mit diesem Update eingeführte Feature-Flag zu deaktivieren:

Öffnen Sie auf dem Zielcomputer den Registrierungs-Editor, indem Sie die Windows-Taste + R drücken und regedit.exe eingeben.
Navigieren Sie zu HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides.
Erstellen Sie einen neuen DWORD-Wert (32-Bit) mit dem Namen 718619.
Setzen Sie die Daten auf 0.
Starten Sie die Zielmaschine neu.

Die dauerhafte Lösung für diese Umgebung besteht darin, sysprep /generalize /oobe /shutdown auf dem Basis-Image auszuführen, bevor irgendeine Bereitstellung erfolgt.

HINWEIS: Dieser Registry-Workaround stammt aus der Community und ist nicht offiziell von Microsoft dokumentiert. Stellen Sie sicher, dass er auf Ihren spezifischen Build zutrifft, bevor Sie ihn anwenden.

In Domänenumgebungen stellen einige Benutzer fest, dass der erste RDP-Versuch fehlschlägt, der zweite jedoch erfolgreich ist, oder dass das Konto beim zweiten Versuch gesperrt wird. Falsche NTLM-Authentifizierungseinstellungen (lmcompatibilitylevel) können in Domänen- oder Legacy-Umgebungen, in denen auf verschiedenen Computern unterschiedliche NTLM-Richtlinien erzwungen werden, zu Authentifizierungsfehlern führen.

Die Lösung besteht darin, den lmcompatibilitylevel auf beiden Computern abzugleichen:

Sowohl auf dem Domänencontroller als auch auf dem RDP-Host drücken Sie die Windows-Taste + R und geben Sie regedit.exe ein.
Navigieren Sie zu HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
Suchen Sie einen DWORD-Wert mit dem Namen lmcompatibilitylevel oder erstellen Sie ihn.
Setzen Sie den Wert auf 5, wodurch Folgendes erzwungen wird: Nur NTLMv2-Antwort senden, LM und NTLM ablehnen.
Starten Sie beide Maschinen neu.

Dies entspricht dem Gruppenrichtlinienpfad: Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen > Netzwerksicherheit: LAN-Manager-Authentifizierungsebene. Das Festlegen auf Nur NTLMv2-Antwort senden. LM und NTLM verweigern auf beiden Rechnern beseitigt die Nichtübereinstimmung, die den wiederholten Fehler auslöst.

Die Ereignisanzeige auf dem Zielsystem ist der schnellste Weg, genau festzustellen, welche Grundursache zutrifft, bevor irgendwelche Einstellungen geändert werden. Ich führe dies zuerst auf jedem System aus, bei dem die Lösung nicht sofort offensichtlich ist.

Drücken Sie auf dem Zielcomputer die Windows-Taste + R, geben Sie eventvwr.msc ein und drücken Sie Enter.
Erweitern Sie im linken Bereich Windows-Protokolle und wählen Sie Sicherheit aus.
Klicken Sie im rechten Bereich Aktionen auf Aktuelles Protokoll filtern.
Geben Sie 4625 in das Feld Ereignis-IDs ein und klicken Sie auf OK.
Klicken Sie auf den aktuellsten Eintrag mit der Ereignis-ID 4625 und lesen Sie die Details im unteren Bereich.

Status- und Unterstatuscode	Bedeutung	Anzuwendende Maßnahme
0xC000006A	Benutzername korrekt, Passwort falsch	Passwort überprüfen, Anmeldeinformationsverwaltung prüfen
0xC0000064	Benutzername existiert auf dem Zielsystem nicht	Genauen Kontonamen bei den lokalen Benutzern überprüfen
0xC0000234	Konto gesperrt	In Active Directory oder der lokalen Benutzerverwaltung entsperren
0xC0000072	Konto deaktiviert	Konto in der Benutzerverwaltung aktivieren
0xC000015B	Anmeldetyp nicht gewährt	Maßnahme 1 oben (Recht `Anmelden über Remotedesktopdienste zulassen` hinzufügen)
0xC000006F	Konto durch Anmeldezeiten eingeschränkt	Kontoeigenschaften prüfen
0xC0000070	Arbeitsstationsbeschränkung	Konto auf bestimmte Computer beschränkt

Wenn SubStatus 0x0 anzeigt, verlassen Sie sich stattdessen auf den Status-Code. Wenn Status oder SubStatus 0xC000015B anzeigen, das Konto aber bereits in der Gruppe Remote Desktop Users ist, prüfen Sie vor dem Anwenden von Fix 1, ob eine GPO auf Domänenebene das lokale Recht außer Kraft setzt.

Das Feld Logon Type lohnt ebenfalls eine Prüfung. Type 10 ist remoteinteraktiv, was RDP verwendet. Logon Type 10 steht für RDP (RemoteInteractive). Andere Anmeldetypen können auf andere Authentifizierungspfade oder eine fehlerhafte Sitzungsbehandlung hinweisen, was eher auf ein Problem mit Netzwerk-Relay oder Gateway-Konfiguration als auf ein lokales Richtlinienproblem deutet.

In Domänenumgebungen führen Sie dieselbe Suche nach Event ID 4625 im Security-Protokoll des Domänencontrollers sowie auf dem Zielcomputer aus. Der Domänencontroller protokolliert die Zurückweisung der Authentifizierung oft, bevor der Zielcomputer sie überhaupt protokolliert, und beide Einträge zusammen zeigen Ihnen genau, wo die Authentifizierungskette unterbrochen wurde.

Nicht jeder RDP-Fehler erzeugt in Domänenumgebungen auf dem Zielcomputer einen sauberen 4625-Eintrag, insbesondere wenn die Authentifizierung bereits früher am Domänencontroller fehlschlägt.

Wenn das nicht funktioniert hat, bleiben nach den obigen Korrekturen zwei Randfälle:

Der Zielcomputer befindet sich in einem eingefrorenen Sitzungszustand der Remote Desktop Services. Nach einem unerwarteten Stromausfall oder einer erzwungenen Trennung kann TermService in einen Zustand geraten, der neue Authentifizierungen ablehnt. Ein vollständiger Neustart des Zielcomputers behebt dies. Wenn Sie einen alternativen Zugriffsweg auf den Computer haben, können Sie über services.msc nur die Remote Desktop Services neu starten, ohne einen kompletten Neustart.
Eine Gruppenrichtlinie auf Domänen- oder Organisationseinheitsebene weist Ihrem Konto das Recht Deny logon through Remote Desktop Services zu, das jedes darunterliegende Allow-Recht außer Kraft setzt. Führen Sie auf dem Zielcomputer rsop.msc aus und navigieren Sie zu Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

Wenn Ihr Konto sowohl unter Allow log on through Remote Desktop Services als auch unter Deny log on through Remote Desktop Services erscheint, gewinnt das Deny unabhängig von der Gruppenmitgliedschaft. Sie müssen das Konto aus dem Deny-Eintrag auf der Richtlinienebene entfernen, auf der er angewendet wird; dafür ist Zugriff auf die Group Policy Management Console erforderlich.

6 Hauptursachen machen die überwältigende Mehrheit der Fälle aus, die ich gesehen habe, und werden häufig in der Microsoft-Dokumentation, in Community-Foren und bei der Problembehandlung vor Ort berichtet.

Fehlermeldung	Ursache	Umgebung
`Der Anmeldeversuch ist fehlgeschlagen.`	Fehlendes Richtlinienrecht `Allow log on through Remote Desktop Services` Falsches Benutzernamenformat (lokal vs. Domäne stimmen nicht überein)	Arbeitsgruppe oder Domäne
`Ihre Anmeldeinformationen haben nicht funktioniert. Der Anmeldeversuch ist fehlgeschlagen.`	Veraltete oder widersprüchliche Anmeldeinformationen in der Anmeldeinformationsverwaltung	Alle Umgebungen
`Anmeldeinformationen ungültig.`	Probleme mit Microsoft-Konto-Anmeldeinformationen in einigen RDP-Szenarien (oft wegen Nichtübereinstimmung von Kennwort/PIN oder fehlerhafter Verarbeitung der Anmeldeinformationen)	Windows 11
`Es ist ein Authentifizierungsfehler aufgetreten. Die angeforderte Funktion wird nicht unterstützt.`	CredSSP-/NLA-Sicherheitsinkompatibilität zwischen Client und Ziel (oft nach Updates oder wenn eine Seite nicht vollständig gepatcht ist)	Nach Updates, alle
`Es ist ein Authentifizierungsfehler aufgetreten. Die lokale Sicherheitsautorität kann nicht kontaktiert werden.`	NLA-Fehler, wenn der Domänencontroller nicht erreichbar ist	Domänennetzwerke
`Anmeldefehler: Dem Benutzer wurde der angeforderte Anmeldetyp auf diesem Computer nicht gewährt.`	Dem Konto wurde das RDS-Anmelderecht explizit per Gruppenrichtlinie verweigert	Domänen- oder lokale Richtlinie

HINWEIS: In gemischten Umgebungen führt ein falsches Format des Benutzernamens (zum Beispiel ein lokaler Benutzername statt DOMAIN\username, oder umgekehrt) zu einem sofortigen Authentifizierungsfehler, selbst wenn das Kennwort korrekt ist.

Der Fehler kann auch auftreten, wenn eine Verbindung zu einem völlig falschen Host hergestellt wird (zum Beispiel wenn DNS auf eine andere Maschine auflöst) oder wenn Remotedesktop auf dem Ziel nicht ordnungsgemäß aktiviert ist.

Die meisten dieser Ursachen lassen sich auf die Art und Weise zurückführen, wie RDP seine Authentifizierungsebenen stapelt, bevor auch nur ein einziges Pixel des Remote-Desktops sichtbar ist. Dieses Design ergibt für ein Protokoll für Unternehmensnetzwerke Sinn. Für IT-Techniker, die Remote-Support auf Endpunkten leisten, die sie nicht vollständig kontrollieren, sind diese Ebenen jedoch eine unvermeidliche Quelle für Sitzungsfehler. HelpWire ist genau für diesen Anwendungsfall entwickelt. Sie starten eine Sitzung einfach, indem Sie einen Link senden, und der Endbenutzer verbindet sich ohne jegliche Kontokonfiguration auf seiner Seite. Zusätzlich ermöglicht der unbeaufsichtigte Zugriff Folgearbeiten, ohne dass Sie erneut durch die Authentifizierungskette müssen.

Korrekte Anmeldeinformationen heben ein fehlendes Richtlinienrecht nicht auf. Das Recht Anmelden über Remotedesktopdienste zulassen in der lokalen Sicherheitsrichtlinie ist eine eigene Einstellung, getrennt von lokalen Administratorrechten. Wenn Ihr Konto auf dem Zielrechner nicht unter diesem Recht aufgeführt ist, lehnt Windows die Verbindung ab, noch bevor es prüft, ob das Kennwort gültig ist. Ich habe gesehen, wie Leute ihr Kennwort zweimal zurücksetzen, ihr Konto zur lokalen Administratorgruppe hinzufügen und dennoch auf denselben Fehler stoßen, weil keine dieser Maßnahmen diese Richtlinieneinstellung betrifft.

Die zweite, stille Ursache ist die Anmeldeinformationsverwaltung auf dem verbindenden Rechner. Windows speichert RDP-Anmeldeinformationen, die an den Hostnamen oder die IP-Adresse des Ziels gebunden sind. Sind diese gespeicherten Anmeldeinformationen veraltet oder gehören sie zu einem anderen Konto, kann Windows je nach Art des gespeicherten Eintrags automatisch die hinterlegten Anmeldeinformationen für das Ziel anwenden, noch bevor Sie zur Eingabe aufgefordert werden. Sie sehen die Fehlermeldung, vermuten ein falsches Kennwort, ändern es und laufen erneut gegen die gleiche Wand. In einigen Fällen überschreiben in der Anmeldeinformationsverwaltung gespeicherte Anmeldeinformationen die manuelle Eingabe, insbesondere nach Kennwortänderungen.

Kontosperrung ist eine dritte Ursache, die in Arbeitsgruppen-Umgebungen oft übersehen wird. Wenn ein anderes Gerät, eine veraltete gespeicherte Anmeldeinformation in einem Browser oder eine getrennte RDP-Sitzung wiederholt alte Anmeldeinformationen gegen dasselbe Konto verwendet, wird das Konto gesperrt, noch bevor Sie Remotedesktopverbindung überhaupt öffnen. Ein Blick in die lokale Benutzerverwaltung des Zielrechners unter Computerverwaltung bestätigt das in unter 30 Sekunden.

Das Deaktivieren der Windows-Firewall ist der instinktive erste Schritt. Firewallregeln steuern, ob die TCP 3389-Verbindung das Ziel überhaupt erreicht. Wenn Sie die Anmeldeaufforderung erreichen, sind Firewallprobleme in der Regel nicht die Ursache.

Das Hinzufügen des Kontos zur lokalen Administratorengruppe ist der zweite Instinkt. Administratorrechte gewähren nicht das Anmelderecht für Remotedesktopdienste. Das sind separate Berechtigungen. Sie können lokaler Administrator sein und trotzdem von RDP blockiert werden, wenn das entsprechende Richtlinienrecht fehlt.

Ohne vorher die Ereignisanzeige zu lesen, zwischen Benutzernamenformaten durchzuwechseln, ist reine Raterei. DOMAIN\user, user@domain.com und der bloße Benutzername können alle dasselbe Konto darstellen. Ohne Event ID 4625 vor sich zu haben, haben Sie keine Grundlage zu wissen, was tatsächlich fehlschlägt.

Das Ausführen des Remotedesktopverbindungs-Clients als Administrator auf dem verbindenden Computer hat keine Auswirkung. Die Authentifizierung richtet sich nach der Sicherheitsrichtlinie des Zielrechners, nicht nach der des Clients.

Überprüfen Sie außerdem, dass Remotedesktop auf dem Zielrechner aktiviert ist und dass die Windows-Edition RDP-Hostverbindungen unterstützt (Windows Home tut das nicht).

NLA authentifiziert die Sitzung, bevor der Remotedesktop geladen wird. Wenn der Zielcomputer den Domänencontroller nicht erreichen kann oder wenn zwischen Client und Ziel ein CredSSP-Versionskonflikt besteht, kann NLA den Authentifizierungsversuch beenden, bevor die Sitzung initialisiert wird. Dies äußert sich auf der Clientseite häufig durch die Meldung The logon attempt failed. Das vorübergehende Deaktivieren von NLA auf dem Zielcomputer unter der Registerkarte Systemeigenschaften > Remote bestätigt, ob NLA die Ursache ist.

Führen Sie auf dem Zielcomputer rsop.msc aus und navigieren Sie zu Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Zuweisen von Benutzerrechten. Wenn das betroffene Konto unter Anmelden über Remotedesktopdienste verweigern aufgeführt ist, setzt dieser Eintrag alle Rechte vom Typ Zulassen außer Kraft und muss auf der Ebene der Gruppenrichtlinien, auf der er angewendet wird, mithilfe der Gruppenrichtlinien-Verwaltungskonsole entfernt werden.

Beginnend mit dem Windows-Update vom April 2026 (KB5083769) hat Microsoft verpflichtende Warnhinweise hinzugefügt, bevor .rdp-Dateien eine Verbindung herstellen, die Benutzer dazu auffordern zu bestätigen, welche lokalen Ressourcen freigegeben werden sollen. Dies ist eine Sicherheitsfunktion zur Verhinderung von Spoofing-Angriffen, kann jedoch lästig wirken, wenn der Dialog die Einstellungen nicht speichert. Das Setzen von RedirectionWarningDialogVersion auf 1 stellt das Dialogverhalten auf den Stand vor April 2026 zurück und dient als vorübergehender Workaround, obwohl die zugrunde liegenden Sicherheitsverbesserungen weiterhin aktiv bleiben.

Profi-Tipp: Richten Sie auf jedem Computer, den Sie remote verwalten, frühzeitig ein dediziertes lokales Administratorkonto für den RDP-Zugriff ein. Vergeben Sie ein starkes Passwort, das in einem Passwortmanager gespeichert ist, und gewähren Sie ihm bereits bei der Einrichtung das Recht Allow log on through Remote Desktop Services. Wenn der Domänencontroller ausfällt, NLA nach einem Update nicht mehr funktioniert oder das Hauptkonto in einen Richtlinienkonflikt gerät, ist dieses lokale Konto der einzige Weg in den Computer, der die gesamte in diesem Artikel beschriebene Authentifizierungskette umgeht.

Wenn Sie .rdp-Dateien für Benutzer verwalten, sollten Sie diese nach dem Update vom April 2026 mit PowerShell signieren, um wiederholte Vertrauenswarnungen zu vermeiden. Nicht signierte .rdp-Dateien lösen unter Windows 11 mit KB5083769 oder neuer bei jedem Start die neue Spoofing-Warnung aus.

Wenn der Fehler „Anmeldeversuch fehlgeschlagen“ Ihren einzigen Zugangsweg zum Computer blockiert und Sie keinen Konsolenzugriff, kein alternatives lokales Konto haben und niemand vor Ort ist, um Einstellungen zu ändern, stößt die Standard-RDP-Fehlerbehebung an eine harte Grenze. Sie können secpol.msc nicht öffnen, die Anmeldeinformationsverwaltung nicht leeren oder NLA auf einem Computer nicht deaktivieren, bei dem Sie sich nicht anmelden können.

In diesem Szenario bietet HelpWire einen praktischen Ausweg. Der Endbenutzer öffnet einen Sitzungslink, ohne Kontokonfiguration, ohne NLA-Handshake und ohne erforderliche Domänenerreichbarkeit auf seiner Seite. Sobald die Sitzung aktiv ist, können Sie alle in diesem Artikel beschriebenen Korrekturen direkt auf dem Computer anwenden und RDP für die zukünftige Nutzung wiederherstellen.

Beheben Sie den RDP-Fehler Anmeldeversuch fehlgeschlagen unter Windows

Was bedeutet “RDP Logon Attempt Failed”?

Wie beheben Sie den Fehler “Remote Desktop Logon Attempt Failed”?

Lösung 1: Gewähren Sie das Anmelderecht für Remotedesktopdienste

Lösung 2: Veraltete Anmeldeinformationen in der Anmeldeinformationsverwaltung löschen

Lösung 3: Authentifizierung auf Netzwerkebene diagnostizieren und deaktivieren

Lösung 4: Beheben Sie den RDP-Fehler “The Logon Attempt Failed” mit einem Microsoft-Konto

Lösung 5: Beheben Sie den RDP-Fehler “Anmeldeversuch fehlgeschlagen” nach einem Windows-Update

Fix 6: Beheben Sie den Fehler, dass der RDP-Anmeldeversuch beim zweiten Versuch in Domänenumgebungen fehlschlägt

Verwenden der Ereignisanzeige zur Diagnose von RDP-Authentifizierungsfehlern

Ursachen für den RDP-Fehler Logon Attempt Failed

Warum zeigt RDP „Remote Desktop Connection Logon Attempt Failed“, obwohl das Passwort korrekt ist?

Was die meisten Menschen als Erstes nach “Remotedesktop-Anmeldung fehlgeschlagen” versuchen (und warum es nicht funktioniert)

Häufig gestellte Fragen