Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am looking to deploy 2 additional Windows Server 2003 domain controllers into a separate confidential DMZ alongside 6 DCs that are installed in the regular network, making a total of 8 DCs. The 2 confidential DCs will communicate with the regular network DCs through the firewalls via IPSec.

However, I am wondering how I will stop regular network workstations and servers trying to authenticate with the confidential DCs? Is there a way of using AD Sites and Services to stop regular network workstations and server from trying to communicate with these confidential DCs?

What I am trying to say is, will there be a problem or when a regular network workstation or server tries to authenticate with the confidential DCs and times will this cause issues or will it timeout and try another DC and carry on?

share|improve this question
Why do you want objects in the DMZ to authenticate to AD? – Izzy Jul 6 '09 at 16:39
A Certificate Authority is being added so users can log on using a certificate on a smart cards. Due to external design constrains and internal time constrains the the CA must be in a confidential area (sigh). – TheMoo Jul 7 '09 at 7:58
up vote 5 down vote accepted

You can't completely stop client computers from attempting to communicate with them "ever", but by placing them into a separate AD site (assuming they're in a different subnet than the "production" DCs), you'll prevent client computers from attempting to access them so long as at least one of the "production" DCs remains up at all times. If all the "production" DCs are unavailable, the clients will attempt to contact a DC in another site-- potentially the "confidential" site.

Preemptively, in case someone suggests it in another answer: Trying to play games w/ the DNS entries created by the "confidential" DCs is probably a bad idea. I don't doubt that there's a way you could manipulate the DNS entries the DCs register to stop authentication but still allow replication, but I can't imagine that Microsoft would "support" such monkey-business.

share|improve this answer
@squillman: Thanks for the edit. I was rushing, as I typed, trying to make sure that I had an answer in before Evan Anderson. >smile< (You've discovered one of the words that I always mistype, too... How embarassing! I need to be using a browser w/ spellcheck in textareas...) – Evan Anderson Jul 6 '09 at 16:59
Chrome rocks for inline spellchecking – Izzy Jul 6 '09 at 17:26
@Izzy, true, true... – Avery Payne Jul 6 '09 at 18:00
Microsoft does support such monkey business to some extent. See: If you put DCs in teh DMZ you don't want non-SRV-record-aware apps finding teh DC through the DNSDomainName.FQDN, this will prevent that while still allowing for replication and regular SRV-record site-specific location of the DCs. – Ryan Fisher Jul 6 '09 at 18:34

A better answer is (if possible) to use ADAM (now called AD LDS) instead of placing real DCs in the DMZ. If not I would certainly set up domain isolation

share|improve this answer

We are deploying a Windows Server 2008 Read Only Domain Controller in Our DMZ for web services. Previously we used a 2003 server with local accounts, but this was a management nightmare. We are following this guide using a new forest in the DMZ and creating a one way trust so our internal users can authenticate with their existing accounts.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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