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?
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.
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
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.