Windows 10 AlwaysOn Conditional Access Connection Fix – Part 2

Standard

The last couple of months I worked together with Microsoft on protecting the Windows 10 AlwaysOn VPN connection with AzureAD Conditional Access. As I’ve explained in this blogpost I found a strange issue where a user was able to connect without having being compliant to the Conditional Access request. I described that in this blogpost. After publishing that blogpost Microsoft came back to me that even that configuration is not the ‘total’ solution. The reason is that the VPN backend (RAS or NPS) should enforce the use of the AzureAD Conditional Access certificate. In this blogpost I will explain the steps needed to get this configured.

The first step in this process is to disable CRL checking on NPS. The AzureAD Conditional Access certificates does not have CRLs within the certificate. If you don’t disable the CRL check you will not be able to connect anymore since NPS requires to check if the certificate is not revoked. NPS does this by checking the CRL of the certifcate. You can disable CRL checking on your NPS server by adding the follow registry key:

  1. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13
  2. Click Edit > New and select DWORD (32-bit) Value and type IgnoreNoRevocationCheck
  3. Double-click IgnoreNoRevocationCheck and set the Value data to 1
  4. Click OK and reboot the server. (Restarting the RRAS and NPS services will not be enough)

Next step is to configure NPS to enforce the use of the AzureAD Conditional Access certificate for authentication of the VPN. The following steps are needed to configure this:

  1. Open the Network Policy Server snap-in and expand Policies > Network Policies
  2. Click on Constraints and Authentication methods and check if only ‘Microsoft: Protected EAP (PEAP)’ is on the list. If not remove the other EAP types. Also remove all checkboxes in the ‘Less secure authentication methods’ list:
    image
  3. Click on ‘Microsoft: Protected EAP (PEAP)’ and click Edit. Validate if ‘Smart Card or Certificate’ is the only EAP type available in the selection area:
    image
  4. The next step is to configure NPS to only accept the AzureAD Conditional Access certificate for authentication of the VPN. Go to the settings tab and Under ‘Vendor Specific’ click ‘Add’:
    image
  5. Select the first option of ‘Allowed-Certificate-OID’ and click ‘Add’:
    image
  6. Paste the AAD Conditional Access OID of ‘1.3.6.1.4.1.311.87’ as the attribute value and click OK:
    image
  7. Click OK, Close, Apply

Now go back to one of your clients and try to connect. You should get AzureAD Conditional Access and when compliant you should be able to connect. After these changes you should not be able to bypass the Conditional Access flow.

Thanks to Microsoft for helping me in this scenario. If you have any questions regarding these posts please let me know.

4 thoughts on “Windows 10 AlwaysOn Conditional Access Connection Fix – Part 2

  1. Rob

    Hi Arjan, thanks for the update post. Does this mean that if you remove the CRL check from the NPS server that this change applies to all network policies that work with certificate based authentication? That could be a security risk for other configured policies right?

    • Arjan Vroege

      Hi Rob,

      Good Question. I will investigate this.. Come back when I’ve more information.

      Regards, Arjan

  2. bruce

    Hi Arjan,

    I recently set this up for a customer who wanted the behavior of the user performing an MFA challenge via the app on connection.

    We had set it up as per the Microsoft documentation but were still able to connect to the system once the device had been registered to azure active directory without an MFA challenge. it looked to us like the device certificate was being used as the second factor for the connection, not an app based mfa challenge.

    Have you been able to set this up in a way where a user must complete a second factor via the app on connection to the VPN?

    Kindest regards,

    Bruce

    • Arjan Vroege

      Yes, this was the first scenario I’ve tested. Did you applied both the fix on the client and server side which enforces the use of the AzureAD certicate?

      Regards, Arjan

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.