TFS extension authorization failure after upgrade to v6, and then rollback to v5.8.3

pdickers_0718

I had BuildMaster version 5.8.3 installed and working correctly. I am using the TFS extension to retrieve the latest files from a TFS2017 repository, and this has also been working fine. The TFS repository is on a different (Windows) server in the same domain as the server with BuildMaster. The TFS extension in BuildMaster was using a domain account to connect to TFS.

I upgraded BuildMaster to v6.0.1, and also added the "TFSLegacy" extension. However, after the upgrade, the TFS "get latest" step stopped working, with something like an authentication or authorization error, I think.

Then I uninstalled the TFSLegacy extension, uninstalled v6.0.1, re-installed v5.8.3, and restored the database from the (v5.8.3) backup that was created by the installation of v6.0.1. Everything seems fine with the applications except that the TFS "get latest" step no longer works.

I have tried re-entering the account information in the SCM provider information, but a "test connection" returns errors like:

Provider error. Could not connect to TFS: Microsoft.TeamFoundation.TeamFoundationServerUnauthorizedException: TF30063: You are not authorized to access [URL for TFS]. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.GetResponse() at Microsoft.TeamFoundation.Client.Channels.TfsHttpWebRequest.SendRequestAndGetResponse(HttpWebRequest webRequest, WebException& webException)

On the server with BuildMaster, I can open a browser, and connect to the same TFS URL, and successfully log in with the account that I am using for TFS in BuildMaster. I also tried using an account that's local to the TFS server (not a domain account); this also fails with the same error, but that account also works from a browser.

Any suggestions for tracking down the cause of this error?

Product: BuildMaster
Version: 5.8.3

Hmm ... just a quick response to start...

The extension code didn't really change between versions, just the SDK it was compiled against (InedoSDK vs BuildMasterSDK). This seems consistent with the install / rollback you encountered, so I don't think it's particularely related to a software change...

So a 401 means unauthorized, but it seems TFS isn't providing any more information. Since you're using the web to test the conenction, make sure the Application Pool is running the same user account you are.

It could also be a proxy server, since the browser uses a proxy server by default,

pdickers_0718

In BuildMaster, the setting for "Proxy.Enabled" was set to enabled; I have tried the setting for "Proxy.BypassOnLocal" set to both true and false with no change.

I also tried both a fully-qualified server name and just the server name in the URL for TFS, but neither changed the result.

In IIS on the TFS server, the IIS log included entries with 401.1 results with a win-32 status of 3221225581. I added the local account that I am currently attempting to use to the Remote Desktop Users group on the TFS server, and then successfully logged in to the server using remote desktop with that local account.

After that, I did get a one-time successful connection from BuildMaster to TFS, but it didn't seem to last. Now IIS on the TFS server is logging 200.0 results from this account when it connects, followed immediately by a 401.1 error with no user account listed in those log entries. BuildMaster still shows a 401 error.

401.1, that's some progress. Basically, this means that integrated authentication is not working; there are only those few settings you can change on the BuildMaster side (use system account, default credentials, etc), so if it doesnt work, then it means something on the domain or TFS server changed.

your best bet is to search for "401.1 errors" -- here's something that came up for me, but i don't know if it work fo ryou https://support.microsoft.com/en-us/help/896861/you-receive-error-401-1-when-you-browse-a-web-site-that-uses-integrate -- there are a ton of other articles / suggestions that came up, too.

pdickers_0718

I discovered one more thing.

If I edit the existing source control provider for TFS that I have set up (or if I create a new one) - if I enter the (current, valid) password in the password field and then click "Test Connection", it works, but if I save the provider configuration, open it again and test the connection (with the already saved valid password), it fails with the 401 unauthorized error.

It seems like the provider configuration is not saving the account password, or is saving it incorrectly.

pdickers_0718

I discovered one more error detail. BuildMaster logged an error that it couldn't use the folder (for the "get latest" copy on the build server) because it belonged to a workspace for a different account.

I believe this is because I changed from using a domain account to a local account on the TFS server machine for the TFS connection from the BuildMaster machine.

I deleted the workspace for the previous account. I edited the TFS connection in BuildMaster, entered the account information for the local account that I am now using, and saved it without doing a "Test Connection". Now, everything seems to be working okay.

This installation of BuildMaster has been through many upgrades. Maybe someday I will do a full uninstall and a clean install of the latest version, and build new applications in that version, etc.

If anyone needs to know, I found (and then deleted as needed) the TFS workspaces as follows (this is using TFS 2017 and Visual Studio 2017).

On my workstation with Visual Studio 2017 installed, I ran the "Visual Studio 2017"-"Developer Command Prompt". This opens a command prompt window with all the appropriate environment variables set to allow the "TF" command to be used.

Then, run:
tf vc workspaces /owner:* /computer:* /collection:"http://URL-for-TFS-collection/"
to show all the existing workspaces (this shows username and workstation as well).

To delete an existing workspace, use a command like this (note that this uses the singular form "workspace" where the previous command uses the plural "workspaces"):
tf vc workspace /delete /collection:"http://URL-for-TFS-collection/" WORKSPACE-NAME;USERNAME-for-the-workspace

This will let you know if there are any pending changes in the workspace, and ask if you are sure you want to delete the workspace.