Tuesday, December 26, 2017

networking - Advice on Active Directory design for multihomed servers



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?


Answer



In the end I went with the two sites solution:




  • Two DCs for the "servers" network, two DCs for the "clients" network.

  • Two AD sites, one for the "servers" networks and one for "clients" one.

  • DCs in the "servers" network will only have a NIC sitting on that one (clients are not going to talk to them at all), so this is easy.

  • DCs in the "clients" zone will have two, but will only register in the DNS their client-side ones.


  • Servers will talk to their DCs, clients will talk to their ones.



Of course, this means enabling replication traffic between the two networks; the DCs in the "clients" network will still have a NIC sitting on the "servers" network, but as it will not get registered in the DNS, the DCs in that network will contact them using their client-side IP addresses; so that NIC will in fact be completely useless, and some firewall ports will need to be opened. The only other option would be mangling the DCs' hosts files, but let's hope that can be avoided.



Well, I think this is the best that could be done to fulfill as many (crazy) requirements as possible.



Thanks for all advice :-)


No comments:

Post a Comment

linux - How to SSH to ec2 instance in VPC private subnet via NAT server

I have created a VPC in aws with a public subnet and a private subnet. The private subnet does not have direct access to external network. S...