Share via

Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 3)

  • Article

Today’s Tip…

Yesterday’s tip outlined the services and components involved in assuring the health and security compliance of remote device requesting access to high-value assets, such as VPN.  In brief, those components are:

  • Conditional Access
  • Azure AD Connect Health
  • Windows Health Attestation Service
  • Windows 10 Health Attestation CSP
  • Intune Compliance Policies

But how do all of these components work together to form a complete end-to-end solution?  Who is responsible for verifying the health of the device?  What does the authentication flow look like?

Let’s try to answer some of these questions by looking at a sample connection flow.

The Process

Conditional Access requires that Azure Active Directory (AAD) be used as the source of trust for the authentication of remote devices.  An ideal scenario might be to have the VPN server call into Azure Active Directory (AAD) directly at time of the connection attempt, passing along health information provided by the client.  However, while some VPN endpoints support this capability, many more do not. 

To ensure interoperability with the broadest possible set of remote access endpoints, Windows 10 does not send health information directly to the VPN endpoint.  Rather, the client token broker service intercepts the connection attempt and, before allowing its completion, calls into Azure Active Directory for a health evaluation. 

If health is validated, a short-lived client authentication certificate is issued from an Azure AD Certificate Authority and used to authenticate the connection.  Essentially it is this AAD-CA issued short-term certificate that is used to authenticate against the VPN endpoint. 

Handling the call to Azure AD on the client in this way makes the compliance solution supportable without requiring changes on the network device.

The Flow

clip_image001

A very high-level VPN connection flow for conditional access looks like this:

  1. User clicks connect on VPN.  At this point, Windows 10 does not send device information directly to the VPN server.  Instead the VPN client service calls into the AAD Windows Attestation plug-in. 
  2. The AAD WAM plugin calls the AAD tenant to authenticate using 2-factor authentication (using a Passport gesture and the device token).
  3. AAD leverages the cloud-based conditional access engine to validate device compliance (recall that major components of the framework include the Windows Health Attestation Service and Intune compliance policies).
  4. If compliant, a short-term certificate is requested and issued from the AAD-CA, returned to the client attestation plugin, and placed in the local certificate store.
  5. The VPN Client then uses this short-lived certificate to authenticate to the VPN server.
  6. After a default period of 60 minutes, the AAD plugin repeats the process to re-evaluate device health and refresh the certificate.

Providing an SSO Experience

The conditional access experience works best on an AAD domain-joined device using Passport for Work for Single-Sign-On (SSO).  Integration with Passport for Work gestures provide a truly seamless SSO experience.  When you sign into an AAD domain-joined device with PPW:

  • The client already has the gesture for PPW
  • The device token used to authenticate to AAD

To provide a complete SSO experience the device need simply obtain the AAD certificate to connect because two-factor authentication has already been performed to logon to the device.

What About Remediation?

Remediation is handled by the conditional access framework and is outside the scope of this article.

For more information see the Controlling access based on device health whitepaper at https://technet.microsoft.com/en-us/library/mt592023(v=vs.85).aspx

For more information on device compliance and the Windows Health Attestation Service see Controlling the health of Windows 10-based devices