1

I'm trying to take over an old infrastructure and clean it up, but I'm running into some issues deciding on the new architecture.

We have a set of around a dozen or two test/production servers in a rack, with two parallel networks between them. Each server has two NICs, and is connected to both networks.

One of the networks is the external net, with public internet IPs, and internet access. The other one is a local network, with internal IPs, and is used as a fast lane internal communication network, to transfer backups and connect to DBs, without being affected/affecting the external network's bandwidth.

I want to set up a domain controller in the network, and my initial plan was to set it up in the internal network, so all the AD communication is sent over the internal lan, but if I want the AD to have internet access (for updates etc) it would also have to be connected to the external network, which would make it multi homed.

Alternatively, I can connect it to the external net only, but that would mean that AD communication goes over the external net as well, and the DNS names given to the servers will point to external IPs, which is not really what I want. Also, in this case all the servers will mark the external net adapter as a Domain adapter (Ideally I would like the external adapter to be a "Public" network, and the internal one the "private"/"domain" network)

Is setting up the DC as a multi-homed server the only logical solution here? I feel like I'm missing something very simple

P.S. To note: I don't need the DC to be accessible from the internet, and the DNS names created by the DC should not be public, they're only for internal adressing.

P.P.S. My plan was to set up both NICs on the DCs (static IPs on both networks), block any incoming connections to the server over the external net adapter (it will be only for internet access), and bind the local DNS servers to the internal IP. Each of the servers in the net will be accessing the DC by the internal IP to avoid resolution issues. Does that sound good enough?

  • serverfault.com/questions/573681/… for why you shouldn't give your DC direct internet access. – MDMoore313 Jul 30 '14 at 12:03
  • @BigHomie that's a very good point, and I would have gone for that, except for one thing - if I do this, what will happen with DNS forwarding? All the other servers should use the DC's DNS IP, but if the other servers try to resolve external host names - they will fail, since the DC can't resolve them, right? – Artiom Jul 30 '14 at 12:19
  • well, at $job we have separate internal and external facing DNS servers. This way, the entire internet can't peek through and directly connect to our workstations via hostname from the internet. Servers that have to be access via the internet (say, RDS) are resolvable via the external DNS servers. To my knowledge the external facing DNS servers are not DCs. – MDMoore313 Jul 30 '14 at 12:22
  • Oh yeah, I definitely get that.. The DNS from DC is not public facing.. But I was under the impression that it should be able to resolve public DNS (not the other way around). So if one of the machines in the network tries to resolve a host name, it asks the DCs DNS (which is the only DNS server(s) in the server's network settings), and the DC will either know the answer, or ask it's forwarders, right? – Artiom Jul 30 '14 at 12:25
  • 1
    what does it forward to, your ISP? sounds like you need a separate DNS server based off this info, and as long as this DNS server has outside access, and your DC can access it, you should be fine. – MDMoore313 Jul 30 '14 at 12:27
3

I think your plan is flawed.

From my point of view, the "right" thing to do is:

  • Put a Firewall in front of all of this
  • Put a Router in front of all of this (can be the same as the FW, depends of course)
  • Have all Servers as "internal", you can still segregate them into multiple networks of course
  • Disable/Rip out the secondary NIC if you don't need the bandwith, or trunk them for failovering
  • Forward the necessary ports to the necessary servers

Now you can just route "internally" between the networks, without multi-homing them.

  • The whole thing is already behind a firewall, actually. The issue with your suggestion is that if I do it like that then all the servers will have only internal IP addresses. It's no good for us, since the servers have to be public facing (a lot of them are Web servers). – Artiom Jul 30 '14 at 8:59
  • You can either NAT them to your internal address.. – MichelZ Jul 30 '14 at 9:00
  • Multiple web servers, different IPs, hostnames etc.. Other servers are dedicated, and need full remote access. We don't have a class C subnet for nothing :-) – Artiom Jul 30 '14 at 9:27
  • As such, a NAT is out of the question – Artiom Jul 30 '14 at 9:28
  • If you say so :) – MichelZ Jul 30 '14 at 9:29
0

A domain controller with multiple ip addresses is almost never a solution to anything. It causes more problems than it solves. The problems are particularly acute for DNS, because the "ListenAddresses" is only half the problem. You would also need to configure the PublishAddresses value, and if you don't your domain controller would happily hand out the wrong address randomly until you lost your mind or came back here asking why it isn't working.

Additionally, it is generally a bad idea to allow critical servers such as domain controllers to access the Internet, even if it is only outgoing access. If you ever have an incursion, the first thing malware does is phone home over the Internet and invite all their friends. Need updates? Use the built-in server update role on another machine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.