Traditionally at my place of work we have an internal subnet that is completely protected behind our firewall. No ports are allowed to be opened to direct connections from the public network. We also run a DMZ where we only allow specific ports to be opened as they are needed. In addition, we don't allow connections to the internal network to be open from the DMZ, but the internal network can open connections to the DMZ. I would hazard that this is a pretty traditional DMZ-stlye configuration.

We also host our domain controllers in our internal network. Up to this point, the implication of this has been that we need to manage DMZ password separately since there is no AD authentication. This hasn't been a big deal since we have only had a handful of DMZ servers.

Now we are about to launch a product that will require significantly more DMZ servers, and during the last phase of our testing we have already had issues with password management on the DMZ systems. The solution would seem to be to punch the hole from the DMZ to the internal network to allow for DMZ servers to be joined to the domain.

For me this raises 2 questions:

  1. Is this even a good idea?
  2. Assuming that it is not a terrible idea, is it better to allow specific routes for each server to get back to the domain controllers, to allow the entire subnet to get back, or to deploy a DC on the DMZ and only allow that server to get back through.

I'm hoping that someone out there has some thoughts.

5 Answers 5


Use the "Selective Authentication" feature with a Master and Resource forest

The best idea, in my opinion, is to configure a separate forest in the DMZ and consider it a resource forest. That is, no user accounts in that forest (except for default users)

Then use a feature called Selective Authentication to allow only a pre-determined set of users to authenticate to that resource forest. This will limit the exposure of your internal AD forest, yet allow for centralized administration of the accounts.

Generally speaking, the financial cost of deploying a second forest, ( OS licenses, redundancy, backup and DR considerations, patch maintenance etc) would be better spent on adding multi-factor authentication to your primary account forest, or a subset of those users.

  • This is very close to what we ended up doing.
    – Kirk
    Feb 6, 2014 at 15:08

1) Clearly not a good idea. That would mean that if a DMZ machine that is joined to the domain is compromised, then your corporate AD would be in danger, which isn't acceptable

The only option is to deploy a separate Active Directory forest for your DMZ, potentially with different zones; for example, the main writable domain controllers in an isolated network segment and read only domain controllers in the other segments, but in any case without a link to your corporate AD.

There's indeed a management/administrative overhead, but security wise you don't have many other options.


If your internal production AD is critical and contains sensitive systems, DATA etc, which would have a high business impact if compromised then you should consider a seperate forest. If a completely isolated "DMZ" forest is not practical or too costly to manage (high admin costs through account duplication and so on) you can consider a new "DMZ" forest connected with a one way trust, (DMZ Forest trusts the Internal "Production" forest. The DMZ forest should be implemented on the internal network with RODC's (if available with your version). DMZ devices can then authenticate through configured ports on your firewall to access the "DMZ" Forest RODC's only, allowing centralised management of DMZ devices. Production Forest Admins can use their Production accounts to administer DMZ devices across the trust. This is high level and may not suit all dmz requirements and assumes a basic requirement to centrally manage DMZ systems.


Use of a RODC might be an option for you. Place the Read-Only Domain Controller in the DMZ. Harden the operating system to only allow Authentication traffic access from other servers in the DMZ and AD replication traffic from it's AD replication partners in the private network. Block inbound requests from the DMZ to the private network (should already be done). Configure a push replication from the DC's in the private network so the requests are made from the private network side.

AD Federation Services might be another option.


Generally, two designs are available:

  1. Two separated forests where you can use AD FS or unidirectional trust (DMZ trusts Internal but not the contrary).
  2. One forest with Read Only Domain Controller placed in the DMZ.

More information: https://technet.microsoft.com/en-us/library/dd728030(v=ws.10).aspx

You must log in to answer this question.

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