SuriyaSujithkumar-5060 avatar image
0 Votes"
SuriyaSujithkumar-5060 asked AnshulKumarMINDTREELIMITED-5501 commented

Conditional Access seems to works without ingesting **IgnoreNoRevocationCheck** on RRAS Or NPS.

Conditional Access seems to works without ingesting IgnoreNoRevocationCheck on RRAS Or NPS.

As per the below article, implemented condition access in our environment as an additional layer of security before connecting to AOVPN.

Here is an overview about our environment.

8 - RRAS --> Radius Authentication (2 NPS)
Clients - Windows 10 20H2

Devices are managed using Intune and client authentication (user certificate) from our PKI via NDES.

Below are the included/excluded steps during the implementation.

  1. Due to security recommendation, skipped Step 7.1 (ignoring certification revocation on RRAS and NPS).

  2. Skipped adding the below XML as well from Step 7.5 Procedure 3

    <TLSExtensions xmlns=""><FilteringInfo xmlns=""><EKUMapping><EKUMap><EKUName>AAD Conditional Access</EKUName><EKUOID></EKUOID></EKUMap></EKUMapping><ClientAuthEKUList Enabled="true"><EKUMapInList><EKUName>AAD Conditional Access</EKUName></EKUMapInList></ClientAuthEKUList></FilteringInfo></TLSExtensions>

  3. Added "IgnoreNoRevocationCheck" under: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 & 25" on our managed clients

  4. Steps (7.2 - 7.4) implemented with no difference to the above article.

Result: it is working after following the above steps but it would be much appreciated to know what could be a potential impact by ignoring revocation check from clients end. (1 possible known would be, the clients would fail to do CRL check). what are other security risks involved.

· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Hi, if the posted answer resolves your question, please mark it as the answer by clicking the check mark. Doing so helps others find answers to their questions.

0 Votes 0 ·

1 Answer

vipulsparsh-MSFT avatar image
0 Votes"
vipulsparsh-MSFT answered vipulsparsh-MSFT commented

@SuriyaSujithkumar-5060 Thanks for reaching out. I am sure you are aware that for your scenario the CRL will fail as Azure AD does not publish any CRL for short lived certificates.

Having said that, a normal CRL check is done to determine if the current certificate is revoked or not or is it still valid to use in the handshake process.
The security risk behind is about the Certificate private key no longer a secret thing, in which any attacker who got hold of the private key can actually fake a transaction being the actual service/account that certificate was for.

Admins mostly revoke the cert when they are sure that the private keys are compromised.

Other scenarios include, when a certificate is no longer needed or when the company decides to use a different certificate than they revoke the existing certificate.
A CRL check in above scenarios would confirm the users/machines are connecting to a valid entity which can be verified using CRL so that they don't fall prey for accessing malicious sites/services.

· 4
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

That's obsoletely correct even i thought the same as well and thanks for your answer.

What if we do the same on the NPS & RRAS mentioned in the step 1, assume, whenever a client is sending a connection request to RRAS, it is then forwarded to NPS and it evaluates the request based on the policy defined for the corresponding client scope, in this transaction NPS also verifies the cert about (expiry/revocation), obviously CA cert is going to fail as it is a short-time lived cert, how can we approach this situation without having a need to modify the registry?

if we implement the step1, then no matter what client request for VPN access, NPS is simply going to ignore because we are making changes to the registry but not to the NPS policy.

neither ways modifying the registry is not recommended in my opinion perhaps how you see this in your way.

0 Votes 0 ·
vipulsparsh-MSFT avatar image vipulsparsh-MSFT SuriyaSujithkumar-5060 ·

@SuriyaSujithkumar-5060 I understand your concern, but as long as you are depended on the certificates issued by Azure AD for auth, you will have to implement this. If you manage your on prem CA and are using that for auth then you can choose not to perform this step. Although, the server does not do this for every service on the server but just for the radius service so it will still do the CRL check for any other things.

Also if your user/device is compromised to that extent of revoked certificate that you are thinking then I believe we have other things to take care of than just a VPN access.
many organizations are doing this method, can you help me understand one scenario which you think an adversary can use if the CRL check fails and can gain , as that point that will be already be impersonating the user for many things and not just VPN access.

Another check I can think of which I dont think anybody is currently doing, any client which needs access to your VPN must have a certificate issued from either Azure AD or your on prem AD, the Azure AD context will be secure anyway as we use device compliance followed by MFA to provide access, where you can ignore the CRL check as it is valid just for 60 mins.
For other on prem scenario, you can run a manual/scheduled task to check of your CA CRL list of revoked certificates for users/devices and then corresponding check for any VPN successful access against that user/device. May be a PowerShell script or something.

0 Votes 0 ·

Today I simply tried connecting to VPN from one of our BYOD Intune managed windows 10 devices with out the registry key "IgnoreNoRevocationCheck" and it seems to work. the same I tried a couple of times last week, it wasn't working unless until you have the registry key "IgnoreNoRevocationCheck" placed on the client.

Please check out this link and compare the steps that I have implemented in our environment;

    1. Step 7.1 - Completely ignored on both servers (NPS & RRAS) and client devices as well.

    2. Step 7.2 - Configured as per the article

    3. Step 7.3 - Configured as per the article

    4. Step 7.4 - Imported the Microsoft VPN Root certificate only on our RRAS servers but NOT on (NPS or PKI)

    5. Step 7.5 - Ignored adding XML *"</AcceptServerName></EapType>*" in our EAP configuration VPN profile but we have enabled conditional access.

I I suspect either client or NPS is actually doing a check on every connection attempt for CRL but somehow not taking any action, I guess.

please share your thoughts here.

0 Votes 0 ·
Show more comments