Keine Tastatureingabe am Terminalserver

Unter der Rubrik Kuriositäten präsentieren wir Ihnen IT-Probleme der nicht alltäglichen Art. In dieser Woche standen wir vor dem Phänomen, dass auf einem Terminalserver mit Windows Server 2012 R2 (inzwischen umbenannt in Remotedesktop-Sitzungshost) nur in einer RDP-Sitzung Tastatureingaben ausgeführt wurden. Die Maus hingegen funktionierte in allen RDP-Sitzungen.

Der lange Weg zur Lösungsfindung

Nach einer ersten Kontrolle des Systems und der Überprüfung der erforderlichen Systemdienste, begann die Recherchearbeit. Scheinbar handelte es sich um kein allzu verbreitetes Problem. Eine erste Suche in den Microsoft-Foren brachte zwar potentielle Lösungsansätze hervor, aber keiner der beschriebenen Fälle deckte sich wirklich mit unserer Problematik.

Dennoch haben wir die gefundenen Lösungsansätze überprüft:

  1. Bedienung der Tastatur erleichtern
    Im Problemfall sollen sämtliche Optionen deaktiviert werden. In unserem Fall war keine der Einstellungen aktiviert, womit dieser Lösungsansatz hinfällig war.
    (Systemsteuerung > Center für erleichterte Bedienung > Bedienung der Tastatur erleichtern)
  2. Remotedesktopverbindung (Lokale Ressourcen)
    Eine weitere Empfehlung sieht vor, dass die Tastatureinstellungen im RDP-Client anzupassen sind. Dieser Ansatz passte jedoch nicht zum bestehenden Fehler.
    (Remotedesktopverbindung > Lokale Ressourcen > Tastatur)

Tastaturtreiber

Der nächste Schritt sah eine Überprüfung des Gerätemanagers und insbesondere der Tastaturtreiber vor. Windows Server 2012 R2 verfügt über eine eigene Remotedesktoptastatur für die Remotedesktopverbindungen. Ein weiterer potentieller Lösungsansatz besteht darin, den besagten Tastaturtreiber zu entfernen. Wir wollten den Treiber in einem ersten Schritt allerdings nur durch eine neue Version ersetzen.

G DATA USB Keyboard Guard

Die Suche nach einem neuen Treiber führte uns schließlich zur Lösung des Problems. Der Benutzer TuVMH des Microsoft TechNet-Forums beschreibt exakt dasselbe Fehlerbild mit identischer Softwarekonstellation wie in unserem Fall. Und glücklicherweise, was bekanntermaßen bei Forenbeiträgen nicht immer der Fall ist, teilt er seine Lösung der Allgemeinheit mit.

Der Fehler wird durch den installierten G DATA Security Client verursacht. Die aktuelle Version beinhaltet eine Funktion namens USB Keyboard Guard.

Viele Angriffsmethoden sind per USB möglich: Ein manipuliertes, programmierbares USB-Gerät – wie etwa ein Speicherstick – kann sich beispielsweise als Tastatur am Windows-System anmelden und einem Angreifer aus der Ferne die Kontrolle über das System ermöglichen.

Auf der BlackHat-Hackerkonferenz in Las Vegas demonstrierten zwei Forscher der Berliner Security Research Labs (SRLabs) jetzt anhand Ihres „BadUSB“ getauften Angriffs die Manipulation der USB-Geräte-Firmware, die in ähnlicher Form in allen USB-Geräten vorhanden ist. Theoretisch könnten so alle USB-Geräte zum Angriffsvektor werden – von der Maus über den Drucker bis hin zur Digitalkamera!

https://www.gdata.de/de-usb-keyboard-guard

Kurioserweise war die Funktion auf dem Terminalserver unseres Kunden zwar nicht aktiviert, dennoch führte der G DATA Security Client dazu, dass die virtuelle Remotedestoptastatur nicht unter mehreren Remotedesktopverbindungen genutzt werden konnte.

Zu Testzwecken wurde der Virenschutz vom Terminalserver deinstalliert und anschließend ein Test durchgeführt: Et voilà! Tastatureingaben funktionierten in allen RDP-Sitzungen wieder erwartungsgemäß.

Da es allerdings fahrlässig wäre, den Server ohne Virenschutz zu betreiben, wurde der G DATA Security Client nach einem Neustart des Servers ein zweites Mal über den G DATA Management Server installiert.

In unserem Fall war dies die Lösung, denn Tastatureingaben funktionierten anschließend problemlos in mehreren Remotedesktopverbindungen.

Schlagwörter: