31

I have been using Azure DevOps for a project for quite some time, but suddenly publishing to my own organisation/collection feed results in a 403.

I created a feed and I can select it on the nuget push build step, but it does not work. I created a new feed to publish the NuGet packages to and this works perfectly again. It seems to me like a token expired, but I never created one or used it to authenticate. I also do not want to change my NuGet feed to the new one, as I want to use older packages as well.

This is the buildpipeline:

enter image description here

And this is the stack trace:

Active code page: 65001 SYSTEMVSSCONNECTION exists true SYSTEMVSSCONNECTION exists true SYSTEMVSSCONNECTION exists true

[warning]Could not create provenance session: {"statusCode":500,"result":{"$id":"1","innerException":null,"message":"User

'a831bb9f-aef5-4b63-91cd-4027b16710cf' lacks permission to complete this action. You need to have 'ReadPackages'.","typeName":"Microsoft.VisualStudio.Services.Feed.WebApi.FeedNeedsPermissionsException, Microsoft.VisualStudio.Services.Feed.WebApi","typeKey":"FeedNeedsPermissionsException","errorCode":0,"eventId":3000}} Saving NuGet.config to a temporary config file. Saving NuGet.config to a temporary config file. [command]"C:\Program Files\dotnet\dotnet.exe" nuget push d:\a\1\a\Microwave.0.13.3.2019072215-beta.nupkg --source https://simonheiss87.pkgs.visualstudio.com/_packaging/5f0802e1-99c5-450f-b02d-6d5f1c946cff/nuget/v3/index.json --api-key VSTS error: Unable to load the service index for source https://simonheiss87.pkgs.visualstudio.com/_packaging/5f0802e1-99c5-450f-b02d-6d5f1c946cff/nuget/v3/index.json. error: Response status code does not indicate success: 403 (Forbidden - User 'a831bb9f-aef5-4b63-91cd-4027b16710cf' lacks permission to complete this action. You need to have 'ReadPackages'. (DevOps Activity ID: 2D81C262-96A3-457B-B792-0B73514AAB5E)).

[error]Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1

[error]Packages failed to publish

[section]Finishing: dotnet push to own feed

Is there an option I am overlooking where I have to authenticate myself somehow? It is just so weird.

Jeremy Caney
  • 7,102
  • 69
  • 48
  • 77
modmoto
  • 2,901
  • 7
  • 29
  • 54

9 Answers9

47

"message":"User 'a831bb9f-aef5-4b63-91cd-4027b16710cf' lacks permission to complete this action. You need to have 'ReadPackages'.

According to this error message, the error you received caused by the user(a831bb9f-aef5-4b63-91cd-4027b16710cf) does not have the access permission to your feed.

And also, as I checked from backend, a831bb9f-aef5-4b63-91cd-4027b16710cf is the VSID of your Build Service account. So, please try with adding this user(Micxxxave Build Service (sixxxxss87)) into your target feed, and assign this user the role of Contributor or higher permissions on the feed.

In addition, here has the doc you can refer:

enter image description here

There is a new UI in the Feed Permissions:

New UI to allow project-scoped builds

Elan Hasson
  • 1,214
  • 1
  • 19
  • 29
Mengdi Liang
  • 17,577
  • 2
  • 28
  • 35
  • 1
    Ok thanks i will check that later. But this seems weird to me, as this user is not a user i ever created or saw in the userlist. I think it was created by azure itself. That is why i did not understand the error message. The only thing that changed was that i moved from a private collection to a public one. Maybe this was the cause? The new feed worked like the old one straight out of the box, also without adding any rights or tokens to the user/pipeline:/ – modmoto Jul 23 '19 at 07:23
  • 1
    Yes, you're right. This user is a **Build Service account** which exists in pipeline as default, its domain is build. You can see this under your **Security Service Group** – Mengdi Liang Jul 23 '19 at 08:43
  • 1
    Thanks a lot, this was the problem =) Looks like making your project a public one means, that the user need more rights than earlier. Kind of makes sense now. Thanks a lot! – modmoto Jul 23 '19 at 14:55
  • "And also, as I checked from backend, a831bb9f-aef5-4b63-91cd-4027b16710cf is the VSID of your Build Service account." How can you search by GUID? – Steven T. Cramer Aug 30 '19 at 07:55
  • 3
    To answer my own question. https://learn.microsoft.com/en-us/rest/api/azure/devops/graph/users/list?view=azure-devops-rest-5.1 you can get raw json from the get and search by ID. (One would think this woudl be in the UI) – Steven T. Cramer Aug 30 '19 at 08:00
  • @Steven T. Cramer Thanks your method sharing. On Microsoft backend, we have tool that can get detail message with this ID. – Mengdi Liang Aug 30 '19 at 08:26
  • Do you guys think this can happen if you have 2 DevOps Projects (both private), and export the build pipeline from one of the projects (thus downloading a JSON file) and then importing said pipeline into the 2nd DevOps project? – bkwdesign Oct 30 '19 at 17:14
  • @bkwdesign. This need depend on different situation. As normal, yes, it will lead. You can see that this service account only specified to one project, when the project changed and the feed is still from the previous project. At this time, need to consider this error would caused. Limited by the comment works number, you can submit one new ticket and add more details into that. I would check that and give the detailed answer into that. – Mengdi Liang Nov 13 '19 at 08:53
  • I've added this account and this doesn't work for me. I screen-shared with an MS employee and so far they couldn't work out what was wrong. – Elven Spellmaker Nov 18 '19 at 13:34
  • @ElvenSpellmaker Did that FTE got the exactly account name by searching the user ID which shown in the error message from our backend? You may need create a new ticket by sharing your error message in that. – Mengdi Liang Nov 18 '19 at 13:45
  • @MerlinLiang-MSFT We both searched the user GUID (I used the users API endpoint) given back and the user clearly has permissions inside the GUI, but gets 403 when it tries to access the feed via a Github PR Trigger, but has permissions if we run the build manually in the UI. He's taken more information including build logs from me today and will pass it to the product team for further investigation, and hopefully they can use the IDs in the logs to find out what's going on. – Elven Spellmaker Nov 19 '19 at 14:04
  • @ElvenSpellmaker. Do you mind show me the activity ID? This could let me get the detailed IIS log from our backend. Also, you could waiting for our product group engineer's response if you think it's sensitive to share it in SO. – Mengdi Liang Nov 19 '19 at 14:07
  • @MerlinLiang-MSFT Sure,`DevOps Activity ID: 24EE358E-A991-4E3B-B32E-D35A11B110C9` is an example of an ID that fails to push Nuget packages to the feed (but it restores fine in this build earlier on). Some builds can read fine, some can't, it's completely random it seems, and the user in question is there with Contributor access. – Elven Spellmaker Nov 19 '19 at 14:10
  • @ElvenSpellmaker, I could get the correct org name from the log of this ID, could you give me that? You can delete it once I get it. – Mengdi Liang Nov 20 '19 at 09:48
  • @MerlinLiang-MSFT, I've just tried something and found out something interesting. This build is happening from a fork and it seems that building PRs from the forks are failing in this instance. (Which shouldn't have _any_ effect on feed authorisation surely? The error says the user doesn't have access but it does?) I verified this by using the build created in the GUI with the support engineer and our YAML builds. EDIT: To be crystal clear, the setting for forks to propagate secrets is ticked (whether it should be or not is another question) – Elven Spellmaker Nov 20 '19 at 12:45
  • @MerlinLiang-MSFT GUI Build: When a PR build from the branch on my fork is triggered the restore fails. When a PR build from the _same_ branch on the main repo the PR restore works fine. When a manual build from either branch is run the restore works fine. YAML Build: Restore _always_ works (which is different from the above behaviour) When a PR build from the branch on my fork is triggered the nuget push fails. When a PR build from the _same_ branch on the main repo the PR nuget push works fine. When a manual build from either branch is run the push works fine. – Elven Spellmaker Nov 20 '19 at 12:45
  • @MerlinLiang-MSFT : We are facing same issue using Azure Pipelines using a private repository, I followed the process given in https://www.youtube.com/watch?v=rUWU2n6FwgA&ab_channel=ProgressTelerik. Will adding the Build Service account seperately as a user and granting permission to the feed compromise on security ? – Sud Oct 21 '20 at 09:55
  • The "Allow project-scoped builds" worked for me. That was not obvious. – Mark Good Jul 06 '21 at 17:01
29

To further expand on Merlin's solution & related links (specifically this one about scope), if your solution has only ONE project within it, Azure Pipelines seems to automatically restrict the scope of the job agent to the agent itself. As a result, it has no visibility of any services outside of it, including your own private NuGet repos held in Pipelines.

Solutions with multiple projects automatically have their scope unlocked, giving build agents visibility of your private NuGet feeds held in Pipelines.

I've found the easiest way to remove the scope restrictions on single project builds is to:

  1. In the pipelines project, click the "Settings" cog at the bottom left of the screen.
  2. Go to Pipelines > Settings
  3. Uncheck "Limit job authorization scope to current project"

Hey presto, your 403 error during your builds involving private NuGet feeds should now disappear!

Dezzamondo
  • 2,169
  • 2
  • 20
  • 33
  • I just can't uncheck that option. Azure DevOps prints: "This setting cannot be changed as it is enforced at the organization level." – Daspuru Feb 27 '20 at 17:27
  • 1
    @Daspuru looks like you'll need to have a chat with the admin of the DevOps organisation. If that's YOU then you'll probably need to dig around the DevOps settings for the organisation before tweaking anything at the project level. Good luck! – Dezzamondo Feb 28 '20 at 16:56
7

Still wondering where that "Limit job authorization scope to current project" setting is, took me a while to find it, its in the project settings, below screenshot should help

enter image description here

Ricky Gummadi
  • 4,559
  • 2
  • 41
  • 67
7

I want to add a bit more information just in case somebody ends up having the same kind of problem. All information shared by the other users is correct, there is one more caveat to keep into consideration. The policies settings are superseded by the organization settings. If you find yourself unable to modify the settings or they are grayed out click on "Azure DevOps" logo at the left top of the screen.

Azure DevOps

Click on Organization Settings at the bottom left.

Organization settings

Go to Pipeline --> Settings and verify the current configuration.

Current settings

When I created my organization it was limiting the scope at the organization level. It took me a while to realize it was superseding the project.

Maximiliano Rios
  • 2,196
  • 2
  • 20
  • 34
2

It may not be immediately obvious or intuitive, but this error will also occur when the project your pipeline is running under is public, but the feed it is accessing is not. That might be the case, for instance, when accessing an organization-level feed.

In that scenario, there are three possible resolutions:

  1. Make the feed public, in which case authentication isn't required; or
  2. Make the project private, thus forcing the service to authenticate; or
  3. Include the Allow project-scoped builds under your feed permissions.

The instructions for the last option are included in @Merlin Liang - MSFT's excellent answer, but the other options might be preferable depending on your requirements.

At minimum, this hopefully provides additional insight into the types of circumstances that can lead to this error.

Jeremy Caney
  • 7,102
  • 69
  • 48
  • 77
  • I now notice [from the comments under the accepted answer](https://stackoverflow.com/a/57156304/3025856) that this was the same root cause for the OP's original problem. As this point gets lost among the many comments, however, I'm going to keep this answer in place for those that might benefit from understanding not only the cause, but also the additional options for mitigating the issue. – Jeremy Caney Mar 04 '21 at 10:26
2

Another thing to check, if using a yaml file for the Pipelines, is if the feed name is correct.

I know this might seem like a moot point, but I spent a long time debugging the ..lacks permission to complete this action. You need to have 'AddPackage'. error only to find I had referenced the wrong feed in my azure-pipelines.yaml file.

badsyntax
  • 9,394
  • 3
  • 49
  • 67
  • 1
    Tried everything in the answers above this one and they were all good to go. I was using a yml build file and had the wrong feed specified. Thanks for posting this and preventing any further damage to my forehead. One more bang against the desk and I was probably going to be looking for a new career. – Mike Devenney Jan 24 '22 at 14:16
1

If you don't want to/cannot change Project-level settings like here

You can set this per feed by clicking 'Allow Project-scoped builds' (for me greyed out as it's already enabled).

That's different from the accepted answer, as you don't have to explicitly add the user and set the permissions.

enter image description here

Bartosz
  • 4,406
  • 7
  • 41
  • 80
1

Adding these two permissions solved my issue.

Project Collection Build Service (PROJECT_NAME)

[PROJECT_NAME]\Project Collection Build Service Accounts

https://learn.microsoft.com/en-us/answers/questions/723164/granting-read-privileges-to-azure-artifact-feed.html

ravz
  • 13
  • 4
0

If I clone an existing pipeline that works and modify it for a new project the build works fine.

But if I try to create a new pipeline I get the 403 forbidden error.

This may not be a solution but I have tried everything else suggest here and elsewhere but I still cannot get it to work.

Cloning worked for me.

Jason Richmond
  • 91
  • 1
  • 5