Controlling VPN Access with NPS RADIUS and Active Directory Groups

Small IT teams usually face a bad choice when securing remote access: either open the VPN or Wi-Fi to everyone, or hand-maintain a list of per-user rules that collapses under growth. The first option is insecure; the second is unsustainable. A middle path exists if you already run Active Directory.

The short version: Windows Network Policy Server (NPS) can act as a central RADIUS server that reads LDAP group membership and translates it into per-user network policies. You do not need to write custom code or deploy a separate identity appliance.

How NPS maps directory groups to RADIUS attributes

RADIUS (Remote Authentication Dial-In User Service) is the protocol that carries authentication and authorization requests between a network access device—such as a VPN concentrator or wireless controller—and a policy server. NPS is Microsoft's RADIUS implementation, and it integrates with Active Directory through LDAP (Lightweight Directory Access Protocol), the standard query language for directory services.

The connection between the two worlds is the RADIUS attribute framework. When a user authenticates, NPS evaluates connection request policies and network policies. If a policy matches, NPS returns attributes to the access device. Some attributes are standard; others are vendor-specific attributes (VSAs) that carry instructions only certain equipment understands.

One useful VSA is Tunnel-Private-Group-ID. This attribute tells the access device which logical group or profile the user belongs to—for example, which VLAN to assign or which firewall zone to enforce. By mapping an AD group to a policy that returns this attribute, you effectively say: "members of this AD group get this network profile."

A worked example: one group, one policy

Suppose you want only members of an AD group named VPN-Users to establish tunnel-based VPN connections, and you want those users placed into a specific IP pool. The approach is straightforward.

1. Create the AD group VPN-Users and populate it with the appropriate accounts.
2. In the NPS console, create a network policy. Set the condition to match the Windows group VPN-Users.
3. Configure the policy to grant access and specify the RADIUS attributes to return. For example, set Tunnel-Private-Group-ID to the identifier your VPN gateway expects, and include an attribute that assigns the desired IP pool.
4. Ensure that users who do not match the group condition are denied—either through a subsequent deny policy or by relying on the default behavior when no network policy matches.

When a member of VPN-Users connects, NPS matches the group condition, returns the tunnel and pool attributes, and the VPN gateway applies them. A non-member fails the group condition and falls through to the deny path. No per-user rules are stored on the network device itself.

Because the policy references the AD group rather than individual usernames, onboarding is a group-membership change in Active Directory, not a firewall or VPN configuration change.

The trade-off: group hygiene and authentication latency

The model is simple, but it shifts complexity from network configuration to directory hygiene. If VPN-Users contains stale accounts, former employees retain access. If it contains duplicate or nested groups that are not what you expect, the policy may match the wrong population. NPS trusts the group membership it reads at authentication time; it does not know whether your joiner-mover-leaver process is current.

There is also a performance consideration. Every authentication requires NPS to evaluate the policy chain and query the directory. Complex policy chains with many conditions, or heavy LDAP filter strings, add processing overhead. Under high load—say, a morning Wi-Fi rush—this can introduce noticeable delays in authentication.

Finally, this approach assumes a supported platform. Run NPS on a supported Windows Server edition such as 2019 or 2022, and apply security patches. Older builds may lack recent RADIUS hardening fixes.

How to verify the result

Before rolling out to production, confirm the basics.

On the NPS server, check that the service is listening on the standard RADIUS ports. Open a Command Prompt and run:

netstat -an | find "1812"

You should see a UDP listener on port 1812. Port 1813 is the accounting port; check it similarly if you use RADIUS accounting.

Next, from a client device, trigger an authentication for a test user who belongs to VPN-Users. Inspect the RADIUS response—either through NPS logging or on the access device—and confirm that Tunnel-Private-Group-ID matches the value you configured. Repeat with a test user who is not in the group and confirm access is denied.

Validate any LDAP filter strings in a test environment first. An incorrect filter can match too broadly or too narrowly; in the worst case, a malformed condition can block all authentication attempts and cause an outage.

Start narrow, then expand

The practical path is to pick one access scenario—such as VPN—and map exactly one AD group to one NPS policy. Verify the returned attributes with a single test account, then add a second group. Resist the urge to build a large policy tree on day one; the operational cost of inaccurate group membership will outweigh the convenience.