I am completely unable to pull NuGet packages from my Private repos in my Organization.
I am using visual studio code, and the dotnet nuget add package command to no avail.
I have tried using classic PAT, Fine Grained PAT, with ALL permissions checked, and get 403 Forbidden responses every time.
If I use my account's password, I get a 401 response. I am setting up the source with the dotnet nuget add source pointing to my organization source, and passing username and password (I've tried storing in plain text and not, no difference)
Is there any trick to getting it to work? I feel like github packages is pretty useless for private orgs if we can't use it as a package source for private repos
Found the solution:
My org did not have permissions set for Classic tokens, and fine grained tokens do not expose the packages permissions.
To fix, I went into my org settings => Personal Access Tokens => settings => set "Personal access token (classic)" to allow
Related
I need to review all source code permissions on a particular folder structure. I have gone through the apis and can't find what I need or haven't figured out how to use them correctly yet.
I have also tried the tfssecurity command but, can't figure out how to make it look at just a specific team project.
I am using Azure DevOps Server 2020 and the source is in TFVC.
This is part of a source control audit and I need to produce a report of what permissions users have on a folder in source.
I have tried the following apis: https://learn.microsoft.com/en-us/rest/api/azure/devops/security/?view=azure-devops-server-rest-6.0
Along with the tfssecurity command.
None are producing the results I need.
Found the APIs needed to do this.
Use this one to get all of the namespaces and find the ones that you want to get the security data for.
https://{instance}/{collection}/_apis/securitynamespaces
After that call this API to get the ACLs for that namespace.
https://{instance}/{collection}/_apis/accesscontrollists/{securityNamespaceId}?alwaysAllowAdministrators=True
Once you get all of the ACLs for the namespace, you can then look at each ACE to find out the permissions.
https://{instance}/{collection}/_apis/identities?descriptors={descriptors}&queryMembership=expandedDown
I've been unsuccessful with having my build publish to the new Package Feed in TFS 15 RC2. I'm currently running TFS offline and using a local build agent. I've followed these instructions to no avail.
Since the last image in those instructions is cropped around the URL, and that URL was specific to VSTS online, I thought mine might be wrong. So I tried the following (none worked):
Using http://[computername]:8080/tfs/DefaultCollection/_packaging/{feedName}/nuget/v3/index.json
gives an error when it tries to prompt for input of credentials in
interactive mode.
Using http://[computername]:8080 gives a 404.
Using http://[computername]:8080/tfs gives same error as #1.
Using http://[computername]:8080/tfs/DefaultCollection gives same error as #1
Since some errors happened while trying to do an interactive prompt, I thought it might be a permission error. The following links give some information, but it seems like the Build Agent should already be in the right category for publishing permissions.
https://www.visualstudio.com/en-us/docs/package/feeds/common-identities
https://www.visualstudio.com/en-us/docs/package/nuget/auth
Anyone happen to know a solution? Thanks!
EDIT
The build agent was running as NT AUTHORITY/Network Service, which is the default of the agent config. I removed this agent and configured it to run under my user account, which is an admin on the system. After doing so, I was able to publish without issues to the Packages using the URL in #1 (as Cece below has written). Is there something else I need to do to get the permissions set for the default agent?
The Internal Feed URL is the NuGet Package Source URL for the feed you want to publish to.
When you create a new Feed, navigate to your feed, and select Connect to feed. You'll see the NuGet package source URL. The format should be like: http://{tfsserver}:8080/tfs/DefaultCollection/_packaging/{FeedName}/nuget/v3/index.json
I'm trying to use the Jenkins TFS Plugin and have trouble authenticating. I saw that user on the TFS administration, and gave it permissions on my project.
I've created a local user account (via Local Users and Groups) - TfsServer\TfsUserAdmin, and I'm trying to use it to authenticate against the TFS server.
I able able to use the name and password of the user. For example this works (though it prints an empty list):
tf workspaces -format:brief -server:http://TfsServer:8080/tfs/Redacted_Collection -login:TfsServer\TfsUserAdmin,RedactedPassword
If I change the password on the above command I get an error, so authentication does work.
The next command is:
tf workspace -new "RedactedWorkspaceName;" -noprompt -server:http://TfsServer:8080/tfs/Redacted_Collection -login:TfsServer\TfsUserAdmin,RedactedPassword
This fails with the error:
TF14045: The identity TfsServer\TfsUserAdmin is not a recognized identity.
I don't think I can change these commands, they are created by the plugin.
I've found people with similar errors, but none of them had the user name at the error - only a GUID or the server name.
Can I work with TFS and a local user?
You will likely need to use Shadow Accounts to get your Jenkins server to talk to TFS...
Create a local user on both your TFS server and your Jenkins server with the same Username & Passowrd. Then use that account to authenticate.
This is the only way to get cross domain coms working without trust and is a feature of Windows & AD. If your org has disabled it you will need to look at creating a trust relationship between your domains.
I'm hosting a project on my Jenkins server. That project has a GitHub repo and I have it set up so it automatically builds new commits. In order for that to work, I need to input credentials for a github account that has full access to the repo.
The problem is, that if I want him to add his login info to the credentials list, I'd have to give him acces to all credentials on the server (I don't want that).
I tried using the credentials under "{username}" > "Credentials", but those didn't show up in the project setup (even with 100% access to everything on the server).
Is there a way for the user to store his credentials and use them for the project without giving him full access to all credentials on the server?
Add the user's credentials under Global security and then allow project based Matrix Authorization Strategy per project as shown:
I found the answer in this mailing list entry:
In short: You need to
install and activate the Authorize Projects Plugin,
enable "run as specific user" strategy in global security settings,
enable this for the project in question.
This allows you to use the credentials for this specific user.
Enabling ssh-agent is the final step to make this work conveniently.
I've installed opshub on my pc that is on domain ABC. I have succesfully migrated projects from a TFS server on domain ABC to visual studio online. Now I've added a TFS server that is in domain DEF and it doesn't ask me for credentials for that server. I just get a blank collection list, I think its trying to use my current credentials from domain ABC. How can I get it to ask me for the credentials to domain DEF when trying to access that server?
User level authentication details are stored inside Team Foundation cache directory under following locations. If you have already authenticated for the TFS server then details for that server is stored inside cache directory. This won't ask you credentials again while you are doing next migration.
If you want to authenticate with the new credentials for different domain you need to clear data from the following directories.
C:\Users{User}\AppData\Local\Microsoft\Team Foundation\4.0\Cache
C:\Users{User}\AppData\Local\Microsoft\Team Foundation\5.0\Cache
Make sure original folders remains there (Cache). Just remove contents of those directories. Also make sure you close all the applications which uses TFS cache like visual studio, opshub migration utility.
See http://blogs.msdn.com/b/visualstudioalm/archive/2012/08/29/clearing-the-credentials-for-connecting-to-a-team-foundation-server.aspx for correct answer. It worked for me.