Nicht funktionierende Remotedesktop-Anmeldeinformationen beheben

Der Fehler Ihre Anmeldeinformationen haben nicht funktioniert in Remotedesktop bedeutet nicht, dass Ihr Kennwort falsch ist. In vielen Fällen sendet der sich verbindende Computer veraltete, zwischengespeicherte Anmeldeinformationen, die eine Kennwortänderung überstanden haben. In manchen Konfigurationen befindet sich der Zielcomputer in einem Windows-Hello-PIN-basierten Anmeldestatus, der die RDP-Anmeldung mit Microsoft-Konto blockieren kann. Das sind die häufigsten Auslöser, doch Anmeldefehler haben auf beiden Rechnern mehr als ein Dutzend unterschiedliche Ursachen.

Dieser Leitfaden behandelt die zuverlässigsten Lösungen, die in der Microsoft-Dokumentation und Q&A sowie in wiederkehrenden Community-Fehlerbehebungsthreads gemeldet wurden.

Inhaltsverzeichnis

Finden Sie in der Tabelle unten die wahrscheinlichste Ursache und gehen Sie direkt zu der entsprechenden Lösung, statt jede einzelne Option zu testen.

Ursache	Seite	Fix-Abschnitt
Zwischengespeicherte oder veraltete Anmeldeinformationen	Client	Fix 1
Windows Hello-PIN-bezogenes Microsoft-Konto-Anmeldeproblem	Zielcomputer	Fix 2
Falsches Format des Benutzernamens	Client	Fix 3
Benutzer nicht in der Gruppe Remote Desktop Users	Zielcomputer	Fix 4
Delegierung von Anmeldeinformationen durch GPO blockiert	Client	Fix 5
Nichtübereinstimmung der RDP-Sicherheitsebene	Zielcomputer	Fix 6
`Always prompt for password` ist aktiviert	Zielcomputer	Fix 7
Netzwerkprofil auf `Public` gesetzt	Zielcomputer	Fix 8
Nichtübereinstimmung der LAN-Manager-Authentifizierungsebene	Zielcomputer	Fix 9
`fDenyTSConnections` auf `1` gesetzt	Zielcomputer	Fix 10
Einschränkung für leere Kennwörter	Zielcomputer	Fix 11
RDP-Listener nicht aktiv	Zielcomputer	Fix 12
Abgelaufenes RDP-Zertifikat	Zielcomputer	Sonderfälle
Nicht-Standard-RDP-Port	Zielcomputer	Sonderfälle

Dies ist die am häufigsten bestätigte Lösung, wenn Remote Desktop-Anmeldeinformationen auf Geräten mit Microsoft-Konten und aktivierter Windows Hello-PIN nicht funktionierten. In Benutzerberichten hat die lokale Anmeldung mit dem Kontokennwort den RDP-Zugriff wiederhergestellt, nachdem auf dem Zielgerät zuvor ausschließlich die PIN verwendet wurde.

HINWEIS: Windows Hello for Business ist eine separate Unternehmensfunktion, die die RDP-Anmeldung mittels zertifikatsbasierter Bereitstellung über Microsoft Intune oder Active Directory Certificate Services unterstützt. Dafür sind eine PKI-Infrastruktur, die Bereitstellung von Zertifikaten und Domänencontrollerzertifikate erforderlich. Sie ist in Standard-Consumer- oder SMB-Setups nicht verfügbar und steht in keinem Zusammenhang mit dem hier beschriebenen Consumer-PIN-Szenario.

Melden Sie sich auf dem Zielsystem von der aktuellen Sitzung ab.
Klicken Sie auf dem Anmeldebildschirm auf Anmeldeoptionen.
Wählen Sie die Passwortoption (das Schlüsselsymbol) aus.
Melden Sie sich mit Ihrem vollständigen Kennwort für Ihr Microsoft-Konto an.
Stellen Sie die RDP-Verbindung vom Client-Computer erneut her.

Klicken Sie auf dem Anmeldebildschirm auf Anmeldeoptionen, klicken Sie dann auf Ich habe meine PIN vergessen.
Authentifizieren Sie sich mit den Anmeldeinformationen Ihres Microsoft-Kontos, einschließlich etwaiger Zwei-Faktor-Bestätigung.
Wenn Sie aufgefordert werden, Ihre PIN zurückzusetzen, bestätigen Sie das Zurücksetzen. Sie können dieselbe PIN erneut eingeben.
Versuchen Sie die RDP-Verbindung erneut, nachdem der passwortbasierte Anmeldevorgang abgeschlossen ist.

Mehrere Benutzer bestätigten, dass das Deaktivieren dieses einzelnen Schalters das Problem behoben hat, ohne dass ein Ab- und erneutes Anmelden erforderlich war.

Auf dem Zielcomputer gehen Sie zu Einstellungen > Konten > Anmeldeoptionen.
Suchen Sie nach Zur Verbesserung der Sicherheit nur die Anmeldung mit Windows Hello für Microsoft-Konten auf diesem Gerät zulassen.
Schalten Sie es aus.
Melden Sie sich ab und melden Sie sich mit dem Kennwort für das Microsoft-Konto wieder an.

Die Windows-Anmeldeinformationsverwaltung auf dem verbindenden Computer zwischenspeichert TERMSRV/-Einträge. Nach einer Passwortänderung sendet sie bei jedem Verbindungsversuch das alte Passwort stillschweigend, ohne nachzufragen.

Öffnen Sie auf dem Computer, der die Verbindung herstellt, die Anmeldeinformationsverwaltung. Suchen Sie im Startmenü danach, oder führen Sie control /name Microsoft.CredentialManager aus.
Klicken Sie auf Windows-Anmeldeinformationen.
Suchen Sie alle Einträge, die mit TERMSRV/ beginnen, gefolgt vom Namen oder der IP-Adresse des entfernten Rechners.
Klicken Sie auf jeden Eintrag und dann auf Entfernen.
Erneut verbinden. Windows wird Sie zur Eingabe neuer Anmeldeinformationen auffordern.

Öffnen Sie die Remotedesktopverbindung (mstsc.exe).
Geben Sie den Namen des Remote-Computers oder die IP-Adresse ein.
Klicken Sie auf Optionen anzeigen.
Klicken Sie in den Anmeldeeinstellungen auf den Link Bearbeiten neben dem gespeicherten Benutzernamen.
Geben Sie das aktuelle Passwort ein und speichern Sie.

In manchen Konfigurationen werden RDP-Anmeldeinformationen nicht über Sitzungen hinweg beibehalten. Das direkte Hinzufügen eines Eintrags für generische Anmeldeinformationen in der Anmeldeinformationsverwaltung zwingt Windows dazu, diese zu verwenden.

Öffnen Sie Anmeldeinformationsverwaltung > Windows-Anmeldeinformationen.
Klicken Sie auf Generische Anmeldeinformationen hinzufügen.
In der Internet- oder Netzwerkadresse geben Sie TERMSRV/ gefolgt vom Hostnamen oder der IP-Adresse des Remote-Computers ein. Zum Beispiel: TERMSRV/103.27.76.117 oder TERMSRV/COMPUTERNAME.
Geben Sie den Benutzernamen und das Passwort ein.
Klicken Sie auf OK, schließen Sie die Anmeldeinformationsverwaltung und verbinden Sie sich erneut.

Das Format des von Ihnen eingegebenen Benutzernamens bestimmt, welchen Authentifizierungsanbieter Windows anspricht. Die Verwendung des falschen Formats leitet die Anfrage an die falsche Identitätsquelle weiter und schlägt selbst mit korrektem Kennwort fehl.

Microsoft dokumentiert, dass Sie sich bei einem Remotegerät, das Microsoft Entra beigetreten ist, je nach verwendetem Anmeldeweg entweder mit user@domain.com oder AzureAD\user@domain.com anmelden können. Wenn ein Format fehlschlägt, versuchen Sie das andere.

Kontoart	Korrektes Format	Hinweise
Lokales Konto	`COMPUTERNAME\username</code`	Beispiel: `DESKTOP-AB12\john`
Domänenkonto (NetBIOS)	`DOMAIN\username`	Beispiel: `CORP\johndoe`
Domänenkonto (UPN)	`username@domain.com`	Beispiel: `johndoe@corp.local`
Microsoft-Konto	Vollständige E-Mail-Adresse	Beispiel: `john@outlook.com`
Microsoft Entra beigetreten	`AzureAD\user@domain.com` oder `user@domain.com`	Microsoft dokumentiert beide Formate für unterschiedliche Anmeldewege. Versuchen Sie das alternative Format, wenn das erste fehlschlägt.

Ein Konto muss auf dem Zielcomputer entweder zur Gruppe Remotedesktopbenutzer oder zur Gruppe Administratoren gehören. Event ID 4625 mit dem Unterstatus 0xC000015B bestätigt, dass dem Benutzer der erforderliche Anmeldetyp nicht gewährt wurde. Alleinige Gruppenmitgliedschaft kann dennoch durch ein explizites Verweigern bei der Zuweisung von Benutzerrechten blockiert werden.

Führen Sie auf dem Zielcomputer diesen Befehl als Administrator aus:
net localgroup "Remote Desktop Users" /add "DOMAIN\username" oder in PowerShell:
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\username"
Öffnen Sie Ausführen und geben Sie secpol.msc ein.
Navigieren Sie zu Lokale Richtlinien > Zuweisen von Benutzerrechten.
Doppelklicken Sie auf Anmelden über Remotedesktopdienste zulassen.
Klicken Sie auf Benutzer oder Gruppe hinzufügen.
Geben Sie den Kontonamen ein und klicken Sie auf OK.
Überprüfen Sie in derselben Liste, ob ein Anmelden über Remotedesktopdienste verweigern-Eintrag vorhanden ist, der den Benutzer oder dessen Gruppe enthält. Entfernen Sie alle expliziten Verweigerungseinträge.

Wenn Richtlinien zur Delegierung von Anmeldeinformationen auf dem verbindenden Computer einschränken, wie Anmeldeinformationen weitergeleitet werden, kann sich der RDP-Client selbst mit einem korrekten Kennwort nicht authentifizieren. Dies gilt für alle Kontotypen und ist eine der am häufigsten übersehenen Ursachen dafür, dass Anmeldeinformationen bei Remotedesktop nicht funktionieren. Die Korrektur erfolgt auf dem Clientcomputer, nicht auf dem Remotecomputer.

Öffnen Sie auf dem Verbindungscomputer Ausführen und geben Sie gpedit.msc ein.
Navigieren Sie zu Computerkonfiguration > Administrative Vorlagen > System > Delegierung von Anmeldeinformationen.
Setzen Sie Delegierung gespeicherter Anmeldeinformationen verweigern auf Nicht konfiguriert.
Setzen Sie Delegieren neuer Anmeldeinformationen verweigern auf Nicht konfiguriert.
Öffnen Sie Zulassen der Delegierung gespeicherter Anmeldeinformationen mit ausschließlich NTLM-basierter Serverauthentifizierung. Setzen Sie es auf Aktiviert.
Klicken Sie auf Anzeigen neben Server zur Liste hinzufügen und geben Sie TERMSRV/* ein. Klicken Sie auf OK.
Wiederholen Sie Schritt 5 für: Zulassen der Delegierung gespeicherter Anmeldeinformationen, Zulassen der Delegierung neuer Anmeldeinformationen mit ausschließlich NTLM-basierter Serverauthentifizierung und Zulassen der Delegierung neuer Anmeldeinformationen.
Navigieren Sie zu Computerkonfiguration > Administrative Vorlagen > Windows-Komponenten > Remotedesktopdienste > Remotedesktopverbindungsclient.
Setzen Sie Speichern von Kennwörtern nicht zulassen auf Nicht konfiguriert.
Setzen Sie Aufforderung zur Eingabe von Anmeldeinformationen auf dem Clientcomputer auf Nicht konfiguriert.
Schließen Sie den Gruppenrichtlinien-Editor und führen Sie gpupdate /force in einer Eingabeaufforderung mit erhöhten Rechten aus.

Mehrere Nutzer bestätigten diesen Fix, nachdem alle anderen Lösungen fehlgeschlagen waren. Wenn die zwischen Client und Ziel ausgehandelte Sicherheitsebene zu keiner Einigung führt, wird die Authentifizierung verweigert, bevor die Anmeldeinformationen vollständig geprüft werden.

Öffnen Sie auf dem Zielcomputer Ausführen und geben Sie gpedit.msc ein.
Navigieren Sie zu Computerkonfiguration > Administrative Vorlagen > Windows-Komponenten > Remotedesktopdienste > Remotedesktop-Sitzungshost > Sicherheit.
Öffnen Sie Verwendung einer bestimmten Sicherheitsebene für Remotedesktopverbindungen (RDP) erforderlich machen.
Stellen Sie es auf Enabled ein. Wählen Sie im Dropdown RDP als Sicherheitsebene.
Klicken Sie auf OK, und führen Sie dann gpupdate /force in einer Eingabeaufforderung mit erhöhten Rechten aus.

Wenn diese Richtlinie auf dem Remotecomputer aktiviert ist, setzt sie die auf dem Client gespeicherten Anmeldeinformationen außer Kraft und erzwingt eine erneute Authentifizierungsaufforderung. Diese Aufforderung schlägt stillschweigend fehl und erzeugt einen Anmeldeinformationsfehler statt eines sichtbaren Kennwortdialogs.

Öffnen Sie auf dem Zielcomputer Ausführen und geben Sie gpedit.msc ein.
Navigieren Sie zu Computerkonfiguration > Administrative Vorlagen > Windows-Komponenten > Remotedesktopdienste > Remotedesktop-Sitzungshost > Sicherheit.
Öffnen Sie Beim Herstellen der Verbindung immer nach dem Passwort fragen.
Setzen Sie es auf Disabled oder Not Configured.
Melden Sie sich ab und wieder an oder führen Sie gpupdate /force aus.

Wenn das Netzwerkprofil des Zielsystems auf Public eingestellt ist, blockiert Windows eingehende RDP-Verbindungen. Microsofts Hinweise zur RDP-Problembehandlung führen das Netzwerkprofil und die Firewallkonfiguration als mögliche Ursachen für Verbindungsfehler an. Dies ist ein häufiger Befund, wenn ansonsten in der Konfiguration alles korrekt aussieht.

Öffnen Sie auf dem Zielcomputer Einstellungen > Netzwerk und Internet > Status.
Klicken Sie auf Verbindungseigenschaften ändern.
Setzen Sie das Netzwerkprofil auf Privat.

Eine Nichtübereinstimmung des Authentifizierungsniveaus zwischen dem verbindenden Computer und dem Remotecomputer führt zur Ablehnung der Anmeldeinformationen auf der NTLM-Aushandlungsebene, unabhängig davon, ob das Kennwort korrekt ist oder nicht.

Öffnen Sie auf dem Zielcomputer Ausführen und geben Sie gpedit.msc ein.
Navigieren Sie zu Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen.
Öffnen Sie Netzwerksicherheit: LAN-Manager-Authentifizierungsebene.
Stellen Sie es auf einen der folgenden drei nachweislich funktionierenden Werte ein: Send NTLMv2 response only, Send NTLMv2 response only. Refuse LM oder Send NTLMv2 response only. Refuse LM and NTLM. Jede der drei Optionen behebt die Inkonsistenz. Die am wenigsten restriktive Option, die Sie zuerst ausprobieren sollten, ist Send NTLMv2 response only.
Klicken Sie auf OK.

Wenn RDP in den Einstellungen als aktiviert angezeigt wird, Verbindungen jedoch weiterhin fehlschlagen, können zwei Registrierungswerte die Einstellung in der Benutzeroberfläche außer Kraft setzen. Microsoft dokumentiert fDenyTSConnections als die Einstellung, die steuert, ob Benutzer mithilfe der Remotedesktopdienste eine Remoteverbindung herstellen können.

Öffnen Sie den Registrierungs-Editor als Administrator (regedit.exe).
Navigieren Sie zu: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
Bestätigen Sie, dass fDenyTSConnections auf 0 gesetzt ist.
Prüfen Sie außerdem:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services. Wenn fDenyTSConnections hier auf 1 gesetzt ist, erzwingt eine Gruppenrichtlinie die Sperre. Das Ändern des lokalen Werts wird nicht beibehalten. Das GPO muss an der Quelle korrigiert werden.
Um zu überprüfen, ob der RDP-Port nicht vom Standardwert geändert wurde, navigieren Sie zu: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp
Suchen Sie nach PortNumber. Wechseln Sie die Anzeigebasis auf Decimal.
Der Wert sollte 3389 sein. Falls dies nicht der Fall ist, muss sich Ihr RDP-Client stattdessen über diesen benutzerdefinierten Port verbinden, und zwar im Format hostname:PORT.

Nach jeder Änderung an der Registrierung starten Sie die Remotedesktopdienste neu: Öffnen Sie services.msc, suchen Sie Remotedesktopdienste, klicken Sie mit der rechten Maustaste und wählen Sie Neu starten.

Windows blockiert RDP standardmäßig für Konten, für die kein Kennwort festgelegt ist. Dies ist eine Einschränkung der lokalen Sicherheitsrichtlinie, keine RDP-Einstellung.

Öffnen Sie Ausführen und geben Sie gpedit.msc ein.
Navigieren Sie zu Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen.
Öffnen Sie Konten: Verwendung leerer Kennwörter bei lokalen Konten nur für die Anmeldung an der Konsole zulassen.
Setzen Sie es auf Disabled.

Bevor Sie annehmen, dass das Problem mit Anmeldeinformationen zusammenhängt, vergewissern Sie sich, dass das RDP-Protokoll auf dem Zielcomputer tatsächlich auf Verbindungen lauscht. Wenn der RDP-Listener nicht aktiv ist, weist der Server Verbindungen bereits auf Protokollebene zurück, bevor Remotedesktop-Anmeldeinformationen ausgewertet werden. Dies führt zu Fehlermeldungen, die wie Authentifizierungsfehler aussehen.

Führen Sie diesen Befehl mit administrativen Rechten auf dem Zielcomputer aus, über PowerShell Remoting oder mit physischem Konsolenzugriff:

qwinsta

Suchen Sie nach einem Eintrag namens rdp-tcp, dessen STATE auf Listen gesetzt ist. Falls er fehlt oder einen anderen Status anzeigt, liegt beim RDP-Dienst ein Protokollfehler vor. Überprüfen Sie die Registrierungsschlüssel in Fix 10 oben und das RDP-Zertifikat im Abschnitt zu Sonderfällen unten, und starten Sie anschließend Remote Desktop Services neu.

PROFI-TIPP: Auf jedem von Ihnen aus der Ferne verwalteten Rechner sollten Sie ein dediziertes lokales Administratorkonto führen, das keine Anmeldung mit einem Microsoft-Konto verwendet. Wenn MSA-, PIN- oder Zertifikatsprobleme RDP blockieren, umgeht ein lokales Konto die MSA-Anmelde-Pipeline vollständig und ermöglicht Ihnen weiterhin den Zugang.

Für IT-Supportteams, die remote auf mehreren Rechnern arbeiten, ist HelpWire als Ergänzung zu RDP empfehlenswert. Sitzungen starten über einen Link, ohne dass der Remote-Benutzer irgendwelche Systemeinstellungen ändern muss. Das bedeutet, dass RDP-Authentifizierungsfehler auf dem entfernten Rechner den Start einer Support-Sitzung nicht verhindern. Bewahren Sie lokale Admin-Anmeldeinformationen in einem Passwort-Manager auf, nicht zwischengespeichert in der Anmeldeinformationsverwaltung auf Ihrem eigenen Rechner.

Öffnen Sie auf dem Zielcomputer die Ereignisanzeige und prüfen Sie unter Windows-Protokolle > System auf Ereignis-ID 1057 oder 1058 von Microsoft-Windows-TerminalServices-RemoteConnectionManager. Diese Ereignisse weisen darauf hin, dass das selbstsignierte Zertifikat nicht erneuert werden konnte.

Öffnen Sie mmc.exe > Datei > Snap-In hinzufügen/entfernen > Zertifikate > Computerkonto.
Navigieren Sie zu Zertifikate > Remotedesktop.
Löschen Sie das abgelaufene selbstsignierte Zertifikat.
Starten Sie Remotedesktopdienste in services.msc neu. Windows erstellt das Zertifikat automatisch neu.

Navigieren Sie zu C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys.
Übernehmen Sie den Besitz der RDP-bezogenen Schlüsseldatei.
Löschen Sie die Datei.
Starten Sie die Remotedesktopdienste neu.

Beim Verbinden über den Hostnamen vergewissern Sie sich, dass der DNS-Name auf die richtige Maschine aufgelöst wird, insbesondere nach einem Neuaufsetzen der Maschine oder einer IP-Änderung.

Führen Sie auf dem Zielrechner in einer Eingabeaufforderung mit erhöhten Rechten IPCONFIG /All aus und notieren Sie die tatsächliche IP-Adresse.
Führen Sie auf dem Rechner, der die Verbindung herstellt, nslookup MACHINENAME aus und bestätigen Sie, dass die zurückgegebene IP-Adresse übereinstimmt.
Führen Sie außerdem Test-NetConnection -ComputerName SERVER-IP -Port 3389 in PowerShell aus. Wenn TcpTestSucceeded False zurückgibt, liegt das Problem am Netzwerk oder an der Firewall, nicht an den Anmeldeinformationen.
Wenn das DNS veraltet ist, verbinden Sie sich direkt über die IP-Adresse oder aktualisieren Sie den DNS-Eintrag.

Wiederholte fehlgeschlagene RDP-Versuche lösen auf mit der Domäne verbundenen Computern die Kontosperrungsrichtlinie aus. Prüfen Sie auf dem Domänencontroller die Ereignisanzeige auf Ereignis-ID 4625 mit Unterstatus 0xC0000234. Für ein lokales Konto auf dem Zielcomputer führen Sie Folgendes aus:

net user USERNAME

Suchen Sie in der Ausgabe nach Account active: No. Zum Reaktivieren:

net user USERNAME /active:yes

Microsoft dokumentiert, dass Sie sich bei einem Remote-Gerät, das Microsoft Entra beigetreten ist, je nach Anmeldemethode mit user@domain.com oder AzureAD\user@domain.com anmelden können. Wenn ein Format fehlschlägt, versuchen Sie das andere. Bestätigen Sie in jedem Fall, dass der Benutzer auf dem Zielgerät zur Gruppe Remote Desktop Users hinzugefügt wurde. Überprüfen Sie außerdem das Gerät im Entra Admin Center unter Devices > the specific device > Local administrators.

Ereignis-ID 4625 in den Windows-Sicherheitsprotokollen zeichnet jeden fehlgeschlagenen Anmeldeversuch auf. Das Feld Unterstatus gibt den genauen Grund für den Authentifizierungsfehler an, was das Rätselraten bei der Diagnose vollständig beseitigt.

Substatus-Code	Fehlerursache	Anzuwendende Maßnahme
`0xC000006A`	Benutzername korrekt, falsches Kennwort	Anmeldeinformationsverwaltung leeren, aktuelles Kennwort überprüfen
`0xC0000234`	Konto gesperrt	Mit einem Administratorkonto entsperren oder auf das automatische Entsperren gemäß Kontosperrungsrichtlinie warten
`0xC0000072`	Konto deaktiviert	Konto in der Computerverwaltung aktivieren
`0xC0000071`	Kennwort abgelaufen	Kennwort des Zielkontos ändern
`0xC000015B`	Benutzer hat kein RDP-Anmelderecht	Zur Gruppe Remotedesktopbenutzer hinzufügen und die Zuweisen von Benutzerrechten prüfen

Um auf diese Protokolle zuzugreifen: Öffnen Sie Ereignisanzeige > Windows-Protokolle > Sicherheit > filtern Sie nach Ereignis-ID 4625. In den Ereignisdetails erweitern Sie Fehlerinformationen und lesen Sie den Unterstatus-Hex-Wert.

Das Erste, was die meisten tun, wenn die Windows-Remotedesktop-Anmeldeinformationen nicht funktionieren, ist, das Kennwort ihres Microsoft-Kontos zurückzusetzen. Das hilft in den oben beschriebenen Szenarien mit PIN und zwischengespeicherten Anmeldeinformationen jedoch nicht. Häufig liegt das Problem nicht am Kontokennwort selbst, sondern an zwischengespeicherten Anmeldeinformationen oder an einem nicht übereinstimmenden Authentifizierungszustand zwischen Geräten. Das Zurücksetzen des Kennworts behebt das Problem nicht, weil der Client weiterhin die älteren zwischengespeicherten Anmeldeinformationen übermittelt, bis der gespeicherte TERMSRV/-Eintrag gelöscht oder ersetzt wird.

Der zweite häufige Versuch besteht darin, NLA ein- und auszuschalten. Bei dem Windows-Hello-PIN-Problem und veralteten zwischengespeicherten Anmeldeinformationen ist der NLA-Status nicht die Variable. Das PIN-Problem tritt auf, weil die Standardauthentifizierung per Windows-Hello-PIN gerätegebunden ist und nicht über die standardmäßigen RDP-Authentifizierungsabläufe weitergereicht wird. Das Deaktivieren von NLA schwächt außerdem die Verbindungssicherheit, ohne die eigentliche Ursache zu beheben.

Ein dritter Ansatz, der in einigen Foren-Threads kursiert, besteht darin, den Registrierungsschlüssel WinStations zu löschen. Das kann jedoch den Computer unbrauchbar machen und eine vollständige Neuinstallation des Betriebssystems erforderlich machen.

Wenn die RDP-Konfiguration selbst das Problem ist und nicht ein Formatierungsproblem der Anmeldeinformationen, lohnt es sich, ein für Supportaufgaben entwickeltes Tool im Werkzeugkasten zu behalten. Beispielsweise startet HelpWire Sitzungen, indem ein Link an den Remote-Benutzer gesendet wird, der dann einen leichtgewichtigen Client ausführt. Sie verbinden sich dann, ohne sich überhaupt gegenüber den lokalen Konten des Remote-Computers authentifizieren zu müssen. Wenn Sie auf einen Computer zugreifen müssen, dessen RDP-Anmeldeinformations-Stack defekt ist, entfällt damit die Abhängigkeit davon, dass RDP korrekt konfiguriert ist.

Wenn die Remote-Desktop-Anmeldeinformationen nicht funktionieren, ist der häufigste Grund ein veraltetes Kennwort, das im Windows Credential Manager auf dem verbindenden Computer zwischengespeichert ist und nach einer Kennwortänderung ohne Aufforderung automatisch gesendet wird. Ein weiterer häufiger Grund ist, dass der Zielcomputer zuletzt lokal mit einer Windows Hello PIN authentifiziert wurde, was in manchen Konfigurationen die Microsoft-Konto-Anmeldung per RDP blockieren kann.

Eine standardmäßige Windows Hello-PIN ist gerätegebunden und wird über die standardmäßigen RDP-Authentifizierungsabläufe nicht weitergeleitet. RDP erfordert in Standard-Consumer- und SMB-Konfigurationen kennwortbasierte Anmeldeinformationen.

Windows Hello for Business ist eine separate Unternehmensfunktion, die RDP über zertifikatbasierte Authentifizierung unterstützt, jedoch eine PKI-Infrastruktur, die Bereitstellung von Zertifikaten über Intune oder AD CS sowie Domänencontroller-Zertifikate erfordert. Sie ist in Standard-Consumer- oder SMB-Setups nicht verfügbar.

Öffnen Sie die Anmeldeinformationsverwaltung über das Startmenü, klicken Sie auf Windows-Anmeldeinformationen und entfernen Sie jeden Eintrag, der mit TERMSRV/ beginnt und dem Remotecomputer entspricht. Wenn Anmeldeinformationen nicht zwischen Sitzungen beibehalten werden, verwenden Sie Generische Anmeldeinformationen hinzufügen in der Anmeldeinformationsverwaltung und geben Sie die TERMSRV/[hostname] Adresse zusammen mit dem Benutzernamen und dem Kennwort manuell ein.

Ja. Die Einstellungen zur Delegierung von Anmeldeinformationen unter Computerkonfiguration > Administrative Vorlagen > System in Gruppenrichtlinie auf dem Client, der die Verbindung herstellt, steuern, ob Anmeldeinformationen überhaupt weitergeleitet werden. Delegierung gespeicherter Anmeldeinformationen verweigern oder Delegierung neuer Anmeldeinformationen verweigern auf Enabled gesetzt, blockiert die Authentifizierung stillschweigend. Beide auf Not Configured setzen und TERMSRV/* unter Delegieren gespeicherter Anmeldeinformationen mit nur-NTLM-Serverauthentifizierung zulassen aktivieren, löst dies.

Löschen Sie die Einträge in der Anmeldeinformationsverwaltung auf dem verbindenden Computer und versuchen Sie es erneut. Wenn die Verbindung weiterhin fehlschlägt, führen Sie Test-NetConnection -ComputerName SERVER-IP -Port 3389 in PowerShell aus. Wenn TcpTestSucceeded True zurückgibt, die Anmeldeinformationen jedoch weiterhin fehlschlagen, liegt das Problem auf dem Zielcomputer. Wenn TcpTestSucceeded False zurückgibt, liegt das Problem am Netzwerk oder an der Firewall. Sobald Sie auf dem Zielcomputer sind, lesen Sie die Ereignis-ID 4625 im Sicherheitsprotokoll, um den genauen Fehlergrund zu ermitteln.

So beheben Sie nicht funktionierende Remotedesktop-Anmeldeinformationen

12 Möglichkeiten, nicht funktionierende Remotedesktop-Anmeldeinformationen zu beheben

Lösung 1: Melden Sie sich einmal mit Ihrem Kennwort auf dem Zielcomputer an (Problem mit der Windows Hello-PIN)

Methode A: Melden Sie sich ab und melden Sie sich mit einem Passwort wieder an

Methode B: Wenn die Passwortoption fehlt oder ausgegraut ist

Methode C: Deaktivieren Sie den Umschalter für die Anmeldung nur mit Windows Hello (eigenständige Fehlerbehebung)

Lösung 2: Veraltete Anmeldeinformationen aus der Anmeldeinformationsverwaltung auf dem Verbindungsrechner löschen

Methode A: Einträge über die Anmeldeinformationsverwaltung entfernen

Methode B: Aktualisieren Sie das Passwort direkt im RDP-Client

Methode C: Eine manuelle generische Anmeldeinformation hinzufügen, wenn gespeicherte Anmeldeinformationen nicht beibehalten werden

Lösung 3: Verwenden Sie das korrekte Benutzernamenformat

Lösung 4: Fügen Sie den Benutzer der Gruppe Remotedesktopbenutzer hinzu und überprüfen Sie die Anmelderechte

Lösung 5: Gruppenrichtlinie für Anmeldeinformationsdelegierung auf dem Verbindungscomputer korrigieren

Lösung 6: Ändern Sie die RDP-Sicherheitsebene per Gruppenrichtlinie auf dem Zielcomputer

Lösung 7: Deaktivieren Sie „Immer nach Kennwort fragen“ auf dem Zielcomputer

Lösung 8: Ändern Sie das Netzwerkprofil auf dem Zielcomputer von Öffentlich zu Privat

Lösung 9: Legen Sie die LAN-Manager-Authentifizierungsebene auf dem Zielcomputer fest

Lösung 10: Überprüfen Sie den Registrierungsschlüssel fDenyTSConnections und den RDP-Port

Lösung 11: Leeres Kennwort für das Zielkonto beheben

Lösung 12: Überprüfen Sie den Status des RDP-Listeners

Korrekturen für Randfälle bei nicht funktionierenden Anmeldeinformationen für Remotedesktop

Fehler bei selbstsigniertem RDP-Zertifikat (Ereignis-ID 1057 oder 1058)

DNS und Gerätezuweisung überprüfen

Kontosperrung

Azure AD / Entra ID beigetretene Computer

So lesen Sie die Ereignisanzeige für fehlgeschlagene RDP-Anmeldungen

Häufige Fehler, die gemacht werden, wenn die Anmeldeinformationen für Windows-Remotedesktop nicht funktioniert haben

Häufig gestellte Fragen