Remote Desktop host setup: what to enable and what to expose
Turn on RDP safely, understand the edition limits, fix the certificate warning, and know why port forwarding to the internet is a bad idea.
- Build
- 26300.9457 / 26100.33650
- Edition
- Pro (26H2) / Server
- Architecture
- x64
- Support
- Documentation (E1)
- Evidence
- E1Official documentation
- Verified
- 2026-10-29
- Page type
- Setup
The short answer
Section titled “The short answer”RDP works out of the box on Pro, Enterprise and Server. Home editions can act as a client only.
Three settings decide whether it is usable and safe:
- Enable Remote Desktop and allow the specific users.
- Network Level Authentication (NLA) — keep it on.
- How you reach it — LAN, VPN, or a gateway. Never a forwarded port 3389.
Enable it
Section titled “Enable it”Settings → System → Remote Desktop → On, then add users under Remote Desktop users.
# is it on, and who may connectGet-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnectionsGet-LocalGroupMember -Group 'Remote Desktop Users' -ErrorAction SilentlyContinueGet-NetFirewallRule -DisplayGroup 'Remote Desktop' | Select-Object Name,Enabled,Direction,ActionfDenyTSConnections = 0 means enabled. The firewall rules are per-profile (Domain/Private/Public) — enabling on Private only is usually what you want.
NLA and why it matters
Section titled “NLA and why it matters”With NLA, the client authenticates before a session is created, so an unauthenticated attacker never reaches the logon screen.
Registry: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\UserAuthentication = 1.
Turning it off makes old clients work and exposes the logon screen to the network. Do not do it on anything reachable.
The certificate warning
Section titled “The certificate warning”“ The identity of this remote computer cannot be verified” appears because the host presents a self-signed certificate. Options:
| Approach | Result |
|---|---|
| Ignore, tick “don’t ask again” | works, no real identity check |
| RDP with a domain/GPO-issued cert | warning gone, identity verified |
| Connect by IP | always self-signed |
On a LAN with a trusted network, ignoring is common. Over any untrusted path, use a VPN and treat the warning as a signal that you are not verifying the host.
Ports and firewall
Section titled “Ports and firewall”- Default port 3389/TCP (and UDP for some transports).
- Changing the port is not a security measure — scanners find it anyway.
- On a LAN, restrict the firewall rule to your subnet rather than “any”.
# restrict the RDP rule to a subnet (example)Set-NetFirewallRule -DisplayGroup 'Remote Desktop' -RemoteAddress 192.168.50.0/24Session behaviour worth knowing
Section titled “Session behaviour worth knowing”| Behaviour | Why it surprises people |
|---|---|
| Connecting disconnects the local console session | one interactive session on client OS |
| Disconnecting does not log off | apps keep running, session stays |
| Audio/video redirection defaults | may capture the client’s microphone |
| Drive/printer redirection | shares local resources into the session |
| Monitor count and scaling | client-side setting, not host |
Server editions allow multiple concurrent sessions; client editions allow one.
When RDP is the wrong tool
Section titled “When RDP is the wrong tool”- Helping someone else — use Quick Assist (no open port, no account).
- Occasional access from anywhere — a VPN plus RDP, not RDP alone.
- Headless server — RDP is fine, but check licensing (CALs) for multi-user use.
Related
Section titled “Related”Lab boundary
Section titled “Lab boundary”E1. RDP behaviour and policy are documented by Microsoft. The lab VMs run Pro/LTSC with RDP available, but no inbound connection was tested for this page.