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.
Related
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.
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.
How hard is it to enable TFS to start using secure connections, if its not already? Does doing so affect SQL configuration also? How can we force SSL to be required?
Im looking over this reference material
https://msdn.microsoft.com/en-us/library/aa833872%28v=vs.120%29.aspx#DisAd
Reading the above, I get the impression that MS is trying to discourage someone from using SSL for TFS over the internet?
Then I stumbled on to this blocg post
http://www.jwsecure.com/2009/01/29/using-tfs-via-the-internet/
Summary = just get a ssl cert and force ssl and port-forward a high port to 443
thoughts?
Firstly, the MSDN article you posted above shows you the detailed steps on how to set up HTTPS with SSL for TFS. To summarize main steps include:
Install a certification authority, obtain and install a server certificate for servers.
Request, install and configure websites with a certificate for Team Foundation Server using Internet Information Services (IIS) Manager.
Configure Team Foundation Server to require HTTPS and SSL.
Install the certificate on client computers.
You can also check this walkthrough: https://msdn.microsoft.com/en-us/library/aa833873.aspx
Secondly, you don't need to configure SQL Server. But if you have SQL Reporting Service, you need to configure it to support HTTPS with SSL.
Thirdly, to enable TFS to be available with external connections, you need to configure it with HTTPS with SSL. Also with it, web connections to TFS are more secure. However, these process needs more administrator's configuration & maintenance work. So you need to determine whether to use it based on your requirement.
when I go to application tier, configure installed features ,start wizard,
it will ask whether I would like to have sharepoint on this machine or not, I go for it and the error displays is:
TF400081: Cannot connect to the Internet. An Internet connection is needed to be able to install SharePoint.
We are using a proxy on the network to access the internet, when I look in the log it says:
Exception Message: The remote server returned an error: (407) Proxy Authentication Required. (type WebException)Status: ProtocolError
Response Status Code: ProxyAuthenticationRequired
how can I run the standard configuration wizard do that it gets authenticated by the proxy?
This is because it's trying to download all the prerequisites for sharepoint. It may just be easier to do an offline install by manually installing the prereqs yourself.
http://blogs.technet.com/b/patrick_heyde/archive/2010/03/02/install-sharepoint-2010-without-internet-access.aspx
There is two ways:
1. switch off require authentication for your server on proxy
install your own intermediate proxy (Proxomitron.info for example) on you work computer and make TFS server to connect to you proxy instead of corporate.
And configure an intermediate proxy to bypass all connection without authentication.
My typical workflow is that I develop on localhost, but with Google Apps Marketplace this hasn't been possible. OpenID works fine, but access to Data APIs via Oauth results in errors.
Token invalid - Invalid token: ACL not found for domain: 358xxxxxxxxx and consumer: 736xxxxxxxxx
Currently I have been using the following workflow, but it is very tiresome.
local develop » local push to github » remote pull from github » remote test » repeat
Is there a way to develop locally or another suggested workflow?
Solution:
A mashup of #koma and #JTeagle suggestions, I have multiple branches with Oauth keys in each config respective of the branch. I also created a unique localhost domain my_project.dev which satisfies Google's requirements (since their localhost trigger wasn't working for me)
I am not sure what github as to do with it, but if I understand well, it is difficult to do OAUTH on localhost. That is indeed cumbersome.
My solution for this problem is to register my dynamic DNS domainname in the Google Api Console and then do port forwarding on the router to my development machine.
This way, your development environment can do all the OAUTH requests and the callbacks from Google hit the router, and I can debug them.