I'm troubleshooting Windows RRAS/PPTP authentication through Windows NPS, which proxies requests to FreeRADIUS 3.x and privacyIDEA using MS-CHAPv2. With the native Windows 10/11 VPN client, an incorrect first login causes Windows to display another credential prompt in the same connection dialog. Even when the user then enters the correct credentials, the second attempt is rejected. Canceling the prompt and starting a completely new VPN connection works normally.
It appears that RRAS/NPS and the Windows client reuse the original MS-CHAPv2 challenge during the retry, while FreeRADIUS or privacyIDEA has already consumed or invalidated the authentication state for that attempt. Setting the client-side MaxDenials value to 1 is not usable because Windows performs an initial unauthenticated or cached probe and the normal login dialog then fails.
What is the correct way to configure FreeRADIUS, rlm_privacyidea, or the NPS proxy so a failed MS-CHAPv2 attempt returns MS-CHAP-Error with R=0 (retry not allowed), causing RRAS and Windows to terminate the PPP session instead of prompting within the same session? Is there a reliable unlang rule in Post-Auth-Type REJECT, or an NPS Remote RADIUS Server Group setting, that can rewrite or preserve this behavior through the proxy?
3 Answers
Also verify the credential requirements on the directory side. MS-CHAPv2 generally needs access to an appropriate password representation; disabling reversible encryption for stored domain passwords can cause authentication failures in some designs. This is worth checking separately from the retry behavior, especially if the backend is validating against domain credentials rather than only a local privacyIDEA factor.
First check the RADIUS authentication-attempt or retry counter on the Windows side. If it allows another try inside the same PPP session, Windows can resend credentials with the original MS-CHAPv2 challenge, which may no longer be valid for the privacyIDEA transaction. A fresh connection creates a new challenge and explains why the next attempt succeeds.
That said, rewriting MS-CHAP-Error in FreeRADIUS may not be enough if NPS or RRAS replaces, consumes, or ignores the attribute while proxying. Capture the packets on both sides of NPS and compare the Access-Reject responses to verify whether R=0 survives the proxy.
Even if you get the attribute rewrite working, PPTP and MS-CHAPv2 are legacy technologies with significant security drawbacks. If the client requirements allow it, moving to IKEv2/IPsec, SSTP, OpenVPN, or WireGuard is a better long-term fix. For the immediate issue, disabling in-session retries or forcing a new PPP session is safer than allowing Windows to reuse a consumed challenge.
I ran into this before and initially blamed the retry handling. Checking the password storage and MS-CHAPv2 prerequisites is important, because a backend that cannot perform the required challenge-response validation will reject both the first and second prompts.