Best way to share a network between joint venture partners

BACKGROUND
Our company has recently entered into a Joint Venture (JV) in which we are the managing partner. As the managing partner, we are responsible for the network setup and support. This JV is only for one job and neither partner wants the other partner to have access to their rest of the existing networks.

We need to share files from an AD network, VOIP phone system, printers, and a couple of SQL servers. The plan is to physically put all shared resources at the site in question and have both JV partners login to our AD for authentication to the shared resources. Each of the JV partners have existing AD networks that will be accessed via VPN tunnels from this shared site. Each of the JV partners will continue to retain their existing email and existing shares from their home sites.

Both partners are currently Win2003R2 shops running WindowsXP with initiatives to push out Windows7 within the next 6 months. The SQL servers are version 2005.
This site will be active for about 4 years.

QUESTIONS
How can we allow our partner to login to our AD, but prevent them from accessing any other servers except for the ones on the site?
How can we set this up so that each partner's respective IT departments can manage the local workstations without any admin privileges on our AD?
Currently, we are working from the network diagram below. Using VLANs we can prevent each JV partner from traversing the others' VPN link and still allow access to the shared resources, but this setup does not allow each joint venture partner to manage their own workstations and users.

Some other ideas we have been tossing around are:

• Setting up a 2-way trust between the JV partners and allowing each partner to manage their own users and machines. What are the pluses and minuses to this? How far does this trust extend?
• Creating a new domain and setting up 1-way trusts from each of the original domains. What are the pluses and minuses to this?

Solution 1:

re: "How can we allow our partner to login to our AD, but prevent them from accessing any other servers except for the ones on the site?"

I'd strongly encourage you to create an AD forest expressly for the JV resources. Create one-way intransitive forest trusts with the JV members' existing AD infrastructures. Using selective DNS forwarding, maintain the DNS for the JV in a secure AD integrated DNS zone hosted by JV servers. This keeps the partner at "arms length" from your own servers. Both partners should be explicitly placing shared data / applications / servers into the shared area. Using your existing AD for the "shared area" may save you a little money on licensing, but it's not worth the added risk and complexity.

re: "How can we set this up so that each partner's respective IT departments can manage the local workstations without any admin privileges on our AD?" and "Currently, we are working from the network diagram below. Using VLANs we can prevent each JV partner from traversing the others' VPN link and still allow access to the shared resources, but this setup does not allow each joint venture partner to manage their own workstations and users."

I'm not sure I understand. I see what you're saying re: isolating network traffic from the JV members, but I'm not following the rest. Are the JV members going to have user and computer accounts in their own AD forests, or in the JV forest? That's unclear to me. I'd have the JV members maintain their user and computer accounts in their own AD forests, and grant access to JV shared resources though membership in groups in the JV AD forest.

Ohh! I think I'm getting it. At this "site" there will be some client computers that are shared by the users from both JV members working together! Am I right?

You could handle those "shared" computers a number of different ways.

I'd probably join the computers to the JV AD domain, but you might not. The ownership of the client computers would probably dictate how I'd handle that. If the client computers remains with each JV member then I think I'd join them to the owning JV member's AD domain.

With client computers joined to the JV AD domain user accounts from either JV member domain (as well as the JV AD domain itself) could be used to logon to the client computers (since there would be trust relationships in place from the JV AD forest to the members' AD forests).

Be aware that it would be helpful to have read-only domain controllers from each members' AD forest in place at the "shared site". If the client computers ared joined to the JV AD forest computer group policy will come from the JV AD forest. User group policy would come from the members' AD forests, though, so having a local DC would be helpful. If the client computers are joined to the members' AD forests then, obviously, having a local DC from each members' forest would be nice.

Delegation of control in the JV AD forest can be used to give the JV members' IT staff any abilities they need in the JV AD forest itself. Group policy "Restricted Groups" could be used to grant JV members' IT staff administrative rights over "their" client computers that are joined to the JV AD domain. (Client computers that remain in the members' AD forests are a moot point.)

re: "Setting up a 2-way trust between the JV partners and allowing each partner to manage their own users and machines. What are the pluses and minuses to this? How far does this trust extend?" and "Creating a new domain and setting up 1-way trusts from each of the original domains. What are the pluses and minuses to this?"

A Windows "trust relationship" does not grant access to anything, per se. Look at this statement: "Domain A trusts domain B."

Now, replace the word "trusts" with the phrase "is permitted to name in permissions users, groups, and computers from": "Domain A is permitted to name in permissions users, groups, and computers from domain B."

A "trust" doesn't grant access, it permits you the ability to grant access. If you have a dedicated JV AD forest you'll want it to have external intransitive 1-way trusts with the JV members' AD forests so that users and groups from the JV members' forest can be named in permissions or joined to groups in the JV AD forest. This would allow the user and computer accounts for each JV member to be managed in that member's own AD forest. By using groups that are located in the JV AD forest to control permissions to JV resources the JV could effectively manage permission to access JV resources.

You wouldn't want a 2-way trust in any circmstance, from my understanding of your situation. Am I correct in thinking that it is not mutually desirable for either JV member to name the users, groups, or computers from the other member in permissions? It sounds like there aren't going to be shared resources hosted on servers owned by both JV members, so mutual trust isn't necessary. Having said that, again, a 2-way trust only permits the capbility of granting access and does not actually grant any access.

I have some experience with a similar project a few years ago between a local hosptical association and several groups of doctors. In their case, they created a dedicated AD forest for the JV, but didn't create trust relationships to the existing JV members' infrastructures. We ended up with duplicate credentials in both the JV members' local AD and the JV AD. That was the biggest "wart" that I saw in their network, and something I'd avoid in the future.

I see that you're in construction. I have a Customer who does contact engineering and project management for large-scale constructions projects and often has employees located in field offices (aka "trailers") on Customer sites for years at a time. I have yet to have a situation where the Customer or another contractor on the project go to the level of detail that you're looking for, but the situation I outlined above would be how I'd pursue it if it did happen. The expense of a few Windows Server licenses and computers to host domain controllers for the JV AD (and members' on-site read-only DCs) isn't much amortized over 4 years, and creates a very solid foundation upon which to conduct shared operations.