Network Policy Server discarded the request for a user, yet again
Another variant on the neverending "Network Policy Server discarded the request for a user" problems, but this one's a bit more tricky. Auth-type is MSCHAPv2 over PEAP from two clients, X and Y authenticating to NPS on Server 2019 with all updates applied. X authenticates successfully. Y, even though it's been configured to send exactly the same data as X, doesn't. In addition both X and Y authenticate successfully to FreeRADIUS, but only X authenticates to NPS.
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 3/30/2023 5:42:14 PM
Event ID: 6274
Task Category: Network Policy Server
Level: Information
Keywords: Audit Failure
User: N/A
Computer: radius.bt.local
Description:
Network Policy Server discarded the request for a user.
Contact the Network Policy Server administrator for more information.
User:
Security ID: bt\test321
Account Name: test321
Account Domain: BT
Fully Qualified Account Name: BT\test321
Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
Called Station Identifier: -
Calling Station Identifier: -
NAS:
NAS IPv4 Address: XXXXXXXXXXXX
NAS IPv6 Address: -
NAS Port-Type: -
NAS Identifier: -
NAS Port: -
RADIUS Client:
Client Friendly Name: client
Client IP Address: XXXXXXXXXXXX
Authentication Details:
Connection Request Policy Name: CRP - process EAP requests locally
Network Policy Name: -
Authentication Provider: Windows
Authentication Server: radius.bt.local
Authentication Type: EAP
EAP Type: -
Account Session Identifier: -
Reason Code: 1
Reason: An internal error occurred. Check the system event log for additional information.
No logs on the DC provided anything useful, enabling further logging on the NPS server with "netsh ras set tracing * enabled" and looking in %windir%\tracing produced an IASSAM.LOG which is empty (well, a 2-byte BOM). IAS.LOG is empty, as is IASACCT.LOG, IASHLPR.LOG, IASNAP.LOG, IASRAD.LOG, IASRECST.LOG, IASSDO.LOG, and IASSVCS.LOG. Again, to emphasise the first point, client X and client Y are sending identical data, things like RADIUS and EAP TLVs, with identical entries in the server RADIUS logs apart from the datestamps, but after sending the MSCHAP response inside the tunnel client X gets back a success/failure and client Y gets no response. Both clients authenticate successfully to FreeRADIUS, so it's not a problem with Y's MSCHAP implementation, and client X authenticates successfully to NPS so it's not one of the usual problems leading to the discarded-request issue.