I have setup TFS 2017 in a VM, create a project and added the package feed extension. I then created a feed and a personal access token with full access.
My problem is that I cannot push a package to the feed from the command line using nuget.exe 3.5.0 and a personal access token. I am using the instructions found here and on the feed page (2nd command below)
My commands:
nuget.exe sources Add -Name MyFeed -Source "http://server2016:8080/tfs/DefaultCollection/_packaging/MyFeed/nuget/v3/index.json" -Username administrator -Password x7m5hochjcf4vabp3zqeekrzi7mtbyk6at5tujdt2ny5fgienlgq
nuget.exe push -Source "MyFeed" -ApiKey VSTS C:\temp\octopack.3.4.6.nupkg
nuget.exe list -Source MyFeed
The output I get for both push and list:
Using credentials from config. UserName: administrator
Please provide credentials for: http://server2016:8080/tfs/DefaultCollection/_packaging/MyFeed/nuget/v3/index.json
UserName:
I tried entering the username and PAT again, but it just prompted me again.
If I use my Windows credentials (same account as the PAT) it works fine. I checked with Fiddler and the auth challenge is getting sent and responded to. The server returns a 401.
Any idea why TFS isn't accepting the PAT?
As of nuget 5.0, you have access to set "ValidAuthenticationTypes". See nuget sources -?
-ValidAuthenticationTypes Comma-separated list of valid authentication types for this source. By default,
all authentication types are valid. Example: basic,negotiate
This controls a new key in your nuget.config
<add key="ValidAuthenticationTypes" value="basic" />
Which prevents nuget from attempting Negotiate/NTLM/Kerberos auth against your local TFS/AzureDevOps Server.
Some History
The problem here is usually Negotiate getting in the way. Nuget (and tools built on the underlying libs like 'msbuild /restore' or 'dotnet') is good at making auth simple when you are logged in and AD can negotiate NTLM/Kerberos for you. Unfortunately when configuring Basic creds it can try to pass these off during negotiate, which fails. It is worth noting this was only a problem with the local Server instances and not the azure.dev.com/visualstudio.com cloud hosted instances since Negotiate wouldn't trigger in the cloud scenarios.
This was addressed in part under credentialProvider plugin flows, which could return an auth type for its creds, and if a specific environment variable were set nuget would disable UseDefaultCredentials and skip negotiate (this was used in Azure Pipelines for nuget auth for TFS/AzureDevops Server).
It got a final fix in nuget 5.0 with https://github.com/NuGet/NuGet.Client/pull/2297, which lets you set the auth type even in config files, when manually specifying PATs/passwords for basic auth. As of now, nuget docs are still pending.
I could reproduce your issue if use nuget.exe 3.5.0 and a personal access token. But there is no issue if you use nuget.exe 3.4.3 and a personal access token in TFS 2017.
Please get the nuget.exe 3.4.3 from Nuget page directly instead of using nuget.exe 3.5.0.
Maybe you need to add the -StorePasswordInClearText option to the nuget.exe sources Add command.
Related
We use a private nuget repo, via a VPN, (hosted on local TFS) and since one of the recent Calalina upgrades, I can no longer connect to the feed.
I keep getting repeatedly asked for my credentials. I have tried inputting them in format of either domain\username and username#company.com but they don't work. I have also tried using a Personal Access token too, but get the same issue.
I can access the nugget feed from windows or the TFS Portal without any problems.
TFS Version 16.131.28106.2
We have authentication problems since we update our TFS server from 2017 update 1 to update 3.1. (everything works fine just before the update)
Most of the time, the authentication works, but sometimes, it doesn't. I cannot really explain what is happening.
EG : A user was able to connect from web interface, from Poweshell but wasn't able to use sourceTree anymore.
Also, the Endpoints created in the Services section have the same problem, We are unable to to a Git fetch. Same error message.
fatal: Authentication failed for 'http://********:********#xxxx
Any tips on it?
Just try below items to narrow down the issue:
Update the cached credentials for git:
Go to Control Panel -> Credential Manager -> Windows Credentials (Generic Credentials)
Then update the password for git:http://ServerName:xxx/
If there is nothing that starts with git:http..., go and ADD the generic credentials:
Set up authentication with credential managers or SSH.
Download and run the latest Git for Windows installer, which includes the Git Credential Manager for Windows. Make sure to leave the Git Credntial Manager installation option enabled when prompted.
For SourceTree:
Navigate to C:\Users\USERNAME\AppData\Local\Atlassian\SourceTree and remove the passwd file.
Also try other ways mentioned by others in this thread: https://community.atlassian.com/t5/Sourcetree-questions/Getting-quot-fatal-Authentication-failed-for-quot-error/qaq-p/624663
Look at my backup and I think we found the problem, each time we update TFS, the authentication method switch from NTS to Kerboros.
Don't understand why this setting change.
Need to use the following command to return to NTLM
TFSConfig Authentication /provider:NTLM /siteType:ApplicationTier
how to fixed tfs Authentication problem
-> go through the location
Control Panel\User Accounts\Credential Manager
-> remove some credentials related to tfs.
Delete all credentials that have TFS anywhere in the name/url in the Credential Manager
(Control Panel -> User Accounts -> Credential Manager)
Clear the TFS Cache on the client machine The folder path is:
C:\Users***\AppData\Local\Microsoft\Team Foundation\6.0\Cache.
I am trying to integrate Jenkins (2.32.2) with TFS 2013. I have installed the necessary Tfs plugin (5.3.1). However, when I try to configure the TFS plugin in Jenkins to contact the TFS Team Project Collections by mentioning THE URL of the default collection of TFS (http://10.100.2.69:8080/tfs/DefaultCollection/) and the correct credentials,
I get an error "javax.ServletException: com.microsoft.tfs.core.exceptions.TECoreExceptions: the soap endpoint http://10.100.2.69:8080/tfs/DefaultCollection/Services/v1.0/Regitration.asmx could not be contacted"
Note: I have managed to configure this successfully on my local environment at work, but cannot configure in the clients environment. The credentials are correct. Can it be something with the proxy settings at the clients end ?
Receiving a 403 response is the server telling you, “I’m sorry. I know
who you are–I believe who you say you are–but you just don’t have
permission to access this resource. Maybe if you ask the system
administrator nicely, you’ll get permission. But please don’t bother
me again until your predicament changes.”
More details please see
：403 Forbidden vs 401 Unauthorized HTTP responses
So this error seems not related to your credentials. You need to make sure the system proxy settings were correct - sometimes after upgrading to the latest version of the plugin it may be using the default Java system proxy.
You could check the info here: Jenkins > Plugin Manager > Advanced to match the wildcard domain that your TFS server resided on.
We want to migrate our custom steps from XAML build to new build task in TFS2015 on-premise. I installed NodeJS and tfx-cli but when tfx-cli want to connect to TFS I need to provide pat (personal access token) but I cannot find where I can get it. All samples is for VSO but not for on-premise TFS2015. Is it possible to get PAT from on-premise TFS2015?
TFS 2015 doesn't support Personal Access Tokens, this feature was introduced with TFS 2017. In the mean time you'll either need to configure basic auth and use that (only enable basic auth if your TFS server is running over SSL), Or use the trick below to trick the command lien tools to authenticate by lettign an NTLM proxy (like Fiddler) handle the auth for you.
If you do not want to configure Basic Authentication on your TFS server (which many people don't want due to security concerns), then you can use a neat trick to let Fiddler handle your authentication:
Then enter:
C:\>set http_proxy=http://localhost:8888
C:\>tfx login --auth-type basic --service-url http://jessehouwing:8080/tfs/DefaultCollection
You'll be prompted for a username and a password, it doesn't really matter what you enter, fiddler will handle the authentication for you in the background:
More detailed steps outlined on my blog.
If you're battling self-signed certificates, which is also a common problem when using tfx against a on-premise TFS server, make sure you're using a recent enough version of Node and point it to an aditional cert store using environment variables:
As of Node.js 7.3.0 (and the LTS versions 6.10.0 and 4.8.0) it is now possible to add extra well-known certificates to Node.js with an environment variable. This can be useful in cloud or other deployment environments to add trusted certificates as a matter of policy (as opposed to explicit coding), or on personal machines, for example, to add the CAs for proxy servers.
See the CLI documentation for more information on using NODE_EXTRA_CA_CERTS, as well as the original pull-request.
NODE_EXTRA_CA_CERTS=file#
Added in: v7.3.0
When set, the well known "root" CAs (like VeriSign) will be extended with the extra certificates in file. The file should consist of one or more trusted certificates in PEM format. A message will be emitted (once) with process.emitWarning() if the file is missing or malformed, but any errors are otherwise ignored.
Note that neither the well known nor extra certificates are used when the ca options property is explicitly specified for a TLS or HTTPS client or server.
There's another option for tfx-cli to connect to the TFS instance, and it is basic authentication. Just use the following format:
tfx login --auth-type basic --username myuser --password mypassword --service-url http://tfscollectionurl
Here is the quote from Github:
You can alternatively use basic auth by passing --auth-type basic
(read Configuring Basic Auth). NTLM will come soon.
Note: Using this feature will store your login credentials on disk in
plain text.
I installed TEE-CLC-11.0.0.1306 onto my Windows Server 2003 R2. I am able to perform TF commands in the command line successfully. But when I set the TF_AUTO_SAVE_CREDENTIALS environment variable, I get this error:
A client error occurred: The credentials cannot be saved to the active credential manager (Null Credentials Manager). You must manually configure stored credentials for this mechanism or specify credentials a different way.
I opened the "Stored User Names and Passwords" tool by running: control keymgr.dll
and I can't seem to manually create the credentials. On my Window 7 machine, the TEE credentials are stored properly and working, so I went to: Control Panel\All Control Panel Items\Credential Manager to look at the entry for TEE as an example, but it didn't exist.
Why can't the credentials be stored by the 'tf' command after setting the environment variable?
Is the issue related to the OS (Windows Server 2003 R2)?
Where are the credentials stored when this is properly enabled? (I can't find them on my Win 7 machine.)
Is there a way to manually create the credentials on the Window Server 2003 R2 machine, as the error message suggests?
The Team Explorer Everywhere command-line client cannot save credentials on Windows. Team Explorer Everywhere, like Visual Studio, uses the Windows credential manager to persist credentials. Credentials stored in Credential Manager will override your domain credentials if you are domain-joined or a shadow account.
Simply open the
Credential Manager and add credentials for the TFS server.
(Technically Windows is not a supported platform at all, we would recommend you use the actual TFS command-line client, part of the Team Explorer installation. The above steps work for it, too.)