Επεξεργασία

Κοινή χρήση μέσω

Change application connection & security policies for your organization

  • Άρθρο

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 applications can access services and resources in your organization. You can access most of these policies in Organization settings.

Prerequisites

Permissions: Be a member of the Project Collection Administrators group. Organization owners are automatically members of this group.

Manage a policy

To change application connection, security, and user policies for your organization, do the following steps.

  1. Sign in to your organization (https://dev.azure.com/{yourorganization}).

  2. Select gear icon Organization settings.

    Screenshot of Organization settings button, preview page.

  3. Select Policies, and then toggle your policy to on or off as needed.

Screenshot of select policy, and then turn On or Off.

Change application connection policies

To allow seamless access to your organization without repeatedly prompting for user credentials, applications often use the following authentication methods:

  • OAuth: Generate tokens for accessing REST APIs for Azure DevOps. All REST APIs accept OAuth tokens, making it the preferred method of integration over personal access tokens (PATs). The Organizations, Profiles, and PAT Management APIs only support OAuth. You can also use OAuth tokens with Microsoft Entra ID to provide secure and seamless authentication for users within your organization.

  • SSH: Generate encryption keys for use with Linux, macOS, and Windows running Git for Windows. You can't use Git credential managers or PATs for HTTPS authentication with SSH.

  • PATs: Generate tokens for:

    • Accessing specific resources or activities, such as builds or work items.
    • Clients like Xcode and NuGet that require usernames and passwords as basic credentials and don't support Microsoft account and Microsoft Entra features, such as multifactor authentication.
    • Accessing REST APIs for Azure DevOps.

By default, your organization allows access for all authentication methods.

You can limit access for OAuth and SSH keys by disabling these application connection policies:

  • Non-Microsoft application via OAuth: Enable non-Microsoft applications to access resources in your organization through OAuth. This policy is defaulted to off for all new organizations. If you want access to non-Microsoft applications, enable this policy to ensure these apps can access resources in your organization.
  • SSH Authentication: Enable applications to connect to your organization's Git repos through SSH.

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.

To remove access for PATs, revoke them.

Change 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. For example, the user must:

  • Be a member of a specific 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 require multifactor authentication, set further checks to gain access, or block access altogether.

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 (CAPs) set by tenant administrators.

Azure DevOps can also perform more CAP validation once you're signed in and navigating through a Microsoft Entra ID-backed organization:

  • If the “Enable IP Conditional Access policy Validation” organization policy is enabled, we check IP fencing policies on both web and non-interactive flows, such as non-Microsoft client flows like using a PAT with git operations.
  • Sign-in policies might be enforced for PATs as well. Using PATs to make Microsoft Entra ID calls requires adherence to any sign-in policies that are set. For example, if a sign-in policy requires that a user sign in every seven days, you must also sign in every seven days to continue using PATs for Microsoft Entra ID requests.
  • If you don't want any CAPs to be applied to Azure DevOps, remove Azure DevOps as a resource for the CAP. We don't enforce CAPs on Azure DevOps on an organization-by-organization basis.

We support MFA policies on web flows only. For non-interactive flows, if they don't satisfy the conditional access policy, the user isn't prompted for MFA and gets blocked instead.

IP-based conditions

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.