Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Always On VPN Clients Prompted for Authentication when Accessing Internal ResourcesWhen 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.”

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

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.

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Additional Information

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Hands-On Training

 

Leave a comment

28 Comments

  1. Hello,

    thank you very much for this post

    Reply
  2. We 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.

    Reply
    • Blaine

       /  June 18, 2020

      Having the same exact issue. The FQDN works fine, but short name does not. I can ping the short name

      Reply
    • Steve

       /  August 5, 2020

      I 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.

      Reply
      • Can 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, 2020

        Setting 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?

      • Great 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, 2020

        Here 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.

      • That should work!

  3. Ian Miller

     /  December 6, 2019

    We 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?

    Reply
  4. Stuart Townsend

     /  April 8, 2020

    Hi 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

    Reply
    • It’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.

      Reply
  5. Christopher Sharp

     /  April 21, 2020

    This 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.

    Reply
    • Blaine

       /  June 18, 2020

      How can I tell if my PC is failing a CRL check?

      Reply
      • Enabling the CAPI2 operational event log on the client and you should find that information there. 🙂

  6. Jorge Palacios

     /  August 27, 2020

    Hi Richard, How do you assign an active directory account to the user certificate?

    Reply
    • When 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.

      Reply
  7. Ajni

     /  December 10, 2020

    Had this exact problem yesterday, in my case the CRL was not reachable from the client. Thanks!

    Reply
  8. Hasan Reza

     /  February 21, 2021

    Dear Rick, If it was not for your article I would be banging my head , Thank you , u are true soul saver

    Reply
  9. rommel kast

     /  February 23, 2021

    Richard thank you, you are a life saver. Had this exact problem.

    Reply
  10. Stephane

     /  March 22, 2023

    Hi 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.

    Reply
    • Your 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.

      Reply
  1. Always On VPN Users Prompted for Certificate | Richard M. Hicks Consulting, Inc.
  2. Certificate-Based Authentication Changes and Always On VPN | Richard M. Hicks Consulting, Inc.

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading