Using Windows Server NPS as a RADIUS Engine for VPN and Wireless – A Practical Guide

Why NPS as a RADIUS Engine Matters

When you need a single point of authentication for both VPN and wireless clients, the Windows Server Network Policy Server (NPS) can act as a RADIUS engine. It centralizes policy logic, simplifies user management, and provides detailed accounting logs that help with compliance and troubleshooting.

Concrete Problem – One Policy, Two Access Methods

Imagine a small organization that uses both a remote‑access VPN (OpenVPN or SSTP) and 802.1X‑secured Wi‑Fi. Without a central RADIUS server, each solution would require its own authentication store, leading to duplicate accounts and inconsistent policy enforcement. The goal: authenticate VPN and Wi‑Fi clients against the same Active Directory (AD) domain, enforce conditional access, and collect accounting data.

Step‑by‑Step Configuration Workflow

1. Install the NPS Role

Run the following on the Windows Server that hosts AD (or a dedicated NPS server) as an administrator:

Install-WindowsFeature -Name NPS -IncludeManagementTools

After installation, open the NPS Management console.

2. Register the Server with AD

In the console, right‑click NPS (Local) and select Register server in Active Directory. Confirm the dialog – this creates the necessary AD objects for policy evaluation.

3. Add RADIUS Clients

Both the VPN server and wireless access point (AP) must be registered as RADIUS clients. Use the client IP or FQDN and a shared secret. For example, to add an AP:

# In NPS console: RADIUS Clients > New
# Name: Office‑AP
# Address: 10.0.0.5
# Shared Secret: StrongSecret123

Repeat for the VPN server (e.g., vpn.example.com).

4. Create a Simple PAP Policy (Test Only)

For a quick test, create a policy that allows PAP (Password Authentication Protocol) for a specific group. In the NPS console:

# Policies > Network Policies > New
# Policy name: Test‑PAP
# Conditions: User Groups – Add the AD group "VPNUsers"
# Constraints: Authentication Methods – Check PAP
# Settings: Allow access

Remember: PAP is insecure; use it only in a lab environment. In production, choose EAP‑TLS or PEAP with MFA.

5. Configure the VPN Server to Use RADIUS

On the VPN server (e.g., Windows Server 2019 with RRAS), open the RRAS console, right‑click the server, and choose Properties. Under the Security tab, select Authentication and choose RADIUS authentication. Add the NPS server’s IP and the same shared secret used earlier.

6. Verify Accounting Logs

After a client connects, go back to the NPS console, expand Accounting, and view the latest entries. A successful PAP session should appear with the client IP, user name, and session start time.

7. Test the Setup

• From a Windows client, connect to the VPN using SSTP. Provide an AD credential that belongs to the VPNUsers group.
• On the client, run netsh wlan show profile to confirm the profile references the correct RADIUS server and uses EAP‑TLS (if configured).
• Check the NPS accounting log for a successful entry.

Best‑Practice Insights

• Use Strong Authentication: Replace PAP with PEAP or EAP‑TLS. These protocols encrypt the credentials and support MFA.
• Certificate Trust: For EAP‑TLS, install a CA that is trusted by both the NPS server and client devices. Avoid self‑signed certs unless you deploy a local CA.
• Time Synchronization: Ensure NPS and all clients share NTP time. Clock drift can cause RADIUS failures.
• Conditional Access Policies: Leverage Network Policy Server - Conditional Access to require device compliance or MFA based on user or location.
• Testing First: Deploy a lab instance before production. Misconfigured policies can block legitimate traffic.

Trade‑Offs and Limitations

While NPS centralizes authentication, it introduces certain complexities:

• Certificate Management: EAP‑TLS requires a robust PKI. Expired or mis‑issued certs will drop connections.
• Scalability: A single NPS server can become a bottleneck if you have a high‑density environment. Consider clustering or a dedicated RADIUS appliance for large deployments.
• Feature Gaps: NPS does not natively support all modern MFA methods (e.g., FIDO2). You may need an additional MFA gateway.
• Complex Policies: Conditional Access can become hard to troubleshoot if you mix many attributes. Keep policies focused and document them.

Actionable Takeaway

Turn Windows Server NPS into a RADIUS engine to unify VPN and wireless authentication. Start with a simple PAP policy in a lab, then migrate to EAP‑TLS or PEAP with MFA for production. Keep an eye on certificate health, time sync, and policy clarity to avoid accidental outages. Once the NPS server is stable, enable accounting to satisfy audit and compliance requirements.