Каковы недостатки создания контроллеров домена всех моих серверов Windows Server?

• У контроллеров домена нет локальных учетных записей. Таким образом, все, что работает на этих машинах, придется перенастроить для работы с учетными записями домена.
• Контроллеры домена никогда не следует делать снимки или возвращать к предыдущему образу любой формы, иначе вы столкнетесь со сценариями отката USN. Это означает, что если вы запустите какое-либо решение для создания образов или виртуализации, вы потеряете возможность использовать функции создания снимков.
• Любой локальный администратор контроллера домена является администратором домена.
• Значительно увеличится сетевой трафик и трафик репликации.
• Серверы, расположенные в сегментах сети, разделенных списками ACL коммутатора или межсетевыми экранами, потребуют настройки ряда дополнительных правил доступа для поддержки достаточного трафика репликации.
• Ваши шансы на повреждение баз данных AD возрастают
• Вы нарушаете общую безопасность принцип наименьшей гордости.
• Когда в будущем вы захотите повысить уровень функциональности вашего домена, вам придется обновить каждый отдельный сервер, который у вас есть, до соответствующей версии, а не только выделенные контроллеры домена.
• Возможная для использования площадь вашего домена увеличится на несколько порядков, поскольку любые приложения на любом из этих серверов станут потенциальными векторами атак для инфраструктуры вашего домена (например, эксплойт SQL может впоследствии привести к взлому всего вашего домена)
• Некоторые службы не будут работать или настоятельно не рекомендуется использовать на контроллерах домена (например, службы терминалов).

Лучший совет, который я могу вам дать, - по возможности запускать контроллеры домена как очень дискретные объекты, то есть не загружать на контроллер домена службы, которые не являются существенными для работы контроллера домена. Это обычно упускается из виду в очень маленьких магазинах и особенно в Small Business Server по практическим соображениям и соображениям стоимости, но как только вы увеличите масштаб, вы в идеале захотите двигаться к точке, где контроллеры домена являются ТОЛЬКО контроллерами домена, и вы запускаете столько контроллеров домена, сколько вы реально необходимость адекватной репликации и отказоустойчивости.

Чтобы добавить к очень хорошему списку, опубликованному Крисом Торпом, вот еще несколько причин, по которым это плохая идея:

• Затем каждый сервер должен быть уведомлен об изменениях в Домене.
• Серверы, которые не работают в течение длительного времени, могут вызвать проблемы с репликацией.
• В зависимости от того, насколько велик ваш домен, это может быть довольно значительным недостатком памяти.
• Тогда каждый сервер будет в DNS как разрешаемый доменным DNS-доменом. Получите достаточно серверов, и некоторые DNS-клиенты начнут рвать от размера DNS-ответа.
• Затем на каждом сервере будут размещаться все групповые политики, у которых есть собственный трафик репликации, поэтому вы получите несогласованное покрытие GPO до тех пор, пока репликация не сойдется, что может занять несколько часов в большой сети контроллеров домена.

Действительно, аргумент «накладных расходов на репликацию» действительно силен. Если у вас небольшое количество локальных серверов, скажем, менее 10, это не так уж плохо. Как только вы доберетесь до больших чисел, особенно если они удалены друг от друга, проблемы начнут увеличиваться. Репликация внутри сайта AD осуществляется по принципу «один ко многим», и между сайтами обычно настраиваются промежуточные узлы, передающие обновления. Реплицировать должна не только информация AD, но и вся информация групповой политики (которая хранится в «SYSVOL») должна быть реплицирована на каждый DC. Это очень сложная репликационная сетка, когда вы получаете много контроллеров домена в среде, и намного проще что-то пойти не так.

С точки зрения безопасности вы действительно не хотят, чтобы потенциальные злоумышленники получали локальный доступ к DC. Гораздо проще извлечь хэши паролей всего домена, когда вы находитесь локально по отношению к DC, а с Rainbow Tables это в значительной степени завершает игру, если только ваши политики паролей не намного строже, чем обычно используются сегодня.

Это очень плохая идея. Я не могу придумать причину для этого. Многие службы MS не работают или не поддерживаются на контроллерах домена. Также любая ошибка или дыра в любом программном обеспечении, которое вы устанавливаете на DC, ставит под угрозу безопасность всего вашего домена.