Summary Explains what Network Policy Server is, how it evaluates an authentication request, and how it is deployed to provide RADIUS authentication for WPA2-Enterprise wireless clients against Active Directory.
Network Policy Server is Microsoft's implementation of RADIUS, shipped as a role service of Network Policy and Access Services in Windows Server. It has been the RADIUS server in Windows Server since 2008, replacing Internet Authentication Service.
NPS itself holds no user accounts. It is a policy engine that sits in front of an identity store — in almost all deployments, Active Directory. When a wireless client authenticates, NPS validates the credentials against AD, decides whether the connection should be permitted, and returns the authorisation attributes that tell the access point what to do with that client.
It can operate in three modes. As a RADIUS server it makes the decision itself. As a RADIUS proxy it forwards requests to another server, which is how authentication is passed to a different forest or a third-party system. It was also the enforcement point for Network Access Protection, a feature removed from Windows Server 2016 onward and not relevant to new deployments.
For wireless, only the RADIUS server role matters.
NPS is the authentication server in the 802.1X model described in KBA-048 - Meraki Wireless — RADIUS 802.1X Versus Splash Page Authentication. The access point never validates credentials — it relays them.
Wireless Client Access Point NPS Server
(supplicant) (authenticator) (authentication server)
| | |
|=== EAPOL ============> | |
| |--- RADIUS UDP 1812 ----> |
| | Access-Request |
| | |--+ validate
| | | | against
| | |<-+ AD
| | |
| |<-- Access-Accept ------- |
| | Tunnel-Private-... |
| | Filter-Id |
|<== EAP-Success ======= | |
| |--- RADIUS UDP 1813 ----> |
| | Accounting-Start |
The credentials themselves travel inside the EAP tunnel between client and NPS. The access point relays that tunnel without being able to read it, which is why a compromised AP cannot harvest passwords.
Three things must be true before NPS will authenticate a wireless client:
Meraki recommends placing the RADIUS server and the gateway access points in the same Layer 2 broadcast domain where practical, to avoid routing and firewall delays in the authentication path.
Add the Network Policy and Access Services role, selecting the Network Policy Server role service. On a small estate this is often placed on a domain controller; on anything larger it belongs on dedicated member servers, so that a DC reboot does not take wireless authentication down with it.
This step is easy to miss and produces a total failure if skipped. Registration authorises the NPS computer account to read the dial-in properties of user accounts in the domain, by adding it to the RAS and IAS Servers group. Until this is done, NPS can see the domain but cannot evaluate user accounts against it, and every request is denied.
Registration is done from the NPS console, or with:
netsh nps add registeredserver
If NPS serves users from more than one domain, it must be registered in each.
The certificate is presented to clients during the PEAP or EAP-TLS handshake. There are three options, in descending order of preference:
| Option | Suitability |
|---|---|
| Certificate from an internal PKI (AD CS) | Best fit for domain environments — the CA is already trusted by domain-joined clients through Group Policy |
| Certificate from a public CA | Works, and is useful where many non-domain devices connect, but incurs cost |
| Self-signed certificate | Lab only. Clients cannot validate it, so server validation must be disabled, which removes the protection PEAP is there to provide |
Where AD CS is in use, the RAS and IAS Server certificate template is designed for this purpose. The certificate must have the Server Authentication EKU, a subject name that is populated, and a chain that clients trust.
⚠️ Disabling Server Validation Defeats the Purpose: If clients are configured not to validate the NPS certificate, they will hand credentials to any RADIUS server presenting itself as yours. This is exactly the evil twin attack PEAP is designed to prevent. Treat a deployment that requires server validation to be turned off as unfinished, not as working.
Each gateway AP must be added by its LAN IP with the shared secret. Collect the addresses from the dashboard under Wireless > Monitor > Access points, adding the LAN IP column. Access points showing a LAN IP of N/A are repeaters in a mesh — they have no LAN address and do not need adding.
Where the APs occupy a dedicated management subnet, the whole subnet can be registered as a single RADIUS client instead. This is only advisable when nothing else lives in that range.
For SSIDs using VPN concentration or concentrated Layer 3 roaming, only the concentrators need to be added rather than every AP.
The Configure 802.1X wizard, started from the NPS console with the Standard Configuration option RADIUS server for 802.1X Wireless or Wired Connections, creates a matched pair of policies. Select Secure Wireless Connections, confirm the RADIUS clients, choose Microsoft: Protected EAP (PEAP) as the authentication method, select the server certificate, and specify the group whose members may connect — Domain Users for user authentication, or Domain Computers for machine authentication.
Two follow-up steps are needed that the wizard does not perform:
Understanding the evaluation order explains nearly every unexpected NPS result.
Access-Request arrives
|
v
Connection Request Policies evaluated top-down, first match wins
| decides: authenticate here, or proxy
v
Network Policies evaluated top-down, first match wins
|
+--> Conditions do they match? no --> try next policy
| yes
+--> Constraints are they met? no --> DENY (stop here)
| yes
+--> Settings returned in the Access-Accept
|
v
Access-Accept or Access-Reject
Connection request policies run first and decide only where the request is handled — locally, or forwarded to another RADIUS server. In a straightforward wireless deployment the single default policy handling everything locally is sufficient.
Network policies then decide the outcome. Each has three parts:
| Part | Purpose | Behaviour on mismatch |
|---|---|---|
| Conditions | Determine whether this policy applies at all — group membership, NAS Port Type, client IP, time of day | Move on to the next policy |
| Constraints | Requirements the connection must satisfy — permitted authentication methods, session timeout, day and time restrictions | Deny the request outright |
| Settings | What is returned on success — RADIUS attributes, VLAN, filter names | n/a |
⚠️ Constraints Do Not Fall Through: A failed condition moves evaluation to the next policy. A failed constraint denies the connection immediately, with no further policies considered. A user matching a broad early policy whose constraints they cannot satisfy is rejected even though a later policy would have admitted them. This is why policy order matters so much, and why a new policy added at the bottom of the list often appears to have no effect.
Authorisation is returned as attributes in the Access-Accept, configured under the network policy's Settings tab.
For per-user VLAN assignment, three standard attributes are set together:
| Attribute | Value |
|---|---|
Tunnel-Medium-Type |
802 (includes 802.11) |
Tunnel-Pvt-Group-ID |
The VLAN ID as a string |
Tunnel-Type |
Virtual LANs (VLAN) |
All three are required — a VLAN ID sent without the accompanying type attributes is ignored. On the Meraki side, RADIUS override must also be enabled on the SSID under VLAN setup, or the attributes are received and discarded.
To apply a dashboard group policy instead, return Filter-Id with a value matching the group policy name configured under Network-wide > Configure > Group policies. Meraki also accepts Reply-Message, Airespace-ACL-Name, or Aruba-User-Role for the same purpose; the attribute type chosen must match what the dashboard expects.
Knowing which attributes arrive is what allows useful NPS conditions to be written.
| Attribute | Contents |
|---|---|
User-Name |
The identity supplied by the supplicant |
NAS-IP-Address |
LAN IP of the gateway access point |
Called-Station-ID |
AP MAC and SSID name, colon-separated — AA-BB-CC-DD-EE-FF:SSID_NAME |
Calling-Station-ID |
Client device MAC address |
NAS-Port-Type |
Used to match the Wireless - IEEE 802.11 condition |
Meraki-Device-Name |
AP name as configured in the dashboard |
Called-Station-ID is the practical way to build per-SSID policies on a shared NPS server, since it carries the SSID name. A condition matching a pattern ending in the SSID name confines a policy to that one network.
Repeater access points in a mesh have no LAN IP, so NAS-IP-Address is absent for clients associated to them. NAS-Identifier, which by default carries the node MAC and virtual AP number, can be used instead.
NPS has no clustering model. Redundancy is achieved by building two independent servers with identical policy sets and listing both in the dashboard under the SSID's RADIUS servers. The access points try them in the order listed, falling to the second when the first does not respond.
Two consequences follow. Policy changes must be applied to both servers, since there is no replication between them — the NPS configuration can be exported and imported to keep them aligned. And both servers must carry the full set of RADIUS clients, because either may receive a request from any AP.
The dashboard includes a RADIUS test utility that exercises the path from every access point, which is more useful than testing from one machine. Under Wireless > Configure > Access control, use the Test button against the server entry and supply a real set of credentials. Results are reported per AP:
| Result | Meaning |
|---|---|
| APs passed | Online and authenticated successfully |
| APs failed | Online but could not authenticate — check reachability and that the AP exists as a RADIUS client |
| APs unreachable | Offline, so not tested |
A failure on some APs but not others almost always means the failing ones are missing from the RADIUS clients list. Note that alerting for 802.1X failures can lag by up to five minutes.
Adding a RADIUS server to an SSID disconnects clients currently associated to it, so schedule the change accordingly.
NPS events are in Event Viewer under Custom Views > Server Roles > Network Policy and Access Services, or in the Security log.
| Event ID | Meaning |
|---|---|
| 6272 | Access granted |
| 6273 | Access denied — the Reason Code in the event body identifies why |
| 6274 | Request discarded, commonly a malformed request or an unknown RADIUS client |
Event 6273 is where troubleshooting starts. The Reason Code distinguishes a wrong password from a user outside the permitted group from a constraint failure, and saves a great deal of guesswork.
Accounting can additionally be written to local log files or to SQL Server, configured under the Accounting node.
Every authentication fails regardless of credentials. Easily missed because the server is domain-joined and otherwise appears healthy.
Users fail only when associated to that AP. Presents as an intermittent, location-specific fault that will not reproduce elsewhere. Event 6274 on the server is the tell.
Requests are silently discarded rather than rejected with a clear error, so it resembles a firewall or reachability problem. Confirm the secret before investigating the network path.
Clients prompt to accept an unknown certificate, or fail silently on platforms that will not prompt. Usually means the issuing CA is not in the clients' trusted roots, or the certificate lacks the Server Authentication EKU or a populated subject name.
A new policy placed below an existing broad policy never matches. Alternatively a user matches an early policy and is denied by its constraints without later policies being tried. Check the order in both policy lists.
The wizard scopes the policy to a single group. Members of other groups match no policy and are rejected. Machine authentication requires Domain Computers rather than Domain Users — and machine authentication is not the same thing as MAC-based authentication, which is a separate dashboard feature entirely.
UDP 1812 and 1813 must be permitted from every AP LAN IP to the NPS server. The Windows firewall rules are created with the role, but network firewalls between the AP VLAN and the server VLAN are a frequent obstacle. See KBA-015 - Firewall Rules for Active Directory for the wider set of ports these servers typically need.
Domain-joined clients are best configured by Group Policy, under Computer Configuration > Policies > Windows Settings > Security Settings > Wireless Network (IEEE 802.11) Policies. The profile sets WPA2-Enterprise with AES, PEAP as the authentication method, the trusted root CAs the client should accept, and whether authentication is user or computer based. Distributing the profile centrally is optional for user authentication and effectively mandatory for machine authentication. See KBA-016 - Group Policy Processing and Application for how the GPO is applied.
Non-domain devices need the profile configured manually, including trusting the issuing CA. Where a significant population of unmanaged devices exists, consider whether they belong on a WPA2-Enterprise SSID at all, or on a separate network as discussed in KBA-048 - Meraki Wireless — RADIUS 802.1X Versus Splash Page Authentication.
NPS is included with Windows Server and is well suited to straightforward wireless and wired 802.1X against a single directory. Cisco ISE is a separate product with its own licensing, and earns its cost where profiling, posture assessment, guest lifecycle management, TrustSec, or policy across many device types is required. For device administration specifically — authenticating engineers to switches and routers — TACACS+ is the more appropriate protocol, covered in KBA-009 - Cisco ISE TACACS+ Server Setup and compared with RADIUS in QRG-005 - RADIUS vs TACACS+ Comparison.