You want to reach a Windows 11 PC, or a Windows Server, from another machine using Remote Desktop. The switch is easy to find. What this article adds is the set of choices around it: who is allowed in, which networks the firewall lets in, and how a remote worker should reach the machine without TCP port 3389 ever being open to the internet.
Applies to: Windows 11 Pro, Enterprise and Education, and Windows Server, as the machine being connected to (the host). Windows 11 Home can be used as a client to connect out, but it cannot host incoming Remote Desktop connections. Commands run in an elevated PowerShell prompt.
Do not expose TCP 3389 to the internet. Do not forward it on a router, and do not create a firewall or cloud rule that allows it from Any. Microsoft’s own guidance on connecting from outside the network is to use a VPN, and its documentation warns that opening a PC to the internet is not recommended. Microsoft’s long-standing advice is also to block port 3389 at the perimeter firewall. If people must connect from outside, use a VPN or a Remote Desktop Gateway, described below.
What is going on
Turning on Remote Desktop makes the PC listen for RDP connections, on TCP port 3389 by default. Microsoft says this opens a port on the PC and makes it reachable by devices on the local network, and that members of the Administrators group plus any users you add can then connect. Three separate things must all be true before a connection works, and each one is also a place to be careful:
- The feature is on. Behind the Settings toggle is the registry value
fDenyTSConnectionsunderHKLM\SYSTEM\CurrentControlSet\Control\Terminal Server. A value of 1 denies connections, 0 allows them. - The firewall allows it. Windows Defender Firewall has a group of inbound rules named Remote Desktop. Microsoft lists allowing Remote Desktop through the firewall as a requirement. This is where you limit who can reach the port.
- The account is allowed. Administrators can connect. Other accounts must be in the Remote Desktop Users group and not be denied the right Allow log on through Remote Desktop Services.
Network Level Authentication (NLA) adds a fourth control. With NLA, the user must authenticate before a remote session is created, which Microsoft says reduces the risk of unauthorised access. Microsoft recommends keeping it on, and says to disable it only temporarily for old clients that cannot use it.
Before you start / check first
1. Is this machine able to host?
Windows Professional, Enterprise and Education, and Windows Server, can host Remote Desktop. Windows Home cannot. If you are not sure which edition you have, check Settings > System > About. [UNCONFIRMED: the exact Settings path for reading the edition. Microsoft Learn states the supported editions but not where to read the edition on Windows 11.]
2. Does Group Policy already control it?
In a domain, a policy can override what you set locally and rewrite it at the next Group Policy refresh. Microsoft documents two places where fDenyTSConnections can live: the local value, and a policy value that exists only if the relevant Group Policy setting is configured. Check both:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" -Name fDenyTSConnectionsThe second command reports an error if no policy sets the value, which is fine. If it exists, change the policy, not the local value. Microsoft also notes that when both values exist, both should be 0 to avoid listener problems. If the options in Settings are greyed out, a policy is almost certainly the reason.
3. Decide how people will reach it
| Where the user is | Safe way in | Not acceptable |
|---|---|---|
| On the same LAN or VLAN | Direct RDP, firewall rule limited to your management subnet. | Rule open to Any. |
| Remote, with a VPN | Connect to the VPN first, then RDP to the internal address. Microsoft calls this the preferable option over port forwarding. | Port forward on the router. |
| Remote, no VPN, Windows Server estate | Remote Desktop Gateway: RDP carried over HTTPS (TCP 443), with policies about who may reach which machine, and MFA through RADIUS (NPS). | TCP 3389 exposed on a public address. |
Why this works
Every layer removes a way in. The firewall rule stops machines outside your subnet from even reaching the port. The Remote Desktop Users list stops accounts that have no business there. NLA makes a connection prove who it is before a session is created. A VPN or RD Gateway puts a second authenticated hop in front of RDP so the RDP port itself is never on the internet. None of these replaces strong passwords.
The fix
Before you start: you need to be a member of the local Administrators group. Make sure every account that will be allowed in has a strong, unique password (Microsoft says so explicitly), and that you are connected to the PC in a way that survives the firewall change (be at the console, or connect from an address you are about to allow). Do not do this over an RDP session you cannot afford to lose.
1. Switch it on, with NLA
- Select Start > Settings > System > Remote Desktop.
- Turn Enable Remote Desktop to On and select Confirm.
- Expand the setting and tick Require devices to use Network Level Authentication to connect, if it is not already ticked.
- Note the checkbox Make my PC discoverable on private networks to enable automatic connection from a remote device. Microsoft says it is ticked by default.
2. Say who is allowed
In the same page select Remote Desktop users (on some releases the link reads Select users that can remotely access this PC), then Add, type the account name, and select OK. From PowerShell:
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\Username"Keep this list short and name people or one purpose-built group, not Everyone or all domain users. Remember that every member of the local Administrators group can also connect, so check who is in it. In a domain, manage the right Allow log on through Remote Desktop Services by Group Policy rather than machine by machine. Microsoft’s security baseline for servers lists Administrators and Remote Desktop Users as the intended holders of that right.
3. Limit the firewall rule to your own subnet
First list the rules that belong to the Remote Desktop group and see their state:
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Format-Table DisplayName, Enabled, Profile, DirectionIf the rules are not enabled yet, enable the group, then restrict it to the address range your administrators connect from. -RemoteAddress takes a single address, a subnet such as 192.168.10.0/24, a range, or a keyword such as LocalSubnet:
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Set-NetFirewallRule -DisplayGroup "Remote Desktop" -RemoteAddress 192.168.10.0/24Check the range before you press Enter. Enable-NetFirewallRule with no parameters enables every firewall rule on the machine, so always name the group. And if the range does not include the PC you are working from, you have just locked yourself out of the PC. Start with LocalSubnet if you are unsure. [UNCONFIRMED: the display group name “Remote Desktop” is the English name. On a non-English Windows the display group name is localised, so list the rules with Get-NetFirewallRule first and copy the name it shows.]
If Group Policy manages these firewall rules in your domain, make the scope change there instead, or a policy refresh may undo it.
4. The same thing in PowerShell, start to finish
This is the scripted equivalent of steps 1 to 3, for a server or for several machines:
# turn Remote Desktop on
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections -Value 0 -Type DWord
# require Network Level Authentication (1 = required)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name UserAuthentication -Value 1 -Type DWord
# open the firewall group, then limit it to your subnet
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Set-NetFirewallRule -DisplayGroup "Remote Desktop" -RemoteAddress 192.168.10.0/24On a Windows Server using the classic dialog, the same two choices are on the Remote tab of System Properties: allow remote connections, and Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure).
5. Reaching it from outside: VPN or Remote Desktop Gateway
- VPN. Connect to the VPN, then open Remote Desktop to the internal name or address. The PC is never exposed to the public internet. This is what Microsoft recommends over port forwarding.
- Remote Desktop Gateway. It carries RDP in an encrypted HTTPS tunnel on TCP 443 (and UDP 3391 for RDP over UDP) so no internal RDP port is open to the internet. It authenticates the user first, can use RADIUS to add multi-factor authentication such as Azure MFA, and uses Connection Authorization Policies and Resource Authorization Policies to decide who may reach what. Use a publicly trusted certificate, not a self-signed one, in production.
- Microsoft Entra sign-in. On Entra joined or hybrid joined Windows 11 with the 2022-10 cumulative update or later, Remote Desktop Connection can sign in with a Microsoft Entra account (the advanced option Use a web account to sign in to the remote computer). You must connect by hostname, not by IP address. Microsoft also notes Remote Credential Guard must be off on the connecting device.
If you absolutely must forward a port on a router, Microsoft says to limit it to the source addresses you will connect from and to use a strong password, and calls a VPN preferable. Changing the listening port away from 3389 is documented by Microsoft but is not a security control and should not be relied on.
6. Lockout, passwords and MFA
- Account lockout. A lockout policy limits password guessing against every account allowed in. In Group Policy: Computer Configuration > Windows Settings > Security Settings > Account Policies > Account Lockout Policy. Microsoft’s current security baseline value for the threshold is 10, and it advises a fairly short lockout duration such as 15 minutes, because an attacker can otherwise lock your users out on purpose.
- Strong, unique passwords. Microsoft says all accounts with remote access should have strong, unique passwords. A shared or reused local administrator password is the worst case for Remote Desktop. Microsoft documents a Group Policy to deny the Remote Desktop logon right to local accounts that are members of Administrators.
- MFA. Plain RDP with a password has no second factor. Add it in front: a VPN that requires MFA, an RD Gateway using RADIUS and NPS for MFA, or Entra sign-in as above.
Verification
From a PC inside the range you allowed, check that the port answers:
Test-NetConnection -ComputerName PC-NAME -CommonTCPPort RDP
# or name the port
Test-NetConnection -ComputerName PC-NAME -Port 3389Look for TcpTestSucceeded : True. Then connect with Remote Desktop Connection (mstsc.exe) and sign in with an account on the allowed list. Run the same test from a machine outside the allowed range: it should report TcpTestSucceeded : False. If it succeeds from there, the scope is not doing its job. On the host itself, qwinsta should list rdp-tcp in the Listen state, and the two Get-ItemProperty checks from the start should show 0.
If the test fails from the allowed range, check in this order: the PC is on and reachable, the firewall rule is enabled and the scope includes your source address, fDenyTSConnections is 0 in the local and policy locations, and the Remote Desktop Services (TermService) service is running.
Turning it off again
Turn it off when you are done, and by default on machines that do not need it. Either toggle Enable Remote Desktop to Off in Settings, or:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections -Value 1 -Type DWord
Disable-NetFirewallRule -DisplayGroup "Remote Desktop"Then remove accounts you added to Remote Desktop Users (Settings, or lusrmgr.msc), and remove any router port forward you made while testing. [UNCONFIRMED: whether turning the setting off disconnects sessions that are already open. Check with qwinsta and log off any session you do not want.]
Notes
- Group Policy wins. If a domain policy sets
fDenyTSConnections, the NLA requirement or the firewall rules, local changes are overwritten at the next refresh. Microsoft documents a case where sessions are dropped during a refresh when the local and policy settings disagree. - Do not leave NLA off. If an old client fails to connect with NLA on, update the client rather than turning NLA off. If you disable it for a test, set
UserAuthenticationback to 1 afterwards. - Registry changes. Back up the registry key before editing it by hand, as Microsoft advises.
- A sleeping or powered-off PC does not answer. The PC must be on and on the network for Remote Desktop to work.
- Vendor documents used: Enable Remote Desktop on your PC,
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-allow-access; Allow access to your PC from outside your PC’s network,https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-allow-outside-access; General Remote Desktop connection troubleshooting,https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/rdp-error-general-troubleshooting; Remote Desktop cannot connect to the remote computer,https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/remote-desktop-cannot-connect-remote-computer; Remote Desktop sessions disconnected during Group Policy updates,https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/client-disconnected-group-policy-updates; Connect to remote Microsoft Entra joined device,https://learn.microsoft.com/en-us/windows/client-management/client-tools/connect-to-remote-aadj-pc; Remote Desktop Services, access from anywhere (RD Gateway),https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-plan-access-from-anywhere; Deploy the Remote Desktop Gateway role,https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-gateway-role; Ports used by Remote Desktop Services,https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/ports-used-by-rds; Enable-NetFirewallRule,https://learn.microsoft.com/en-us/powershell/module/netsecurity/enable-netfirewallrule; Set-NetFirewallRule,https://learn.microsoft.com/en-us/powershell/module/netsecurity/set-netfirewallrule; Test-NetConnection,https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection; Set the account lockout threshold to recommended value,https://learn.microsoft.com/en-us/services-hub/microsoft-engage-center/health/remediation-steps-ad/set-the-account-lockout-threshold-to-the-recommended-value; Local accounts,https://learn.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts; Microsoft Security Bulletin MS12-036,https://learn.microsoft.com/en-us/security-updates/securitybulletins/2012/ms12-036.
Stuck connecting, or not sure your setup is safe? Describe it (no passwords or public IP addresses) in The Patch Panel and we will go through it with you. The best answer earns points on Top of the Stack.