Some clients can only authenticate to VPN when connecting as Administrator

Question

I'm trying to set up users to connect to our Azure-hosted network over a VPN. All client machines are running Windows 10. The connection is 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 Authentication 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

It turns out the problem wasn't with the VPN configuration at all, or even with the certificates themselves, but with the way the certificates were installed.

My problem had a lot of parts, so I tried to leave out "irrelevant" information from my question. One of these pieces of information was that I was doing this entire VPN installation programmatically, using custom software I'd developed.

It seems that this problem was caused by the fact that my program installed the client certificate while running as Administrator. When I tried installing the client certificate from a program that was running in a normal user context (non-admin), this problem no longer occurred.

(For more details on the programmatic certificate installation, I made this post on StackOverflow: X509Certificate2 only works temporarily when added to Current User store as Administrator)

As for the "it worked on some devices" part of the question, I was confused by two factors:

• Somehow, installing the certificate as Administrator allows it to work- but only until the computer reboots.
• I had fiddled with some computers in trying to debug this and had manually installed the certificate on some of them.

So computers where I ran the automatic installer would "work" until rebooted. And computers where I happened to install the certificate manually would work indefinitely until I tried running the installer again, at which point they would fall back into the former category.

I didn't know any of this at the time, so it just seemed like "some of them work, some of them don't".