Remotedesktop getrennt wegen Sicherheitsfehler: Lösung

Kurz gesagt: Wird die Remotedesktopverbindung wegen eines Sicherheitsfehlers getrennt, hat das laut Microsoft zwei typische Ursachen auf dem Remotedesktopserver: falsch konfigurierte Authentifizierungs- und Verschlüsselungseinstellungen oder ein beschädigtes Lizenzzertifikat. Prüf zuerst die Ereignisanzeige auf dem Server, dann die Sicherheitsschicht der Verbindung und erst danach die Zertifikatseinträge in der Registry.

Stand: 03.11.2026

Woran erkennst du den Sicherheitsfehler?

Microsoft beschreibt die Meldung im englischen Original so: „Remote desktop disconnected. Because of a security error, the client could not connect to the remote computer. Verify that you are logged onto the network and then try connecting again.“ Ältere Clients zeigen eine Variante mit „Terminal server“ statt „remote computer“.

Die Meldung allein verrät noch nicht, welche Ursache vorliegt. Microsoft unterscheidet zwei Fehlerbilder:

• Authentifizierung und Verschlüsselung: Nach einem Verbindungsabbruch klappt keine neue RDP-Verbindung, oder die alte Sitzung bleibt aktiv, obwohl der Client längst getrennt ist. Meldest du dich neu an, entsteht unter Umständen eine zweite Sitzung.
• Beschädigtes Lizenzzertifikat: Clients werden wiederholt abgewiesen, obwohl Netzwerk und Anmeldedaten stimmen.

Was zeigt die Ereignisanzeige?

Schau auf dem Sitzungshost in der Ereignisanzeige unter Anwendungs- und Dienstprotokolle (Applications and Services Logs), Microsoft, Windows in diese Protokolle: RemoteApp and Desktop Connections, TerminalServices-LocalSessionManager und TerminalServices-RemoteSessionManager. Auf dem Lizenzserver ist TerminalServices-Licensing zuständig. Typische Einträge:

• Ereignis 50 (TermDD): Die RDP-Komponente X.224 hat einen Fehler im Protokollstrom erkannt und den Client getrennt.
• Ereignis 1088 (TermService): Die Kulanzzeit für die Lizenzierung ist abgelaufen, ohne dass sich der Dienst bei einem Lizenzserver registriert hat. Ohne Lizenzserver läuft ein Sitzungshost nur 90 Tage nach dem ersten Start.
• Ereignis 1004 (TermService): Der Server kann keine Clientlizenz ausstellen.
• Ereignis 1010 (TermService): Es wurde kein Lizenzserver gefunden.
• Ereignis 28 (TermServLicensing): Die Lizenzierung läuft nur auf Domänencontrollern oder Servern in einer Arbeitsgruppe.

Tauchen die Lizenzereignisse auf, kümmere dich zuerst um Lizenzserver und Remotedesktop-CALs. Das Löschen von Zertifikaten hilft nicht, wenn schlicht keine Lizenz verfügbar ist.

Wie prüfst du Sicherheitsschicht und Verschlüsselung?

1. Öffne auf dem Sitzungshost die Konfiguration des Remotedesktop-Sitzungshosts.
2. Klicke unter Connections mit der rechten Maustaste auf die Verbindung, meist RDP-Tcp, und wähle Properties.
3. Wähle auf dem Reiter General unter Security layer eine Sicherheitsmethode.
4. Leg unter Encryption level die Stufe fest: Low, Client Compatible, High oder FIPS Compliant.

Wichtig: Verschlüsselungsstufen aus einer Gruppenrichtlinie überschreiben die Einstellung in der Konsole. Ist die Richtlinie „System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing“ aktiv, gewinnt diese. Eine geänderte Stufe greift erst bei der nächsten Anmeldung. Prüf außerdem, ob zum Zertifikat der Verbindung ein privater Schlüssel vorhanden ist: In den Zertifikatsdetails muss der Hinweis „You have a private key that corresponds to this certificate“ stehen.

Für die Fehlersuche empfiehlt Microsoft, auf Client und Server das CAPI2-Protokoll zu aktivieren: in der Ereignisanzeige CAPI2 aufklappen, mit der rechten Maustaste auf Operational klicken und Enable Log wählen. Bleiben getrennte Sitzungen hängen, hilft die Gruppenrichtlinie Configure keep-alive connection interval unter Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Connections. Setz sie auf Enabled.

Wie behebst du ein beschädigtes Lizenzzertifikat?

Diese Schritte ändern die Registry. Sichere sie vorher und führe die Schritte auf jedem betroffenen Remotedesktopserver aus.

1. Öffne den Registrierungs-Editor und gehe zu HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerRCM.
2. Exportiere den Schlüssel als Sicherung über das Menü der Registry (Export Registry File).
3. Lösche die Werte Certificate, X509 Certificate, X509 Certificate ID und X509 Certificate2.
4. Schließe den Registrierungs-Editor und starte den Server neu.
5. Aktiviere anschließend den Remotedesktop-Lizenzserver erneut.

Klappt die Verbindung danach immer noch nicht, liegt die Ursache woanders. Über die exportierte Datei spielst du den alten Stand per Doppelklick wieder ein.

So unterstützen wir dich

Wir betreuen Terminalserver und Remotedesktop-Umgebungen für Unternehmen in Osnabrück und Umgebung, entfernter per Fernwartung. Bei Verbindungsfehlern prüfen wir Ereignisprotokolle, Lizenzierung und Zertifikate und bringen den Zugang wieder zum Laufen. Mehr auf unserer Seite zum IT-Support in Osnabrück.

Häufige Fragen

Liegt der Fehler am Client oder am Server?

Microsoft verortet beide typischen Ursachen auf dem Remotedesktopserver: bei Authentifizierung und Verschlüsselung oder beim Lizenzzertifikat.

Wie lange läuft ein Sitzungshost ohne Lizenzserver?

Laut Ereignis 1088 bis zu 90 Tage nach dem ersten Start. Danach braucht er einen registrierten Lizenzserver.

Brauche ich für zwei Admin-Zugriffe Lizenzen?

Nein. Remotedesktop erlaubt zwei gleichzeitige Verbindungen zur Verwaltung ohne Remotedesktop-CALs. Für mehr Verbindungen brauchst du die Rolle Remotedesktop-Sitzungshost und passende CALs.

Ist das Löschen der Zertifikatswerte riskant?

Fehler in der Registry können ernste Probleme verursachen. Exportiere deshalb den Schlüssel vorher, dann kannst du ihn bei Bedarf zurückspielen.

Quellen

• Troubleshoot Remote desktop disconnected errors (Microsoft Learn, abgerufen am 03.11.2026)