3

My organization is in the process of setting up a new network at a hosting provider for a very large application project. Since the whole system uses Active Directory we are planning on using a pair of Domain Controllers there that replicate to our headquarters over VPN. These DCs would also serve as backup for our existing system so we could lose connection or power entirely at our headquarters and the remote system could stay up and still let people log in.

Our hosting provider has setup 10.180.87.0/24 as our subnet to use with them. But because our internal IPs are 192.168.1.0/24 and they already have it in use they require us to NAT over to 192.168.50.0/24. This part wasn’t a big issue and easily setup with our Watchguard firewall appliance.

First sign of trouble was when I put the two servers on the domain and they couldn’t connect or find the domain at all. I ended up putting a post-NAT address of DOMAIN.LAN into the hosts file on both servers. They were then able to locate and join the domain.

Making them Domain controllers however has been a problem. They get all the way through setup and then fail with an error when they try to setup all the replication with “RPC server is not available”. I know the domain is prepped correctly, Last week I did all prep work to promote a new server to DC to replace an older machine which went through fine.

I suspect the NAT is the issue and servers are trying to set themselves up with pre-NAT addresses. Our provider wants us to remap our IP scheme to fit with their network and I'm not exactly thrilled with the idea. One option we are considering is creating a server and network on 192.168.50.0/24 and using intersite replication to go from 10.180.87.0/24 to 192.168.50.0/24 to 192.168.1.0/24 (although that is probably gonna be messy network config-wise to figure out.) But I’m not completely convinced if that would solve the issue. A DMZ is another option but need to look into it more before I try to get our provider to set that up.

Has anybody had experience with a similar setup or alternatives for getting DC setup on a remote connection?

Improve this question
3
  • 2
    I wonder whether the right architecture in thie scenario might be to use Federation services instead of remote DCs. Not sure Domain controllers will have much luch replicating over a NAT'd connection
    – uSlackr
    Mar 13, 2012 at 22:39
  • Yes I agree with the above commenter. Please don't do this.
    – Ryan Ries
    Mar 13, 2012 at 22:47
  • We already run FS but it is out of our headquarters, which unfortunately means if our main site goes down for whatever reason we lose FS.
    – Shial
    Mar 14, 2012 at 12:45

2 Answers 2

Reset to default
10

You don't want to do this through NAT. You could construct a nightmarish scenario where you manage the DNS records for the DCs and hand-register the NAT "outside" addresses in the DNS. With the right port-forwards through the NAT you could probably make it all work.

You would be best served with a site-to-site VPN to allow the DCs to have transparent communication and to allow them to register their NIC-assigned addresses in DNS. IPSEC on public IP addresses is a possibility, too.

Beyond the network communication issues, though, I think you have a security architecture concern.

I would argue that you need two AD forests. Your "back office" AD forest should really be separate from the AD forest that runs your application. You can certainly have a replica DC from the application forest within your physical headquarters location, but I'd strongly caution against a two-way trust between the forests. I certainly wouldn't want both domains to be part of the same AD forest.

Improve this answer
1
  • This is on a site to site VPN so I'm having serious doubts about how the hosting provider setup this connection on their end.
    – Shial
    Mar 14, 2012 at 12:49
1

I got it to work due to the time crunch but it is a complete hack and I am working on rebuilding the whole network in the next few months to eliminate the need for it. As it turns out the domain lookup is via the server IP but replication is by looking up the GUID. Running repadmin /fix /s:DC1 gives you a report where you can see the GUID it is attempting to connect to, this is also found in DNS under Forward Lookup Zones, domain.loc, _msdcs.

I added to the Hosts file (c:\windows\system32\drivers\etc\hosts) on the new DCs both the post-NAT address of the server and the GUID and I was able to get them to replicate successfully. This is what I had to add in to make it work for each DC that was on the other side of the NAT:

192.168.50.3   DC1.domain.loc
192.168.50.3   b48aa2d2-5b6a-8723-ab6c-239b8a76c782323a._msdcs.domain.loc

I REALLY do not suggest anybody else try and do this in a production system for anything long term. I'm documenting it and working on reengineering the network as part of our overall plan to get rid of this.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .