0

I originally asked this question on stack overflow and was referred here.

Using Hyper-V I built a private windows domain which is fenced off from our main network. Ultimately I want to provision this domain for others to use for dev and test, so they can be domain admin.

My problem is this: the domain controller has the DHCP service running. If someone deploys the domain to their Hyper-V host and mistakenly connects it to the main network, the DHCP service will start assigning bad IP configurations.

I would like to prevent this situation. I considered writing a service to wrap dhcploc, this service would then stop the local DHCP service if a remote DHCP server can be found. This is really damage limitation, since the rogue DHCP server would still have a small window of opportunity.

Is there is a better/simpler alternative that would acheive the objective? Are there any caveats I should be aware of?

Thanks

Improve this question
2
  • Why do you have DHCP enabled?
    – Izzy
    Jul 9, 2009 at 15:51
  • We have a client/server product, and want to be able to test for and repro any bugs that may stem from clients with dynamically assigned addresses. At the moment, our DHCP tests are quite isolated. I expect that if the whole team uses DHCP we will flush out more bugs. Furthermore, DHCP can be configured to statically assign addresses to certain MACs. My server components have known MACS, so when you deploy the images (DC, Exchange, SQL etc) everything works with zero user configuration.
    – Alex Peck
    Jul 9, 2009 at 16:31

3 Answers 3

Reset to default
1

Given that your test DHCP config uses MAC addresses to assign regular IPs you can limit the scope to include only the known MAC addresses. This way, even if someone puts it on the main network accidentally, it won't hand out any IPs because none of the requests match any of the MACs in its scope. As far as potential problems of putting a test DC on your main network it depends on a couple of things:

1) Hopefully you are using a separate subnet for the test network than the main network. Ex. test net = 172.16.0.0 and main net = 10.0.0.0. This will limit the test DCs access to stuff on the main network as long as it can't get to a router that is aware of both subnets and is set to route between them. 2) How was the test DC created? If it was attached to the main network first to grab AD data via replication and then removed and put in the test environment, it would still know about the other DCs on the main network and try to replicate to/from them once it came up. This is very bad for obvious reasons...If it was created within the test environment and has a unique domain name separate from the main domain name, then you are good to go.

What I meant by "larger problems" is that if people are putting DCs on the main network accidentally then someone should be giving them some training on using Hyper-V rather than trying to limit the damage in case they do! I'd be very nervous if I had DEV people playing with DCs (test or not) around my production network...Could you have their Hyper-V workstations separated even more on a different subnet altogether from the main network?

Improve this answer
2
  • That's excellent, thanks. The MAC address restriction sounds like the way to go. The DC was created seperately and uses a distinct domain name and subnet, so I think we are pretty safe. All the users are proficient engineers, but I wanted to safeguard against accidents wherever possible.
    – Alex Peck
    Jul 9, 2009 at 17:38
  • We do something similar: the (Microsoft) DHCP server has a configured scope; there's an exclusion that covers the entire scope; then we have reservations so that specific MAC addresses get specific IP addresses.
    – Roger Lipscombe
    Sep 16, 2009 at 14:34
1

When you say "fenced off", what exactly do you mean?

If you have two DHCP servers on the same subnet, then you'll have some requests going to one DHCP server and some going to the other and, of course, conflicts if both servers are giving IPs from the same pool.

For the situation you described, I would create a routed subnet for your "fenced off" server and use a VLAN to isolate the subnet or you could use another cheap switch for a more physical separation.

Your Windows DHCP server can be multi-homed (connected to two or more networks). With two network cards, you cable one card into your production network and cable the other card into a separate network switch or separate VLAN allowing one server to act as a DHCP server for both networks. Or, per your original question, you would not need to do this if you want to continue to operate two DHCP servers.

Then on the fenced off switch or VLAN, you create a subnet that is different than your production network. For example:

Production Switch/VLAN: 172.16.0.0/16 Development Switch/VLAN: 172.17.0.0/16

Production DHCP Server may use a scope of 172.16.1.1 - 172.16.1.200 Development DHCP Server may use a scope of 172.17.1.1 - 172.17.1.200

In the Production DHCP scope, you could hand out a static route to Development and on the Development DHCP scope, you could hand out a static route to Production....

You may need some routing between the two if, for example, your Development area needs Internet access and the Internet is accessible only via Production network.

Improve this answer
2
  • Thanks for the input. By fenced off, I mean that in Hyper-V the domain is connected to a virtual network with either a private or internal binding. By connecting to the main network, I mean changing the binding to the host's physical NIC. I expect that we will deploy 10-30+ test domains running on Hyper-V workstations. Neither I, nor the eventual users, are able to alter the configuration of the production network. From your description, it sounds as though if the private domain uses a subnet that is definately not used in production, then there can be no conflict. Is that correct?
    – Alex Peck
    Jul 9, 2009 at 16:15
  • +1. a separate VLAN id running through the network is perfect for that. Totally logically isolates the traffic, so it does not easily interfere with each other. Then if needed install a router to route between them.
    – TomTom
    Jan 10, 2013 at 15:50
1

Easiest thing to do is not have DHCP at all. Is the private virtual domain so large that you can't manage the IP addresses using static IPs? Secondly, you have larger problems if people are connecting DCs to your main network that are supposed to be for testing only. I haven't used Hyper-V yet, but in VMWare at least you can assign pretty granular permissions that would prevent a user from attaching the VM to a different network or changing it's network config.

Improve this answer
1
  • Unfortunately we have a dependency on DHCP. Devs/testers will deploy the domain to their own workstations with the Hyper-V role, so they can pretty much connect anything to anything. At the risk of highjacking my own question, what might happen if the DCs are connected to the main network?
    – Alex Peck
    Jul 9, 2009 at 16:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .