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.
Related
After updating from TFS 2018 v3 to DevOps Server 2019.0.1 last weekend I now receive this authentication error when attempting to manage security:
TF30063: You are not authorized to access tfs.
I receive this error when attempting to manage security from the Server Administration Console via Application Tier > Administer Security. I also receive the error when I attempt to set permissions via tfssecurity cli tool. I am in the local administrator group and I am listed in the console administration user section.
I'm trying to set permissions because after the update I received several reports from employees that receive errors when they try to access their projects. Those errors are:
TF40049: You do not have licensing rights to access this feature: Code.
*** Edit: Update
This error reoccurred when I upgraded from 2019 to 2020 RC1. The difference is, this upgrade required a migration of the server- since server requirements changed for the new version of DevOps Server.
I spent 8 hrs working through this issue yesterday, and this is what fixed our problem:
deleted DevOps server cache. (location of cache listed in devops admin console on server)
reboot server.
I deleted the cache off the server based on an article I read with the same error, a user was having security/permissions issues with visual studio and they deleted the vs cache on their local machine and it solved their problem. I don't know if deleting the cache or the reboot would have fixed it independently because I did them both as a single troubleshooting step.
Hope this helps someone.
** Edit: Update 08/13/20 **
After upgrading again, I have ran into the same issue and this does not fix my error anymore. I've tried deleting the server cache, rebooting, reapplying permissions, configuring a new service account, reapplying changes, rebooting again, etc. I still have not found a solution for this error. I cannot schedule backups through the supplied backup scheduler without permissions to manage security settings through the configuration panel.
I'm installing TFS 2015 Express. I can't get past the configuration process. I'm getting the Windows Security popup. I've typed my username and password. My username is being recognized but not my password.
Which credentials TFS is expecting? I'm entering the info I use to login to Windows.
Thanks for helping
You could use local Admin account or Domain account to install TFS2015 Express.Try below ways to narrow down the issue:
When you run the tfs_express.exe to install, right click the .exe
and select run as administrator.
Disable your antivirus software or add the .exe in trust list.
Remove your account info which stored in Credential Manager (Control
Panel-All Control Panel Items-Credential Manager-Windows Manager) and
try again
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.
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.)
I am using VSSConverter.exe to migrate from VSS to TFS (About time too). I am having an issue because the account I am running it under is not on the same domain as the TFS server. Is there any way to tell the VSSConverter.exe tool which server account to use?
For example when I use the tf command line I add the /login:myname,mypassword switch like this:
C:> tf dir $\ /login:myname,mypassword etc...
Is there some way I can do the same with the VSSConverter.exe?
The error I am getting by is this:
TF60071: Your user account does not have permission to connect to the Team
Found ation Server 'https://www.example.com/tfs/DefaultCollection'.
Please contact your Team Foundation Server administrator and request that
the appropriate permission be added to your account.
VSSConverter.exe will try and connect to TFS with the account that it is currently running as. Sometimes that account cannot be added to TFS, or used with TFS - e.g. There is no domain trust between the two domains.
To specify alternate credentials, you can use the windows credential manager to store them. VSSConverter will then try and use these to connect to the server.
In Windows 7, you can do this:
Control Panel > User Accounts > Manage Windows Credentials > Add a Windows credential
Network address: www.example.com
User name: DOMAIN\user
Password: Password
You can also get to it by going to:
Start > Run
Type: **rundll32.exe keymgr.dll,KRShowKeyMgr**