I have noticed that there is a difference in how service connection permissions are handled between TFS 2018 and Azure DevOps Server 2019. (and Azure DevOps)

I ran through the following test in a POC environment.

In both versions of TFS I set up a project with two service connections.

TFS settings screen showing two service connections. One is called "ProdConnection" the other is called "EveryonesConnection"

We also have two users in the project on each server.

  • AdminUser – has access to both connections
  • BasicUser – has access to only the “EveryonesConnection”
An Azure DevOps setting screen overlayed by a TFS setting screen. They show the service connections that either user (mentionned just before) has got access to.

In both TFS 2018 and Azure DevOps Server 2019 I have built a release pipeline with two stages.

A release pipeline in Azure DevOps server showing the "Dev" and the "Prod" stage

Each stage only contains one phase and one Azure PowerShell task.

In the “Dev” stage the Azure PowerShell task uses the “EveryonesConnection”.

In the “Prod” stage the Azure PowerShell task uses the “ProdConnection”.

If I sign on as BasicUser I get the following behaviour when trying to change the Azure PowerShell task in the Prod stage.

VS402913: The release definition cannot be saved because the environment ‘Prod’ references a service endpoint that cannot be found, or that you do not have permission to access. Details: ‘Task ‘Azure PowerShell script: InlineScript’ is using endpoint ‘ProdConnection”

This prevents the BasicUser from changing the existing task or using the prod connection that they are not supposed to have access to.

A screenshot showing an error message.

However with the same setup in Azure DevOps (Server) the Basic User can save changes to the Prod stage without trouble.

They are still not able to pick the Prod connection for new tasks as it does not come up in their dropdown.

A drop down showing that ProdConnection is not an option on a new task.

This difference in behaviour means that customers who want to prevent certain users from modifying stages that use particular service connections, need to set additional permissions at the stage level.