Conditional access is a crucial security feature for protecting your organisations services from unauthorised access. However, by default, personal access tokens created in an Azure DevOps organisation are not subject to conditional access policies. In this blog post, I will explain how you can configure Azure DevOps to adhere Azure Active Directory Conditional Access Policies for personal access tokens, and why it’s important to do so.
What is a Personal Access Token
A personal access token (PAT) is a token that contains security credentials for Azure DevOps. This PAT identifies a user account and has access to an Azure DevOps organisation or projects in the organisation. The access depends on the given scope.
The scope can be global, which means that the PAT has full access, but a PAT can also be scoped to certain subjects Azure Pipelines (e.g. permission to run pipelines) or Azure Board (e.g. create work items).
There are two ways to create a personal access token in Azure DevOps:
- Using the Azure DevOps GUI
- Through the Personal Access Token Lifecycle API (recommended)
What is Conditional Access?
Azure Active Directory (Azure AD) Conditional Access is a policy-based access management feature that allows organisations to control how and when users access their applications and resources. By defining conditions, such as user location, device state, or IP-fencing, administrators can create policies that require users to provide additional verification, such as multi-factor authentication, before accessing specific resources.
Prerequisites
To configure Conditional Access for PATs you must be a member of the Project Collection Administrators group. This group can be found on organisational level.
Configure Personal Access Tokens with Conditional Access
If you have an Azure AD-backed Azure DevOps organisation with configured Conditional Access Policies (CAP), a validation occurs when you log in to Azure DevOps via the browser and will show you a multi-factor authentication prompt. For Azure DevOps personal access tokens CAP is not enabled by default.
Azure DevOps CAP validations
Azure DevOps can also perform CAP validations while navigating through Azure DevOps. To enable this, select the option Enable Azure Active Directory Conditional Access Policy Validation.
It is important to note that there are two types of flows: web flows and third-party flows. When the validation option is enabled, all web flows will adhere to all conditional access policies. However, third-party flows, such as PAT authentication via the Azure DevOps CLI extension, will only adhere to IP-based conditional access policies. IP-fencing supports IPv4 and IPv6. Note that multi-factor authentication for personal access tokens is not supported.
The option to Enable Azure Active Directory Conditional Access Policy Validation can be found in the organisation settings:
When the Azure AD CAP validation is enabled all new personal access tokens will adhere to the conditional access policies. Existing personal access tokens will not adhere to conditional access policies.
Third-party flow with CAP validation enabled
In the image below you see the validation for signing in to Azure DevOps using Azure AD. Besides that, the actor in the allowed IP range (on-premises / VPN) uses the PAT to connect to Azure DevOps. The Conditional Access Policy validation succeeded because the actor connects from an allowed IP range (indicated by the on-premises / VPN orange arrow).
The external actor in the blocked region is denied access by the Conditional Access Policy validation because they are not connecting from the correct IP range (indicated by the external orange arrow).
When the external actor attempts to perform the action, an error message will be displayed:
Sign-in flow with CAP validation disabled
In the image below you see the validation for signing in to Azure DevOps using Azure AD (indicated by the orange arrow). Besides that, the actor in the allowed IP range (on-premises / VPN) can use personal access tokens without conditional access, because the CAP validation is disabled. This also applies to the external actor, who can also use personal access tokens without CAP validation. As we can see no conditional access is applied for personal access tokens and the external actor can access the Azure DevOps organisation.
Conclusions
This is how you can protect your Azure DevOps organisation. It is important to let personal access tokens adhere to conditional access policies to prevent attacks from leaked personal access tokens. This blog is scoped to personal access tokens, but SSH keys are also included in these validation checks.
Azure Cloud | John Lokerse 