Using the Extensible Authentication Protocol (EAP) with client certificates is the recommended best practice for authentication for Windows 10 Always On VPN deployments. EAP, and especially Protected EAP (PEAP), has a lot of settings to configure and it is not uncommon to encounter issues related to some parameters being defined incorrectly. This post covers one of the more common issues related to EAP/PEAP misconfiguration.
Action Needed?
When establishing an Always On VPN user tunnel connection, users may find the connection does not complete automatically, and they are informed that additional action is needed.
Clicking on the VPN connection and then clicking Connect prompts the user with the following message.
“Action needed. Continue connecting? We don’t have enough info to validate the server. You can still connect if you trust this server.”
Common Causes
This message can occur when (EAP) is used and is configured to perform server validation with a restricted set of NPS servers, as shown here.
NPS Server Certificate
The NPS server performing authentication for the connection request must have a certificate that includes a subject name that matches one of the names of the NPS servers defined in the EAP configuration. The certificate must be issued by the organizations private certification authority (CA).
EAP Configuration
Alternatively, the client-side EAP configuration may be incorrect. Although the NPS server may have the correct hostname configured on its certificate, it may not be entered correctly on the client. Ensure the hostname listed in the “Connect to these servers” field matches the subject name or SAN of the NPS server certificate defined in the network policy used for the Always On VPN user tunnel. Look carefully at the syntax when defining multiple NPS servers. Multiple servers are separated by a semi-colon and there are no additional spaces. Missing either one of these critical details will result in connection prompts. Also, ensure that all NPS servers used for authentication (those defined on the VPN server) are included in this list.
Note: Administrators must ensure that all VPN clients have updated their EAP configuration before adding additional NPS servers to the environment. Failure to do so will result in connection prompts.
Security Best Practice
To be clear, the behavior above is not ideal from a security perspective. Validating the NPS server before authenticating is crucial to ensuring the highest level of security and assurance, preventing credential theft from a man-in-the-middle attack. For this reason, it is recommended that users not be given the choice to authorize an NPS server. Authorized NPS servers should be defined by administrators exclusively. This is accomplished by selecting the option “Don’t ask user to authorize new servers or trusted CAs” in the Notifications before connecting drop-down list, and by selecting the option “Don’t prompt user to authorize new servers or trusted certification authorities“.
KpR
/ April 5, 2021Hey Richard
Based on my experience, the client doesn’t read SAN but only the subject name when you performed radius authentication.
I don’t know if it was a bug or something else but I had to change my radius certs
Richard M. Hicks
/ April 6, 2021That’s not been my experience. It’s been a while since I tested though, so it could have changed since then. I’ll do some testing soon and see what I can find.
Richard M. Hicks
/ April 7, 2021You are correct. The client only matches against the subject name field, not the subject alternative name field. I’ve updated the post to reflect that information. Thanks for bringing that to my attention!
Some Guy
/ April 6, 2021Careful! The screenshots show that that EAP dialog box is expecting regular expressions for the certificate name. In regular expressions, the “dot” character is a wildcard meaning “any character”. Since you didn’t escape your literal dots, an attacker could go out and register lab4richardhicks.net and make a legit VPN server with a legit certificate that your client will happily accept.
Richard M. Hicks
/ April 6, 2021Good observation! I think using FQDNs here is sufficient for most deployments, to be honest. However, for those with the highest security requirements, it might require some additional configuration here. I’ll investigate for sure!
Yves Distefano
/ May 17, 2021Hello Richard,
Thanks for all your posts it really helped us setting multiple RAS servers for our enterprise. We are approx 1000 employees splitted in 3 sites and 2 domains. Lately we had a random issue with one of our RAS where the IKEEXT service simply crashes and creates double “ports” consumption. Let’s say we have approx 240 users on that site, we have 490 ports configured, services crashes and we run out of ports available. The only workaround we have so far is a server reboot. The problem is that this particular business unit has to be 24/7. Seems to me we got no choice to schedule a reboot, we plan also on setting SCOM alerting on it when we reach a certain threshold.
I’ve read an old post where the situation is the same and you mention two settings to look after:
Security Association expiration time (minutes)
Security Association data size limit (MB)
I would like to know which setting will have the better impact on our issue and I would like to know if you had time to develop the PowerShell script to manage orphaned sessions too
Any help would is appreciated, thank you
Richard M. Hicks
/ May 20, 2021I think Microsoft is aware of this issue and is working on a fix. Hopefully, they’ll release something soon. The SA settings I recommend are 28,800 (8 hours) and 10,2400 (1GB) for remote access VPN. You can find the script to remove stale connections on the VPN server here: https://github.com/richardhicks/aovpn/blob/master/Remove-VpnConnections.ps1.
Paul
/ December 1, 2021Richard, thanks to information on your helpful website, I have implemented Always On VPN using SSTP and PEAP (user certificates). But when the user connects in, they get the message “you might not have permissions to use this network resource”. Obvious I suppose if the client is authenticating via certificates and not their account details, but -and this is a profound lack of understanding on my part- how do other people get round this?
Richard M. Hicks
/ December 2, 2021If certificate authentication is configured correctly it will work just like using usernames/passwords. Where specifically are you seeing this warning?
Paul
/ December 2, 2021Richard,when the user successfully connects in, they get that message when trying to access any network resource, even using an IP address. The RRAS server shows them connected with their correct UPN. They haven’t specified a password and the option to “use current login” isn’t there with “smart card or certificate”. When changed to mschapv2 it all works. I think I am missing something conceptually about authenticating with certificates
Richard M. Hicks
/ December 2, 2021Hi Paul. Have a look at this point and let me know if the suggested fix also works for you.
https://directaccess.richardhicks.com/2021/09/20/always-on-vpn-short-name-access-failure/
Thanks!
Paul
/ December 3, 2021Thanks Richard: UseRasCredentials=0 does fix the problem, but it turns out I made a silly mistake. I had modified the template VPN in Windows to use certificates instead of MsChapV2 and updated the EAP field in Intune without changing the Authentication Method from Derived Credential to Certificates. Now Intune is asking for a client authentication certificate but why? The VPN connects perfectly well using a user certificate issued by AD. Do I really need to import this from AD into Intune? Thanks for helping a confused person!
Richard M. Hicks
/ December 3, 2021All you have to do is enable certificate authentication in Intune. You don’t have to explicitly state which certificate you are using. I’m not sure what that option is there anyway, to be honest. 🙂
Bo Christiansen
/ January 3, 2022Richard, first of all thanks a lot for helping me set up a good user-tunnel VPN solution. Problem is, that I got one very weird and yet undescribed issue, when using the WHfB (key-trust) for storing the certificate. This allows logon using the certificate in TPM/WHfB using smartcard mode, and it really works fine, when connecting manually. But for auto connect it does not work. It just hangs at action required. The fun fact is that certificates retrieved from WHfB does not prompt for any PIN, when using the RAS client. Feels like a small thing, but I have hit dead-end, as I have no logs telling me, what is halting the process.
Richard M. Hicks
/ January 4, 2022Not sure what’s up there, to be honest. I’ve not done any Always On VPN deployments where WHfB was used. Unfortunately, I don’t have any experience to share with you here. :/
Bo Christiansen
/ January 4, 2022Thanks anyway – I just skipped the Always on part and use the .pbk file for now. You should do an article about certificate attestation, so people start using TPM functionality for preventing export of the private keys.
Richard M. Hicks
/ January 4, 2022I actually wrote something a while back about ensuring certificates are configured to use TPM.
https://directaccess.richardhicks.com/2018/02/12/directaccess-and-always-on-vpn-with-trusted-platform-module-tpm-certificates/
I didn’t go into attestation specifically though. That’s obviously a lot more complex. 🙂
Thomas Gusset
/ February 15, 2022From an administrative perspective, it would be desirable not to explicitly list the RADIUS servers in the VPN profile, as one has to adjust the profile if one wants to use other RADIUS servers.
How is this to be evaluated from a security perspective if one only sets the “trusted root certification authority” to the internal CA and does not tick the option “connect to these servers”?
Richard M. Hicks
/ February 15, 2022You could certainly do that. It would only require the NPS server to supply a valid certificate from that trusted CA. The client would accept it from any NPS in that scenario. Alternatively, you could use a DNS alias that resolves to the IP addresses of all your NPS server. You would then need to include that name on the certificate as the primary subject name, however (not just a SAN entry).
Matt
/ January 4, 2023Seen this issue today on a Windows 11 vm I’ve been testing. I checked and the “Don’t ask settings” are present. I then noticed that my Intune deployment did not set the authentication type correctly. It set it as EAP-MSCHAP v2 instead of PEAP. It sets it correct only Windows 10.
Richard M. Hicks
/ January 4, 2023Yes, I see that behavior quite frequently as well. It’s undoubtedly a bug because the same configuration profile works flawlessly on Windows 10. :/