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

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

  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
  1. Always On VPN Users Prompted for Certificate | Richard M. Hicks Consulting, Inc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: