Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

As the question states, what are the drawbacks of making every capable Windows 2003 or 2008 Server in my organization a domain controller for the domain? Is it just overkill? Will many 3rd party applications explode? Something else I'm not thinking of?

Are there any advantages?

share|improve this question
    
Unnecessary overhead with AD on each machine, plus broadcast noise on the network. Apart from that, nothing. –  user3914 Sep 29 '10 at 22:36
    
Why would you want to? What advantages do you see in doing so? Would you implement something, anything, without realising an advantage? –  John Gardeniers Sep 30 '10 at 0:46
    
I am not planning on doing it, but couldn't find a concise pro/con list as to why not to do it. My gut was telling me it wasn't a good idea, just wanted the reasons why. –  NinjaBomb Sep 30 '10 at 13:21

3 Answers 3

up vote 16 down vote accepted
  • Domain controllers have no local accounts. So everything running on those machines will have to be reconfigured to work with domain accounts.
  • Domain controllers should never be snapshotted or reverted to a previous image of any form, or you will encounter USN rollback scenarios. This means that if you run any kind of imaging solution or virtualisation, you will lose the use of snapshotting features.
  • Any local administrator of a domain controller is a domain administrator.
  • Network and replication traffic will increase significantly.
  • Servers located in network segments seperated by switch ACLs or firewalls will require a number of additional access rules configuring to support sufficient replication traffic.
  • Your odds of corruption in the AD databases increases
  • You're violating the general security principle of least priveledge.
  • When in future you wish to upgrade your domain functionality level, you'll have to upgrade every single server you have to the appropriate version, rather than just the dedicated domain controllers.
  • The exploitable surface area of your domain will increase by orders of magnitude, as any applications on any of these servers will then become potential attack vectors for your domain infrastructure (e.g. a SQL exploit may subsequently lead to your entire domain being compromised)
  • Some services will not function or are strongly discouraged on domain controllers (e.g. Terminal Services).

Best advice I can give you is to run domain controllers as very discrete entities wherever possible i.e. load no services onto a domain controller that is not essential to the operation of the domain controller. This is commonly overlooked with very small shops and especially Small Business Server for practical/cost reasons, but once you scale beyond that you ideally want to be heading towards a point where DCs are JUST DCs, and you only run as many DCs as you realistically need for adequate replication and fault tolerance.

share|improve this answer
3  
+1 for principle of least priveledge –  knitti Sep 29 '10 at 23:49
    
To add examples to the last bullet Points: SharePoint 2010 requires some (undocumented) extra procedure to enable Sandboxed Solutions when running on a DC. Also, SQL Server will warn against installing on a DC, presumably because of the "No Local Accounts" limitation –  Michael Stum Sep 30 '10 at 1:23
    
One more bullet point to add to the list...... Srsly????????? –  ThatGraemeGuy Sep 30 '10 at 8:11

To add to the very good list Chris Thorpe posted, here are some more reasons why doing that is a bad idea:

  • Every server will then need to be notified of changes to the Domain.
  • Servers that are down for any significant length of time can cause replication trouble.
  • Depending on how large your domain is, it can be a quite significant memory suck.
  • Every server will then be in DNS as resolvable by the domain DNS-domain. Get enough servers, and some DNS clients will start puking at the size of the DNS Reponse.
  • Every server will then host all the Group Policies, which has its own replication traffic, so you will get inconsistent GPO coverage until replication has converged, which can take some hours in a large network of DCs.

Really, the "replication overhead" argument is a really strong one. If you have a small number of servers local to each other, say under 10, it isn't as bad. Once you get to large numbers, especially if they're remote from each other, problems start magnifying. Replication inside an AD Site is one-to-many, and between sites are generally configured with bridge-head hosts funneling the updates. Not just AD information needs to get replicated, so does all the Group Policy information (that's what's stored in "SYSVOL") needs to get replicated to every DC. It's a very complex replication mesh when you get many DCs in an environment, and it's a lot easier for things to go wrong.

From a security stand-point you really do not want potential attackers getting local access to a DC. It is a lot easier to extract the entire domain's password hashes when you're local to a DC, and with Rainbow Tables that's pretty much game-over unless your password policies are much more strict than are commonly used today.

share|improve this answer

It's a very bad idea. I can't really think of a reason to do this. Many MS services will not run or are not supported on DCs. Also any bug or hole in any software you install on a DC risks your entire domain's security.

share|improve this answer
1  
I know Exchange is one application that is not supported on DCs. As far as another "very bad idea" - imagine the replication overhead. –  Cypher Sep 29 '10 at 23:10
1  
Exchange is supported on DCs, it's just discouraged. –  ThatGraemeGuy Sep 30 '10 at 8:16

Your Answer

 
discard

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.