I've been tasked by a customer to come up with a working Active Directory design for a scenario with the following requirements (simplified, they are actually a lot worse):
- There is a subnet for client systems.
- There is a subnet for server systems.
- The two networks are not connected.
- Each server should have two network cards, one on the servers' network, the other one on the clients' network.
- Traffic between clients and servers should only flow on the clients' network.
- Traffic between servers should only flow on the servers' network.
- This should apply to domain controllers, too.
Needless to say, this doesn't go very well with how Active Directory uses DNS to locate domain controllers; any possible approach would lead to one of the following scenarios:
- DCs register their "client-side" IP address in the domain DNS; clients will talk with them using that address, but so will do servers, and AD replication traffic.
- DCs register their "server-side" IP address in the domain DNS; servers will talk with them using that address and replication traffic will flow on that network, but clients will be unable to reach them.
- DCs will register both IP addresses in the domain DNS; it's anyone's guess what any system will do to reach them.
Of course, these requirements are completely crazy and all of them can't be satisfied at the same time, unless using crazy solutions like splitting the DNS service on the two networks and populating its SRV records by hand (argh) or having the servers locate DCs using DNS and the clients locate DCs using WINS (double-argh).
The solution I came up with is having two DCs on the "servers" network and two DCs on the "clients" one, defining two AD sites and crossing the boundary between the two networks only with DC replication traffic. This will still require some DNS mangling, because each server will still have two network cards (apart from the two server-side DCs and purely back-end servers), but it has at least some chances to work.
Any advice, other than fleeing as fast as possible?
Best Answer
Let me begin by saying that I concur with many of the others -- either convince the client otherwise or run.
However, given your listed requirements (there are many unlisted), I can think of (and partially tested) at least the groundwork for making this happen.
There are several specific aspects that need to be considered.
One and two have a lot in common -- in general we are at the whim of Microsoft on this one and have to work within the bounds of Microsoft's AD DS processes.
Number three we have a little bit of room to work with. We can choose the labels used for accessing services (files, database instances, etc.).
Here is what I propose:
Build your Domain Controllers (DC)
Configure AD Sites and Services properly
Configure additional zone in AD DS Integrated DNS
Configure the second NIC's on your DC's
Configure member server NIC's
Configure DNS [stub] resolver behavior in the sites
Configure mappings/resources appropriately
What am I talking about?
I have not completely tested this as it is rather ludicrous. However, the point of this (wow, lengthy) answer is to begin evaluating whether or not it is possible -- not whether it should be done.
@Comments
@Massimo 1/2 Do not confuse multiple AD DS sites in the acme.local zone, and thus SRV records populated by DC's in those sites in the acme.local zone with needing SRV records in the clt.acme.local zone. The client's primary DNS suffix (and Windows domain to which they are joined) will still be acme.local. The client/workstations only have a single NIC, with primary DNS suffix likely derived from DHCP, set to acme.local.
The clt.acme.local zone does not need SRV records as it will not be used in the DC locator process. It is only used by clients/workstations to connect to member server's non-AD DS services using the member server IP's in the clt network. AD DS related processes (DC locator) will not use clt.acme.local zone, but the AD DS sites (and subnets) in acme.local zone.
@Massimo 3
There will be SRV records for both clt and srv AD DS sites -- just that they will exist in the acme.local zone -- see note above. The clt.acme.local zone does not need DC related SRV records.
Clients will be able to locate a DC fine. Client DNS servers point to the clt IP's of the DC's.
When DC locator process on the client kicks off
@Massimo 4
Ugh, nice catch. The way I see it there are two ways around this problem.
or
All in all none of it is pretty, but that isn't necessarily the end goal. Maybe the client is just testing your tech chops. Plop it on their conference table and tell them "Here, this will work, but I am charging you 4x my normal rate to configure and support it. You can reduce it to 1.5x my normal rate -- .5x PITA charge, by doing [correct solution]."
As noted earlier, my recommendation is to convince otherwise or run. But it sure is a fun little exercise in ridiculous. :)