A lot of planning goes into the features and capabilities of each Windows release. Over the years I’ve noticed that there is not a great deal of awareness out in the general public for just how much work and labor goes into a new version of Windows. We’ll most often hear someone say something like “Microsoft comes out with a new version of Windows every few years”….a statement which glosses over the concerted effort of thousands of people in planning, writing, testing and documenting each feature and capability of a new release.
What is even less seldom discussed is that there are times when the product is put in situations or used for needs that were not tested or planned for in pre-release. It’s a fact of life in IT, though, that business need dictates the applications to which your servers will be used and the situations they will be in. This is summed up best by the Heinz Guderian quote “No plan of battle ever survives contact with the enemy”-though the “enemy” in this situation is really not that at all, but rather our lifeblood at Microsoft-our customers.
Placing Active Directory domain controllers (DCs) in a network segment that is separated by network address translation (NAT) from the rest of the network-and its peer DCs-is probably one of those situations. There are quite a few distinct business reasons why this sort of network topology will be implemented. The most common is to provide an authenticating domain controller in a demilitarized network zone (DMZ) . This can be used to answer authentication requests from application servers which are also placed in the DMZ, or from clients who connecting from outside the DMZ- perhaps via the internet.
What may be the least preferable reason to place a domain controller in a “NATted” network is to use that network to secure an environment. This can be a controversial statement in light of common guidance and advice around securing perimeter networks. We’ll get into specifics a bit later in this blog post and talk about why there are challenges that make this a less preferred thing to do. A good way of thinking of this is to consider that the Active Directory code-all of those separate components that comprise Active Directory-rely on an underlying foundation of network connectivity to be present and working; a foundation of network connectivity which doesn’t take into account network address translation.
The Microsoft guidance on hosting domain controllers separated by a NATted network is summed up by the article “Active Directory functionality is not supported over a router that has Network Address Transla... . This does some good general guidance on what network connectivity is required for things to work well.
Now, let’s consider a simple network address translation scenario where domain controllers are involved.
In the picture above we see DC A in our corporate environment and DC B in our DMZ environment. DC A has a network address in the 192.x.x.x network and DC B has a network address in the 172.x.x.x network. In itself this is by no means a problem. The difficulty may come into the scenario when we consider how it is domain controllers are found by clients and by each other: DNS.
Each domain controller will register records in DNS which advertise that the DC can provide services. These are called SRV records . These records in turn map back to a CNAME alias record called the MSDCS record. That record is responsible for providing a resolution to the host record, or A record, which contains the IP address of that DC. The difficult part of a NAT scenario, at least for a domain controller, is that the DMZ DC must register an IP address in its host record which is reachable in some way by its peer domain controller across the network.
Network address translation works to replace IP header information so that the destination IP is actually different than that which the originator knew of. In our scenario a network device or server between the two DCs (represented as a firewall) does the network address translation.
This is an acceptable thing as long as the two servers can ultimately find each other and communicate. But without additional steps taken this won’t happen very well.
DCA = 192.x.x.x
NAT Int = 192.x.x.x
NAT Ext = 172.x.x.x
DMZ_DC = 172.x.x.x
Why is this a problem? Well, DCA can always initiate AD Replication outbound through the NAT device. However, DMZ_DC cannot by default and will fail when it tries. The problem in this scenario is that DMZ_DC resolves the name "DCA" to the internal IP address of 192.x.x.x and cannot reach the DC. That is because NAT is occurring at the network device and if DMZ_DC sends traffic to that IP it simply won’t make it.
In this situation, DMZ_DC needs to resolve the name "DCA" to the NAT Ext IP address in order for this to succeed. However, DCA is registering its name in DNS with its true IP address.
Now, if we manually edit the DNS Host record for DCA on the DMZ_DC side in DNS, it will simply be reregistered by DCA at the next dynamic refresh of DNS by that computer, and then AD Replication will occur in the one way that works consistently and then the problem will exist again.
The idea here is to tell a component on DCA to register both the true IP address AND the NAT Ext IP address (even though the NAT Ext IP Address isn't bound to DC1).
We can do this with the DNS Server component. To do that we need to add a registry value on DCA.
HKLMSYSTEMCurrentControlSetServicesDNSParameters
Registry Value: PublishAddresses
Registry Value Type: REG_MULTI_SZ
Registry Value Data:<IP addresses>
The data should contain the IP addresses we need to register separated by a line feed. (IP addresses should be entered on different lines)
Why and how will this work? Because the DNS Server component in Windows Server 2003 and Windows Server 2008 have "Netmask Ordering" enabled by default, so DNS Server will return both IP addresses to the client but will list the IP on the same subnet as the client first. So the clients on the Internal network should choose the correct IP address.
This should also work for the DNS requests from the DMZ_DC. DNS Server will order the list with the IP address on the same subnet as the DNS Client that requested the address, and will chose the next closest IP subnet/class. So on both internal and external sides, the "client" should choose the correct IP address.
The above is a scenario that a business can arrive at and deal with in a lot of different ways. The sole intent here is to provide information that can help you use Microsoft products in the ways that you need to. Administrators and planners may need adapt or add to this scenario as needed but hopefully this gives some knowledge to get you started on that path.