Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 4)
Today’s Tip…
In our last tip we outlined an example connection flow for VPN device compliance using the Conditional Access Framework, including the issuance of a short-lived certificate by an AAD-CA. In this tip, let’s take a closer look at the CA and the certificate it issues.
An Azure Active Directory Certificate Authority is essentially a ‘mini-CA’ cloud tenant and is a required component for a Conditional Access Framework device-compliance solution. The certificate used by the client for health attestation and the VPN connection must be issued by an Azure Active Directory-based Certificate Authority.
AAD Issued Short-Lived Certificate
When a VPN connection attempt is made, the AAD Token Broker on the local device establishes communications with the Azure Active Directory tenant, which then validates device health based on the deployed set of compliance rules. If compliant, AAD sends back a short-lived certificate that is used to authenticate the VPN. The certificate lifetime cannot be modified.
Basically, this AAD issued short-lived certificate becomes the client authentication cert which can be used for the next hour. As the certificate approaches its expiration, the client will again communicate with AAD for a health evaluation. If still in a healthy state, a new cert is issued allowing a continuation of the connection.
At This Point You Must Have Questions
At this point I am sure a number of question and concerns have popped up in your mind so let’s try to address a few of them now.
What if you have an existing Enterprise CA?
The Conditional Access Framework is an Azure cloud-based solution requiring an AAD CA tenant to interact with the health attestation service and evaluate client health. Unfortunately, the current release is unable to communicate with an on-premises certificate authority. An Azure AD CA is a root authority and cannot be configured as a subordinate.
This may actually be a plus for some who organizations who would as soon do away with their own internal CA infrastructures.
My Enterprise is concerned about trusting what is essentially an “external” authority for authentication to resources on their network.
It’s understandable that some enterprises may initially resist trusting and ‘external’ certificate authority on authentication servers within their domain network. The risk is not as great as it might seem as the enterprise admins themselves will continue to will have administrative control over an AAD-CA.
If this concerns proves insurmountable however there is an alternative where the root certificate need only be placed on the VPN server, thus eliminating the need to trust the AAD root on the domain. In this deployment Kerberos authentication can then be done using a separate certificate which has been provisioned for SSO authentication to domain resources.
Are there limitations for the use of AAD-issued certificates?
AAD provides a fully functional certificate authority. The usual certificate-based authentication methods, such as EAP-TLS, can be used to secure the remote connection.