1

Resolved

Problem authenticating against the TFS Server

description

Hi guys - I spent some time installing TfsBuildLab, and initially had trouble getting it to work. Every time I started the service, I was getting exceptions in the event log, with the following message: "You are not authorized to access the server <tfsserver>". I thought this may have ben to do with the event registration security permissions, so I set the events up manually and turned auto event registration to false, as per the install instructions, but I continued to get exceptions logged with this same message.
 
I hunted through the code, and I found that in the Callista.BuildLab.Core.Tfs class, the exception was occurring because of the following code:
 
                if (string.IsNullOrEmpty(tfsUser) && string.IsNullOrEmpty(tfsPassword))
                {
                    _tfs = new TeamFoundationServer(tfsUri);
                }
                else
                {
                    _tfs = new TeamFoundationServer(tfsUri, new NetworkCredential(tfsUser, tfsPassword));
                }
 
 
In my case, I have values for both tfsUser (in the format domain\userid), and tfsPassword, as I specified these in the config file. It appeared that having the domain specified as part of the userid string does not result in the domain value being applied to the NetworkCredential in the line contained within the "else" block. In other words, because the code is not explicitly setting the domain, tfsBuildLab is trying to connect to the server using credentials which have a uid specified as "domain\username" and a blank domain string.
 
To resolve this issue, I believe that either the above code should use the TeamFoundationServer constructor that does not take the network credentials (this results in the thread principal's identity (i.e. the service account) credentials being used, which means that the service must be running as an account which has permission to connect to the server (as an admin??)), or the code inside the else block above should also be specifying a domain. It would be possible (and probably less complicated for configuration also) to perform a string.split on tfsUser to separate the domain out from the actual userid, otherwise I'd suggest simply including a new config setting for the user's domain, and changing the tfsUser setting to accept a uid only (without the domain specifier).
 
Cheers
Mark

comments

PeterBlomqvist wrote Sep 20, 2007 at 6:51 PM

Mark,

Thanks for an excellent post and tracking down the problem, we will fix this in v1. I hope that it works well for you otherwise.

/Peter

wrote Sep 20, 2007 at 6:53 PM

wrote Sep 20, 2007 at 7:51 PM

MOlausson wrote Sep 20, 2007 at 7:57 PM

Hi Mark,

Thanks for the feedback - I've added a check if the tfsUser is specified as a domain\user and if so I split and pass each part to the constructor. Hopefully this will help in your case. The strange thing is that I've used the user\domain in my environment and it has worked fine. But anyway, the fix feels more appropriate and.

The change is checked in as changeset #4579 and will be in the v1 release in the next couple of weeks.

// Mathias

Markl_nz wrote Sep 26, 2007 at 2:39 AM

Awesome, thanks heaps guys.

Mark

wrote Feb 13, 2013 at 1:49 AM

wrote May 14, 2013 at 10:15 PM

wrote May 14, 2013 at 10:15 PM

wrote Jun 12, 2013 at 12:23 AM