right now I am trying to Setup Continuouse Integration - Delivery for a basic WCF Service, which will be hosted on a Microsoft Azure VM. The Project is Version Controlled through Visual Studio Online. So I installed Jenkins (also on the Azure VM), TFS plugin etc. and started the first Test Build:
As Server URL I used "[VSO Adress]/DefaultCollection"
and for Login purposes my Microsoft Account (I can Access VSO with that). The Problem is, when I run the Build I get the following error in Jenkins:
Started by user Developer
Building in workspace C:\Program Files (x86)\Jenkins\jobs\test\workspace
[workspace] $ "C:\Program Files (x86)\TEE-CLC-11.0.0.1306\TEE-CLC-11.0.0\tf.cmd" workspaces -format:brief -server:[VSO Adress]/DefaultCollection ****"
An error occurred: Access denied connecting to TFS server [VSO Adress] (authenticating as har****#*******o.com)
FATAL: Executable returned an unexpected result code [100]
ERROR: null
Finished: FAILURE
So my question is, whether it is generally possible to connect Jenkins and VSO that way and if so, which login credentials are needed
You will not be able to authenticate with your Microsoft ID as Jenkins is not able to get the encrypted token. If you head over to VSO you can open your profile (top right) and configure alternative credentials you can use them to login.
Also you can get service account credentials through the API. I created a simple tool for this: http://nakedalm.com/tfs-service-credential-viewer/
It's crude but usually works.
Related
I've been hitting my head against this wall for days now and to my knowledge I've followed every direction I've found. But I'm still getting a 500 Error when I browse to the URL.
What I've got to work with is a Windows Server 2012 R2 with IIS 8.5. I'm not married to IIS but I'd prefer not to dip into YET another tech just to get this running.
What I've done:
Old-style blazor-server app (with Program / Startup pair) without authentication. Dependencies:
SharpZipLib
LiteDB
published it using dotnet publish -o bin/publish --self-contained -r win7-x64
copied that folder to the server
On the server:
installed urlrewrite2
installed everything under Windows Features Word Wide Web Services and Web Management Tools
restarted
created a new site in IIS
set the application pool to unmanaged
set the physical path to the folder I copied from my dev system
What I haven't done:
Anything regarding Visual Studio as I'm currently forced to contend with Visual Studio Code and none of that applies/is possible here.
Provisional Workaround
running dotnet my.dll --urls http://*:1234 does work to expose the app to the network
the command needed to be run inside the application folder otherwise the app would fail to load the connection string.
I've also had to provision a production database and modify my appsettings.json accordingly
This is workable for now but not having the app "auto start" with the server is unsatisfactory.
Web deployment task failed. Error ERROR_USER_UNAUTHORIZED
We are using Tfs Build Automation and msdeploy for publishing an web application on remote machine.
On "Visual Studio Build" step we set this parameters on "MSBuild Arguments":
/p:DeployOnBuild=true;PublishProfile=myProfile;AllowUntrustedCertificate=true;UserName=$(UserName);Password=$(Password)
After quing the build we get this error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.targets(4276,5): Error ERROR_USER_UNAUTHORIZED: Web deployment task failed. (Connected to the remote computer ("MySERVER") using the Web Management Service, but could not authorize. Make sure that you are using the correct user name and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access the site. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.)
I am sure that username and password is correct, and the user isAdministrator on the server (MySERVER).
I checked the Management Service log on IIS and found something important:
the build agent's username(tfsadmin) sent for deploy on IIS instead of the user/pass that I set in build variables.
Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2018-01-03 09:29:02 MYSERVERIP HEAD /msdeploy.axd site=MySiteName 8172 - MyBuildServerIP - - 401 2 5 1322
2018-01-03 09:29:02 MYSERVERIP HEAD /msdeploy.axd site=MySiteName 8172 tfsadmin MyBuildServerIP - - 401 1 1326 86
Update 1:
I add more information, as you see below in build log, in msBuildArgs the password is empty (instead of ********)!
WebDeploy Version : 3.6
TFS Version : 2015.1
Target Machine (MySERVER) : Windows 2012 R2
IIS Version : 8.5
The "tfsadmin" user has local administrator of target server (MyServer) and IIS Manager Permission on the target IIS Site.
Build log :
2018-01-06T06:37:19.9298797Z Starting task: Build solution $/MyProject/MySolution.sln
2018-01-06T06:37:20.0529203Z Executing the powershell script: D:\Agents\Agent-01\tasks\VSBuild\1.0.16\VSBuild.ps1
2018-01-06T06:37:20.3760645Z ##[debug]Entering script VSBuild.ps1
2018-01-06T06:37:20.3790648Z ##[debug]vsLocation =
2018-01-06T06:37:20.3800653Z ##[debug]vsVersion = 14.0
2018-01-06T06:37:20.3810663Z ##[debug]msBuildLocation =
2018-01-06T06:37:20.3820668Z ##[debug]msBuildVersion =
2018-01-06T06:37:20.3830692Z ##[debug]msBuildArchitecture = x64
2018-01-06T06:37:20.3840679Z ##[debug]msBuildArgs = /p:DeployOnBuild=true;PublishProfile=myProfile;AllowUntrustedCertificate=true;UserName=tfsadmin;Password=;Pass2=********
2018-01-06T06:37:20.3840679Z ##[debug]solution = D:\Agents\Agent-01\_work\2\s\MyProject\MySolution.sln
2018-01-06T06:37:20.3860721Z ##[debug]platform =
2018-01-06T06:37:20.3870700Z ##[debug]configuration =
2018-01-06T06:37:20.3880727Z ##[debug]clean = true
2018-01-06T06:37:20.3890697Z ##[debug]restoreNugetPackages = true
2018-01-06T06:37:20.3890697Z ##[debug]logProjectEvents = true
2018-01-06T06:37:20.4010877Z ##[debug]Loading module from path 'D:\Agents\Agent-01\agent\worker\Modules\Microsoft.TeamFoundation.DistributedTask.Task.Internal\Microsoft.TeamFoundation.DistributedTask.Task.Internal.dll'.
...
Can anybody help me ?
You are correct that the wrong username and password were ultimately used to authenticate the request. Running the command net helpmsg 1326 (1326 is the sc-win32-status value from the log entry you provided) yields "The user name or password is incorrect."
Also interesting is the request/response logged before that. The substatus value 2 for a 401 means "Access is denied due to server configuration favoring an alternate authentication method." according to TechNet. And net helpmsg 1322 yields "This operation is disallowed as it could result in an administration account being disabled, deleted or unable to logon."
Review (or re-review) the instructions at https://learn.microsoft.com/en-us/iis/publish/using-web-deploy/configure-the-web-deployment-handler
If your deployment is still not working, take a look at Microsoft's Troubleshooting Common Problems with Web Deploy.
Deploy from VS with the command line will use the user name and password you provided. However deploy from TFS will use the build agent. So, the first thing is that the service account of the build process should has the correct permission to access the remote server.
Just try to give the build service account local administrator permissions and IIS Manager Permissionson to the site's scope on the remote server ("MySERVER"). Then set the username parameter to "" (empty quotes) and the password field omitted.
Reference: Build only works with username and password in msbuild arguments
This error code can surface because of a number of different reasons.
It typically indicates an authentication or authorization problem, and
can happen because of any of hte following reasons:
If connecting using the Web Management Service:
Verify that the username and password are correct
Verify that the site exists
Verify that the user has IIS Manager Permissions to the site's scope
If connecting using the Remote Agent Service:
Verify that the username and password are correct
Verify that the user account you specified is a member of the Administrators group on the remote computer. NOTE: Because of a bug
in Web Deploy 2.0, the user must be either the built-in Administrator
or a member of the Domain Administrators security group. Attempts to
sync with any other user account, even if it is an administrator,
will see this error code. Verify that the site exists
Reference : ERROR_USER_UNAUTHORIZED
UPDATE:
By default, Web Deploy will connect using HTTP Basic Authentication.
When using HTTP Basic Authentication, specific credentials must be supplied,
e.g.
msdeploy.exe -verb:dump -source:apphostconfig,wmsvc=demo-host,authType:basic,username=someuser,password=somepassword
In your scenario, you can try set the AuthType as NTLM, then try it again.
Just try adding the line <AuthType>NTLM</AuthType> to the publish .pubxml file.
Try this:
On your server go to Computer Management
From the left pan select Local Users and Groups
Go to users find the tfsadmin user
Right click on it and click on Set Password
Give your existing password (whatever it is)
This seems unnecessary but worked for me. I hope someone can explain the "why".
When I try to publish it I get the following error message:
Error 1 Web deployment task failed. (Could not connect to the remote computer ("..*.*"). On the remote computer, make sure that Web Deploy is installed and that the required process ("Web Management Service") is started. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DESTINATION_NOT_REACHABLE.)
I dont understand why is it referring me to a remote computer, I've specified the destination URL as my own IP address. And I have web management service checked on windows features.
How do I solve this particular error?
Try to publish to the file system, if this works move the files into you wwwroot, normally c:\inetpub\www.
then go to start and run inetmgr to open iis configuration manager, if you see your folder there right click and convert to application, accept settings then right click / manage / browse and you should see your site or an IIS error that should be easy to debug.
I never use the deploy to IIS feature from VS as it's pants.
Good luck!
The release notes for NuGet 1.5 state
NuGet now supports connecting to private repositories that require basic
or NTLM authentication.
However, the link contained in there simply leads to the hosting your own nuget feeds page, without any further mention of how to set up authentication.
I would like to set up a NuGet server that is accessible via https from the internet, but only allows people who can successfully authenticate to view or download the packages on the server.
I did create an application without auth as described in the Creating Remote Feeds section in the documentation, and it works nicely on the intranet. What do I have to do to enable authentication on this repo?
An additional requirement would be that solution should not cost hundreds of dollars (the first two answers promote products that might solve the problem but cost a lot).
This can be done by enabling Windows Authentication on the Web Site and adding credentials on the build server via the Sources command-line option, by default the credentials are stored using a DPAPI key restricted to the current user on the current machine (thus, for a build server, you would need to add credentials while logged in under the service account.)
For Developer workstations you only need to add the feed in NuGet Package Manager and then input/store credentials when refreshing the feed (you should be prompted.)
Step 1 - Require Authentication on NuGet Server (IIS Configuration)
You need to make sure the authentication module you wish to use is installed for IIS, for NTLM auth you will need the Windows Authentication module. Once installed you can open IIS Manager and drill down to your website, open the Authentication settings and Enable Windows Authentication, be sure to disable any authentication modules you do not want to support (such as Anonymous, Basic, etc.)
To ensure that user credentials are used, right-click on the Site and select "Advanced Settings", then click on the button for "Physical Path Credentials". In the dialog ensure that "Application User (pass-through authentication)" is selected.
More detailed information about standard IIS configuration for Windows Authentication can be found on TechNet including configuring from a command-line and enabling Negotiate (if that was your goal.)
Step 2 - Add Sources to NuGet Config (Build Server, Publishers)
nuget.exe sources add -Name "Fabrikam Feed" -Source "https://nuget.fabrikam.com:443/nuget/"
nuget.exe sources add -Name "Fabirkam Publish" -Source "https://nuget.fabirkam.com:443/"
Here we are adding two entries, one which will be used as the normal, authenticated Feed URL (for fetching packages from the server.) The second will be used for publishing to the server (adding or updating nupkg files.)
Step 3 - Update Credentials for Added Sources (Build Server, Publishers)
nuget.exe sources update -Name "Fabrikam Feed" -Source "https://nuget.fabrikam.com:443/nuget/" -UserName "Developer" -Password "g0d"
nuget.exe sources update -Name "Fabrikam Publish" -Source "https://nuget.fabrikam.com:443/" -UserName "Developer" -Password "g0d"
Here we have added credentials to the config, if you view %APPDATA%\NuGet\NuGet.config you should see the feeds you have added as well as encrypted credentials.
If you do not have the ability to log in as the server it is possible to store credentials in clear text by utilizing the StorePasswordInClearText option, but this is not advised in a shared environment.
Step 4 - (Optional) Disable the Publish URL in Visual Studio (Developers)
Open Visual Studio and navigate to the NuGet Package Manager Settings Dialog, untick the "Fabrikam Publish" feed. This will not affect your ability to publish, however, if you do not disable this feed you will receive errors when you try and refresh packages for "All" sources (as it is a publish URL, not a feed URL.)
Step 5 - (Optional) Store Windows Credentials in Visual Studio (Developers)
Open Visual Studio and navigate to the NuGet Package Manager, click on "Fabrikam Feed". You should be prompted for credentials. You can enter credentials here and tick the save/remember options. This ensures that attempting to refresh the feed in Visual Studio doesn't constantly ask for credentials. In the latest releases of NuGet Package Manager the feed is fetched using a standard HTTP request and the credentials you've stored to nuget.config are NOT used.
Notes:
You do not need a third party solution to host private, secure feeds. NuGet server is freely available and NTLM/AD/Windows security is supported by both IIS and NuGet tooling.
Developers who do not need to publish to the feed do not need to store credentials in their config. They also do not need a 'Publish' feed configured. This is only necessary for build servers or other publishers (re: Steps 2 and 3.)
All developers who will use the package feed will be interested in Step 5, this should be all that is required for most developers. They can simply add the feed from within Visual Studio, then enter their credentials when prompted.
If credentials change you can navigate to Start -> Manage Windows Credentials and delete "VSCredentials_nuget.fabrikam.com".
Step 2 can be performed in visual studio, but for clarity I've given the command-line here. Step 3, however, must be performed via command-line (or using the NuGet APIs.)
In a future release of NuGet rumor is credential information can be stored at the solution or project level (details are unclear), this is likely only of interest to people in a multi-tenant build environment where they do not have access to the build server.
Hope this helps someone else out there!
The solution I actually chose was to use TeamCity as NuGet server; while it's a bit of a hassle to set up because it lacks nuget push functionality, it now works nicely and at no additional cost serving NuGet packages to authenticated users only.
We are running Visual Studio 2012 and Team Foundation Server 2012. In the Team Explorer window, I am able to successfully connect to our TFS environment. However, when I select the Security link under Team Project or Team Project Collection, I receive a message "Team Foundation Server: Login Failure: unknown user name or bad password".
I have not found a log file or anything in any event viewer file that helps debug this problem.
Is there a log file I can search for that contains some 'hints' as to want the connection problem is?
where are your credentials stored on your locale machine that are used to connection team foundation?
We realized that the root cause for this issue is that Visual Studio is trying to open a browser using the same credentials used to connect to TFS. If those credentials are not allowed to run processes on your machine (I suspect in your case it’s domain users on a different domain which is not trusted by the client domain) then opening the browser will fail. That explains why you can hit those URLs using a browser instance that is opened using your own credentials.This will be fixed in a future release of visual studio.
In TFS 2012, the management interface for permissions and project settings has largely shifted to Team Web Access.
Clicking any of the following settings from Team Explorer 2012 will produce the "Logon failure: unknown user name or bad password" error:
•Team Project Collection > Security
•Team Project Collection > Group Membership
•Team Project > Security
•Team Project > Group Membership
•Team Project > Work Item Areas
•Team Project > Work Item Iterations
•Team Project > Project Alerts
I have the same problem. To correct it (temporaly), you must run VS 2012 with this command:
C:\Windows\System32\runas.exe /netonly /user:{domain\loginname} "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe"
Change {domain\loginname} by the domain and login name of your tfs domain account. A console will ask for your password and all works!
I also experienced the same issue with TFS. I found a solution for that. You have to remap your workspaces in your PC or Remote server. If you have any uncommitted changes in your projects, you have to keep backup, otherwise you will lost your changes.
Steps -
Go to Workspaces in Visual Studio
File-> Source Control -> Advanced -> Workspaces
Remove the current workspaces.
Remap the projects again.
I was experiencing the same issue with TFS Express 2012. I don't know if my situation applies to you but here are the facts:
My TFS instance was running on a remote server.
Neither that server or my local machine were on a domain.
I was using the same user account name on both machines but with
different passwords.
Setting the passwords to be same fixed the problem.
The functions that weren't working were the ones that launch the project website, which I could navigate to directly anyway.
Managed to fix the issue myself by mapping a drive to the area where TFS appears to have A cache located - but then I have 2 separate workspaces going across 2 separate domains