Accessing Team Foundation Server Remotely


Team Foundation client applications, such as Team Explorer, access Team Foundation Server functionality through a collection of Web services hosted on Internet Information Services (IIS) 6.0. The initial RTM release of Team Foundation Server only supports Integrated Windows Authentication, which allows clients to use their Windows credentials to access this functionality.


 


Integrated Windows Authentication is an ideal choice for most deployment scenarios in a corporate environment, but it is not an optimal choice in Internet scenarios due to limitations resulting from proxy servers, firewalls, and trusted connections. For this reason, we originally planned to support Basic and Digest authentication as well. For more information, see Integrated Windows Authentication (IIS 6.0).


 


Unfortunately, we were not able to complete this implementation in time to ship with the initial RTM release of Team Foundation Server. We are continuing to work on adding this support in the near future, which should be available sometime soon after the release of Team Foundation Server. However, this means that Team Foundation Server does not immediately support some scenarios, such as accessing Team Foundation Server through a proxy that does not maintain a connection between the client and server.


 


This does not mean that Team Foundation Server is not accessible from across the Internet. You can use a Virtual Private Network (VPN) should your scenario require accessing Team Foundation Server from outside your local intranet. Alternatively, and subject to your own risk analysis, you may opt to expose your Team Foundation Server directly to the Internet and require the use of encrypted connections (e.g., HTTPS using SSL/TLS); however, you may be thwarted by proxies on the client side of the equation, such as those provided by Internet Service Providers (ISPs).


If your intended use of Team Foundation Server requires support for Basic or Digest authentication, we would like to hear your feedback on the importance of these authentication mechanisms in your deployment scenarios.


[Now available as a KB article: http://support.microsoft.com/kb/916845] 


754

Comments (39)

  1. Dave says:

    Dev’garten’s (http://www.devgarten.com) TFS instance is sitting behind an ISA 2004 Reverse Proxy with Integrated Auth doing the howdoyoudo stuff.

    I connect to it via VSTS and I enter my creds that run against the server. It will be moved over to SSL when my certificate arrives, which will secure the comms, although there isn’t anything critical on that infrastructure yet.

    The age old issue of publishing services via the web have always had this issue; however, the strengths in having high-value services managed in a carrier-grade DC always outweigh trying to maintain your own home garden.

    I’m a big believer in put your money into redundant, high-speed connectivity infrastructure and relocate your apps to DC’s, where someone else is worrying about perimeter security, DR, backup. That’s why I think hosted and leased TFS services will be huge πŸ˜‰

  2. Rob Caron blogs about the Team System Friday Morning Briefings.  He also talks about Project Server and…

  3. Marc says:

    This is the worst news I’ve head in a while.

    I’m truly speechless and befuddled…

  4. Jamie says:

    Rob-

    We’re setting up TFS in our office in the states, and are going to be working with some developers in India. They have their own domain, and are likely not going to trust our domain.

    During our testing of TFS, it seems that we are ok for connecting via the Team Explorer, as it simply prompts for your credentials, and they can enter a username/password that we’ve created for them in our domain.

    However, a bigger issue is the Proxy server for TFS. I can’t seem to get it working. I know the documentation states that you must have the exact same domain account running the TFS Proxy as the main TFS service account, but I REALY REALLY need a way around that – as they are reluctanct to trust our domain.

    Any suggestins?

  5. Gary says:

    Dave,

    How did you configure your ISA 2004 server?  We’re trying to configure our ISA 2004 server to provide an https/ssl link to our TFS but are having little joy at the moment.

  6. Steve Smith says:

    Working over the Internet is extremely important.  Being able to add consultants, contractors, and even FTEs who are working remotely is extremely common today, both for large enterprises and for smaller organizations.  Not supporting basic "over-the-internet" scenarios is a huge shortfall for VSTS in my opinion.  Basically the product only works using client-server architecture, not Internet and web services architecture.  Very, very disappointing, to me, at least.

  7. Steven Smith says:

    I had to buy a new box to install Team Foundation Server — apparently it just won’t work on my old Dell…

  8. RobCaron says:

    Jamie –

    I asked some people to look into this. One suggestion is to move Team Foundation Server to its own domain. That new domain could be given a one-way trust to the domains in the US and India. That would not impact what the India domain trusts, or what the US domain trusts.

  9. JerryNixon says:

    I just read this blog to our development team. Shoulders sunk and we all muttered how horrible this is. Thank you for making this clearly known, however.

  10. Jamie says:

    Thanks, Rob. I will look into your idea. I was also thinking of joining their (India’s) TFS Proxy server to our domain, even though it is located in India. That may or may not be simpler???

    Please let me know what you find regarding the TFS Proxy account. It seems that since we require the India team to use VPN into our office servers, getting the Proxy to work is the last step!

    Thanks for your help!

  11. RobCaron says:

    Jamie –

    In your comment you said, "I know the documentation states that you must have the exact same domain account running the TFS Proxy as the main TFS service account, but I REALY REALLY need a way around that – as they are reluctanct to trust our domain."

    However, this isn’t a requirement. The only requirement is that the "TFSProxy" account must be a member of the Team Foundation Server Valid Users group on each Team Foundation Server for which it proxies.

  12. David says:

    I hate to beat this issue into the ground, but being able to connect to TFS over the internet is essential for our development team. When you think this issue will be resolved or a patch/SP will be issued?

  13. Mike says:

    Access over the Internet is absolutely necessary. This is a huge disappointment! We have been readying ourselves for the rolling out of TFS as we are shifting from Delphi to VSTS at the start of a big new project. We have a distributed development team with members spread across 2 states. We have worked this way for 7 years and I would imagine having a distributed development team is now the rule not the exception. Limiting TFS to only be accessible via a local LAN, or going through the huge expense of setting up a VPN or HTTPS, is ridiculous. I guess we’ll have to use our existing source control and bug tracking tools, that we’ve been able to access via the Internet for the last 7 years, until a real version of TFS comes out.

    This should be priority one for the next release. It’s a showstopper problem.

  14. Emilio says:

    I agree with Mike, we were expecting more of TFS. Specifically an easy way to make it accesible from internet.

  15. Distributed access should be a cornerstone feature of TFS.  Very poor planning on Microsoft’s part.

  16. kfrost says:

    Wow, that’s one of the biggest reasons I was looking to get TFS installed and have spent the better part of the day reading up on it.  Glad I didn’t dive in and install it.  

    Extremely disappointed.

  17. DavidKean_MS (Moderator): We’ll be starting our chat about Visual Studio Team Edition for Software Developer…

  18. Ben says:

    I have a scenario where I have developers working on the same project from multiple sites. My team is entirely distributed and none of us work in the same location. Due to my developers setups, VNP isn’t a viable option either.

    This is basically going to force us to adopt VSS 2005 but we will be loosing out on the work item tracking etc which is one of the most important features of TFS for us.

    Until TFS supports remote connectivity there’s absolutely no point in adopting it, from our point of view anyway.

  19. We are currently migrating to Team system from the Visual SourceSafe.  We have developers in offices…

  20. Jamie says:

    Rob/all – I finally have a TFS environment set up that involves two different non-trusting domains, where the TFS server is in our "main" domain and the clients are in a different domain. There is no trust between them. Then I configured the Proxy server on a machine that is not a member of either domain, but is located at the remote location (over in India along with the TFS client workstations). Everything is working great – although I know this is not supported by MS:)

    The trick was getting the right combination of local versus domain accounts. The local accounts had to be configured properly to allow pass-through authentication. The local accounts included the proxy service account.

    I created a Visio diagram of how I got it to work. If you would like to see it, let me know on this blog.

  21. Faysal says:

    Hi Jamie,

    We have a very similar scenario with yours’. Would you please share your visio diagram with me. my e-mail is faysalbasci(-&at&-)yahoo.com Thanks in advance

  22. Kevin says:

    Jamie –

    I would also very much like to see your visio diagram on how you set this up.

    kevinw -AT- software-logistics.com

    Thank you!

  23. PJ says:

    This is a huge problem, not being able to operate VSTS across the internet without a VPN. It eliminates a lot of use scenarios for us. I’m glad to hear you plan to add this in this functionality in the near future.

  24. DusanMihajlovic says:

    Jamie,

    could you please forward the visio diagram of the solution to this dreadfull problem – my e-mail is "dusan at finsoft dot com".

    I am following Team System forums, and there are a lot of answers to people that can’t be bothered to read the documentation, but whenever a fundamental question like this is asked it stays unanswered.

    This is more of Microsoft behaviour from early nineties than what we were used to in .NET era. Really disappointing.

  25. james.mcallister@bakerhughes.com says:

    I have a similar scenario with yours. Could you please share your visio diagram with me. My email is James.McAllister@BakerHughes.com

  26. Rob Caron says:

    In Brian Harry’s recent Tech Ed 2006 and Stuff in the pipe for Team Foundation Server…

  27. Alan Buck says:

    Is this still true? You can’t access TFS using basic or digest authentication. I found some information that you could set up this if you moved the TFS into a workgroup. If this is all still true then when will you be able to have basic or digest authentication within a domain?

  28. Joshua says:

    Jamie could you send me a copy of your Visio as I am facing a similar problem. joshua DOT allanson AT gmail DOT com. Thanks

  29. Deepak says:

    Hi Jimmi,

    Can u please send that Visio diagram to me at khare_deepak@hotmail.com, since i have to make setup of TFS in the same way.

    Appreciate your help.

    Regards

    Deepak

  30. Stephane says:

    Hi All,

    We are facing the same problem. Can this visio diagram be downloaded somewhere ?

    Best-

  31. SteveM says:

    Hi,

    Jamie’s solution above to the problem of working with Team Server across different domains is very elegant and I hope that someone can post the diagram.  A possible problem is that the TFS proxy server works to make the source code control very efficient, but still does not address the fundamental problem of authorization across two non-trusting domains which immediately happens with reports and the project portal.

    I have a similar situation to Jaime but have a serious issue with the handling of local accounts.  The entire purpose of domains and AD is to handle the administration of accounts and access.  If we have to set up local accounts for all users in both domains then we have defeated the purpose of the AD administration.

    I need to implement a solution whereby development groups in domains X and Y have equal access to a Team Foundation Server located in either domain.  

    – Steve

  32. SaloS says:

    Send me this visio dialgram too

    salos at mail dot ru

    Thanks

  33. Pancham says:

    Jammie

    We are also in the same situation. Can you please share your visio? My email address is pancham_singh@yahoo.com.

    Steve,

    Have you found any solution?

    Thanks.

  34. TFSλ₯Ό μ΄μ „ν•˜λ©΄μ„œ μƒˆλ‘œμš΄ 사싀듀을 μ•Œκ²Œ λ˜λŠ” 것듀이 κ½€ μžˆλ‹€. κ·Έ μ€‘μ—μ„œλ„ Basic 인증을 μ§€μ›ν•˜μ§€ μ•ŠλŠ” λ‹€λŠ” 사싀은 μΆ©κ²©μ μ΄μ—ˆλ‹€. Beta 3κΉŒμ§€λ„ 정식 λ²„μ „μ—μ„œλŠ” μ§€μ›ν•˜κ² λ‹€λŠ”