Need some AD help/theory

jonw757

Gawd
Joined
Dec 7, 2004
Messages
661
We currently have 3 physical sites, our larger site has 4 domain controllers, the 2 other sites have 1 DC at each. Our network team decided that we need to put the 2 sites in their own DMZ although we are all on the same domain. So we'll say that the first 4 DC's, site A are on the 10 network and the other two are DMZ'd to site B 192.168.1.0 and site C 192.168.2.0. 1st is this a good practice and will AD even work correctly? They have NAT'd the DMZ IP's so that we can access them from the 10 network. So 192.168.2.10 NAT's to 10.0.0.10 but if you go to \\dcsitea they dont resolve because DNS has them as the DMZ IP which we dont have access too. Let me know if there is any more info needed, it seems way over complicated to me and the security of the DMZ serves no purpose as we are accessing the same domain anyway just different resources.
 
Why the DMZ? Are both sites trusted....DMZ is to allow connections from an untrusted network into your own trusted network.

I agree in that it seems overcomplicated to me.

oh, and Server 2003?
 
Originally the thought of security, but we share the same domain and many of the same resources so either way they still need to contact the same servers. Yes everything is 2003 Server, was just built last year so all equipment is new. Could AD work within a DMZ properly all on the same domain?
 
You might have to create the DNS entries manually most likely in the fwd zone.

I had a similar issue because I am running IPSec VPN between all my sites, and therefore the networks can't overlap. Because of this, I have a similar situation where I have 10.10.10.0/24 and 172.27.20.0/24 and 192.168.0.0/24, soon to be 192.168.1.0/24 as well... it's a long story. (Actually, 172.16.x.x/16 is also coming, but that's another story...)

What a mess...

Putting your DCs in the DMZ means they are much more exposed than they need to be! Damn... I wish I was an AD expert, too!
 
Do your NAT devices automatically update IPs in DNS queries to match the NAT IP addresses? If so, the only adjustment you need to make is to perform all you DNS queries at the central site.

If you perform any DNS resolutions anywhere else, you'll run into replication issues. If their are any direct connections between the two sites that will be DMZd, youy will not be able to use them for replication traffic. Not much you can do about that.

If your NAT doesn't update DNS queries as they pass through, you need to use a non-AD integrated DNS zone, and manually make the appropriate entries for the other DNS controllers and all other DNS entries for that zone name at each site. :(

What sort of firewalls do you have to contend with, if any? If you have any stateless firewalls, expect to have a whole lot of fun. Its not a great joy to deal with even stateful firewalls and AD replication.

If you have to deal with any port limitations, you will need to make registry edits to limit the ports used (the default is to randomly pick the AD replication port from any port in the 1025-4999 range, plus addtional RPC ports from that range). Not many firewall people like to allow that many contiguous ports open.

I compromised with our firewall team and limited the AD replication traffic to a single port, and the other RPC ports to a another 100 port range.

MS has some good articles:

http://support.microsoft.com/kb/179442/en-us -All the ports needed
http://support.microsoft.com/kb/224196/en-us - limiting AD replciation to one port
http://support.microsoft.com/kb/154596/ - setting a port range for all other RPC traffic ports
http://support.microsoft.com/kb/154596/ - Netlogon traffic and NATs

I have a situation where we have one site that has two different NAT routers with DCs on the other side, and DNS is only done through one. The DC in that DMZ cannot be configured to talk to one of the DCs in our environment as DNS queries result in an IP that is only addressable through the NAT on the link through which the DNS request was passed. It therefore believes that their are two DCs with the same name (The other DC can succesfully initiate connection to it, but it can't initiate a connection the other way since the DNS returns a value that can't be routed). That results in a Kerberos ticket punching failure about once a month that causes our Exchange server cluster to failover when it happens, and results in a load of KCC failures about not being able to communicate with the DC in the other site. Really fun stuff. :mad:

We just have to live with it until our network guys finish the move to a MPLS based network, and we lose one of the NATs.
 
Back
Top