Troubleshooting NPS failure to process RADIUS Change of Authorization (CoA) requests (RFC 3576)

Question

1. Environment & Issue:

In an 802.1X deployment utilizing Microsoft Network Policy Server (NPS) alongside a third-party Network Access Control (NAC) engine, inbound RADIUS Change of Authorization (CoA) / Disconnect Messages (DM) are not processed. As a result, post-auth dynamic VLAN re-assignment and session enforcement fail.

2. Observed Behavior:

Initial EAP-TLS / PEAP-MSCHAPv2 authentications complete successfully.

Posture-triggered CoA requests originating from the NAC server to NPS on UDP port 3799 (or 1700) produce no state change on the client network interface.

Default NPS logs (%SystemRoot%\System32\LogFiles) do not show corresponding accounting or authorization events for the CoA transaction.

3. Questions:

What specific tracing or ETW providers (e.g., netsh ras set tracing ias enable) need to be activated on Windows Server to log inbound RFC 3576 CoA packet processing and RADIUS attribute parsing?

Does Microsoft NPS natively process RADIUS CoA requests for standard network access client re-authorization, or does it require a dedicated RADIUS proxy / IAS extension DLL to handle CoA/DM packet types?

What event sources in Windows Event Viewer (e.g., NPS, IAS) log failures related to CoA shared secret mismatches or unmapped NAS clients?

Answer 1

Welcome to Microsoft Q&A Forum! 

Thank you for providing the detailed information.

Based on the scenario described, the observed behavior is generally consistent with how Microsoft Network Policy Server (NPS) is documented to operate when a third-party NAC attempts to send RFC 3576 Change of Authorization (CoA) or Disconnect Message (DM) packets directly to NPS.

1. Tracing and Diagnostics for CoA Investigation

NPS does not provide a dedicated "CoA transaction log" comparable to standard Access-Request or Accounting logging. For deep troubleshooting, please enable NPS/IAS and RAS tracing:

netsh ras set tracing * enable

or

netsh ras set tracing ias enable

Trace output is written to:

%SystemRoot%\Tracing

Commonly reviewed files include:

IASSAM.LOG IASNAP.LOG RRASEtwTracing.etl

These traces can help determine whether RADIUS packets are reaching the service and whether NPS is attempting to process the request. Microsoft troubleshooting guidance specifically references IASSAM.LOG and IASNAP.LOG for NPS-related diagnostics. To verify packet arrival, capture network traffic using:

netsh trace start capture=yes report=yes tracefile=c:\temp\nps.etl

or use Wireshark/Network Monitor with a filter such as:

udp.port == 3799

This can help confirm whether the NAC server is transmitting CoA or Disconnect-Request packets to the NPS server.

2. NPS and RFC 3576 CoA Support

This is typically the key finding in deployments such as the one described. Microsoft NPS is primarily a RADIUS Authentication, Authorization, and Accounting (AAA) server and proxy supporting RFC 2865 and RFC 2866 operations. Microsoft documentation describes support for:

• Access-Request
• Access-Accept
• Access-Reject
• Accounting-Start
• Accounting-Stop
• Accounting-Interim

However, public Microsoft documentation does not describe NPS as an RFC 3576/RFC 5176 Dynamic Authorization Server that processes inbound CoA or Disconnect-Message requests to modify active client sessions In most 802.1X deployments requiring dynamic VLAN changes, posture-based reauthorization, or session termination, the CoA target is typically the network access device that owns the session, such as a switch, wireless controller, or VPN concentrator, rather than NPS itself.

For that reason, if a NAC solution is sending CoA packets directly to NPS and expecting NPS to trigger endpoint reauthorization or VLAN reassignment, the available Microsoft documentation does not identify that as a supported NPS function. Additionally, while NPS supports extension APIs for authentication, authorization, and accounting customization, Microsoft documentation does not describe an extension mechanism that adds native RFC 3576 CoA processing.

3. Event Viewer Sources to Review

For NPS/RADIUS troubleshooting, review the following locations:

• Event Viewer -> Custom Views -> Server Roles -> Network Policy and Access Services
• Event Viewer -> Applications and Services Logs -> Microsoft -> Windows

In addition, review NPS accounting logs if logging is enabled:

%SystemRoot%\System32\LogFiles

If issues such as shared secret mismatches, unknown RADIUS clients, malformed requests, or other standard RADIUS processing failures occur, NPS typically records them through its standard NPS/IAS logging mechanisms and related event sources. However, because CoA processing is not documented as a standard NPS authorization workflow, administrators should not expect dedicated CoA-specific audit records in NPS accounting logs.

For further information, please visit:

Network Policy Server - Win32 apps | Microsoft Learn

RADIUS Authentication, Authorization, and Accounting - Win32 apps | Microsoft Learn

Enabling EAPHost Tracing - Win32 apps | Microsoft Learn

Logging With Network Policy Server - Win32 apps | Microsoft Learn Configure Network Policy Server Accounting | Microsoft Learn

If this answer was helpful, please Accept the Answer. Thank you for choosing Microsoft Q&A to raise your concern