Ошибки проектирования Active Directory

Virtual Domain Controller

Всем привет. Поставил себе задачу развернуть первый контроллер домена Active Directory для будущего демо стенда. Этот стенд планирую использовать для дальнейших демонстраций и других занимательных экспериментов. Казалось все просто — берем ставим Windows Server и устанавливаем директорию. Именно такой путь советует большая часть гайдов из интернета. Но это не наш метод.

Проводя аудиты информационной безопасности доменных Active Directory, мне доводилось наблюдать не только проблемы с безопасностью. Часть искомых проблем относится к неправильному планированию директории. Ценностью данной статьи будет в фокусировании внимания на критические пункты, учет которых обязателен перед стартом.

Практическое описание о разворачивании первого контроллера домена будет дано в следующей статье. Сейчас же рассмотрим основные ошибки при проектировании:

Планирование имен

«Как корабль назовешь так он и поплывет» — мудрость которая в отношении директории играет огромное значение.

Стоит понимать, что во время процесса создания директории вы указываете два абсолютно разных имени – Active Directory (NetBIOS) и DNS. Задача первого обеспечить работу LDAP запросов и функциональности служб Active Directory. DNS же служит для трансляции имен компьютеров или приложений в IP адреса.

Рассмотрим следуюшею задачу: компания Norvato планирует разворачивать службы каталогов. У организации есть внешнее пространство имен norvato.ua или просто внешняя зона DNS. Ниже три схемы которые могут быть использованы для именования:

  • Внутренняя DNS зона служб каталогов идентична внешней.
  • Внутренняя DNS зона отлична от внешней псевдодоменом первого уровня.
  • Внутренняя DNS зона является субдоменом внешней.

При выборе первого варианта, появятся проблемы с трансляцией имен в IP адреса. Эта проблема называется split DNS. Второй сценарий подойдет для задач тестирования, а не для продуктивного развертывания.

Остался третий, рекомендованный, используем субдомен. Именование будет иметь следующий вид:

  • Имя Active Directory (NetBIOS): CORP
  • DNS зона: corp.norvato.ua

Синхронизация времени

Время играет огромную роль в работе служб каталогов Active Directory, в частности, из-за работы протокола Kerberos. Причем, в зависимости от сложности топологии, важность возрастает кратно. Особенно это явно выражается в топологиях состоящих с двух и более доменов.

По умолчанию, максимальное временное отклонение составляет 5 минут. Это значит, что если фиксируется отклонение более заданного порогового значения, Kerberos вовсе перестанет работать.

В моей практике была одна бессонная ночь ликвидации последствий беспорядка со временем. В процессе миграции версии гипервизоров, с ESXi 6.5 до 6.7 была выполнена переустановка хоста виртуализации. Причиной послужила проблема с невозможностью корректного включения Secure Boot из-за одного не подписанного VIB пакета. Все было бы нечего, если бы не оплошность в  задании NTP серверов гипервизора. А дальше, как в анекдоте: смеркалось — через VMotion приехал контроллер домена с ролью PDC и выхватывает не корректное время. Ночь была весела и красочная…

Чтобы обезопасить себя от такого исхода, рекомендую статью к прочтению: О времени в Active Directory Domain Services на VMware vSphere

За источник точного времени ответственна FSMO роль — эмулятор PDC. Причем, в случае наличия нескольких доменов в лесу, PDC эмулятор корневого домена леса будет источником точного времени для PDC эмуляторов других доменов. Сервера и рабочие станции будут синхронизировать точное время с местных PDC.

Как синхронизируется время в лесу Active Directory
Как синхронизируется время в лесу Active Directory

Резервное копирование

Как бы парадоксально это не звучало, но не все делают резервные копии и, тем более, копии контроллеров домена. Даже существует миф, что для резервного копирования нужно что-то дополнительно покупать и внедрять. Имею ввиду централизованную систему резервного копирования как Microsoft DPM или Veeam Backup & Replication.

В реальности дела обстоят намного проще чем кажется. В любом Windows Server имеется в наличии Windows Server Backup. Эти замечательные службы умеют не только бекапировать но и чертовски хорошо восстанавливать.

Операционная система

Рекомендации касаемо операционной системы можно охарактеризовать в следующих пунктах:

  • Максимальная доступная версия

Стоит понимать, что версия операционной системы контроллера домена не влияет на работу с ним более старых операционных систем. Конечно, наличие их в принципе не является хорошей стратегией, вместе с тем какие системы будут, а какие нет, задается настройками политик.

  • Server Core обязателен

Именно тот пресловутый режим без графического интерфейса. Преимуществами Sever Core будут высокая стабильность (меньше кода — меньше ошибок) и безопасность (меньшая площадь для атаки). К недостаткам можно отнести отсутствие привычных органов управления. Эту неприятность мы переживем с помощью Windows Admin Center, о котором обязательно поговорим.

  • Uefi и Secure boot быть

Secure boot — это технология, которая позволяет обезопасить себя от выполнения вредоносного кода во время старта операционной системы, в данной случае нашего контроллера. Для минимизации таких типов атак данная опция рекомендована к развёртыванию.

Это из того что обязательно. Далее нас ждет практика. Все статьи цикла можно найти по следующему тегу.

 

Оставить комментарий

  Подписаться  
Уведомление о