RDP-Authentifizierung: Häufige Fehlerquellen und Lösungen

So stellen Sie sicher, dass eine Remote-Desktop-Verbindung funktioniert

Wenn Sie möchten, dass Remote Desktop auf einem Zielcomputer funktioniert, müssen drei grundlegende Voraussetzungen erfüllt sein.

1. RDP muss auf dem Zielcomputer aktiviert sein.

2. Der Benutzer, der Zugriff wünscht, muss lokal auf dem Zielcomputer oder durch den lokalen Administrator zur Gruppe Remote Desktop hinzugefügt werden.

3. Der Port 3389 TCP muss für den Zielcomputer geöffnet sein und vom Client aus erreichbar sein. UDP 3389 könnte ebenfalls geöffnet werden, ist jedoch nicht zwingend erforderlich.

Außerdem unterscheidet sich der Authentifizierungsmechanismus je nachdem, ob der Zielcomputer einer Domäne angehört, keiner Domäne angehört oder direkt mit Entra ID (ehemals Azure AD) verbunden ist. Wenn der Computer einer Domäne angehört, muss das Ziel auch in der Lage sein, einen Domänencontroller zu erreichen, um sich mit diesem Konto beim Computer zu authentifizieren.

Zunächst werden einige Szenarien behandelt, um aufzuzeigen, was schiefgehen kann und wie man diese Probleme behebt.

In diesem ersten Szenario versucht ein Benutzer, eine RDP-Verbindung zu einem Zielcomputer herzustellen. Der RDP-Client fragt zunächst, welches unterstützte Protokoll auf dem Remotecomputer verfügbar ist. In diesem Szenario antwortete das Ziel mit einer Anforderung der Netzwerkauthentifizierung (NLA). NLA ist eine Funktion, die die Authentifizierung des Benutzers oder Clients sicherstellt, bevor der Zugriff auf Remote Desktop gewährt wird. Aufgrund der Sicherheitsvorteile wird dringend empfohlen, NLA zu aktivieren.

Sie können diese Funktion über die Option unter Systemeigenschaften auf dem Zielcomputer aktivieren oder deaktivieren, wie in Abbildung 1 dargestellt.

Je nachdem, welche Authentifizierungsmethode aktiviert ist, unterstützt der RDP-Client standardmäßig Benutzername und Passwort. RDP unterstützt jedoch auch die folgenden Authentifizierungsmethoden:

• Smartcards
• Entra ID-Benutzer: Wenn der Computer mit Entra ID verbunden ist, wird auch ein Authentifizierungsmechanismus namens PKU2U verwendet.
• Windows Hello for Business: Dies ähnelt Smartcards, da es Zertifikate verwendet.

Neben Smartcards und Windows Hello for Business kann auch ein FIDO2-Sicherheitsschlüssel verwendet werden. Insbesondere wenn WebAuthn-Redirection aktiviert ist, kann in einer RDP-Sitzung die Authentifizierung über einen lokal angeschlossenen Sicherheitsschlüssel oder biometrische Merkmale des Clients passieren.

Der Benutzer gibt dann seinen Benutzernamen und sein Passwort ein, die über die richtige Zugriffsebene auf dem Zielcomputer verfügen. Danach erstellt Windows ein Anmeldeereignis in der Sicherheitstabelle auf dem Zielcomputer mit der Ereignis-ID 4624. Diese ID bedeutet, dass sich ein Konto erfolgreich angemeldet hat. Sie können dies in der Ereignisanzeige sehen, indem Sie zu Windows-Protokolle\Sicherheit navigieren. Das Ereignis wird auch als Anmeldetyp 3 angezeigt, wie in Abbildung 2 zu sehen ist. Dies zeigt an, dass es sich um eine netzwerkbasierte Anmeldung handelt.

Windows erstellt auch ein Ereignis auf dem Zielgerät unter Anwendungs- und Dienstprotokolle\Microsoft\Windows\TerminalServices-RemoteConnectionManager\Operational mit der Ereignis-ID 1149, die eine erfolgreiche Anmeldung am Gerät anzeigt.

Sobald die grafische Benutzeroberfläche auf das Zielgerät übertragen wird, erstellt Microsoft außerdem ein neues Ereignis unter derselben Ereignisanzeige mit den Ereignis-IDs 21 und 22. Die Ereignis-ID 21 gibt die Sitzungs-ID an, die der Verbindung zugewiesen wurde, und 22 gibt an, dass die interaktive Sitzung geladen wurde.

Achten Sie darauf, dass alle beteiligten Systeme (Client, Remote-Host, Domänencontroller/Azure Zeitserver) synchronisierte Systemzeiten haben (NTP). Differenzen über wenige Minuten können zu Authentifizierungsfehlern führen, besonders bei Kerberos oder Zertifikats-basierten Verfahren.

Wenn alles nach Plan verläuft, sollte der Benutzer den Windows-Bildschirm sehen.

So beheben Sie den Fehler „Ihre Anmeldedaten funktionieren nicht“

Wenn der Benutzer die Fehlermeldung Ihre Anmeldedaten funktionieren nicht erhält, können Sie verschiedene Schritte unternehmen, um dieses Problem zu beheben.

Benutzerzugriff und Berechtigungen

Die häufigste Lösung besteht darin, sicherzustellen, dass Sie den richtigen Benutzernamen und das richtige Passwort eingeben. Wenn Sie das falsche Konto oder Passwort verwenden, wird unter der Tabelle Sicherheitsereignisse auf dem Zielcomputer die Ereignis-ID 4625 generiert.

Ein weiterer Schritt besteht darin, sicherzustellen, dass Sie das Präfix verwenden. Wenn Sie sich beispielsweise mit einem lokalen Konto auf einem Computer authentifizieren möchten, der einer Domäne angehört, müssen Sie beim Anmelden ein anderes Präfix für den Benutzernamen verwenden. Dieses könnte beispielsweise .\username oder localhost\username lauten.

Dadurch erfolgt die Authentifizierung direkt auf dem Computer und bei lokalen Benutzern. Wenn Sie sich mit einem Domänenkonto authentifizieren möchten, müssen Sie entweder DOMAIN\useraccount oder [email protected] verwenden.

Der Zielcomputer muss jedoch auch in der Lage sein, einen Domänencontroller zu erreichen, um das Konto authentifizieren zu können.

Wenn Sie NTLM deaktiviert haben oder planen, die Verwendung dieses Protokolls zu deaktivieren, müssen Sie einige zusätzliche Anforderungen erfüllen, um sicherzustellen, dass RDP über Kerberos funktioniert.

• Stellen Sie sicher, dass Sie eine Verbindung zum vollqualifizierten Domänennamen (FQDN) des Ziels herstellen, wie WS-123.contoso.com.
• Stellen Sie sicher, dass Sie einen Benutzerprinzipalnamen als Benutzernamen verwenden, wie [email protected].
• Der Client muss außerdem in der Lage sein, mit dem Domänencontroller zu kommunizieren.

Auf aktuelle Updates prüfen

In der Vergangenheit haben Updates von Microsoft ebenfalls dazu geführt, dass RDP nicht mehr funktionierte. Dazu gehört auch das Update KB5008380, das erstmals im März 2023 veröffentlicht wurde und nach seiner Veröffentlichung dazu führte, dass die RDP-Authentifizierung nicht mehr funktionierte.

Um RDP wieder funktionsfähig zu machen, müssen Sie das Update entfernen und auf einen neuen Patch von Microsoft warten. Wenn RDP funktioniert hat, aber plötzlich nicht mehr funktioniert, überprüfen Sie, ob kürzlich Updates auf dem Ziel und dem Client installiert wurden.

Überprüfen Sie, ob der Port offen ist und auf dem Zielendpunkt funktioniert

In den meisten Fällen wird keine Meldung angezeigt, dass die Anmeldedaten nicht funktionieren, wenn das Netzwerk oder der Port nicht zugänglich ist. Es ist jedoch einfach zu überprüfen, ob der Port von einem anderen Windows-Rechner aus blockiert ist.

Öffnen Sie auf dem Client PowerShell und geben Sie den folgenden Befehl ein:

Test-NetConnection IPaddress -port 3389

Wenn dieser Befehl die Meldung TcpTestSucceeded ausgibt, bedeutet dies, dass das Netzwerk und der Port erreichbar sind. In einigen Fällen, wenn ein Computer nicht mehr erreichbar ist, Sie aber wissen, dass der Computer online ist, kann es sein, dass zentrale Änderungen an der Firewall oder am Windows-Firewall-Profil vorgenommen wurden.

Die Windows-Firewall kategorisiert Netzwerkverbindungen standardmäßig in drei Profile:

• Domäne: Dieses Profil wird für Computer in Active Directory verwendet.
• Privat: Dieses Profil ist für Heimnetzwerke, SOHO-Netzwerke (Small Office/Home Office) oder Arbeitsgruppennetzwerke vorgesehen.
• Öffentlich: Dieses Profil ist für Verbindungen in öffentlichen Bereichen vorgesehen.

Standardmäßig lässt die Windows-Firewall alle ausgehenden Verbindungen zu und blockiert alle eingehenden Verbindungen, mit Ausnahme derjenigen, die für jedes Netzwerkprofil ausdrücklich zugelassen sind.

Sie können sehen, welches Profil ein Computer hat, indem Sie den folgenden Befehl in PowerShell ausführen:

Get-NetConnectionProfile

Anschließend können Sie mit dem folgenden Befehl eine RDP-Zulassungsregel in der Windows-Firewall für ein bestimmtes Profil hinzufügen:

New-NetFirewallRule -DisplayName „AllowRDP” -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Allow -Profile Domain

Dadurch wird der RDP-Datenverkehr für das Windows-Firewall-Profil Domäne zugelassen.

Überprüfen Sie, ob der Computer mit Entra ID verbunden ist

Ein weiteres Szenario, das die Fehlermeldung Anmeldeinformationen funktionieren nicht verursacht, ist, wenn Sie eine virtuelle Maschine (VM) in Azure haben, die mit Entra ID verbunden ist.

In diesem Fall erhalten Sie möglicherweise eine ähnliche Fehlermeldung wie in Abbildung 3, jedoch ist der Benutzer mit den richtigen lokalen Benutzergruppen verbunden und die Firewall ist geöffnet. Es scheint, als wäre alles in Ordnung.

Für Computer, die in Azure ausgeführt werden und mit Entra ID verbunden sind, müssen zwei zusätzliche Einstellungen konfiguriert werden, damit dies ordnungsgemäß funktioniert.

Zunächst müssen Sie die richtigen Berechtigungen in Microsoft Azure konfigurieren, wobei Sie der VM zwei Rollen hinzufügen müssen. Dies erfolgt mithilfe der rollenbasierten Zugriffssteuerung von Azure. Navigieren Sie zu Virtuelle Maschine\Zugriffssteuerung\Rollenzuweisung hinzufügen und weisen Sie dem gewünschten Benutzer entweder Anmeldung als Benutzer der virtuellen Maschine oder Anmeldung als Administrator der virtuellen Maschine zu.

Der Azure-Agent auf der VM fügt den Benutzer als Remote-Desktop-Benutzer oder Administrator auf dem Zielcomputer hinzu.

Zweitens müssen Sie einen DNS-Namen für den Computer konfigurieren oder die Host-Datei lokal ändern. Der Grund dafür ist, dass Entra ID JSON-Web-Token zur Authentifizierung auf dem Computer verwendet, sodass das Token mit dem Namen der in Entra ID registrierten VM und dem öffentlichen FQDN des Computers übereinstimmen muss.

Der einfachste Ansatz besteht darin, den Entra-Gerätenamen lokal auf dem Client in die Host-Datei einzufügen, wo Sie die IP-Adresse des Computers und den Host-Namen, unter dem er registriert ist, hinzufügen, wie in Abbildung 4 dargestellt.

Es wird nicht empfohlen, eine VM in Azure mit einer öffentlichen IP-Adresse und einem offenen RDP-Port zu haben, da dies die Wahrscheinlichkeit eines Brute-Force-Angriffs erheblich erhöht. Der beste Ansatz wäre eine sichere Verbindung zum Remote Desktop, beispielsweise einen VPN-Tunnel, über den Sie sicher mit einem Netzwerk kommunizieren können, bevor Sie RDP verwenden.