A while back I wrote about troubleshooting and resolving Windows 10 Always On VPN errors 691 and 812. There are numerous issues that can result in these errors, and in that post I pointed out they can be caused by disabling TLS 1.0 on Windows Servers prior to Windows Server 2016. However, administrators may encounter a another scenario in which they receive errors 691 or 812 which is related to Active Directory user account configuration.
SSTP and Error 691
When attempting to establish an Always On VPN connection using the Secure Socket Tunneling Protocol (SSTP), administrators may encounter the following error message.
“The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server.”
In addition, an error 691 with event ID 20227 from the RasClient source can be found in the Application event log on the client.
“The user <domain\user> dialed a connection named which has failed. The error code returned on failure is 691.”
IKEv2 and Error 812
When attempting to establish an Always On VPN connection using Internet Key Exchange version 2 (IKEv2), administrators may encounter the following error message.
“The connection as prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.”
In addition, an error 812 with event ID 20227 from the RasClient source can be found in the Application event log on the client.
NPS Event Log
On the NPS server the administrator will find an entry in the application event log with event ID 6273 from the Microsoft Windows security auditing source and the Network Policy Server task category indicating the network policy server denied access to the user. Looking closely at this event log message shows Reason Code 65 and the following reason.
“The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access to the user. To change the Network Access permission setting to either Allow access or Control access through NPS Network Policy, obtain the properties of the user account in Active Directory Users and Computers, click the Dial-in tab, and change Network Access Permission.”
Resolution
There are two options available to address this issue. The user account in Active Directory can be configured to grant access or allow access to be controlled via NPS network policy, or the NPS network policy can be configured to ignore user account dial-in properties.
User Account
Follow the steps below to change Network Access Permission on an individual user’s Active Directory account.
- Open the Active Directory User and Computers (ADUC) management console (dsa.msc) and double-click the user’s account.
- Select the Dial-in tab.
- In the Network Access Permission section select the option to Allow access or Control access through NPS Network Policy.
Note: If you do not see the dial-in tab, open the ADUC console on a domain controller. The dial-in tab is not displayed when using the Remote Server Administration Tools (RSAT) for Windows clients.
Network Policy
Follow the steps below to configure NPS network policy to ignore user account dial-in properties.
- Open the NPS management console (nps.msc) and double-click the Always On VPN network policy.
- In the Access Permission section select Ignore user account dial-in properties.
- Click Ok to save the changes.
SM
/ May 16, 2024We’re facing an issue with AOVPN certificates and conditional access, but only on Windows 11 devices. We use Intune to deploy user certificates for authentication, but when users try to connect to AOVPN, they get the error: “The connection was prevented because of the policy configured on your RAS/VPN server.” The error code returned on the Ras Client is 812.
Upon checking the NPS server, I see reason code 265 with the message: “The certificate chain was issued by an authority that is not trusted.” However, the issue seems to resolve temporarily if I delete the user CRL cache and restart the device.
This problem only occurs on Windows 11 devices and affects different users. The affected users can connect with a different device without issues. This problem happens sporadically—sometimes a couple of times a week, and other times just once a month. Additionally, the conditional access is set to 8 hours, and the devices that have the issue seem to work again after the 8-hour period.
I’ve verified that the certificate is trusted on the DC/VPN server/NPS.
Any insights or suggestions would be greatly appreciated.
Richard M. Hicks
/ May 18, 2024That’s quite unusual. If it works at all you must have the correct certificate deployed to your enterprise NtAuth store. However, it might be worth checking just to be sure. Also, make sure that you’ve disabled revocation checking on the NPS server. The Azure CA certificates don’t contain revocation information.
Of course, I would expect if either/both of those configurations were wrong it would affect everyone. I’m not sure why this would only affect Windows 11. :/