Cross Domain host resolution and authentication over a site to site vpn tunnel

turner20
turner20 used Ask the Experts™
on
Hi Experts,

My company (Comp_A) is currently working on a collaborative project with another company (Comp_B).  We have some of our staff sitting within their office (on laptops) connected to their network (not domain); the main file server is joined to Comp_B domain.  Our users have been issued with a user account on Comp_B's domain which they use to access the local network shares and print servers, but they also need to access the remote network shares in Comp_A domain.  The data on the file server in Comp_B domain will also need to be accessed from users over the WAN from Comp_A network. We have configured a Site-to-Site VPN to accomplish this, we can ping any host on each side of the VPN from the other but we cannot resolve hosts as yet on each side.  I did raise the idea of creating a trust between the two domains, but unfortunately the idea was rejected.    

I have two issues:-

1. What is the best way to configure the DNS in this scenario so my users in Comp_A domain can resolve hosts in Comp_B domain and vice versa?  I have thought about placing HOSTS files on my user’s laptops and workstations but it would not be ideal due to the number and rotation of the staff working on the collaborative project.  

2. My users (joined to Comp_A domain) when working on their laptops on Comp_B's network are being prompted for a username and password when they try and connect to network shares in Comp_A's network over the site to site VPN tunnel - i currently have temporary host file on the users laptops detailing Comp_A's hosts and ip's but they don't seem to be able to authenticate against the DC's - how can i achieve this over the vpn tunnel so they aren’t  prompted for a username and password each morning? (i would use vpn client software but we have WAN optimisers at each end of the tunnel so we need traffic to flow through the tunnel not over a vpn client connection for optimisation to work).  

FYI:-
Comp_A is running W2K8 with AD2008, Comp_B is running W2K3 with AD2003.
Comp_A has multiple subnets in the 10.10.0.0/16 range, Comp_B has one subnet 192.168.1.0/24    

Any ideas would be appreciated....

Thanks.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Commented:
If you have 2 domains and need to resolve dns in the other domain is to config in dns server for domaincorpa.local add a condicional forwarding for domaincorpb.local, especifying the dns server for corpb dns server and viceversa.
Another good option when you need to eork with resources in another forest for ad, is to set a trusth relationship and you can use the same users for your domain to give access to resources in the other domain. It's not difficult to config. Only google for how to make a trust relation between domains.
Commented:
serchlop provided a valid solution for the DNS setup.

I would add to that that if you need to be able to resolve host names for both Comp_A and Comp_B without using domain names (in other words, not using FQDNs), you may need to provide the clients with appropriate DNS Suffix search lists (meaning, if a DNS lookup is done for say "fileserverX", the client will try to resolve both fileserverX.comp_a.local and fileserverX.comp_b.local for example if needed). DNS Suffix search entries could be provided through DHCP, or manually.

As for the prompting of the passwords, setting up a trust relationships between the domains would have fully solved that issue as already brought up by both serchlop and yourself. For clarity, the trust relationship allows use of actual Comp_A accounts on the Comp_B domain and/or vice versa. You can set this up one-way, meaning Comp_A domain accounts will work on the Comp_B domain but not vice versa, or two-way, which means Comp_A and Comp_B domain accounts can be used on both domains. I don't know the situation, but perhaps a one-way trust instead of two-way would be acceptable?

Note that even with a trust relationship in place, it is still up to you (or someone) to configure permissions on various resources as appropriate. For example, on Comp_B's file server you would need to configure file share(s) to allow access to Comp_A users or groups (assuming built-in entities such as "everyone" aren't used).

The bottom line is that without the trust, the Comp_B machines will not know who any Comp_A user or machine is, and so must ask for authentication for every session (and will only recognize Comp_B accounts), and so without any trust relationship between the domains, there is really no proper way to handle authentication the way you want.

Clients may be able to save credentials for resources belonging to the other company by checking the appropriate box to remember the password where permitted, but this is not ideal. You could even do something like use a startup script that establishes an authenticated session to for example \\fileserverX\ipc$ with the other domain's username and password supplied in the script, but this is ugly and insecure. It may be pointed out to management that if users and/or admins begin resorting to "hacks" such as this, or saving passwords etc., security can be expected to be at greater risk than with a cross-domain trust in place, assuming both domains are properly administered to begin with.

Author

Commented:
Thanks guys for your comments.  You've both answered my questions.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial