Take the 2-minute tour ×

We've had a single Team Foundation Server (for source code control) on our production domain for a few years (corp.ourcompany.net), and it's worked great. However, we've got a lab now and I'd like to extend source control access to developers operating there (testlab.corp.ourcompany.net). That way, developers working on code either in the lab or in the production network will have access to the same source code (This isn't a question about where to develop - I recognize it should all be in a lab of kinds, but it's not).

It's in a firewalled subset of the network, and there's no access from lab into production, so we've installed a TFS Proxy server in the lab and allowed all the necessary ports. However, since these are two different domains, I'm running into trouble - when I try to configure the proxy server, it asks for a service account that has access to the production TFS, and I can't add one:

  1. When I provide an account from production (corp.ourcompany.net\ProxyAccount), it won't resolve it
  2. If I use a testlab account, I can't grant this account access in production (the account needs to be able to view source code on the production server).

Do I need some kind of trust set up? I don't believe there's currently any, or if it's even an option with how we're set up, but I'm stuck - I can't seem to get the developers in the lab access to source control on the production TFS server. Even if they did have network access, I can't grant their testlab domain logins any kind of application access necessary to log in to TFS.

Am I missing something obvious? Are there other ways to get this accomplished? Other platforms may be more flexible than TFS, but I'm not ready to explore making a change there - I'm interested in a potential way to get TFS to accommodate my needs before I make the case to switch. Thanks!

share|improve this question

2 Answers 2

Use a shadow account. Create a user with the same name and password as one in the domain, but make it a local account on the remote proxy. You have to manually keep the password in synch if you change it on the domain, but it works in this sort of pinch.

share|improve this answer
As long as it can authenticate with NTLM instead of requiring Kerberos, this should work. –  mfinni Dec 14 '13 at 20:26
This might work - I'll try it tomorrow. I can definitely set it up to use NTLM, so I've got just a little bit of hope :) –  SqlRyan Dec 16 '13 at 6:29

To have accounts trusted across domains, you do need a domain trust.

Now, is it necessary to have a full copy of TFS in the lab? Can't you just export and deploy, same as happens when you give the sysadmins new code for them to deploy?

share|improve this answer
The problem is that the TFS server is in production, not the lab - when we stood it up 6 years ago, we didn't have a lab. Now, we're being encouraged to do all development in the lab, and we don't have any source code access there (hence this request). We do have the option of checking code out in production and copying it into the lab, working on it, copying it back and checking it into the server in production, but that's a terrible processes. We could stand up a new TFS server in the lab and export/import all the code, but since dev still happens in both places, we're still stuck. –  SqlRyan Dec 10 '13 at 20:28
Why don't you tell us why your lab environment is a different domain? Unless your code does things that require actual administrative rights over the domain? –  mfinni Dec 10 '13 at 21:26
And why would the devs need to be modifying code in the lab environment? If the changes work, they work. If they don't, wouldn't they rather be making changes using their nice dev tools on their own workstations? –  mfinni Dec 10 '13 at 21:27
I agree with you that it's not an ideal setup and I would love to see something different, but I don't make the decisions, I just work with them. I was really hoping for a potential solution to my problem rather than reasons why I shouldn't have my problem in the first place. –  SqlRyan Dec 11 '13 at 15:49
The solutions have been provided : either don't use a different domain, or add a domain trust. Or re-architect everything. –  mfinni Dec 11 '13 at 16:08

Your Answer


