Integrating Microsoft Azure Conditional Access with Windows 10 Always On VPN has several important benefits. The most important is that it allows administrators to improve their security posture by enforcing access polices that can be dynamically applied. For example, requiring multifactor authentication (MFA) for privileged users (e.g., administrators) or sign-ins that appear to be risky, the type of device they are connecting with, the health of the endpoint, and much more.
Authentication Failure
When configuring Always On VPN to support Azure Conditional Access, administrators may expeirence a failed authentication during preliminary testing. Specifically, an event ID 20227 from the RasClient source may be encountered with the following error message.
“The user <username> dialed a connection named <connection name> which has failed. The error code returned on failure is 812.”
Looking at the event logs on the Network Policy Server (NPS) server reveals an event ID 6273 from the Microsoft Windows security auditing source with Reason Code 258 and the following Reason.
“The revocation function was unable to check revocation for the certificate.”
Root Cause
When Azure Conditional Access is configured for Always On VPN, a short-lived certificate (1 hour lifetime) is provisioned by Azure. This certificate does not include revocation information because, by design, a short-lived certificate does not need to be revoked. However, by default NPS always checks revocation when client authentication certificates are used for authentication. Since the certificate does not include this information, certificate revocation fails.
Resolution
The way to resolve this issue is to disable certificate revocation checking for Protected Extensible Authentication Protocol (PEAP) authentication requests. To do this, open an elevated PowerShell window on the NPS server and run the following command.
New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\’ -Name IgnoreNoRevocationCheck -PropertyType DWORD -Value 1 -Force
Once complete, restart the NPS server for the changes to take effect.
Additional Information
Windows 10 Always On VPN Network Policy Server (NPS) Load Balancing
Windows 10 Always On VPN Network Policy Server (NPS) Server 2019 Bug
Ed Morgan
/ August 31, 2021Hi Richard, isn’t disabling revocation checks a bit of a security breach? If we’re using device tunnels and want to revoke the device certificate, how would we do that?
Richard M. Hicks
/ August 31, 2021Normally, yes! However, in this specific instance, it is recommended (and in fact required) because the certificate is only valid for one hour. We have to disable it because the certificate is issued without any revocation URL, which would cause the NPS authentication process to fail.
To be clear, disabling revocation checking should only be done in this specific scenario where short-lived certificates are issued by Azure Conditional Access. Otherwise, certificate revocation should absolutely not be disabled.
aprovelpd
/ November 5, 2021Hi Richard, thanks for your blog! I have as reason code 300.
-> “No credentials are available in the security package”
Is this a user cert issue?
Richard M. Hicks
/ November 5, 2021Quite possibly. Make sure the certificate is installed on the NPS server correctly and that it has a private key. Make sure it is valid (not expired) and not revoked. Also, ensure the subject name on the certificate matches the hostname of the server.
Bo Christensen
/ February 11, 2022Richard, can you tell me if it is possible to use a different principalname on the Conditional Access VPN user certificate? When I try to enable it – it clearly shows, that the principalname on the user certificate is not the on-premises UPN, but the principalname used in Azure AD. My RRAS/NPS is unable to determine the user based on this, as I use simply the e-mail attribute. Thanks a lot for excellent advice.
Richard M. Hicks
/ February 11, 2022I think so, yes. I’m not an Azure AD expert though, so I’m not certain. Have a look at this post and let me know if it helps. 🙂
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/howto-troubleshoot-upn-changes
Gilles Villeneuve
/ February 23, 2022Hi Richard,
Thanks for always providing such good content.
I have one question regarding conditional access and the Always On VPN.
I have the challenge to make sure if the device is a compliant device then it can access the alwayson vpn without MFA, however, if it is a contractor which we do not manage, he/she should be challenged for MFA.
In this scenario, the contrator is using a personal device which we do not manage. I couldn’t find a way to make it work or any idea.
Any suggestion for this particular case?
Thank you,
Richard M. Hicks
/ March 1, 2022You might be able to do something with NPS policies. Specifically, you could probably create a connection request policy to identify users who are contractors and forward their authentication request to another NPS or RADIUS server that requires MFA.
discombob
/ March 18, 2022AlwaysOn User Tunnels were working fine until enabling conditional access for our environment by inserting the OID into the Intune deployment EAP-XML. Performing an MFA and getting connected is actually successful, but the short-lived certificate given to the client seems to be blocking our ability to access server shares. They time-out with no error and nothing in any Event logs on anything in path (DC, file server, client).
If I remove the “Microsoft VPN root CA gen 1” applied to *Session from the credential manager on the client test workstation, it can browse the server shares again.
Any ideas what could maybe be causing that and why our environment doesn’t seem to trust the cert? It is verified in the trusted root of the local computer stores on all servers in the environment after following this:
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-deploy-cond-access-root-cert-to-on-premise-ad
It’s a hybrid AAD joined environment syncing with AD connect, with proper DNS suffix and routing to the resources in the VPN profile, whose traffic goes through the RAS (tracert) and with user tunnel auth certificates issued by our internal CA.
Richard M. Hicks
/ March 18, 2022Did you publish the Azure VPN certificate to the NTAuth store in your on-premises Active Directory?
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-deploy-cond-access-root-cert-to-on-premise-ad
discombob
/ March 18, 2022Yessir… I mentioned it above, and I can see it in there on each of the servers, which is why this is bugging me so much 😣
Is that about usually the end of what you have to do?
Trying to hunt down whatever it is in this environment, but with nothing in the event logs I might have to open a Microsoft support ticket.
Richard M. Hicks
/ March 19, 2022You mentioned the Azure VPN root certificate was in the trusted root CA store on your machines. However, it also needs to be published in Active Directory in the NTAuth store, specifically.
certutil.exe -dspublish -f auzrevpnrootcertificate.cer RootCA
You should see the Azure VPN certificate on your domain-joined systems by running the following command.
certutil.exe -store -enterprise NTAuth
bueschu
/ March 21, 2022Is it possible to use AoV and conditional access without Intune. I mean to use Hybrid-Joined devices with a user tunnel and vpn-user certificate from a local enterprise CA for authentication.
Richard M. Hicks
/ March 23, 2022Absolutely. The users obviously have to be in Azure AD (sync’d from on-premises Active Directory) but you can deploy the Always On VPN client configuration profile and enable Azure conditional access without using Intune, for sure.
BaldEagle
/ April 5, 2022I conditional access working. I get the short lived certs. My NPS is filtering only the Azure cert OID. I see often the 1 hour cert is expired but we can disconnect and reconnect for up to 12 hours. Note; my CA rules in Azure are set to 12 hour sign-in frequency. My question is what setting did I miss that allows am expired 1 hour cert to be used?
Richard M. Hicks
/ April 5, 2022I’m not sure, to be honest. It sounds like perhaps the authentication is being cached somehow, but I’m not sure. What happens if you restart the NPS service? Can you still connect with an expired certificate then?
BaldEagle
/ April 5, 2022Yes I can stil conenct. Of course if I remove the cert I cannot and I wont get a new one until the 12 hour mark from my CA policy. So for sure I’m using that short lived cert only to authenticate. I did notice the cert does show an updated expiring time every so often that I look. Maybe what is caching is my view of the cert time expiration and it is really is getting a new one everytime I reconect after the 1 hour, even if CA policy is not required. Perhaps to be 100% certain there is a event log I can see what exact cert was used. I know I said I’m already filtering OID but I would like to verify maybe in the logs it shows me the VPN cert that was allowde and the expiriy time there. ? My concern is patching any unknown holes in the security or at least understanding them.
Richard M. Hicks
/ April 6, 2022That sounds plausible. If the certificate lives only for one hour, Azure must update it if the session is still active, at least for the period of time you defined for refresh.
BaldEagle
/ April 5, 2022I enabled the CAPI2 logs and can see the VPN cert used. I can see the not beofre or after date time from the Root Authroity but cannot get a read on if the short lived cert was expired or not when used. I relly want to ensure the short lived cert cant be used within a 12 hour period in my setup. We put the Azure CA policy of 12 hours out there so users would not get a MFA prommpt in the middle of the night but maybe this opens a risk. I could make this 1 hour to be safe if I cannot confim an expired short lived cert cannot be used.
Richard M. Hicks
/ April 6, 2022You might have to do some testing with that and see what the experience is like.
Si
/ March 2, 2023Great content as always, Richard. I was wondering, our AOVPN Azure conditional access root certificate expires in a few weeks and I understand that as soon as we renew, we need to perform some commands in AD and install the new cert on our RAS / NPS servers globally. What I’m not clear on is if the cert needs to be pushed out to the clients trusted store on their laptops as well. If so, that puts us in a chicken & egg situation as remote users will not be able to connect to AD over VPN to get the updated cert installed once we renew it?
Richard M. Hicks
/ March 2, 2023The only thing you need to do is publish the new VPN root certificate to Active Directory using the following commands:
certutil.exe -dspublish -f .\VpnBase64Cert.cer RootCA
certutil.exe -dspublish -f .\VpnBase64Cert.cer NTAuthCA
That will place the new certificate in the trusted root certificates store which replicates to all domain-joined devices. It also places the new certificate in the NTAuth store which is required for authentication.
For native Azure AD joined devices you might need to push the new Azure CA certificate to your endpoints using Intune.
Hope that helps!
Si
/ March 9, 2023Thanks for the response, Richard. Just to clarify, does the new Azure CA root certificate need to be in the client’s trusted root store or just the authenticating servers (RAS / NPS / DC servers)? I did some testing and removed the existing Azure CA root cert from my trusted root store on my laptop and was still able to connect OK. My worry is that we have a lot of full time remote users with AD joined machines, and if they are unable to connect to AOVPN after we renew the cert, then they will not be able to get to AD in order to get the new one.
Richard M. Hicks
/ March 9, 2023Yes, the client would need to trust the Azure CA root certificate. You’ll need to publish it in the RootCA store in Active Directory for domain-joined devices. For native Azure AD joined devices you’ll need to publish the root certificate using Intune.