How to Set Up Windows Server 2019 as a RADIUS Proxy

March 20, 2026
Tutorials
Comment off

Introduction to RADIUS Proxy

A RADIUS proxy receives authentication requests from RADIUS clients (VPN servers, wireless APs, switches) and forwards them to remote RADIUS servers based on configurable rules. Windows Server 2019 with the Network Policy Server (NPS) role can function as a RADIUS proxy in addition to—or instead of—acting as a full RADIUS server. RADIUS proxy deployments are useful for several scenarios: federating authentication between organizations with different RADIUS infrastructure, routing authentication requests to different back-end RADIUS servers based on username realm or connection attributes, and providing a scalable front-end for multiple internal RADIUS servers. This tutorial covers configuring NPS as a RADIUS proxy.

When to Use a RADIUS Proxy

Deploy a RADIUS proxy when you need to: route authentication for users from multiple domains to different NPS servers (realm-based routing), provide RADIUS services to a partner organization without exposing your internal AD, load balance RADIUS authentication across multiple NPS servers, or separate public-facing RADIUS clients from internal AD infrastructure by placing the proxy in a DMZ while keeping NPS servers on the internal network.

Installing NPS for Proxy Role

Install the NPAS role on the proxy server. The proxy does not need to be joined to the domain if you are routing to external RADIUS servers, but for AD-integrated proxying, domain membership simplifies certificate trust.

Install-WindowsFeature NPAS -IncludeManagementTools
nps.msc

When NPS acts purely as a proxy, it does not process authentication requests locally—it only forwards them to remote RADIUS server groups. You do not need to register the proxy NPS server in Active Directory unless it also handles some local authentication.

Understanding Remote RADIUS Server Groups

In NPS proxy configuration, Remote RADIUS Server Groups define the back-end RADIUS servers that handle the actual authentication. Each group can contain multiple servers for load balancing and failover. Configure each server in the group with the IP address, shared secret, and health check settings. NPS uses priority and weight values to distribute traffic across servers in a group.

Creating a Remote RADIUS Server Group

In the NPS console, expand RADIUS Clients and Servers > Remote RADIUS Server Groups. Right-click and select New. Name the group “Internal-NPS-Servers”. Click Add to add servers to the group.

For each server entry: specify the server DNS name or IP address, the shared secret, and adjust the Load Balancing settings (priority 1 for primary, 2 for secondary). The Weight value (default 50) distributes load—two servers with weight 50 each get 50% of requests.

# Using netsh to add a remote RADIUS server group
netsh nps add remoteradiusservergroup name="Internal-NPS-Servers"

netsh nps add remoteradiusserver `
    server=NPS01.yourdomain.com `
    group="Internal-NPS-Servers" `
    authenPort=1812 `
    acctPort=1813 `
    sharedSecret="SharedSecretForProxyToNPS!" `
    priority=1 `
    weight=50 `
    timeout=3 `
    blacklistingOn=yes `
    blacklistSeconds=300

Creating a Connection Request Policy for Proxying

Connection Request Policies determine what happens with incoming RADIUS requests on the proxy. Create a policy that forwards requests to the remote RADIUS server group based on realm (the domain part of the username, such as @yourdomain.com).

In the NPS console, right-click Policies > Connection Request Policies and select New. Name the policy “Forward-to-Internal-NPS”. Set it to Forward requests to the following remote RADIUS server group: Internal-NPS-Servers.

Add a condition: User Name with attribute value matching .*@yourdomain.com$ (regex). This routes any authentication request where the username ends with @yourdomain.com to the internal NPS servers.

netsh nps add crp `
    name="Forward-to-Internal-NPS" `
    processingOrder=1 `
    state=enable `
    forwardServerGroup="Internal-NPS-Servers" `
    conditionId="0x1001" `
    conditionValue=".*@yourdomain.com$"

Realm-Based Routing for Multiple Organizations

A common proxy deployment routes users from multiple organizations to different RADIUS servers based on username realm. Create separate Connection Request Policies for each realm, each forwarding to a different Remote RADIUS Server Group.

# Policy 1: Route @orgA.com to OrgA's RADIUS servers
# Policy 2: Route @orgB.com to OrgB's RADIUS servers
# Policy 3: Default - reject or forward to default group

# Create group for OrgB
netsh nps add remoteradiusservergroup name="OrgB-RADIUS-Servers"
netsh nps add remoteradiusserver `
    server=radius.orgb.com `
    group="OrgB-RADIUS-Servers" `
    authenPort=1812 `
    sharedSecret="OrgBSharedSecret!" `
    priority=1

Configuring Attribute Manipulation

The NPS proxy can modify RADIUS attributes before forwarding requests. This is useful for stripping realm information from usernames before forwarding (if the back-end RADIUS server does not expect @domain suffixes) or adding attributes required by the remote server.

Configure attribute manipulation in the Connection Request Policy > Settings > Attribute. Use Find and Replace rules on the User-Name attribute to strip or modify the realm. For example, to strip @yourdomain.com from the username before forwarding:

# In NPS GUI: Connection Request Policy > Settings > Attribute
# Find: (.*)@yourdomain.com
# Replace with: 1
# This strips the @yourdomain.com suffix before forwarding to the back-end RADIUS server

Configuring RADIUS Clients on the Proxy

Add all RADIUS clients (VPN servers, APs, switches) as RADIUS clients in the proxy NPS server, just as you would for a regular NPS server. The proxy NPS does not need to be registered in AD—it just needs the RADIUS client entries and Connection Request Policies configured.

netsh nps add client `
    name="VPN-Gateway-01" `
    address=10.0.1.5 `
    state=enable `
    sharedSecret="ClientToProxySecret!" `
    requireMessageAuthenticator=enable

Monitoring RADIUS Proxy Transactions

Enable logging on the proxy to audit which requests are being proxied, to which servers, and the results. Configure NPS accounting logging for authentication requests.

netsh nps set accounting logfilepath="C:NPSProxyLogs" logfileformat=IAS logtype=AuthAll

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = @(6272, 6273)
    StartTime = (Get-Date).AddHours(-1)
} | Select-Object TimeCreated, Id, Message | Format-List

Testing Proxy Forwarding

After configuration, test that authentication requests are correctly forwarded. Initiate a VPN connection or 802.1X authentication from a test client and verify on the back-end NPS server that the request arrived and was processed.

# On the back-end NPS server, watch for incoming RADIUS requests
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 6272
    StartTime = (Get-Date).AddMinutes(-5)
} | Select-Object TimeCreated, Message

Conclusion

Configuring Windows Server 2019 NPS as a RADIUS proxy provides flexible routing of authentication requests in complex environments. By separating the public-facing RADIUS proxy from the internal authentication servers, you add a security layer and enable federated authentication across organizational boundaries. Remote RADIUS server groups with priority and weight settings provide built-in load balancing and failover, and realm-based Connection Request Policies give precise control over where each user’s authentication request is directed.