Remote Desktop (RDP) – Einrichtung & Nutzung

Was ist RDP und wann brauchst du es?

RDP (Remote Desktop Protocol) ist Microsofts eigenes Protokoll zur grafischen Fernsteuerung von Windows-Rechnern. Du siehst den Desktop des Zielrechners in einem Fenster auf deinem eigenen Gerät – Maus, Tastatur und Zwischenablage werden transparent weitergeleitet, als würdest du direkt vor dem Gerät sitzen.

Typische Einsatzszenarien im KMU-Alltag:

• Mitarbeitende im Homeoffice greifen auf ihren Büro-PC zu
• IT-Support arbeitet remote an einem Endgerät (ohne physisch hinzugehen)
• Administrieren von Windows Servern ohne KVM-Konsole
• Zugriff auf eine Applikation, die nur auf einem bestimmten Server läuft (z.B. ERP-Client, CAD-Software)

RDP ist auf Port 3389 TCP (und UDP für optimierte Grafikübertragung) unterwegs. Das Protokoll ist in Windows seit XP integriert und kostenlos – kein zusätzlicher Agent, kein Dritt-Abo.

RDP auf dem Zielrechner aktivieren

Variante 1: Über die Einstellungen (Windows 10 / 11)

1. Win+I → System → Remotedesktop
2. Schalter „Remotedesktop aktivieren” auf Ein stellen
3. Bestätigungsdialog mit „Bestätigen” abschliessen
4. Optional: „Remotedesktopbenutzer” öffnen und zusätzliche Konten eintragen (Admins sind automatisch berechtigt)

Variante 2: Über die Systemsteuerung (klassisch)

Win+R → sysdm.cpl → Tab „Remote” → „Remoteverbindungen mit diesem Computer zulassen” aktivieren.

Variante 3: PowerShell (ideal für Remote-Aktivierung oder Scripting)

# RDP aktivieren
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' `
  -Name "fDenyTSConnections" -Value 0

# Windows-Firewall-Regel für RDP freischalten
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

# NLA (Network Level Authentication) erzwingen – empfohlen!
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name "UserAuthentication" -Value 1

Variante 4: Per Registry (z.B. via GPO oder Remote-Registry)

reg add "HKLM\System\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Verbinden mit mstsc

Der eingebaute Windows-Client heisst Remote Desktop Connection (mstsc.exe). Starte ihn mit Win+R → mstsc.

Wichtige Kommandozeilenparameter

REM Verbindung zu IP oder Hostname
mstsc /v:192.168.1.100

REM Mit explizitem Port (falls nicht Standard 3389)
mstsc /v:192.168.1.100:3390

REM Admin-Sitzung (Konsole, Session 0 – wichtig auf Servern)
mstsc /v:SERVER01 /admin

REM Vollbild sofort
mstsc /v:192.168.1.100 /f

REM Bestimmte Auflösung
mstsc /v:192.168.1.100 /w:1920 /h:1080

REM Über RD-Gateway verbinden
mstsc /v:intern-pc01 /g:rdgateway.firma.ch

REM Gespeicherte .rdp-Datei öffnen
mstsc "C:\Users\admin\Desktop\server01.rdp"

.rdp-Dateien erstellen und speichern

Im mstsc-Dialog unter „Optionen einblenden” lassen sich alle Einstellungen (Auflösung, Geräte-Weiterleitung, Gateway usw.) konfigurieren und als .rdp-Datei speichern. Praktisch, wenn du viele Ziele regelmässig verbindest. Die Dateien lassen sich auch auf einem Netzlaufwerk ablegen, damit das ganze Team sie nutzt.

# Alle gespeicherten RDP-Dateien im Benutzerprofil finden
Get-ChildItem "$env:USERPROFILE\Documents" -Filter "*.rdp" -Recurse

RemoteApp: Einzelne Anwendungen statt ganzer Desktops veröffentlichen

Nicht jeder Remote-Zugriff braucht den kompletten Desktop. Mit RemoteApp veröffentlichst du einzelne Anwendungen so, dass sie beim Anwender wie ein ganz normales, lokales Fenster erscheinen – Taskleiste, Fenstergrösse und Mehrfach-Monitor-Unterstützung inklusive. Der Nutzer sieht nur die Applikation (z.B. den ERP-Client oder eine Fachanwendung), nicht den restlichen Server-Desktop. Das reduziert Verwirrung beim Anwender und minimiert die Angriffsfläche, weil niemand aus Versehen im Server-Explorer herumklickt.

Voraussetzungen: RemoteApp läuft technisch auf einem RD Session Host, der Teil einer RDS-Bereitstellung ist (RD Connection Broker + optional RD Web Access/RD Gateway). Für eine einzelne Testmaschine reicht ein einzelner Session Host, für den Produktivbetrieb mit mehreren Servern brauchst du eine echte Farm mit Lastverteilung – dieser Aufbau (Collections, Connection Broker, Session-Hosts im Verbund) ist ausführlich im Artikel Terminalserver / RDS – Support beschrieben.

RemoteApp-Programm veröffentlichen (Server Manager oder PowerShell):

# Neue RemoteApp in einer bestehenden Session Collection veröffentlichen
New-RDRemoteApp -Alias "Editor" -DisplayName "Editor (Server01)" `
  -FilePath "C:\Windows\System32\notepad.exe" `
  -CollectionName "Session-Collection-01" `
  -ConnectionBroker "broker01.firma.local"

# Veröffentlichte RemoteApps einer Collection auflisten
Get-RDRemoteApp -CollectionName "Session-Collection-01"

Ohne RDS-Farm – RemoteApp per .rdp-Datei auf einem einzelnen Server: Für einen einzelnen RD Session Host ohne Connection Broker reicht eine manuell erstellte .rdp-Datei mit den passenden RemoteApp-Eigenschaften:

full address:s:server01.firma.local
remoteapplicationmode:i:1
remoteapplicationname:s:Editor
remoteapplicationprogram:s:||notepad
remoteapplicationicon:s:notepad.exe,0

Der doppelte Strich (||) vor dem Programmnamen verweist auf einen Eintrag in der RemoteApp-Freigabeliste (TSAppAllowList) auf dem Server – ohne diesen Eintrag verweigert Windows den Start aus Sicherheitsgründen.

Benutzer für RDP freischalten

Nur Mitglieder der Gruppe „Administratoren” und „Remotedesktopbenutzer” dürfen sich per RDP verbinden. Normalen Usern gibst du Zugriff so:

# Lokal (auf dem Zielrechner)
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "mmuster"

# Im Active Directory (AD-Umgebung): Sicherheitsgruppe "RDP-Benutzer" erstellen
# und diese Gruppe via GPO in die lokale Gruppe "Remote Desktop Users" einpflegen
Add-ADGroupMember -Identity "RDP-Benutzer" -Members "mmuster"

Per GPO (Computer Configuration → Windows Settings → Security Settings → Restricted Groups oder Local Users and Groups) lässt sich die Mitgliedschaft domänenweit zentral steuern – deutlich sauberer als jede Workstation manuell anzufassen.

Sicherheit: Das Wichtigste zuerst

RDP ist eines der häufigsten Angriffsziele im Internet. Jeden Tag versuchen automatisierte Scanner, Port 3389 auf Firmenfirewalls zu finden und sich mit Brute-Force einzuhacken.

NLA (Network Level Authentication)

NLA erzwingt, dass der Benutzer sich vor dem Aufbau der grafischen Sitzung authentifiziert. Ohne NLA wird zuerst der Windows-Anmeldebildschirm gerendert und übertragen – das kostet Ressourcen und ist ein Angriffspunkt.

NLA prüfen und aktivieren:

# Aktuellen Wert lesen (1 = NLA aktiv)
Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name UserAuthentication | Select-Object UserAuthentication

NLA ist auf Windows 10/11 und Windows Server 2016+ standardmässig aktiv. Deaktiviere es nur, wenn ältere Clients (z.B. Windows XP, alte Linux-RDP-Clients) sich verbinden müssen – und stell es danach sofort wieder an.

Sicherheits-Checkliste für RDP im KMU

RDP-Verschlüsselungsstufen: Security Layer, TLS und CredSSP erzwingen

RDP kennt drei voneinander unabhängige Sicherheits-Schrauben, die gerne verwechselt werden. Für eine wirklich abgesicherte Umgebung solltest du alle drei bewusst setzen statt dich auf die Standardwerte zu verlassen.

Die drei Security-Layer-Optionen im Detail:

• RDP Security Layer – die älteste Variante. Verschlüsselt zwar, authentifiziert den Server aber nicht gegenüber dem Client. Anfällig für Man-in-the-Middle, sollte nicht mehr verwendet werden.
• Negotiate (Standard seit Windows Server 2008) – Client und Server handeln automatisch die stärkste gemeinsam unterstützte Methode aus. Klingt gut, fällt aber bei alten Clients stillschweigend auf die unsichere RDP Security Layer zurück.
• SSL/TLS – erzwingt TLS für Transport und Server-Authentifizierung per Zertifikat. Das empfehlen CIS-Benchmarks, NIST und DISA STIG unisono als einzige akzeptable Einstellung für produktive Umgebungen.

Per GPO erzwingen: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security:

• “Anforderung der Verwendung einer bestimmten Sicherheitsebene für Remoteverbindungen (RDP)” → SSL
• “Verschlüsselungsstufe für Clientverbindungen festlegen” → Hoch

Per Registry (z.B. für Server ohne Domänenanbindung):

# Security Layer auf SSL/TLS erzwingen (0=RDP, 1=Negotiate, 2=SSL/TLS)
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name "SecurityLayer" -Value 2

# Verschlüsselungsstufe auf "Hoch" setzen (1=Niedrig, 2=Clientkompatibel, 3=Hoch, 4=FIPS)
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name "MinEncryptionLevel" -Value 3

CredSSP verdient eine eigene Erwähnung: Die Schwachstelle CVE-2018-0886 erlaubte es Angreifern, den CredSSP-Handshake zu manipulieren und so Remote Code Execution auszulösen. Seitdem gilt: CredSSP-Patches auf Client und Server gleichzeitig einspielen, sonst blockt die “harte” GPO-Stufe (Force Updated Clients) den Verbindungsaufbau komplett.

Bekannte RDP-Sicherheitslücken: BlueKeep und DejaBlue

RDP hatte in der Vergangenheit mehrere kritische, wurmfähige Schwachstellen – also Lücken, die sich ganz ohne Benutzerinteraktion von Rechner zu Rechner weiterverbreiten können, ähnlich wie WannaCry 2017 bei SMB. Wer im Enterprise-IT-Support arbeitet, sollte diese zwei kennen, weil sie regelmässig in Audits und Sicherheitsschulungen als Negativbeispiel auftauchen.

BlueKeep (Mai 2019) sitzt im Remote-Desktop-Services-Treiber (termdd.sys) und lässt sich bereits vor jeder Authentifizierung auslösen – ein Angreifer braucht kein gültiges Konto, nur eine Netzwerkverbindung zu Port 3389. Microsoft reagierte ungewöhnlich deutlich und patchte sogar die längst aus dem Support gefallenen Windows XP und Server 2003. Die Lücke steht bis heute in der CISA-Liste aktiv ausgenutzter Schwachstellen.

DejaBlue (August 2019) betraf dieselbe Komponente, aber auch die neueren, damals noch unterstützten Windows-Versionen. Zwei der Teil-CVEs (1181/1182) sind genauso kritisch wie BlueKeep selbst.

Praktische Konsequenzen für dich:

1. Patchen bleibt Pflicht Nummer eins. Beide Lücken sind seit 2019 geschlossen – jedes ungepatchte System mit RDP ist ein offenes Scheunentor. Ein sauberer Patch-Prozess (siehe WSUS / Patchmanagement) verhindert, dass so etwas Jahre später noch offen ist.
2. NLA mindert das Risiko, ersetzt den Patch aber nicht. Da NLA eine Authentifizierung verlangt, bevor der verwundbare Code-Pfad überhaupt erreicht wird, blockt es unauthentifizierte BlueKeep/DejaBlue-Exploits weitgehend ab – ein legitim angemeldeter Angreifer mit gültigen Zugangsdaten ist davon aber nicht betroffen.
3. Kein Port 3389 im Internet (siehe oben) reduziert die Angriffsfläche auf null von aussen, unabhängig vom Patch-Stand.
4. Uralte, nicht mehr unterstützte Systeme (Windows 7, Server 2008 R2) gehören grundsätzlich nicht mehr produktiv ans Netz – falls doch unumgänglich, konsequent isolieren (eigenes VLAN, keine Internetroute).

Mehr zum grösseren Bild – Absicherung, Monitoring, Reaktion auf Vorfälle – im Artikel IT-Security Grundlagen KMU.

Restricted Admin Mode und Remote Credential Guard gegen Pass-the-Hash

Bei einer normalen RDP-Anmeldung landen deine Zugangsdaten (bzw. die daraus abgeleiteten Hashes/Tickets) im Speicher (LSASS) des Zielrechners. Ist dieser Zielrechner kompromittiert, kann ein Angreifer mit Tools wie Mimikatz diese Credentials abgreifen und für Pass-the-Hash-Angriffe auf weitere Systeme wiederverwenden – ein klassischer Weg, wie sich ein Eindringling von einem einzelnen PC bis zum Domain Admin hocharbeitet.

Microsoft bietet zwei Mechanismen, um genau das zu verhindern:

Restricted Admin Mode

mstsc /v:server01.firma.local /restrictedadmin

Restricted Admin verbindet, ohne deine Anmeldedaten an den Zielrechner zu übertragen. Die Sitzung läuft mit den Netzwerk-Rechten des Zielrechners, nicht mit deinen eigenen – du kannst innerhalb der Sitzung also nicht einfach auf deine eigenen Netzlaufwerke zugreifen, als wärst du lokal angemeldet.

Restricted Admin zentral deaktivieren (empfohlen für die meisten KMU-Umgebungen):

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Lsa' `
  -Name "DisableRestrictedAdmin" -Value 1

Remote Credential Guard

mstsc /v:server01.firma.local /remoteGuard

Remote Credential Guard geht einen sauberen Schritt weiter: Die Kerberos-Anfragen werden zurück an deinen Client umgeleitet – deine Anmeldedaten (auch nicht als Hash) verlassen deinen Rechner überhaupt nie in Richtung Zielserver. Das ist der empfohlene Weg für administrativen RDP-Zugriff in einer Domänenumgebung, sofern beide Seiten es unterstützen.

Voraussetzungen: Client und Server domänengebunden, Kerberos-Authentifizierung (kein NTLM-Fallback), Windows 10/Server 2016 oder neuer auf beiden Seiten.

Mehr zur strukturierten Absicherung privilegierter Admin-Zugänge (Tier-Modell, Jump Hosts) im Artikel AD Security Hardening – Tier-Modell.

RDP sicher von aussen: VPN vs. RD-Gateway

Es gibt zwei saubere Wege, RDP über das Internet zu nutzen:

Option A: VPN + RDP (empfohlen für kleinere KMUs)

Der User baut zuerst eine VPN-Verbindung zum Firmennetz auf (z.B. mit WireGuard, OpenVPN oder Windows Built-in VPN). Danach verhält sich RDP genauso wie im lokalen Netz. Kein Port auf dem Router öffnen, kein spezieller Server nötig.

Mehr dazu auf der Seite VPN – Grundlagen.

Option B: RD-Gateway (Remote Desktop Gateway)

Ein RD-Gateway ist ein Windows Server, der als Proxy zwischen Internet und internen RDP-Hosts sitzt. Clients verbinden sich per HTTPS (Port 443) zum Gateway – der Gateway leitet die Verbindung intern weiter.

Vorteile:

• Kein VPN-Client nötig auf dem Endgerät
• Zugriff mit normalem mstsc möglich (/g:rdgateway.firma.ch)
• Zentrales Logging aller Verbindungen
• Connection Authorization Policies (CAP) und Resource Authorization Policies (RAP) steuern genau, wer auf was zugreifen darf

Voraussetzung: Windows Server mit der Rolle Remote Desktop Services → RD Gateway. Dazu ein gültiges SSL-Zertifikat (Let’s Encrypt geht, oder ein internes CA-Zertifikat).

# RD-Gateway-Rolle auf Windows Server installieren
Install-WindowsFeature RDS-Gateway -IncludeManagementTools

Mehrere Sitzungen auf Windows Server

Auf einem normalen Windows 10/11 PC lässt RDP standardmässig nur eine gleichzeitige Sitzung zu. Meldet sich jemand per RDP an und der lokale User war eingeloggt, wird dieser abgemeldet.

Windows Server verhält sich anders: Mit einer RDS-CAL (Client Access License) können mehrere User gleichzeitig per RDP arbeiten. Das ist der normale Server-Betrieb in KMUs – z.B. wenn 10 User gleichzeitig auf einem Terminal Server arbeiten.

# Aktive RDP-Sessions auf einem Server anzeigen
query session /server:SERVER01

# Session trennen (ohne Abmeldung)
tsdiscon 2 /server:SERVER01

# Session zwangsweise beenden
logoff 2 /server:SERVER01

Session-Timeouts per GPO

Vergessene, offene RDP-Sitzungen sind ein unterschätztes Risiko: Ein Mitarbeiter meldet sich per RDP an einem Server an, geht nach Hause und lässt die Sitzung getrennt (nicht abgemeldet) im Hintergrund weiterlaufen – inklusive aller offenen Programme und angemeldeter Konten. Über Gruppenrichtlinien lassen sich klare Zeitlimits zentral erzwingen.

GPO-Pfad: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Sitzungszeitlimits

Per Registry / lokal setzen (Werte in Millisekunden):

$path = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
New-Item -Path $path -Force | Out-Null

# Idle-Timeout: 30 Minuten
Set-ItemProperty -Path $path -Name "MaxIdleTime" -Value 1800000

# Getrennte Sitzung: nach 2 Stunden endgültig abmelden
Set-ItemProperty -Path $path -Name "MaxDisconnectionTime" -Value 7200000

# Maximale Sitzungsdauer: 0 = unbegrenzt (Standard, meist sinnvoll)
Set-ItemProperty -Path $path -Name "MaxConnectionTime" -Value 0

Wie du eine solche Richtlinie sauber als GPO baust, testest und auf die richtige OU verlinkst, steht im Artikel GPO – Grundlagen.

Performance-Tuning für schwache Leitungen (RemoteFX vs. AVC444)

Im Homeoffice über eine mittelmässige DSL- oder Mobilfunk-Uplink-Leitung fühlt sich RDP schnell träge an: Mauszeiger hinkt hinterher, Fenster bauen sich verzögert auf, Videos ruckeln. Die Ursache liegt fast immer bei der Grafikübertragung – und da hat sich seit den ersten RDP-Versionen einiges getan.

Kurzer Begriffs-Check, weil das gerne durcheinandergerät:

• RemoteFX vGPU war eine virtuelle GPU-Funktion für Hyper-V-VDI-Umgebungen. Sie wurde wegen einer kritischen Sicherheitslücke (CVE-2020-1036) per Update entfernt und existiert in aktuellen Windows-Versionen nicht mehr – falls du sie irgendwo in alter Dokumentation siehst, ist das veraltet.
• RemoteFX Adaptive Graphics ist der ältere Bitmap-Codec für die reine RDP-Bildschirmübertragung (kein VDI-Bezug) und läuft auf vielen Systemen noch als Fallback.
• AVC/H.264 ist der moderne Standard-Codec ab RDP 8 (Windows 8/Server 2012 aufwärts). Er komprimiert deutlich effizienter, vor allem bei Video- und Bewegtbild-Inhalten.
• AVC444 ist ein Sondermodus von AVC/H.264 mit voller Farbauflösung (4:4:4-Chroma statt 4:2:0). Wichtig für gestochen scharfen Text und feine UI-Elemente – kostet aber mehr Bandbreite als das Standard-AVC420.

Für schwache Leitungen empfiehlt sich diese Reihenfolge an Massnahmen:

1. Verbindungsgeschwindigkeit im Client richtig einstellen. Im mstsc-Dialog unter “Optionen einblenden” → Tab Erweitert/Experience die tatsächliche Leitung auswählen (z.B. “Niedrige Breitbandbreite” statt automatisch “LAN”). Das schaltet automatisch Spielereien wie Desktophintergrund, Fensteranimationen, Aero/Transparenz und Schriftglättung ab.
2. Persistentes Bitmap-Caching aktivieren – bereits übertragene Bildschirmbereiche werden lokal zwischengespeichert und nicht erneut übertragen. In den Experience-Einstellungen als Checkbox vorhanden.
3. Farbtiefe reduzieren, falls 32-Bit-Farbe nicht nötig ist: mstsc /v:server01 /w:1366 /h:768 kombiniert mit einer niedrigeren Farbtiefe in der .rdp-Datei (session bpp:i:16) spart spürbar Bandbreite.
4. AVC444 serverseitig gezielt steuern, statt es blind an- oder auszuschalten – per GPO unter Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment:
   • “AVC444-Grafikmodus für Remotedesktopverbindungen priorisieren” – nur aktivieren, wenn Text-/Detailschärfe wichtiger ist als Bandbreite
   • “H.264/AVC-Hardwarecodierung für Remotedesktopverbindungen konfigurieren” – nutzt die GPU des Servers für die Kodierung, entlastet die CPU spürbar bei vielen gleichzeitigen Sitzungen
   • “Bildqualität für RemoteFX Adaptive Graphics konfigurieren” – Werte Mittel/Hoch/Verlustfrei, für schwache Leitungen auf “Mittel” setzen
5. UDP nicht blockieren. RDP nutzt seit Version 8 zusätzlich zu TCP 3389 auch UDP 3389 (RDP-Multitransport/“Shortpath”), um Latenz und Paketverlust besser auszugleichen. Wird UDP von der Firewall oder dem VPN-Gateway verworfen, fällt die Verbindung auf reines TCP zurück und reagiert bei schlechter Leitung spürbar zäher.

Troubleshooting: Häufige Probleme

Verbindung wird abgelehnt (Fehler: „Verbindung nicht möglich”)

# 1. Ist RDP aktiv?
Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections
# 0 = aktiv, 1 = deaktiviert

# 2. Lauscht der RDP-Dienst auf Port 3389?
netstat -ano | findstr ":3389"
# oder PowerShell:
Test-NetConnection -ComputerName 192.168.1.100 -Port 3389

# 3. Firewall-Regel aktiv?
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select DisplayName, Enabled

Häufige Fehlerursachen im Überblick

Diagnosebefehle

# RDP-Dienst (TermService) prüfen und neu starten
Get-Service TermService | Select Name, Status, StartType
Restart-Service TermService

# Event Log nach RDP-Fehlern durchsuchen (Event IDs 1149, 4624, 4625)
Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" `
  -MaxEvents 20 | Select TimeCreated, Id, Message

# Wer ist aktuell eingeloggt?
query user

RDP-Port geändert – und jetzt?

Manchmal findet man Systeme, bei denen der RDP-Port auf einen anderen Wert geändert wurde (Security through Obscurity – kein guter Ersatz für echte Sicherheit, aber manchmal vorgefunden).

# Aktuellen RDP-Port auslesen
Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name PortNumber | Select-Object PortNumber

Wenn der Port geändert ist, musst du ihn beim Verbinden explizit angeben: mstsc /v:192.168.1.100:3390.

Alternativen zu RDP

RDP ist nicht immer die beste Wahl. Hier ein Überblick:

Weiterlernen

• Aktivieren von Remotedesktop auf Ihrem PC – Microsoft Learn
• mstsc-Befehlsreferenz – Microsoft Learn
• RD-Gateway-Rolle bereitstellen – Microsoft Learn
• Unterstützte RDP-Dateieigenschaften – Microsoft Learn
• 10 Tipps zur Absicherung von RDP-Verbindungen – Computer Weekly
• RDP-Verbindungen unter Windows richtig schuetzen – Computer Weekly
• Require use of specific security layer for remote (RDP) connections – Microsoft Learn / admx.help
• Windows Defender Remote Credential Guard – Microsoft Learn
• BlueKeep (CVE-2019-0708) – CISA Advisory
• Graphics encoding over RDP (AVC/H.264, AVC444) – Microsoft Learn

Verwandte Seiten:

• VPN – Grundlagen – RDP sicher von aussen via VPN-Tunnel
• GPO – Grundlagen – RDP-Zugriff und Einstellungen per Gruppenrichtlinie steuern
• AD – User & Gruppen – Remotedesktopbenutzer-Gruppe im AD verwalten
• IT-Security Grundlagen KMU – Warum RDP direkt im Internet keine Option ist
• Terminalserver / RDS – Support – RDS-Farm, Session Collections und RemoteApp im Detail
• AD Security Hardening – Tier-Modell – Privilegierte Zugänge sauber absichern
• WSUS / Patchmanagement – Patches wie für BlueKeep/DejaBlue zuverlässig ausrollen
• ADCS / PKI – Grundlagen – Zertifikate für erzwungenes RDP-TLS bereitstellen