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?

Improve this question
2
  • 1
    Why do you want objects in the DMZ to authenticate to AD?
    – Izzy
    Jul 6, 2009 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, 2009 at 7:58

3 Answers 3

Reset to default
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.

Improve this answer
4
  • @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, 2009 at 16:59
  • 1
    Chrome rocks for inline spellchecking
    – Izzy
    Jul 6, 2009 at 17:26
  • @Izzy, true, true...
    – Avery Payne
    Jul 6, 2009 at 18:00
  • 1
    Microsoft does support such monkey business to some extent. See: 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 6, 2009 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

Improve this answer
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.

Improve this answer

You must log in to answer this question.

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