How to Set Up Remote Desktop Gateway on Windows Server 2025

Remote Desktop Gateway (RD Gateway) is a Windows Server role service that enables authorised users to connect to internal remote desktops and RemoteApp programs over HTTPS (port 443), without requiring a VPN connection. By tunnelling RDP traffic through an SSL-encrypted HTTPS connection, RD Gateway allows secure remote access from any internet location while centralising authentication, authorisation, and connection auditing. On Windows Server 2025, RD Gateway benefits from improved TLS handling, enhanced connection authorisation policies, and tighter integration with Network Policy Server (NPS) for multi-factor authentication. This tutorial covers installing and configuring RD Gateway from scratch, including SSL certificate setup, Connection Authorization Policies (CAP), Resource Authorization Policies (RAP), RDP client configuration, session monitoring, and high availability options.

Prerequisites

Windows Server 2025 (Desktop Experience or Server Core with remote management) — a dedicated or standalone server is recommended for RD Gateway
A public DNS name pointing to the RD Gateway server (e.g., rdgateway.contoso.com)
A valid SSL certificate matching the public DNS name (from a public CA or internal PKI)
Firewall rule allowing inbound TCP 443 from the internet to the RD Gateway server
Active Directory domain environment (for user group-based CAP/RAP policies)
Administrative access to the server and sufficient permissions to install server roles

Step 1: Install the RD Gateway Role Service

The RD Gateway role is part of the Remote Desktop Services (RDS) role. Install it along with the RD Gateway Management Tools:

# Install RD Gateway role service with management tools
Install-WindowsFeature RDS-Gateway -IncludeManagementTools -Restart

# After reboot, verify the role is installed
Get-WindowsFeature RDS-Gateway | Select-Object Name, DisplayName, InstallState

# Also verify that IIS was installed as a dependency (RD Gateway uses HTTPS via IIS)
Get-WindowsFeature Web-Server | Select-Object Name, InstallState

# Check the RD Gateway service is present
Get-Service TSGateway | Select-Object Name, DisplayName, Status

Start the RD Gateway service if it is not already running:

# Start the RD Gateway service
Start-Service TSGateway

# Set the service to start automatically
Set-Service TSGateway -StartupType Automatic

# Confirm service status
Get-Service TSGateway

Step 2: Import or Request an SSL Certificate

RD Gateway requires a server authentication certificate bound to its public FQDN. The certificate must be trusted by connecting clients. Import an existing PFX or request one from your internal CA:

# Option A — Import a PFX certificate from your CA or certificate vendor
$pfxPassword = Read-Host -AsSecureString -Prompt "Enter PFX password"
Import-PfxCertificate `
    -FilePath "C:Certsrdgateway-contoso-com.pfx" `
    -CertStoreLocation "Cert:LocalMachineMy" `
    -Password $pfxPassword

# Option B — Request a certificate from an internal Windows CA
$certReq = @{
    Subject          = "CN=rdgateway.contoso.com"
    DnsName          = "rdgateway.contoso.com"
    CertStoreLocation = "Cert:LocalMachineMy"
    KeyUsage         = "KeyEncipherment", "DigitalSignature"
    EnhancedKeyUsage = "Server Authentication"
}
$cert = New-SelfSignedCertificate @certReq   # Use only for internal testing

# Get the certificate thumbprint (needed for Gateway binding)
$thumbprint = (Get-ChildItem Cert:LocalMachineMy | 
    Where-Object {$_.Subject -like "*rdgateway.contoso.com*"}).Thumbprint

Write-Host "Certificate thumbprint: $thumbprint"

Step 3: Configure the SSL Certificate in RD Gateway Manager

Bind the SSL certificate to the RD Gateway service using PowerShell. The Gateway Manager GUI can also be used, but PowerShell provides repeatable configuration:

# Import the RD Gateway PowerShell module
Import-Module RemoteDesktopServices

# Navigate to the RD Gateway configuration store
Set-Location RDS:GatewayServer

# View current Gateway configuration
Get-Item RDS:GatewayServerSSLCertificate

# Assign the certificate by thumbprint
Set-Item RDS:GatewayServerSSLCertificateThumbprint $thumbprint

# Verify the binding
Get-Item RDS:GatewayServerSSLCertificate

# Restart the Gateway service to apply the certificate
Restart-Service TSGateway

# Confirm HTTPS is listening on port 443
netstat -an | Select-String ":443"

Step 4: Create a Connection Authorization Policy (CAP)

A Connection Authorization Policy (CAP) defines which users or groups are permitted to connect through the RD Gateway. The CAP validates the user’s identity and optionally requires device authentication or NPS-based multi-factor authentication:

# Create an Active Directory security group for RD Gateway users
New-ADGroup -Name "RDGateway-Users" `
    -GroupScope Global `
    -GroupCategory Security `
    -Path "OU=Groups,DC=contoso,DC=com" `
    -Description "Users permitted to connect through Remote Desktop Gateway"

# Add users to the gateway group
Add-ADGroupMember -Identity "RDGateway-Users" -Members "jsmith", "mmiller", "kdavis"

# Create the CAP using PowerShell via the RDS provider
New-Item RDS:GatewayServerCAP `
    -Name "CAP-Domain-Users" `
    -UserGroups "contoso.comRDGateway-Users" `
    -AuthMethod 1    # 1 = Password authentication

# View the created CAP
Get-ChildItem RDS:GatewayServerCAP | Select-Object Name

# View CAP details
Get-Item "RDS:GatewayServerCAPCAP-Domain-Users" | Select-Object -ExpandProperty Attributes

Authentication methods for the CAP -AuthMethod parameter:

1 — Password
2 — Smart card
3 — Password and smart card (both required)

Step 5: Create a Resource Authorization Policy (RAP)

A Resource Authorization Policy (RAP) defines which internal computers or network resources Gateway-authenticated users can connect to. RAPs answer the question: “Even though this user passed CAP, what are they allowed to reach?”

# Create a computer group for allowed RDP targets
# Option A — Use an existing AD group containing allowed computer accounts
New-ADGroup -Name "RDGateway-Targets" `
    -GroupScope Global `
    -GroupCategory Security `
    -Path "OU=Groups,DC=contoso,DC=com" `
    -Description "Computers accessible via RD Gateway"

# Add computer accounts to the target group
Add-ADGroupMember -Identity "RDGateway-Targets" `
    -Members "WORKSTATION01$", "FILESERVER01$", "APPSERVER01$"

# Create the RAP
New-Item RDS:GatewayServerRAP `
    -Name "RAP-Internal-Servers" `
    -UserGroups "contoso.comRDGateway-Users" `
    -ComputerGroupType 1 `
    -ComputerGroup "contoso.comRDGateway-Targets"

# ComputerGroupType values:
# 0 = Any computer
# 1 = AD Domain Services group
# 2 = DHCP scope

# Verify the RAP was created
Get-ChildItem RDS:GatewayServerRAP

# View RAP properties
Get-Item "RDS:GatewayServerRAPRAP-Internal-Servers" | Select-Object -ExpandProperty Attributes

Step 6: Configure the RDP Client to Use RD Gateway

End users must configure their Remote Desktop Connection client to route through the Gateway. This can be done manually or via a pre-configured .rdp file distributed to users:

# Generate a pre-configured .rdp file with Gateway settings
$rdpContent = @"
full address:s:APPSERVER01.contoso.com
gatewayhostname:s:rdgateway.contoso.com
gatewayusagemethod:i:1
gatewaycredentialssource:i:4
gatewayprofileusagemethod:i:1
promptcredentialonce:i:1
username:s:contosojsmith
authentication level:i:2
"@

$rdpContent | Set-Content -Path "C:RDPFilesAppServer01-via-Gateway.rdp" -Encoding ASCII

# Distribute the .rdp file to users via file share or email
Copy-Item "C:RDPFilesAppServer01-via-Gateway.rdp" `
    -Destination "\FILESERVER01UserShareRemoteDesktop"

For manual configuration, users open Remote Desktop Connection, click Show Options, go to the Advanced tab, click Settings under “Connect from anywhere”, and enter the Gateway server FQDN (e.g., rdgateway.contoso.com).

Step 7: Monitor Active RD Gateway Sessions

Monitor active gateway connections, user sessions, and connection events using the RD Gateway Manager and PowerShell:

# View all current active gateway connections
Get-ChildItem RDS:GatewayServerMonitoringData

# Get a count of active connections
(Get-ChildItem RDS:GatewayServerMonitoringData).Count

# View Windows Event Log for RD Gateway connection events
Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-Gateway/Operational" `
    -MaxEvents 50 | Format-List TimeCreated, Id, Message

# Filter for connection success events (Event ID 200)
Get-WinEvent -FilterHashtable @{
    LogName = "Microsoft-Windows-TerminalServices-Gateway/Operational"
    Id = 200
    StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message

# Filter for failed connection attempts (Event ID 201)
Get-WinEvent -FilterHashtable @{
    LogName = "Microsoft-Windows-TerminalServices-Gateway/Operational"
    Id = 201
    StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message | Format-List

Step 8: High Availability for RD Gateway

For production environments, a single RD Gateway server is a single point of failure. High availability can be achieved using Windows Network Load Balancing (NLB) for on-premises deployments or Azure Load Balancer for cloud-adjacent scenarios:

# Install NLB feature on both Gateway nodes
Install-WindowsFeature NLB -IncludeManagementTools

# Create a new NLB cluster (run on the first node)
New-NlbCluster `
    -InterfaceName "Ethernet" `
    -ClusterPrimaryIP "192.168.1.200" `
    -SubnetMask "255.255.255.0" `
    -ClusterName "RDGatewayCluster" `
    -OperationMode "Multicast"

# Add a port rule for HTTPS (443)
Add-NlbClusterPortRule `
    -IP "192.168.1.200" `
    -StartPort 443 `
    -EndPort 443 `
    -Protocol "TCP" `
    -Mode "Multiple" `
    -Affinity "Single"

# Add the second Gateway node to the NLB cluster
Add-NlbClusterNode `
    -NewNodeInterface "Ethernet" `
    -NewNodeName "RDGW02.contoso.com"

# Verify NLB cluster status
Get-NlbCluster | Select-Object Name, ClusterIPAddress, OperationMode
Get-NlbClusterNode | Select-Object NodeName, State

For RD Gateway HA, all nodes in the cluster must share the same SSL certificate (same thumbprint), and the shared DNS name (e.g., rdgateway.contoso.com) must resolve to the NLB virtual IP address. Session state does not need to be shared between Gateway nodes since each connection is stateless at the Gateway layer.

Conclusion

Remote Desktop Gateway on Windows Server 2025 provides a secure, certificate-protected pathway for remote desktop access without exposing RDP (port 3389) directly to the internet. Through carefully defined Connection Authorization Policies and Resource Authorization Policies, you can enforce fine-grained access control — specifying exactly which users can connect and to which internal resources. The SSL certificate requirement ensures all traffic is encrypted in transit, and the built-in event logging provides an audit trail of connection attempts for compliance and incident response. For organisations requiring higher availability, NLB clustering or Azure Load Balancer distributes gateway connections across multiple nodes, eliminating the single point of failure. Combined with Network Policy Server for RADIUS-based MFA, RD Gateway remains a robust and cost-effective solution for secure remote access in Windows Server environments.

Links

Newsletter

Contact