What Is Remote Desktop Gateway

Remote Desktop Gateway (RD Gateway) is a Windows Server role service that enables authorized remote users to connect to internal network resources — including Remote Desktop hosts, virtual desktops, and RemoteApp programs — over an HTTPS-encrypted tunnel on port 443. Without RD Gateway, RDP traffic uses port 3389 directly, which requires opening that port through perimeter firewalls to every machine that needs to be accessed remotely, creating a significant attack surface. RD Gateway encapsulates RDP connections inside HTTPS, allowing a single HTTPS inbound rule on the firewall to serve all internal RDP access through the gateway server.

On Windows Server 2022, RD Gateway integrates with Active Directory for authentication, uses SSL/TLS certificates for the HTTPS tunnel, and enforces connection authorization policies (CAP) and resource authorization policies (RAP) to control who can connect and to which resources. This article walks through the complete setup of RD Gateway on Windows Server 2022, from role installation through policy configuration, SSL certificate binding, client configuration, and monitoring.

Installing the RD Gateway Role

The RD Gateway role service is part of the Remote Desktop Services (RDS) role. It can be installed standalone — you do not need to install the full RDS deployment with Connection Broker or Session Host. On Windows Server 2022, use PowerShell to install RD Gateway and the required supporting features:

Install-WindowsFeature RDS-Gateway -IncludeManagementTools -IncludeAllSubFeature

This installs the RD Gateway role service along with the RD Gateway Manager console (tsgateway.msc) and the Network Policy Server (NPS) feature, which RD Gateway uses for connection authorization. Verify the installation:

Get-WindowsFeature RDS-Gateway, NPAS | Select Name, InstallState

Expected output:

Name         InstallState
----         ------------
RDS-Gateway  Installed
NPAS         Installed

No reboot is typically required for this installation. Open RD Gateway Manager from Server Manager or by running:

tsgateway.msc

SSL Certificate Requirements and Configuration

RD Gateway requires an SSL certificate whose subject name or Subject Alternative Name (SAN) matches the public DNS name that clients will use to connect to the gateway. This is typically an externally resolvable FQDN like rdgateway.yourdomain.com. The certificate must be trusted by the client machines — either from a public CA (recommended for external clients) or from your internal PKI (AD CS) if all clients are domain members with the CA certificate in their Trusted Root store.

Request or import the certificate into the server’s Local Computer Personal certificate store. To request a certificate from an internal AD CS via PowerShell:

# Request a certificate from internal CA
$certParams = @{
    Template       = "WebServer"
    DnsName        = "rdgateway.yourdomain.com"
    CertStoreLocation = "Cert:LocalMachineMy"
    SubjectName    = "CN=rdgateway.yourdomain.com"
}
$cert = Get-Certificate @certParams
$cert.Certificate.Thumbprint

For a certificate from a public CA, import the PFX file:

Import-PfxCertificate -FilePath "C:certsrdgateway.pfx" `
  -CertStoreLocation "Cert:LocalMachineMy" `
  -Password (ConvertTo-SecureString -String "PfxPassword" -AsPlainText -Force)

Once the certificate is in the store, bind it to the RD Gateway role via RD Gateway Manager: right-click the server node, select Properties, go to the SSL Certificate tab, and select the certificate. Or configure it via PowerShell:

# Get the thumbprint
$thumb = (Get-ChildItem Cert:LocalMachineMy | Where-Object {$_.Subject -like "*rdgateway*"}).Thumbprint

# Bind to RD Gateway
$gatewayServer = [Microsoft.WindowsServer.RdGateway.RdgWin32Api]::new()
# Use the GUI (tsgateway.msc) SSL Certificate tab for this binding
# Alternatively, set via the Registry after identifying the correct key

In practice, the certificate binding is most reliably done through tsgateway.msc > Server Properties > SSL Certificate tab > Select an existing certificate > choose your certificate.

Creating Connection Authorization Policies (CAP)

A Connection Authorization Policy (CAP) defines who is allowed to connect through the RD Gateway. Without at least one CAP, all connection attempts through the gateway will be denied. CAPs specify the user groups that are permitted to use the gateway and the authentication methods allowed (password, smart card, or both).

Create a CAP via RD Gateway Manager:

1. Open tsgateway.msc
2. Expand your server node, expand Policies, right-click Connection Authorization Policies, select Create New Policy > Wizard
3. Name it (e.g., CAP-All-Domain-Users)
4. Select the authentication method: Password, Smart card, or Allow users to choose
5. Add the allowed user groups (e.g., Domain Users or a specific security group like RDGateway-Users)
6. Configure session timeout settings if desired
7. Complete the wizard

Via PowerShell (requires the RemoteDesktopServices module or direct WMI/COM access):

# Create a CAP using the RD Gateway WMI provider
$tsGateway = New-Object -ComObject "TsGatewayAuthorizationPlugin"

# Alternatively, use netsh ras add registered (legacy)
# The recommended method is through the MMC snap-in or the following WMI:
$wmi = Get-WmiObject -Namespace "rootCIMV2TerminalServices" -Class Win32_TSGatewayConnectionAuthorizationPolicy

The most reliable scripted method for CAP/RAP management on Windows Server 2022 is through the RD Gateway COM API or via the GUI. For automation at scale, use Desired State Configuration with the xRemoteDesktopSessionHost DSC module, or script via the New-Item provider against the TSGateway WMI namespace.

Creating Resource Authorization Policies (RAP)

A Resource Authorization Policy (RAP) specifies which internal network resources (computer names or IP addresses) gateway users are authorized to connect to. While CAP answers “who can use the gateway,” RAP answers “what can they connect to through the gateway.”

Create a RAP via RD Gateway Manager:

1. Right-click Resource Authorization Policies, select Create New Policy > Wizard
2. Name it (e.g., RAP-Internal-Servers)
3. Specify the user groups that this RAP applies to (typically the same groups as in your CAP)
4. Under Network Resources, choose one of three options:
– Allow users to connect to any network resource
– Allow users to connect to any network resource specified in an Active Directory security group
– Allow users to connect to a specific list of network resources (enter FQDNs or IPs)
5. Specify the allowed port: 3389 (standard RDP) or custom ports if your RDP hosts use non-standard ports
6. Complete the wizard

For security best practice, restrict RAP to a specific AD security group containing your allowed RDP target computers, rather than allowing connections to any resource. Create an AD group called RDP-Target-Computers, add the allowed computer accounts to it, and reference that group in the RAP.

Configuring RD Gateway Port and Firewall Rules

RD Gateway listens on port 443 (HTTPS) by default. This is the same port as standard web HTTPS traffic, which is intentional — it allows RD Gateway traffic to pass through corporate firewalls and proxy servers that permit HTTPS. Verify the port configuration in RD Gateway Manager under Server Properties > Transport Settings.

If IIS is running on the same server and already using port 443, you must either move IIS to a different port or use a different IP address binding for RD Gateway. In most deployments, RD Gateway is installed on a dedicated server or uses a dedicated IP.

Open the required Windows Firewall rules:

# RD Gateway HTTPS inbound (typically already created by role install)
New-NetFirewallRule -DisplayName "RD Gateway HTTPS Inbound" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 443 `
  -Action Allow `
  -Profile Domain,Private,Public

# RD Gateway UDP tunnel (for enhanced performance - optional but recommended)
New-NetFirewallRule -DisplayName "RD Gateway UDP Inbound" `
  -Direction Inbound `
  -Protocol UDP `
  -LocalPort 3391 `
  -Action Allow

# Verify existing RD Gateway rules added by the role
Get-NetFirewallRule | Where-Object {$_.DisplayName -like "*Remote Desktop Gateway*"} | 
  Select DisplayName, Direction, Action, Enabled

On the external perimeter firewall, create a rule allowing inbound TCP 443 (and optionally UDP 3391) to the RD Gateway server’s external IP address.

Configuring RD Clients to Use the Gateway

Remote Desktop Connection (mstsc.exe) on Windows clients supports RD Gateway configuration natively. Users specify the gateway server’s address in the Advanced tab of the RDP connection dialog.

Launch RDP with gateway settings from the command line:

mstsc /v:internal-server.yourdomain.com /gateway:rdgateway.yourdomain.com

Create pre-configured .rdp files for users that include gateway settings:

full address:s:internal-server.yourdomain.com
gatewayhostname:s:rdgateway.yourdomain.com
gatewayusagemethod:i:1
gatewaycredentialssource:i:4
gatewayprofileusagemethod:i:1
prompt for credentials:i:1
username:s:DOMAINusername
screen mode id:i:2
use multimon:i:0

The key RDP file parameters: gatewayhostname is the gateway FQDN, gatewayusagemethod:i:1 means always use the gateway, gatewayusagemethod:i:2 means use gateway only when not on local network (detect automatically).

Distribute the .rdp file via a file share, email, or Group Policy. Users double-click the file to launch RDP through the gateway without manually configuring the gateway address.

Deploy gateway settings via Group Policy to standardize the RDP experience for all domain users:

# GPO path: Computer Configuration > Administrative Templates > Windows Components > 
# Remote Desktop Services > RD Gateway
# Set "Set RD Gateway server address" to rdgateway.yourdomain.com
# Set "Set RD Gateway authentication method" to Use locally logged-on credentials

Network Policy Server (NPS) Integration for Gateway Authentication

When RD Gateway is installed, it integrates with the local Network Policy Server (NPS) to process CAP-based authentication. By default, it uses the local NPS instance. For environments where you want to centralize authentication policy — particularly for RADIUS-based MFA (Azure MFA, Duo, etc.) — you can configure RD Gateway to forward authentication requests to a remote NPS server or use the Azure NPS extension.

Configure RD Gateway to use a central NPS server:

1. In tsgateway.msc, right-click Connection Authorization Policies, select Manage Local NPS Server
2. In NPS console, go to RADIUS Clients and Servers > Remote RADIUS Server Groups
3. Add your central NPS server as a RADIUS server
4. In RD Gateway Manager > Server Properties > RD CAP Store, change from “Local Request” to “Central server running NPS”
5. Enter the NPS server address and configure a shared RADIUS secret

For Azure MFA via NPS extension, install the Azure MFA NPS extension on the NPS server and point RD Gateway to it. This enforces MFA for all gateway connections using Azure AD-registered users.

Monitoring Active Gateway Connections

RD Gateway Manager provides a real-time view of active connections. In tsgateway.msc, expand the server node and click Monitoring to see all current gateway sessions including the client IP, user name, target resource, protocol, and connection duration.

Query active connections via PowerShell using the RD Gateway WMI provider:

# List active RD Gateway sessions
$sessions = Get-WmiObject -Namespace "rootCIMV2TerminalServices" `
  -Class Win32_TSGatewayConnection
$sessions | Select-Object UserName, ClientAddress, ConnectedResource, NumberOfKilobytesReceived, 
  NumberOfKilobytesSent, TransportProtocol | Format-Table -AutoSize

Disconnect a specific session:

# Get session and disconnect
$sessions | Where-Object {$_.UserName -eq "DOMAINusername"} | ForEach-Object {
    $_.Disconnect()
}

RD Gateway also logs events to the Windows Event Log under Applications and Services Logs > Microsoft > Windows > TerminalServices-Gateway. Query events for connection attempts and failures:

# Get recent RD Gateway authentication failures (Event ID 300 = auth failed)
Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-Gateway/Operational" `
  -MaxEvents 100 | 
  Where-Object {$_.Id -in @(300, 302, 303)} | 
  Select TimeCreated, Id, Message | 
  Format-List

Scalability and High Availability

A single RD Gateway server can handle several hundred to over a thousand concurrent sessions depending on the hardware and network configuration. For high availability and load distribution, deploy multiple RD Gateway servers behind a load balancer (Windows NLB or an external hardware/software load balancer such as Azure Load Balancer, F5, or HAProxy).

For NLB-based RD Gateway farms on Windows Server 2022:

# Install NLB feature on each gateway server
Install-WindowsFeature NLB -IncludeManagementTools

# Create NLB cluster
New-NlbCluster -HostName rdgw01.yourdomain.com `
  -ClusterName RDGatewayCluster `
  -InterfaceName "External" `
  -ClusterPrimaryIP 192.168.1.200 `
  -SubnetMask 255.255.255.0 `
  -OperationMode Multicast

# Add second node
Add-NlbClusterNode -NewNodeName rdgw02.yourdomain.com `
  -NewNodeInterface "External" `
  -HostName rdgw01.yourdomain.com

In a farm configuration, all RD Gateway nodes must share the same SSL certificate (use the same wildcard certificate or a SAN certificate bound to the cluster VIP DNS name), and connection authorization policies must be synchronized across nodes. Use a central NPS server (not the local NPS on each gateway node) to ensure consistent policy enforcement across the farm.

Monitor the health of each gateway node using Performance Monitor counters under the Remote Desktop Gateway performance object, which exposes metrics such as total active connections, current connections per protocol, and bytes transferred — enabling capacity planning for the gateway farm.

Links

Newsletter

Contact

How to Configure Windows Server 2022 with Puppet