Separate RADIUS proxy forwarding from user authorization

Source facts

An NPS proxy receives RADIUS connection requests and forwards them to other RADIUS servers for processing. Microsoft says the proxy does not perform connection authorization, so it does not need network policies for that role. The documented proxy can be a domain member or a standalone server and does not require AD DS registration to read user dial-in properties. Microsoft Learn.

Applicability

Confirm whether the planned NPS instance is acting as a proxy, a RADIUS server, or both in the actual design. Identify the access devices, destination server groups, and the team responsible for the final access decision. Keep forwarding configuration distinct from authorization policy.

DSE recommendation

Create a request-flow diagram with the incoming client, applicable connection request policy, chosen remote group, and final authorization owner. Review the network path and shared-secret handling for each hop without placing secrets in the diagram. Ask the receiving administrator to confirm which server will make the access decision. Include an unmatched request and an unavailable destination in the acceptance plan.

Verification

Send approved test requests through the proxy and compare the selected destination with the routing design. Check the response at the access device and the authorization result at the destination server. Preserve timestamps that allow the two teams to correlate the transaction. Resolve unexpected local handling or forwarding before production use.

Official references

Microsoft Learn: Plan NPS as a RADIUS proxy. Source reviewed September 8, 2026.