Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Important
Azure DevOps doesn't support Alternate Credentials authentication. If you're still using Alternate Credentials, we strongly encourage you to switch to a more secure authentication method.
This article shows how to manage your organization's security policies that determine how users and applications can access services and resources in your organization. You can access most of these policies in Organization settings.
Prerequisites
Category | Requirements |
---|---|
Permissions |
|
Manage a policy
To change application connection, security, and user policies for your organization, do the following steps.
Sign in to your organization (
https://dev.azure.com/{yourorganization}
).Select
Organization settings.
Select Policies, and then toggle your policy to on or off as needed.
Restrict authentication methods
To allow seamless access to your organization without repeatedly prompting for user credentials, applications can use authentication methods, like OAuth, SSH, and personal access token (PATs). By default, all existing organizations allow access for all authentication methods.
You can limit access to these authentication methods by disabling these application connection policies:
- Third-party application access via OAuth: Enable Azure DevOps OAuth apps to access resources in your organization through OAuth. This policy is defaulted to off for all new organizations. If you want access to Azure DevOps OAuth apps, enable this policy to ensure these apps can access resources in your organization. This policy doesn't impact Microsoft Entra ID OAuth app access.
- SSH authentication: Enable applications to connect to your organization's Git repos through SSH.
- Tenant admins can restrict global personal access token creation, restrict full-scoped personal access token creation, and enforce maximum personal access token lifespan through tenant-level policies on the Microsoft Entra settings page. Add Microsoft Entra users or groups to exempt them from these policies.
- Organization admins can restrict personal access token creation in their respective organizations. Subpolicies allow admins to permit the creation of packaging-only PATs or the creation of any-scope PATs to allowlisted Microsoft Entra users or groups.
When you deny access to an authentication method, no application can access your organization through that method. Any application that previously had access encounter authentication errors and lose access.
Enforce conditional access policies
Microsoft Entra ID allows tenants to define which users can access Microsoft resources through their Conditional Access policy (CAP) feature. Tenant admins can set conditions that users must meet to gain access, such as requiring that the user:
- Be a member of a specific Entra security group
- Belong to a certain ___location and/or network
- Use a specific operating system
- Use an enabled device in a management system
Depending on which conditions the user satisfies, you can then permit them access, require additional checks like multifactor authentication, or block access altogether. Learn more about conditional access policies and how to set one up for Azure DevOps in the Entra docs.
CAP support on Azure DevOps
When you sign in to the web portal of a Microsoft Entra ID-backed organization, Microsoft Entra ID always performs validation for any Conditional Access policies set by tenant administrators. Since modernizing our web authentication stack to use Microsoft Entra tokens, we now also enforce validation for Conditional Access policies on all interactive (web) flows.
- Using PATs on REST API calls that rely on Microsoft Entra requests requires that any sign-in policies set by tenant admins are also met. For example, if a sign-in policy requires a user sign in every seven days, you must also sign in every seven days to continue using PATs.
- If you don't want any CAPs to be applied to Azure DevOps, remove Azure DevOps as a resource for the CAP.
- We support MFA policies on web flows only. For non-interactive flows, if the user doesn't satisfy a CAP, they aren't prompted for MFA and are blocked instead.
IP-based conditions
If the Enable IP Conditional Access policy validation on non-interactive flows policy is enabled, we check IP fencing policies on non-interactive flows, such as when you use a PAT to make a REST API call.
We support IP-fencing conditional access policies (CAPs) for both IPv4 and IPv6 addresses. If your IPv6 address is being blocked, ensure that the tenant administrator configured CAPs to allow your IPv6 address. Additionally, consider including the IPv4-mapped address for any default IPv6 address in all CAP conditions.
If users access the Microsoft Entra sign-in page via a different IP address than the one used to access Azure DevOps resources (common with VPN tunneling), check your VPN configuration or networking infrastructure. Ensure to include all used IP addresses within your tenant administrator's CAPs.