When deploying Windows 10 Always On VPN using Protected Extensible Authentication Protocol (PEAP) with client authentication certificates, the administrator may encounter a scenario in which the user can establish a VPN connection without issue, but when accessing internal resources they are prompted for credentials and receive the following error message.
“The system cannot contact a domain controller to service the authentication request. Please try again later.”
Resolution
This can occur if one or more domain controllers in the enterprise have expired or missing domain controller authentication certificates. To ensure seamless single sign-on to internal resources, ensure that all domain controllers have a certificate issued by the internal certification authority (CA) that includes the Server Authentication (1.3.6.1.5.5.7.3.1), Client Authentication (1.3.6.1.5.5.7.3.2), KDC Authentication (1.3.6.1.5.2.3.5), and Smart Card Logon (1.3.6.1.4.1.311.20.2.2) Enhanced Key Usage (EKU). Administrators can duplicate the Kerberos Authentication template for this purpose.
Additional Information
Windows 10 Always On VPN Certificate Requirements for IKEv2
Windows 10 Always On VPN Hands-On Training
Patrick
/ May 20, 2019Hello,
thank you very much for this post
Andy Chips
/ June 5, 2019We started to get this exact error message on all our VPN clients after I rebuilt our Enterprise CA server. Even though I followed best practice it seems that something was amiss after this.
If the client used the FQDN to access a network resource rather than just the hostname it worked fine, but it was impractical to change this company-wide in a short space of time.
So, I based on your article I started looking at the DCs. They all had suitable certificates and supported the required EKUs. All very confusing. Bereft of other ideas I ended up deleting the Personal LocalMachine certificates that had been issued prior to the CA rebuild and re-enrolled them by running a GPUPDATE.
After doing this the AlwaysOn VPN clients started working seamlessly again. Thanks for the pointer, Richard.
Blaine
/ June 18, 2020Having the same exact issue. The FQDN works fine, but short name does not. I can ping the short name
Steve
/ August 5, 2020I am having the same issue. Added Certs for all DC’s. Now FQDN works but cannot resolve short names. Removing and re-enrolling the user certificate did not fox it for me.
Richard M. Hicks
/ August 6, 2020Can you try setting the value of UseRasCredentials to “0” in the VPN profile entry in rasphone.bpk and tell me what happens? Curious to know if that changes anything.
Steve
/ August 12, 2020Setting the value of UseRasCredentials to “0” in the VPN profile entry in rasphone.bpk does fix the issue. Now how do I make that change in the xml or ps1 to deploy the change when the profile is created?
Richard M. Hicks
/ August 13, 2020Great to hear! Unfortunately you can’t define this setting in ProfileXML. You’ll have to make this change directly in rasphone.pbk after you’ve deployed the profile. You can find a PowerShell script to do that here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.
.\Update-Rasphone.ps1 -ProfileName [name of your VPN connection] -UseRasCredentials False
Steve
/ September 8, 2020Here is what I did as an update for anyone else. I edited Richard’s Update-Rasphone.ps1 script to only change the UseRasCredentials setting to False. I then put this code at the end of my VPN_Profile.ps1 script. It uses the same $ProfileName variable as the install script and automatically changes the setting every time the profile is installed.
Richard M. Hicks
/ September 9, 2020That should work!
Ian Miller
/ December 6, 2019We have a similar problem (authentication to members servers failing) which I’ve traced to the same root cause. This is useful to know, but the fix is unrealistic for us as there are existing certificates from another CA on our Domain controllers which would be very tricky to change.
Is there a client setting where we can use the internal CA issued client certificates only for the VPN, and then just fall back to normal password based Kerberos for windows file shares and websites?
Richard M. Hicks
/ December 9, 2019It might be possible to configure the VPN to use alternative credentials, but it’s not something I’ve ever tried.
Stuart Townsend
/ April 8, 2020Hi Richard, what is the reasoning behind the requirement for the domain controller authentication? I had this issue and it fixed it for me, so thanks for that. However, I cannot find any mention of this requirement in any Microsoft documentation. I have since removed the certificate from the DC just as a test and I now don’t encounter the problem.
Thanks,
Stuart
Richard M. Hicks
/ April 8, 2020It’s required to map the user of the certificate to an Active Directory account. Without it your users should get prompted for authentication because the resource won’t know who they are.
Christopher Sharp
/ April 21, 2020This can also occur if the Domain Controller’s certificate cannot be authenticated for any other reason, such as the CRL being inaccessible. You should check your client computer’s System event log for errors sourced from LSA to aid in troubleshooting the cause, but one possible cause is the CRL not being available to VPN clients or not being published correctly.
Blaine
/ June 18, 2020How can I tell if my PC is failing a CRL check?
Richard M. Hicks
/ June 18, 2020Enabling the CAPI2 operational event log on the client and you should find that information there. 🙂
Jorge Palacios
/ August 27, 2020Hi Richard, How do you assign an active directory account to the user certificate?
Richard M. Hicks
/ August 28, 2020When you create the user authentication certificate template on the issuing CA you will define the subject name as the Common Name, and the Subject Alternative Name as the User Principal Name.
Ajni
/ December 10, 2020Had this exact problem yesterday, in my case the CRL was not reachable from the client. Thanks!
Richard M. Hicks
/ December 17, 2020CRLs are often overlooked! 🙂
Hasan Reza
/ February 21, 2021Dear Rick, If it was not for your article I would be banging my head , Thank you , u are true soul saver
Richard M. Hicks
/ February 24, 2021Thanks!
rommel kast
/ February 23, 2021Richard thank you, you are a life saver. Had this exact problem.
Richard M. Hicks
/ February 24, 2021🙂
Stephane
/ March 22, 2023Hi Richard
Thanks a lot for you blogpost. We ran into the exact same issue. Problem was that the DC could not check CRL. But what I don’t understand in detail: If the client was in the internal subnet it could access internal resources so the client seems to authenticate with username / password with kerberos. Only over always on VPN the client uses certificates for kerberos authentication. How does it come?
Thanks for your very helpful blogposts.
Richard M. Hicks
/ March 22, 2023Your user can authenticate on-premises because they aren’t using their certificate for credentials. They are providing a username/password and using Kerberos natively instead.