Some clients can only authenticate to VPN when connecting as Administrator

Question

I know I'm not setting up VPN connections exactly how Azure recommends, but I'm hoping someone can help me figure this out regardless.

I have two different, separate Azure accounts where this same setup is causing this same problem, so it should be somewhat reproducible. The basic goal is to have a point-to-site VPN connection for Windows 10 clients that can be initiated from the command line. To this end, the connection is pre-configured and installed on the client machines by directly adding the required settings to system phonebook file (C:\ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk).

I've run into an interesting situation where some users can connect just fine, but others can only connect if they try to initiate the connection with Administrator privileges.

The error that these users get is:

Error 798: A certificate could not be found that can be used with this Extensible Application Protocol

This error appears when trying to connect via the network menu in the Windows toolbar, or when trying to connect via either rasphone or rasdial. But there are two interesting things to note:

• These same users were not having this problem when the VPN connection was first installed. At first it was working fine. This problem started after a few days.
• This error does not occur when running either rasphone or rasdial as Administrator. When run as Administrator, the connection is successfully established.

The authentication is, as you can tell, supposed to be done by certificate. Self-signed certificate to be exact. The client certificate is installed in the Current User\Personal certificate store. Because the root certificate is self-signed, it needs to be added as a CA for the client device in order for it to recognize the client certificate as valid. So the root certificate is installed in the Current User\Trusted Root Certification Authorities and Local Machine\Trusted Root Certification Authorities certificate stores.

This same exact setup, with the exact same certificates in the exact same stores, and the exact same phonebook entry, works all the time on some devices, but requires Administrator permission on others. The certificates must be valid, because otherwise the connection would never work. So what could be making the connection fail in a normal user context?

Below is the full phonebook entry in question (with the name of the connection and the gateway address removed).

[Connection Name]
Encoding=1
PBVersion=6
Type=2
AutoLogon=0
UseRasCredentials=1
DialParamsUID=394750015
Guid=C461B777D7AB504AB0AECABC914B7A56
VpnStrategy=7
ExcludedProtocols=0
LcpExtensions=1
DataEncryption=256
SwCompression=1
NegotiateMultilinkAlways=1
SkipDoubleDialDialog=0
DialMode=0
RedialAttempts=3
RedialSeconds=5
IdleDisconnectSeconds=0
RedialOnLinkFailure=1
CallbackMode=0
CustomDialDll=
CustomDialFunc=
CustomRasDialDll=
ForceSecureCompartment=0
DisableIKENameEkuCheck=0
AuthenticateServer=0
ShareMsFilePrint=1
BindMsNetClient=1
SharedPhoneNumbers=0
GlobalDeviceSettings=0
PrerequisiteEntry=
PrerequisitePbk=
ShowMonitorIconInTaskBar=1
CustomAuthKey=13
CustomAuthData=314442430D00000048000000020000004800000017000000000000000000000000000000000000000000000000000000000000000000FE0006000100FD001800
CustomAuthData=97390292EA748C1C312875C0B087FFECAD8EACD100000000
AuthRestrictions=128
IpPrioritizeRemote=0
IpInterfaceMetric=0
IpHeaderCompression=0
IpAddress=0.0.0.0
IpDnsAddress=10.20.0.5
IpDns2Address=10.20.0.6
IpWinsAddress=0.0.0.0
IpWins2Address=0.0.0.0
IpAssign=1
IpNameAssign=2
IpDnsFlags=0
IpNBTFlags=1
TcpWindowSize=0
UseFlags=2
IpSecFlags=0
IpDnsSuffix=
DisableClassBasedDefaultRoute=1
IDI=
IDR=
ImsConfig=0
IdiType=0
IdrType=0
ProvisionType=0
PreSharedKey=
CacheCredentials=0
NumCustomPolicy=0
NumEku=0
UseMachineRootCert=0
Disable_IKEv2_Fragmentation=0
PlumbIKEv2TSAsRoutes=0
NumServers=0
RouteVersion=1
NumRoutes=1
Routes=0100000002000000100000000A0000000000000000000000000000000000000000000000
NumNrptRules=0
AutoTiggerCapable=1
NumAppIds=0
NumClassicAppIds=0
SecurityDescriptor=
ApnInfoProviderId=
ApnInfoUsername=
ApnInfoPassword=
ApnInfoAccessPoint=
ApnInfoAuthentication=1
ApnInfoCompression=0
DeviceComplianceEnabled=0
DeviceComplianceSsoEnabled=0
DeviceComplianceSsoEku=
DeviceComplianceSsoIssuer=
WebAuthEnabled=0
WebAuthClientId=
FlagsSet=0
Options=0
DisableDefaultDnsSuffixes=0
NumTrustedNetworks=0
NumDnsSearchSuffixes=0
PowershellCreatedProfile=0
ProxyFlags=0
ProxySettingsModified=0
ProvisioningAuthority=
AuthTypeOTP=0
GREKeyDefined=0
NumPerAppTrafficFilters=0
AlwaysOnCapable=0
DeviceTunnel=0
PrivateNetwork=0

NETCOMPONENTS=
ms_msclient=1
ms_server=1

MEDIA=rastapi
Port=VPN3-0
Device=WAN Miniport (IKEv2)

DEVICE=vpn
PhoneNumber=MyAzureGatewayAddress.vpn.azure.com
AreaCode=
CountryCode=0
CountryID=0
UseDialingRules=0
Comment=
FriendlyName=
LastSelectedPhone=0
PromoteAlternates=0
TryNextAlternateOnFail=1

And here's what it looks when you open the connection file in the GUI:

Answer 1

Thank you @Gary Nebbett for those pointers on getting debug information. I was having a hard time figuring out exactly how to diagnose that error further. As it turns out, though, by the time I read this, I had already stumbled onto the cause of my problem.

In the end the problem wasn't with the VPN configuration at all, or even with the certificates themselves, but with the way the certificates were installed. I was doing it all with custom software. At the time of asking this question, I thought that was irrelevant- turns out I as wrong.

For anyone interested, you can see more details of the problem and the solution by checking out these two questions:
ServerFault: Some clients can only authenticate to VPN when connecting as Administrator
StackOverflow: X509Certificate2 only works temporarily when added to Current User store as Administrator

Answer 2

@Keith Stein

Although I understand that the issue did not occur previously or when running as admin, please refer to the below suggestions-

Please refer to this article to troubleshoot P2S VPN related issues. It explains how to fix the error 798. Please let me know if this helps.

I also recently came across this issue related to P2S which gives similar error when -ClientRootCert is left blank, it gives out the same error i.e., Error 798: A certificate could not be found that can be used with this Extensible Application Protocol. Could you check if this is in anyway causing this error for you?

If this still does not fix the issue, I would suggest you to reach out to Azure Support to further troubleshoot this issue. Thank you!

Answer 3

Hello @Keith Stein ,

It is difficult to just guess what might be causing this behaviour. It would be helpful to first gather some more information. I would suggest using Event Tracing for Windows (ETW) to trace the providers Microsoft-Windows-RRAS, Microsoft-Windows-EapHost and possibly "IKEEXT Trace Provider". When I use EAP-TLS, the Microsoft-Windows-EapHost provider does give some information about the certificate selection process (which works in my case) - there will hopefully be additional information in the case of a problem. The other two providers just add some "context" to the trace data.

Here is a screenshot of part of my trace data, so that you can see the type of information that might be available:

Gary