Windows Network Policy Server: RADIUS Client Trust, Policy Order, and Accounting

Network Policy Server (NPS) is Microsoft’s Windows Server implementation of RADIUS for centralized authentication, authorization, and accounting (AAA). It can evaluate requests from wireless access points, authenticating switches, VPN servers, and other network access servers (NAS), or it can operate as a RADIUS proxy that forwards requests to other RADIUS servers. NPS is not an 802.1X supplicant and a laptop is not a RADIUS client in the protocol sense: the network device that sends the Access-Request is the RADIUS client. Correctly separating supplicant, NAS, NPS, identity provider, and policy makes troubleshooting far less speculative.

An NPS decision is the result of a chain: the NAS sends a request from an address configured as a RADIUS client; the shared secret and packet integrity permit processing; a connection request policy chooses local processing or forwarding; an authentication method and identity source validate credentials; a network policy matches in order and authorizes or denies; and optional accounting records the session. A user-facing “authentication failed” message can therefore be caused by a wrong NAS source address, a mismatch in shared secret, an untrusted certificate, an unregistered NPS, policy order, unsupported authentication, or a firewall drop. Changing the network policy first often destroys useful evidence.

Before deployment, inventory the NPS version and edition, domain membership, RADIUS clients, client source IPs, secrets, ports, authentication methods, policy order, remote RADIUS groups, accounting destination, and failover plan. Microsoft documentation states that the Network Policy and Access Services role is not available for Server Core installation; validate the server installation option before building an automation plan. If the organization needs NPS proxy or another RADIUS implementation, distinguish that from the local server’s policy engine.

Model RADIUS clients and packet identity

RADIUS clients are network access servers such as wireless access points, Ethernet switches, VPN servers, and RADIUS proxies. Endpoints that authenticate through those devices are not registered as RADIUS clients. For each NAS, record management name, exact source address as observed by NPS, vendor, location, authentication/accounting ports, protocol support, and owner. If traffic crosses NAT or a load balancer, NPS may see the translated address rather than the NAS’s management address. Register the address NPS actually receives and verify it with packet capture or firewall logs.

Configure a unique high-entropy shared secret on each NAS and its matching NPS RADIUS-client entry. Do not reuse a secret across an entire fleet. Store secrets in an approved vault, restrict access to configuration exports, and rotate using a canary NAS and an agreed maintenance plan. A secret mismatch can look like dropped traffic because NPS cannot authenticate the request. Never include plaintext secrets in incident tickets, scripts, or command-line output.

RADIUS commonly uses UDP 1812 for authentication and UDP 1813 for accounting. Some network access devices use legacy ports such as 1645 and 1646. The NAS and NPS must agree on port numbers, and host and network firewalls must permit only the required source/destination pairs. NPS can be configured to listen on selected adapters and IPv4/IPv6 ports when multihomed; verify the interface binding rather than assuming all NICs accept RADIUS traffic.

Check the NPS role and current listeners with read-only inventory before changing firewall policy. Example commands to capture host identity and current adapters:

Get-ComputerInfo -Property CsName, WindowsProductName, WindowsVersion, OsBuildNumber
Get-NetIPConfiguration |
    Select-Object InterfaceAlias, InterfaceIndex,
        @{Name='IPv4';Expression={($_.IPv4Address.IPAddress -join ',')}},
        @{Name='IPv6';Expression={($_.IPv6Address.IPAddress -join ',')}}
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction

The firewall-profile output is not an NPS health check. Confirm the RADIUS ports in the NPS console, network device configuration, and packet captures. When a request does not appear in NPS logs, capture traffic at the NAS and server-facing interface to determine whether it was sent, routed, or dropped before reaching NPS.

Separate connection request policy from network authorization

Connection request policies decide whether NPS processes a request locally or forwards it to a remote RADIUS server group. Network policies decide whether the request is authorized when processed locally. A proxy configuration can forward requests based on realms, NAS attributes, or other conditions; it is not enough to create a network policy on the proxy if the request is actually being forwarded elsewhere. Trace one test request through the connection request policy and remote server selection before troubleshooting downstream identity policy.

Network policies are evaluated in their configured order. NPS uses request attributes and policy conditions to find a matching policy, and stops when a policy matches. Place the most restrictive and specific rules before broader allow rules. A broad condition near the top can capture a request intended for a later policy; a broad deny can block unrelated access. Keep an exported baseline, document each policy’s purpose, and change one condition at a time.

Conditions commonly constrain user or machine groups, NAS type, NAS identifier, connection type, and other RADIUS attributes. Authorization also depends on authentication method and account properties. A “deny access” policy can be useful as an explicit guardrail, but ensure its conditions are truly scoped. Testing only with an administrator account can hide group membership or dial-in permission behaviors that differ for standard users. Use at least one positive test user and one intentionally denied user from the actual production groups.

When the NPS server is domain-joined, it uses Active Directory as an account database and can evaluate accounts in trusted domains subject to the deployment’s trust and permissions. For certain authorization behavior, the NPS computer account must be in the appropriate RAS and IAS Servers security group in the relevant domains according to Microsoft guidance. Register NPS in Active Directory and validate domain reachability, DNS, secure channel, and group membership. Do not add the NPS computer account to broad privileged groups to silence an authorization error.

Select authentication methods and certificates deliberately

Authentication methods need to match what the NAS, client, identity source, and security policy support. For 802.1X EAP methods, certificate trust, subject or SAN mapping, EKU, expiry, revocation reachability, and private-key access can all affect the exchange. For VPN or dial-up, the NAS and NPS must agree on the selected method and its security properties. Do not “fix” a certificate validation error by disabling server validation on clients; capture the rejected certificate and identify the precise trust, name, usage, or revocation failure.

Test the complete chain from a fresh client: supplicant profile, trusted server identity, user or machine certificate, NAS configuration, shared secret, NPS network policy, directory authorization, and resulting VLAN or access attributes. Record whether the connection uses user or computer authentication and at which stage it occurs. A device certificate can authenticate the machine while a later user authorization step denies access; treat those as distinct observations.

If certificate autoenrollment is involved, verify that the NPS server and clients have the intended templates, enrollment permissions, private keys, and renewal timing. Compare a working and failing certificate by issuer, subject/SAN, EKU, validity, and chain. Avoid copying a private certificate key from one NPS server to another unless the documented design explicitly requires it and the key is protected by an approved transfer process.

Diagnose accepted and rejected attempts using correlated logs

When the Security audit policy and NPS logging are configured, event 6272 indicates that NPS granted access and event 6273 indicates that it denied access. These events are high-value because they include reason codes and request attributes, but absence of an event does not prove NPS accepted anything: the request may not have reached the server, auditing may not be enabled, or a different server may have processed it. Correlate the client timestamp, NAS log, NPS Security event, NPS accounting record, and domain-controller or certificate logs.

$start = (Get-Date).AddHours(-2)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 6272, 6273
    StartTime = $start
} -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Sort-Object TimeCreated

This query can require elevated access and depends on the appropriate audit policy. Protect results because they include usernames, NAS identity, network attributes, and access decisions. Do not enable verbose security auditing without a retention, privacy, and event-forwarding plan.

NPS accounting can log locally to text files or to SQL Server. Choose fields, log location, retention, access control, and storage size before enabling it. Accounting data can support session reconstruction and usage reports, but it is not necessarily real-time health telemetry. For proxies, distinguish authentication logging from forwarded accounting packets and make sure the intended destination is reachable. Compare NPS event decisions with RADIUS accounting Start/Stop/Interim records from the NAS; missed stop records can be a NAS or network issue rather than proof that a session remains active.

For a request rejected with an NPS event, read the reason code and identify whether the failure occurred in request processing, authentication, policy match, user properties, or certificate validation. For no event, capture UDP traffic on the network path, check listener adapter/port settings, and verify that the correct NPS instance is configured on the NAS. For an accepted event but no access, inspect NAS enforcement, VLAN assignment, firewall, DHCP, and application path after RADIUS authorization.

Handle NPS proxy and multihomed routing safely

When NPS is multihomed, configure which adapters send and receive RADIUS traffic and which UDP ports apply per IPv4/IPv6 address. Align those bindings with the NAS source networks and firewall policy. A listener on an internal interface does not automatically receive traffic arriving on an external interface. Avoid routing RADIUS packets across a public or unmanaged network; shared secrets provide protocol protection, not a substitute for network isolation and secure design.

For a RADIUS proxy, define remote server groups and connection request policies with explicit failover behavior. Test what happens when the preferred remote server is unavailable, slow, or rejects the request. Retries can amplify load or create delay; balance availability with user sign-in latency. Configure forwarding of accounting separately when required, and preserve the original NAS identity and attributes that the home server needs for policy evaluation.

Use redundant NPS servers or a supported proxy/load-balancing design where the access service requires availability. Test failover by disabling one path in a controlled environment, not by removing every firewall rule on a production server. Replicate configuration with an export/import process and revalidate local details such as network interfaces, IP addresses, SQL accounting destinations, certificates, and secret ownership after import.

Export and import configuration with protection

NPS supports configuration export for migration or recovery. Microsoft warns that the exported XML configuration is not encrypted and can contain unencrypted shared secrets; importing a configuration overwrites the destination configuration rather than merging new settings. SQL Server logging settings may not be exported and must be configured separately. Treat an export file as a credential-bearing backup: encrypt it, limit access, record a checksum, transfer it over an approved secure path, and destroy temporary copies according to policy.

$exportPath = 'C:\ProgramData\Contoso\Secure\nps-config.xml'

New-Item -ItemType Directory -Path (Split-Path -Parent $exportPath) -Force |
    Out-Null
Export-NpsConfiguration -Path $exportPath
Get-FileHash -LiteralPath $exportPath -Algorithm SHA256

The directory permissions and encryption process must be configured before the export. Do not write this file to a broadly readable share. Before import, verify source and destination server versions are compatible, take a protected export of the destination’s current configuration, and compare policy intent. Import is a destructive replacement, not an additive synchronization. After import, inspect RADIUS clients, policy order, certificate dependencies, accounting, server registration, and adapter/port configuration before allowing real NAS traffic.

Protect secrets, policy, and availability

Keep RADIUS shared secrets unique, strong, and rotated with a change window that updates both NPS and the NAS. Restrict NPS administrative membership, monitor group changes and policy edits, and centralize event forwarding. Review the security of any SQL accounting database and local log folder. Avoid exporting and mailing NPS XML, copying an unrestricted configuration file to every server, or putting secrets into command history.

Create policy backups before major changes and retain the last known-good policy in a secure repository. Configure at least one test NAS and test account so changes can be validated without disrupting all wireless, wired, or VPN access. Define rollback criteria such as elevated 6273 failures, loss of a whole connection method, malformed VLAN assignment, or accounting gaps. Do not rotate the shared secret, change authentication method, and reorder policies in one change; doing so makes root cause difficult to isolate.

A repeatable NPS incident workflow

Identify the affected connection type, user/device, NAS, NPS server, source IP, timestamp, and whether the request reached NPS.
Verify NAS registration, source IP observed by NPS, port numbers, shared secret, route, listener binding, and firewall path.
Determine whether the connection request policy processes or forwards the request; identify the remote RADIUS destination if proxied.
Read 6272/6273 reason data and correlate NAS, NPS, directory, certificate, and accounting logs.
Evaluate policy order and group conditions with a positive and intentionally denied test identity.
Confirm the selected authentication method, certificate, trust chain, and authorization attributes without lowering security globally.
Apply one scoped change, test from the actual NAS and client path, monitor accounting, and retain rollback evidence.

NPS is a central policy engine, so a small configuration error can affect every access device that trusts it. Reliable operations depend on correct RADIUS-client identity, exact packet path, deliberate policy order, current certificate and account state, protected secrets, and evidence from both the NAS and NPS. Treat the RADIUS exchange as a distributed transaction with visible boundaries rather than assuming that one server’s “Access denied” dialog explains the whole failure.

Related:

Sources: