Forum Discussion

zbevdp's avatar
zbevdp
Copper Contributor
Dec 19, 2025

AOVPN / Reasoncode 16

We have an always on vpn configuration.  This worked fine till few months ago, users can't get connected anymore. After reboot of NPS server, all works fine for some time (random, sometimes 1 day, 2 days, 1 week), till the users can't get connected again. Reboot of nps server solves it. When users can't connect, I see an event on NPS server with reason code 16 

Network Policy Server denied access to a user.
 
Contact the Network Policy Server administrator for more information.
 
User:
Security ID: xxx
Account Name:xxx
Account Domain: xxx
Fully Qualified Account Name: xx
 
Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
Called Station Identifier: x.x.x.x
Calling Station Identifier: x.x.x.x
 
NAS:
NAS IPv4 Address: x.x.x.x
NAS IPv6 Address: -
NAS Identifier: server-VPN01
NAS Port-Type: Virtual
NAS Port: 14
 
RADIUS Client:
Client Friendly Name: server-VPN01
Client IP Address: x.x.x.x
 
Authentication Details:
Connection Request Policy Name: Virtual Private Network (VPN) Connections
Network Policy Name: Virtual Private Network (VPN) Connections
Authentication Provider: Windows
Authentication Server: server-NPS01
Authentication Type: PEAP
EAP Type: Microsoft: Smart Card or other certificate (EAP-TLS)
Account Session Identifier: 33373834
Logging Results: Accounting information was written to the local log file.
Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

 

As said, reboot of nps solves issues temporary.  Already installed new nps server but same issue. 

Any suggestions where to check ?

AOVPN
nps
VPN
windows server

1 Reply

  • Jamony's avatar
    Jamony
    MCT
    Sep 17, 2026

    NPS Reason Code 16 is reported when authentication fails because the supplied credentials don't match the user account. Microsoft recommends checking the username/account state and which DC handled the request.

     

    However, because you're using PEAP/EAP-TLS, I would also inspect the certificate side. Capture the complete Event 6273 when the failure occurs and check the certificate subject/SAN, EKU, chain, expiration and mapping to the AD user/computer.

     

    Also check the DC logs for certificate-mapping events related to KB5014754. If a reboot temporarily fixes the issue but it returns and occurs on a replacement NPS server as well, I would investigate shared dependencies such as AD/DC communication, CRL/AIA availability and certificate mapping rather than the NPS installation itself.