NPS RADIUS Authentication Failures: Resolving Event 4402 and the 4400 Series

What You’re Seeing

It is 08:45 on a Monday morning when the network operations dashboard turns solid red. First, corporate laptops fail to associate with the corporate 802.1X wireless network, leaving workstations disconnected from the intranet. Minutes later, remote engineers reporting for duty find their client VPN handshakes immediately rejected by the edge gateway. On network access switches and wireless LAN controllers, RADIUS accounting timeouts begin piling up in rapid succession. Inside the Windows Server instances hosting Network Policy Server (NPS), the underlying service is running, but network authentication has ground to an abrupt, complete standstill.

When you inspect the Windows System event log on the affected NPS server, you will observe the warning and error sequence that defines the outage: Event ID 4401 followed immediately by Event ID 4402, sourced from the NPS (or legacy IAS) provider:

# System Event Log - Event ID 4401 (Warning)
Log Name:      System
Source:        NPS
Date:          10/7/2026 08:42:15 AM
Event ID:      4401
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      NPS01.corp.example.com
Description:
The domain controller DC01.corp.example.com for domain CORP.EXAMPLE.COM is not responding. Network Policy Server will not use this domain controller.

# System Event Log - Event ID 4402 (Error)
Log Name:      System
Source:        NPS
Date:          10/7/2026 08:42:18 AM
Event ID:      4402
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      NPS01.corp.example.com
Description:
There is no domain controller available for domain CORP.EXAMPLE.COM.

If Network Policy Server auditing is enabled on the server, opening the Security event log reveals hundreds of audit failures logged under Event ID 6273:

# Security Event Log - Event ID 6273 (Audit Failure)
Log Name:      Security
Source:        Microsoft Windows security auditing.
Date:          10/7/2026 08:42:20 AM
Event ID:      6273
Task Category: Network Policy Server
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      NPS01.corp.example.com
Description:
Network Policy Server denied access to a user.

User:
    Security ID:            CORP\jdoe
    Account Name:           jdoe
    Account Domain:         CORP
    Fully Qualified Account Name: corp.example.com/Users/John Doe

Client Machine:
    Security ID:            NULL SID
    Account Name:           -
    Fully Qualified Account Name: -
    Called Station Identifier:    00-11-22-33-44-55:Corp-Secure-WiFi
    Calling Station Identifier:   AA-BB-CC-DD-EE-FF

NAS:
    NAS IPv4 Address:       10.10.20.50
    NAS IPv6 Address:       -
    NAS Identifier:         WLC-CORE-01
    NAS Port-Type:          Wireless - IEEE 802.11
    NAS Port:               13

Status:
    Reason Code:            16
    Reason:                 The authentication request was not processed because of an internal error.

What It Actually Means

Think of Network Policy Server as an event bouncer stationed at the entrance of a members-only club. NPS does not carry or maintain a local membership list. Instead, it holds a two-way radio connected directly to the club registrar inside the back office—the Active Directory domain controller. When an employee attempts to authenticate via PEAP-MSCHAPv2 or 802.1X, the bouncer uses the radio to verify the password hash and check whether the user has dial-in privileges. Event 4402 means the radio link has gone silent. Because the bouncer has no local cache of user credentials, every incoming visitor is turned away at the door.

The 4400 event series maps directly to the operational state of the LDAP and RPC communication channels between the NPS service (running under the service binary svchost.exe -k netsvcs as the IAS service) and Active Directory directory services:

When Event 4401 triggers, the NPS service marks the offending DC as dead and initiates DC locator discovery using DNS SRV records. If the network or directory condition affects all domain controllers simultaneously—such as a firewall rule change, DNS breakdown, or an authorization permission failure—Event 4402 follows within seconds, freezing RADIUS authentication across the entire environment.

How to Diagnose

Diagnosing an NPS failure requires following a strict investigative sequence: moving from local event logs to security auditing, checking directory permissions, and validating transport-layer network connectivity.

First, inspect the System event log for recent 4400-series records to determine which domain controllers NPS attempted to reach and when the communication channel broke down:

# 1. Query the System event log for NPS and IAS provider events
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'NPS'
} -MaxEvents 30 |
Where-Object { $_.Id -in 4400, 4401, 4402, 4403, 4404, 4405 } |
Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap

If the Security log is quiet, enable the dedicated Network Policy Server audit subcategory immediately. This allows Windows to emit Event ID 6272 (access granted) and Event ID 6273 (access denied) with explicit reason codes:

# 2. Verify current NPS audit subcategory configuration
auditpol /get /subcategory:"Network Policy Server"

# 3. Enable both Success and Failure auditing for NPS
auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable

With auditing enabled, extract the most recent Event 6273 failures to inspect the specific Reason Code returned by the authentication engine:

# 4. Extract recent RADIUS authentication failures from the Security log
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id      = 6273
} -MaxEvents 10 |
Format-List TimeCreated, Message

When Event 6273 reports Reason Code 16 (Internal error) or Reason Code 33 (Domain not available), the failure correlates directly with Event 4402. Next, verify whether the NPS computer account is registered in Active Directory by checking membership in the built-in RAS and IAS Servers domain local group:

# 5. Check if the NPS computer account is a member of RAS and IAS Servers
Get-ADGroupMember -Identity "RAS and IAS Servers" |
Select-Object Name, SamAccountName, ObjectClass, DistinguishedName

Next, test whether the operating system can resolve Active Directory Domain Controller locator records and whether the network path allows LDAP and Kerberos traffic:

# 6. Verify DNS SRV locator records for LDAP
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.corp.example.com" -Type SRV

# 7. Test TCP connectivity to the primary Domain Controller on LDAP (389)
Test-NetConnection -ComputerName "dc01.corp.example.com" -Port 389

# 8. Test TCP connectivity to the primary Domain Controller on Kerberos (88)
Test-NetConnection -ComputerName "dc01.corp.example.com" -Port 88

# 9. Test TCP connectivity to the Global Catalog on port 3268
Test-NetConnection -ComputerName "dc01.corp.example.com" -Port 3268

Finally, if EAP-TLS or PEAP is deployed for 802.1X wireless or wired authentication, verify that the server’s machine certificate is valid, unexpired, and private-key accessible:

# 10. Inspect local machine certificates for Server Authentication usage
Get-ChildItem -Path Cert:\LocalMachine\My |
Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains "Server Authentication" } |
Format-Table Subject, FriendlyName, NotAfter, Thumbprint -AutoSize

Common Causes

When Event 4402 appears in production, the root cause typically falls into one of six distinct failure patterns across Active Directory permissions, network reachability, and cryptographic binding:

The Fix: Restoring Directory Communication

Resolving Event 4402 requires re-establishing directory authorization and restoring the directory binding channel. Walk through the following remediation steps in order.

1. Register the NPS Server in Active Directory

When Network Policy Server is installed on a member server, it runs under the Network Service or Local System identity. To inspect dial-in attributes, read group memberships across organizational units, and validate domain security identifiers, the server’s machine account must be granted read access to user objects across the domain.

The standard mechanism to grant this permission is adding the server to the domain’s RAS and IAS Servers built-in group. You can perform this registration through the command line using netsh:

# Register the local NPS server in the current Active Directory domain
netsh nps add registeredserver

# Alternatively, register a specific server in a target domain
netsh nps add registeredserver domain=corp.example.com server=NPS01

If the server lacks administrative delegation to modify domain groups directly, perform the assignment from an administrative workstation using the Active Directory PowerShell module:

# Add the NPS machine account to the RAS and IAS Servers domain local group
Add-ADGroupMember -Identity "RAS and IAS Servers" -Members "NPS01$"

# Confirm group membership has taken effect
Get-ADGroupMember -Identity "RAS and IAS Servers" | Where-Object { $_.SamAccountName -eq "NPS01$" }

2. Remediate Cross-Forest Selective Authentication

If your NPS instance is authenticating users across an Active Directory forest trust configured with Selective Authentication, Event 4402 frequently occurs when attempting to authenticate accounts in the trusted forest. Under Selective Authentication, Windows blocks cross-forest authentication requests by default unless the calling principal is explicitly permitted.

To allow NPS to authenticate users from the trusted forest, you must grant the NPS computer account the Allowed to authenticate right on the computer objects of the domain controllers in the trusted forest.

# Grant the Allowed to Authenticate permission on a trusted domain controller
$DCObject = Get-ADComputer -Identity "REMOTE-DC01" -Server "trusted.example.com"
$Acl = Get-Acl -Path "AD:\$($DCObject.DistinguishedName)"
$Identity = [System.Security.Principal.NTAccount]"CORP\NPS01$"
$Right = [System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight
$Type = [System.Security.AccessControl.AccessControlType]::Allow
$Guid = [System.Guid]"68b1d179-0d15-4d4f-ab71-46152e795b69" # Allowed to Authenticate GUID

$Rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($Identity, $Right, $Type, $Guid)
$Acl.AddAccessRule($Rule)
Set-Acl -Path "AD:\$($DCObject.DistinguishedName)" -AclObject $Acl

3. Re-bind PEAP Server Certificates

If the directory connection is established (Event 4400 is present) but client authentication continues to fail with Event 6273 and Reason Code 22 or 23, the issue is often an invalid or newly renewed TLS certificate. When an Enterprise CA issues a renewed certificate to the NPS server, the Network Policy does not automatically rebind to the new certificate thumbprint if the policy was bound to a specific certificate rather than the friendly subject match.

Open the Network Policy Server console (nps.msc), navigate to Policies > Network Policies, open your active authentication policy, switch to the Constraints tab, select Authentication Methods, highlight Microsoft: Protected EAP (PEAP), and click Edit. Ensure the dropdown displays the newly issued, valid machine certificate.

4. Restart the IAS Service Cleanly

Once permissions, network routes, and certificates are restored, restart the Network Policy Server engine to clear any internal domain controller blacklists and force an immediate re-discovery of Active Directory topology:

# Purge machine Kerberos tickets held by Local System
klist -li 0x3e7 purge

# Forcefully restart the underlying Network Policy Server (IAS) service
Restart-Service -Name "IAS" -Force

# Verify the service has returned to a Running state
Get-Service -Name "IAS"

Immediately after the service restarts, check the System event log. A successful recovery is marked by the appearance of Event ID 4400 confirming that LDAP communication has been restored with your domain controllers:

# Confirm successful LDAP connection in the System log
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'NPS'
    Id           = 4400
} -MaxEvents 5 | Format-Table TimeCreated, Message -Wrap

How to Prevent It

Preventing RADIUS authentication blackouts requires eliminating single points of failure across both the network policy tier and the underlying Active Directory topology.

First, deploy Network Policy Server in redundant pairs. Network access devices (wireless LAN controllers, VPN gateways, and core switches) should always be configured with primary and secondary RADIUS server definitions. To ensure consistency between servers, export the master NPS configuration to an XML template and import it onto the secondary node:

# Export complete NPS configuration on the primary server
Export-NpsConfiguration -Path "C:\Backups\NPS-Config-Primary.xml"

# Import configuration onto the secondary NPS node
Import-NpsConfiguration -Path "C:\Backups\NPS-Config-Primary.xml"

Second, establish proactive monitoring on the Windows System event log for Event ID 4401. When a domain controller experiences performance degradation or reboots during maintenance, NPS logs Event 4401 as a warning before failing over. Catching 4401 alerts allows infrastructure teams to investigate directory issues before all domain controllers fail and trigger the critical Event 4402 blackout.

Third, ensure that Active Directory site topology is properly maintained. If the NPS server is located in an Active Directory site without local domain controllers, authentication requests must cross WAN links. If WAN latency spikes or firewalls drop LDAP keepalives, NPS will quickly mark remote DCs as unresponsive. Configure dedicated subnet mappings in Active Directory Sites and Services to ensure NPS always targets proximate domain controllers.

Final Thoughts

Network Policy Server is often treated as a peripheral network utility, but in enterprise operations it acts as the primary gateway bridge between physical network hardware and Active Directory identity. When Event 4402 appears, the failure is almost never a bug in the RADIUS daemon; it is a sign that the directory communication pipeline has fractured. By understanding how the 4400 event series reflects LDAP channel health, enabling granular security auditing, and ensuring proper membership in the RAS and IAS Servers group, you can rapidly restore corporate network connectivity.