3

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?

TheMoo
  • 33
  • 1
  • 7
  • 1
    Why do you want objects in the DMZ to authenticate to AD? – Izzy Jul 06 '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 07 '09 at 07:58

3 Answers3

5

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.

squillman
  • 37,883
  • 12
  • 92
  • 146
Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • @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 06 '09 at 16:59
  • 1
    Chrome rocks for inline spellchecking – Izzy Jul 06 '09 at 17:26
  • @Izzy, true, true... – Avery Payne Jul 06 '09 at 18:00
  • 1
    Microsoft does support such monkey business to some extent. See: http://technet.microsoft.com/en-us/library/cc978020.aspx 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 06 '09 at 18:34
4

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

Jim B
  • 24,081
  • 4
  • 36
  • 60
0

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.

IT Team
  • 113
  • 1
  • 5