В этой статье я бы хотел предложить вам пошаговый туториал по развёртыванию контроллера домена Active Directory на Windows Server 2016 (с графической оболочкой), а также по вводу рабочей станции в получившийся домен. Чем этот туториал может выделиться на фоне других:
- Вместо простого «Далее, Далее, кликаем сюда, вбиваем это» я постарался дать внятное объяснение каждому шагу, каждой настройке, которую предстоит выполнить. Помимо основных понятий Active Directory, DNS и DHCP вы также сможете найти много интересной информации по всем галочкам, которые вы часто видели, но не задумывались об их назначении.
- В конце статьи я предложу способ автоматизировать развёртывание получившегося стенда полностью с нуля, имея на компьютере только iso-образы ОС Windows 7 и Windows Server 2016. И никакого PowerShell. Всего одной командой.
Статья предполагает наличие у читателя лишь самых начальных знаний об устройстве сетей (на уровне «Что такое IP-адрес и DNS-адрес»).
Заинтересовало что-то из вышеперечисленного? Тогда погнали.
Туториал будет происходить не в вакууме, а на конкретном виртуальном стенде, состоящим из двух виртуальных машин:
Начальное состояние стенда:
-
На машине windows_server уже установлена ОС Windows Server 2016 Standard Evaluation (с GUI). Машина находится в состоянии «сразу после установки ОС». В процессе туториала на ней будут развернуты службы Active Directory (с доменом mydomain.com), DNS и DHCP.
-
Машина workstation выполняет роль рабочей станции. На ней установлена ОС Windows 7. Машина находится в состоянии «сразу после установки ОС». В процессе туториала она будет подключена к домену mydomain.com.
Туториал построен следующим образом (если вам интересен только конкретный пункт — смело кликайте прямо туда):
- Объясню, почему я выбрал именно такой стенд для туториала;
- Супер-краткое описание технологии Active Directory;
- Выполняется небольшая предварительная настройка windows_server;
- На windows_server производится включение необходимых компонентов;
- На windows_server происходит настройка контроллера домена AD (совместно с DNS);
- На windows_server происходит настройка сервера DHCP;
- На windows_server регистрируется новая учетная запись в AD;
- На workstation происходит подключение к домену.
В конце туториала вас ждет приятный бонус — я покажу вам как можно развернуть у себя на компьютере весь этот работающий стенд одной единственной командой. Вам понадобится только наличие двух установочных iso-образов (windows 7 и windows server 2016), да небольшой скрипт, ссылку на который я вам дам в конце статьи.
Почему такой стенд?
Такой стенд, с моей точки зрения, отлично подходит для первого самостоятельного «прощупывания» технологии Active Directory. Он минималистичен (всего 2 виртуальные машины), занимает минимум ресурсов, но при этом изолирован и самодостаточен. Его можно развернуть даже на довольно средненьком компьютере и ноутбуке. При этом на стенде уже присутствуют основные сетевые службы (AD + DNS). DHCP хоть и необязателен для функционирования AD, всё равно был добавлен в стенд в ознакомительных целях.
Disclaimer
Данный туториал предлагает исключительно пробное знакомство с Active Directory. Ни при каких обстоятельствах не рекомендуется разворачивать подобную конфигурацию при решении реальных задач администрирования сетей. В самом туториале я постараюсь обратить внимание на основные моменты, которые не рекомендуется применять в реальных сетях.
Туториал предполагает подробный разбор всех шагов по настройке, с пояснениями «что, зачем и почему». Туториал ориентирован на людей, не слишком знакомых с технологиями Active Directory, DNS и DHCP, которые хотели бы немного узнать о внутренней кухне администрирования сетей с Active Directory.
Если же базовая настройка AD вызывает у вас лишь зевоту, переходите прямо сюда и посмотрите, как можно автоматизировать весь процесс по развёртыванию собственного стенда с AD и рабочей станцией.
Что такое Active Directory
Active Directory — это службы каталогов от компании Microsoft, как подсказывает нам Википедия. За этим сухим и невзрачным определением скрывается одна из важнейших технологий в администрировании сетей. Благодаря Active Directory администратор сети получает очень удобное централизованное средство управления учетными записями пользователей, групповыми политиками (в т.ч. политиками безопасности) и объектами в сети (причём Active Directory без особых проблем справляется даже с гигантскими сетями). А благодаря встроенному механизму репликации, «положить» правильно настроенные сервисы AD не так-то просто. Ну и напоследок, благодаря Windows настроить Active Directory можно буквально мышкой, так что даже совсем начинающие IT-шники смогут с этим справиться.
Несмотря на то, что технологией заведует Microsoft, она вовсе не ограничивается управлением Windows-машин — все известные Linux-дистрибутивы уже давным давно научились работать с этой технологией. Повстречаться с Active Directory не просто, а очень просто — практически каждый офис предполагает наличие этой технологии, поэтому даже самым заядлым линуксоидам было бы неплохо разбираться в азах работы Active Directory.
Начинаем
Вы установили Windows Server 2016 и (надеюсь) видите следующий экран:
Эта панель — основное (графическое) средство администрирования Windows Server 2016. Здесь вы можете управлять компонентами и сервисами на вашем сервере (проще говоря, настраивать то, что умеет делать сервер). Эту же панель можно использовать и для базовых сетевых настроек Windows Server, для чего есть вкладка «Локальный сервер».
Базовые настройки Windows Server
Первое, что нужно сделать — это поменять сетевое имя сервера.
Сетевое имя (hostname) — это удобный способ идентификации узла в сети. Сетевое имя используется как альтернатива IP-адресу и позволяет не запоминать IP-адрес компьютера (при том, что этот адрес может меняться время от времени), а связываться с этим компьютером по его логическому названию.
Проблема в том, что по-умолчанию для Windows Server генерируется совершенно нечитаемое и неинформативное сетевое имя (я выделил его красным цветом на скриншоте).
Рабочие станции ещё могут позволить себе иметь нечитаемый Hostname, но никак не сервер. Поэтому я предлагаю поменять эту абракадабру его на что-то более разумное (например, на ADController), благо делается это быстро.
Смена сетевого имени
Нужно кликнуть на текущее имя сервера (отмечено красным цветом), затем во вкладке «Имя компьютера» нажать на кнопку «Изменить…», после чего ввести что-то более благоразумное:
После смены имени машину нужно будет перезагрузить.
Теперь зададим статический IP-адрес для сервера. В принципе это делать не обязательно, раз мы всё равно собрались поднимать DHCP службу, но на самом деле это хорошая практика, когда все ключевые элементы корпоративной сети имеют фиксированные адреса. Открыть меню по настройке сетевого адаптера можно из вкладки «Локальный сервер», кликнув на текущие настройки Ethernet-адаптера (тоже выделены красным цветом).
Настройки IP для интерфейса windows_server
Включаем нужные компоненты
Для нашего стенда нам понадобится включить следующие сервисы (или, как они тут называются, роли) на Windows Server:
- Доменные службы Active Directory;
- DNS-сервер;
- DHCP-сервер.
Пройдемся вкратце по каждому из них.
Доменные службы Active Directory
Эта роль фактически «включает» технологию Active Directory на сервере и делает его контроллером домена (под доменом в технологии AD понимается группа логически связанных объектов в сети). Благодаря этой роли администратор получает возможность управлять объектами в сети, а также хранить информацию о них в специальной распределенной базе данных.
Эта база данных содержит всю информацию об объектах в сети (например, именно в неё заносится информация об учётных записях пользователей). Когда человек подходит к рабочей станции и пытается выполнить вход в свою доменную учётную запись, эта рабочая станция связывается с контроллером домена с запросом на аутентификацию, и в случае успеха загружает пользовательский рабочий стол.
Однако, что же делать, если контроллер домена выйдет из строя (или просто будет недоступен для рабочих станций)? Если вы настроили только один контроллер домена, то дела ваши довольно плохи — без связи с рабочим контроллером домена пользователи не смогут выполнить вход на свои рабочие места. Поэтому в реальных сетях всегда рекомендуется устанавливать как минимум два контроллера на каждый домен. Каждый контроллер домена участвует в так называемом механизме репликации, благодаря чему все контроллеры домена имеют полную копию базы данных со всеми объектами в домене. Если по какой-то причине один из контроллеров выйдет из строя, его место всегда может занять резервный контроллер — и пользователи даже ничего не заметят.
Однако этот туториал рассчитан на простое ознакомление с технологией AD «на виртуалках», поэтому здесь не будет рассматриваться вопрос создания нескольких контроллеров AD в одном домене.
С этим пунктом все более менее понятно, а зачем же нам включать дополнительно ещё DNS-сервер?
DNS-сервер
Обычно протокол DNS (Domain Name System) используется для обращения к узлам в сети не по их IP-адресу, а по доменному имени (строковый идентификатор), что, конечно, гораздо удобнее. Другими словами, DNS чаще всего используется для разрешения доменных имен.
Но область применения протокола DNS не ограничивается только сопоставлением хостового имени и IP-адреса, что как раз подтверждает технология Active Directory. Дело в том, что Microsoft решила построить технологию Active Directory не с нуля, а на основе протокола DNS. В частности, протокол DNS используется при определении местонахождения всех ключевых сервисов Active Directory в сети. Другими словами, рабочая станция при подключении к контроллеру домена понимает, «куда» ей надо обращаться, именно с помощью протокола DNS.
Все DNS-записи (в том числе с информацией о сервисах Active Directory) хранятся на DNS-сервере, а это значит, что нам нужно заиметь свой собственный DNS-сервер! Вот только вопрос, откуда его взять? Есть два варианта:
- Использовать отдельную машину в роли DNS-сервера;
- Использовать саму машину windows_server в роли DNS-сервера.
Первый вариант, безусловно, самый правильный — именно так и надо поступать при реальном администрировании сетей (чем больше вы разносите логику по разным узлам в сети — тем лучше). Но в учебных целях я решил выбрать второй вариант (хотя бы потому, что не придётся создавать ещё одну виртуальную машину).
Именно поэтому эту роль (DNS-сервера) тоже нужно добавить к ролям машины windows_server.
Кстати, если не добавить роль «DNS-сервер» сейчас, то в будущем у вас ещё будет такая возможность при конфигурировании контроллера домена AD.
DHCP-сервер
Протокол DHCP (Dynamic Host Configuration Protocol) нужен для автоматической выдачи сетевых настроек узлам в сети. Под сетевыми настройками понимается IP-адрес, адрес шлюза по-умолчанию, адрес DNS-сервера, и ещё ряд других настроек. Этот протокол чрезвычайно удобен при администрировании сетей, особенно больших.
В этом туториале я использую протокол DHCP чтобы рабочая станция workstation могла получить сетевые настройки (в частности, адрес DNS-сервера) без каких-либо действий с моей стороны.
Протокол DHCP не имеет никакого отношения к технологии Active Directory, и можно было бы обойтись вовсе без него (достаточно прописать все сетевые настройки на рабочей станции самостоятельно), но я решил включить этот протокол в данный туториал просто для общего ознакомления. К тому же, такая связка «Контроллер AD — DNS-сервер — DHCP-сервер» довольно часто встречается в реальной жизни, потому что это очень удобный набор сервисов.
При этом вопрос о том, стоит ли выделять отдельную машину под DHCP-сервер, остаётся открытым. Для небольших сетей однозначно не стоит разносить DNS и DHCP-серверы по разным машинам, но для больших сетей, возможно, имеет все-таки смысл задуматься об этом. В нашей же крошечной сети мы абсолютно ничего не потеряем, если включим DHCP-сервер на той же машине, что и DNS-сервер.
Что ж, довольно теории, давайте лучше перейдём к включению этих самых ролей.
Мастер добавления ролей и компонентов
Возвращаемся на панель мониторинга (самый первый скриншот) и щелкаем на пункт «Добавить роли и компоненты». Вас поприветствует мастер добавления ролей и компонентов. Первый экран («Перед началом работы») пропускаем, он совсем неинтересный, а вот дальше идёт экран «Выбор типа установки»
Выбор типа установки
Нас устраивает значение по-умолчанию (Установка ролей или компонентов»), но интересен и второй пункт — он позволяет задействовать ещё одну возможность Windows Server — инфраструктуру виртуальных рабочих мест (Virtual Desktop Environment — VDI). Эта интереснейшая технология позволяет, буквально, виртуализировать рабочее место. То есть для пользователя создаётся виртуальное рабочее место, к которому он может подключаться через тонкий клиент. Пользователь лишь видит картинку, тогда как само рабочее место может совершенно прозрачно работать где угодно.
Впрочем, технология VDI это отдельная большая тема, а в этом туториале надо сосредоточиться на контроллере AD, так что кликаем «Далее» и видим экран выбора целевого сервера.
Выбор целевого сервера
Мастер добавления ролей позволяет устанавливать роль не только на текущую машину, но вообще на любой добавленный сервер, и даже на виртуальный жёсткий диск. Да, если ваша Windows Server развернута на виртуальной машине (а это довольно частое явление), то вы можете администрировать эту виртуальную машину даже не запуская её! Понаблюдать за этим процессом можно, например, здесь
Нам же такая экзотика ни к чему, так что просто выбираем единственный возможный сервер (обратите внимание, что он теперь называется ADController место непонятной абракадабры), жмём «Далее» и, наконец, попадаем на экран выбора ролей, которые нужно добавить.
Выбор добавляемых ролей
Выбираем три роли, о которых уже говорили ранее, и продолжаем.
Выбор компонентов
Теперь необходимо выбрать дополнительные компоненты. В чём разница между ролью и компонентом, можете спросить вы? О, это не такой уж и лёгкий вопрос, честно говоря!
Согласно идеологии Microsoft, роль — это набор программ, которые позволяют компьютеру предоставлять некоторые функции для пользователей в сети. Например, DNS, DHCP, контроллер домена AD — это всё роли. А вот компоненты — это набор программ, которые улучшают либо возможности ролей сервера, либо самого сервера.
При этом глядя на список «Компонентов» так сходу и не скажешь, что какие-то вещи в списке лишь «вспомогательные». Вот например, DHCP-сервер расценивается как роль, а WINS-сервер — уже как компонент. А чем SMTP-сервер хуже DNS?
В общем-то, чёткой границы между ролью и компонентом не существует. Я лично предпочитаю относиться к ролям как к большим функциональным возможностям сервера, а к компонентам — как к небольшим дополнительным аддонам.
В любом случае, дополнительные компоненты нам не нужны, так что кликаем «Далее».
После этого идёт несколько пояснительных экранов с информацией по каждой добавленной роли, но эту информацию я уже разбирал, поэтому останавливаться лишний раз не буду.
Подтверждение устанавливаемых ролей и компонентов
На экране подтверждения ещё раз видим все устанавливаемые роли и компоненты, после чего жмём «Установить».
Остаётся лишь дождаться, когда заполнится progress-bar, и перейти к следующему пункту туториала — настройке контроллера домена AD.
Настраиваем контроллер домена Active Directory
Все роли и компоненты успешно добавлены, о чём свидетельствует следующий экран:
Вот только AD на сервере всё еще не работает — для этого его необходимо донастроить. Для этого нам настойчиво предлагают «Повысить роль этого сервера до уровня контроллера домена».
Погодите-ка, ЧТО?!
А чем же я занимался последние 15 минут? Я же добавлял роли, и судя по сообщению, они успешно добавились! И тут меня снова хотят заставить добавлять какие-то новые роли? В чем-то тут подвох.
Подвох тут действительно имеется, но вообще в не самом очевидном месте. Вот так выглядит предыдущий скриншот в английской версии Windows Server (картинка из интернета).
Английская версия скриншота
Видите разницу? В английской версии ни слова ни про какие роли! Про повышение есть, про роли — нет. Один из тех случаев, когда перевод вносит сумятицу на пустом месте. Согласно английской версии, никакими ролями мы дальше не занимаемся, что и логично, ведь мы их как раз только что добавили.
Что ж, тыкаем на предложение «Повысить роль этого сервера до уровня контроллера домена», и теперь нас привествует мастер настройки доменных служб Active Directory с предложением выбрать конфигурацию развёртывания.
Конфигурация развёртывания
Всего тут есть 3 варианта развития событий. Для того, чтобы выбрать правильный пункт, давайте сначала разберёмся, что эти пункты означают. В этом нам поможет вот такая картинка (картинка, если что, отсюда):
Технология Active Directory (как и DNS) подразумевает иерархическое построение имён на основе доменов. Домены могут выстраиваться в доменные деревья по принципу «родительско-дочерних» отношений. В основе дерева лежит так называемый корневой домен (на картинке выше это sources.com, xyz.com и abc.com). При этом домен может иметь сколько угодно потомков. Домен-потомок располагается в пространстве имён родителя и является его «поддоменом» (subdomain). У доменного имени домена-потомка есть дополнительный префикс относительно доменного имени родителя (rus.abc.com, eng.abc.com). Один корневой домен основывает только одно доменное дерево со своим независимым пространством имён.
Теперь представьте, что таких независимых деревьев может быть много — в этом случае эти деревья образуют структуру, которая называется «лес». При этом в Active Directory доменные деревья не могут быть «сами по себе» — они обязательно должны находиться в лесу (даже если лес будет состоять всего из одного-единственного домена). Первый домен, который добавляется в лес, называется корневым доменом леса (на рисунке выше это sources.com). Корневой домен леса используется для идентификации всего леса (то есть если корневой домен называется sources.com, то и весь лес называется sources.com).
Теперь возвращаемся к мастеру настройки доменных имен. На этом этапе мастер предлагает следующие варианты:
- Добавить контроллер домена в существующий домен (помните про резервирование контроллеров в домене, так ведь?). Этот вариант не для нас, ведь домена ещё никакого нет;
- Добавить новый домен в лес. Этого мы тоже сделать не можем, т.к. и леса у нас тоже никакого нет;
- Добавить новый лес. Это вариант как раз для нас. При этом нам тут же предлагают выбрать корневой домен для этого леса (первый домен, который будет создан в лесу).
Назовём корневой домен mydomain.com и кликнем «Далее»
Параметры контроллера домена
Рассмотрим возможные параметры:
- Режим работы леса и домена. Домены в одном лесу могут работать в разных режимах в зависимости от версии Windows Server на борту. Лес должен иметь режим не выше, чем самый «старый» домен в его составе. Т.к. мы планируем использовать только Windows Server 2016, то оставим этот режим и для леса и для домена;
- DNS-сервер. Если ранее Вы не активировали роль DNS-сервера в мастере добавления ролей, то можете сделать это сейчас (вам даже предложат такой вариант по-умолчанию);
- Должен ли контроллер домена выступать в роли Global Catalog-сервера;
- Включить ли режим базы данных Active Directory «только на чтение». Основная задача, которую преследует технология RODC — возможность безопасной установки собственного контролера домена в удаленных филиалах и офисах, в которых сложно обеспечить физическую защиту сервера с ролью DC. Контроллер домена RODC содержит копию базы Active Directory, доступную только на чтение. Это означает, что никто, даже при получении физического доступа к такому контроллеру домена, не сможет изменить данные в AD (в том числе сбросить пароль администратора домена) (информация взята отсюда)
А вот пункт 3 рассмотрим поподробнее, он довольно интересный.
Как я уже упоминал выше, каждый контроллер домена имеет полную и исчерпывающую информацию обо всех объектах в своём домене. Если же в домене несколько контроллеров, то они ещё и участвуют в механизме репликации, поддерживая несколько актуальных копий базы данных с объектами домена. Получается, что рабочая станция в домене может узнать информацию о любом объекте из этого домена от своего ближайшего контроллера домена.
Но что же делать, если рабочей станции нужно получить информацию об объекте из другого домена? И вот тут в дело вступает ещё один важнейший механизм технологии Active Directory, который называется глобальный каталог.
Что такое вообще «Глобальный каталог»? Согласно Miscrosoft — это распределенное хранилище данных, которое хранит частичное представление обо всех AD-объектах в лесу. Это хранилище располагается на котроллерах домена, которые имеют дополнительную роль «Global Catalog Server» (Сервер глобального каталога). От обычного контроллера домена GC-сервер отличается в первую очередь тем, что помимо полной копии всех объектов в своем домене, хранит также частичную информацию обо всех объектах в других доменах леса.
Чего это позволяет достичь? Давайте представим, что рабочая станция запросила информацию об объекте из другого домена. Она обращается на ближайший GC-сервер с просьбой предоставить ей информацию об этом объекте. GC-сервер, в свою очередь, может:
- Либо отдать рабочей станции нужную информацию сразу (если эта информация у GC-сервера имеется);
- Либо перенаправить запрос к нужному контроллеру домена, где эта информация точно будет находиться. Чтобы понять, какому контроллеру домена нужно перенаправить запрос, как раз и происходит поиск по GC.
Информация о том, какие атрибуты попадают в глобальный каталог, определена в Partial Attribute Set (PAS), который может настраивать администратор AD. Например, если администратор понимает, что рабочие станции часто будут обращаться к атрибуту, который не содержится в глобальном каталоге, он может добавить туда этот атрибут. Тогда запросы рабочих станций при чтении этого атрибута будут выполняться значительно быстрее, т.к. уже ближайший GC-сервер сможет предоставить им всю нужную информацию.
Однако, если в лесе всего один домен (как у нас), то Глобальный каталог содержит полную копию объектов в домене и всё.
Что ж, возвращаемся к галочке GC, которую за нас уже проставил мастер настройки доменных служб. Если вы попробуете её отключить, то убедитесь, что отключить её нельзя. Это связано с тем, что каждый домен в AD должен иметь хотя бы один GC-сервер, и при добавлении первого контроллера в домен этот контроллер сразу помечается как GC-сервер.
Что ж, давайте согласимся с этим «выбором» мастера и перейдём к последнему параметру на этом скриншоте — к паролю для режима восстановления служб каталогов. Это особый режим безопасной загрузки Windows Server, который позволяет администратору работать с базой данных AD. Этот режим применяется, например, в следующих случаях:
- база Active Directory повреждена и нуждается в исправлении;
- требуется выполнить обслуживание базы данных AD (сжатие, анализ на наличие ошибок);
- требуется восстановить резервную копию базы данных AD;
- требуется сменить пароль администратора.
Да да, вы не ослышались. Чтобы просто восстановить резервную копию базы данных, нужно перезагрузить машину и загрузиться в особом «безопасном» режиме. Это вам не Linux какой-нибудь.
Фух, вроде разобрались. Давайте перейдем дальше на шаг, где нам предложат настроить делегирование DNS.
Делегирование DNS
Что такое делегирование DNS? По большей части, это передача ответственности за некоторую DNS-зону отдельному DNS-серверу. Это распространенная практика в больших сетях, в которых требуется разграничить зоны ответственности за доменные зоны между различными серверами. При делегировании DNS в «главный» DNS-сервер вносится запись о том, что «вот за эту DNS-зону несёт ответственность вон тот DNS-сервер, обращайся туда».
Т.к. у нас всего одна зона DNS и DNS-сервер тоже один, то этот шаг нам необходимо пропустить и перейти к выбору NetBIOS-имени.
NetBIOS-имя
Мы видим, что мастер предложил нам на выбор сразу же имя для нашего домена — MYDOMAIN. Но вы можете (и должны) задать себе вопрос: а что такое вообще NetBIOS-имя и зачем оно нужно? И разве мы уже не настраивали сетевое имя узла (Hostname) в самом начале? Чего же от вас хотят?
NetBIOS (Network Basic Input/Output) — это ещё один способ разрешения имён узлов в сети (более древний и более примитивный, чем DNS). NetBIOS-имена не предполагают никакой иерархии, их длина ограничивается всего лишь 16 символами, и они применяются только для разрешения имён компьютеров в локальной сети. Когда мы в самом начале туториала выбрали сетевое имя ADController — мы, на самом деле, задали именно NetBIOS-имя для сервера. Но теперь от нас снова требуют выбрать NetBIOS-имя (да ещё и другое, отличное от ADContoller). Не много ли NetBIOS-имён для одного компьютера?
Дело в том, что Microsoft пошла ещё дальше — и ограничила длину NetBIOS-имен не 16 символами, а 15 символами. 16-ый символ при этом считается зарезервированным суффиксом, который может принимать фиксированные значения. В зависимости от значения 16-го байта получаются разные классы NetBIOS-имён. Например, если суффикс равен 00, то NetBIOS-имя относится к рабочей станции. Если суффикс равен 1С, то это имя относится к имени домена.
То есть, как вы понимаете, на первом шаге мы задавали NetBIOS-имя для компьютера Windows Server (с суффиком 00). А теперь задаём NetBIOS-имя домена mydomain.com (с суффиксом 1С).
Кстати, можете, ради интереса, отмотать туториал в самое начало и посчитать количество символов в «нечитаемом» автоматически сгенерированном сетевом имени windows_server. Будет как раз 15 символов (максимальная длина NetBIOS-имени).
И напоследок скажу, что вы не можете пропустить этот шаг. NetBIOS хоть и устаревшая технология, но до сих пор используется ради совместимости с некоторыми старыми службами. Настроить контроллер домена Active Directory без NetBIOS-имени нельзя.
Что ж, и с этим тоже разобрались. Оставляем NetBIOS-имя по-умолчанию и двигаемся дальше, к выбору места расположения базы данных AD. Можно оставить значение по-умолчанию, комментировать особо нечего.
Расположение базы данных
Все ваши настройки должны пройти предварительную проверку:
Проверка предварительных требований
Как только всё готово, жмите «Установить» и можете спокойно идти пить чай, потому что после установки автоматически начнётся очень-очень долгая перезагрузка. Зато настройка контроллера домена AD на этом закончена, поздравляю!
Настройка DHCP-сервера
Пришло время заняться настройкой DHCP-сервера. Настройка глобально состоит из двух частей:
- Авторизация DHCP-сервера в домене AD. Не каждый DHCP-сервер может раздавать сетевые настройки в домене AD — только авторизованные. Это сделано с целях безопасности, чтобы другие DHCP-серверы не могли «подсунуть» неправильные настройки компьютерам в домене;
- Настройка новой DHCP-области. Это уже непосредственно настройка самого DHCP-сервера, в ходе которой определяются какие сетевые настройки будут выдаваться компьютерам в сегменте сети.
Для того, чтобы авторизировать DHCP-сервер, нужно вернуться на панель мониторинга (она и так должна быть перед вами после перезагрузки), перейти на вкладку DHCP (слева) и кликнуть на предложение донастроить DHCP-сервер:
Запуск авторизации DHCP-сервера
В открывшемся мастере настройки DHCP после установки пропускаем первый приветственный экран и переходим к экрану авторизации
Авторизация DHCP-сервера в домене
На выбор предлагаются три варианта:
- Использовать учётные данные администратора (по-умолчанию)
- Использовать учётные данные другого пользователя;
- Пропустить авторизацию AD.
По-умолчанию авторизовать DHCP-сервер в домене могут только члены группы EnterpriseAdmins, куда как раз и входит пользователь MYDOMAINАдминистратор. При желании можно потратить немного времени и делегировать эту возможность админам «помельче» (региональным администраторам), почерпнуть больше информации по этой теме можно отсюда.
Итак, выбираем вариант по-умолчанию и завершаем первый этап настроки DHCP-сервера.
Завершение авторизации DHCP-сервера
Теперь переходим непосредственно к настройкам DHCP. Для этого на панели мониторинга кликаем вкладку «Средства» и выбираем пункт «DHCP»
В открывшемся окне с настройками DHCP нужно кликнуть правой кнопкой мышки на IPv4 и затем на пункт меню «Создать область». После этого откроется мастер создания новой области.
Открытие мастера создания новой области
Что такое DHCP-область? Под этим понимается некий диапазон IP-адресов, которые может выдавать DHCP-сервер другим компьютерам в сети. Каждая область помимо диапазона IP-адресов также содержит другие сетевые настройки, с которыми мы сейчас и познакомимся.
Назовём DHCP-область SCOPE1 и перейдём дальше.
На следующем экране вам предложат выбрать диапазон адресов, которые будут выдаваться компьютерам в сети. Ранее я настраивал сетевой интерфейс на Windows Server, выдав ему адрес 192.168.1.1/24. Это статический адрес и он зарезервирован, его выдавать другим компьютерам нельзя.
Зато никто не мешает выдавать все остальные адреса в сети 192.168.1.0/24 — так что задаём диапазон от 192.168.1.2 до 192.168.1.254 (192.168.1.255 — это зарезервированный широковещательный адрес, его выдавать тоже нельзя).
Настройка диапазона адресов
В целом, никто не мешает вам как администратору выдавать меньше IP-адресов, чем доступно в адресации сети. Например, можно было бы выделить в сети всего 100 адресов для автоматической выдачи: 192.168.1.101-192.168.1.200.
Переходим далее и видим предложение о выборе исключений из указанонного диапазона адресов, а также о настройке задержки при передаче сообщения DHCPOFFER
Исключения в диапазоне и задержка DHCPOFFER
С исключениями всё более-менее понятно: если вы не хотите выдавать некоторые адреса в указанном ранее диапазоне, то вы можете указать эти адреса здесь в виде исключений. А что за задержка в DHCPOFFER такая?
Эта настройка уже относится к довольно продвинутому администрированию сетей: если в вашей сети есть несколько DHCP-серверов, то с помощью этой задержки вы можете регулировать нагрузку между ними (подробнее можно прочитать, например, тут).
В любом случае, исключений в диапазоне у нас нет, да и задержка по-умолчанию нас устраивает, так что кликаем дальше и видим настройку сроков аренды адресов.
Настройка времени аренды адресов
Протокол DHCP предполагает выделение адресов только на определённое время, после чего компьютеры должны продлять аренду. Здесь можно настроить это время (по-умолчанию — 8 дней).
8 дней меня лично вполне устраивает, так что кликаем «Далее» и видим предложение настроить другие настройки, которые будут получать клиенты в сети (помимо IP-адреса). Соглашаемся.
Настроить дополнительные параметры
Первая сетевая настройка для клиентов — это шлюз по-умолчанию. В стенде из двух виртуальных машин эта настройка в принципе не нужна. Но можно представить, что windows_server будет играть роль шлюза во внешнюю сеть, и добавить адрес 192.168.1.1 как шлюз по-умолчанию.
Шлюз по-умолчанию
Далее идет настройка DNS. Здесь можно задать имя родительского домена и адреса DNS-серверов. С адресами DNS-серверов всё более-менее понятно — это IP-адреса серверов, куда следует обращаться клиентам за помощью в разрешении DNS-имён. Сейчас в этом списке фигурирует тот же адрес, что мы добавили как шлюз по-умолчанию.
А вот для понимания имени родительского домена, рассмотрим следующую ситуацию.
Допустим, есть домен mydomain.com и есть два компьютера в этом домене с именами comp1.mydomain.com и comp2.mydomain.com. Если comp1 хочет связаться с comp2, то он должен, по-хорошему, использовать следующую команду (обращение по Fully Qualified Domain Name — FQDN):
ping comp2.mydomain.com
Но задумывались ли вы когда-нибудь, что именно произойдет, если попытаться пропинговать другой узел следующим образом?
ping comp2
На самом деле, в этом случае начинается целая магия — очень хитрый процесс разрешения имён (картинка из интернетов).
Процесс разрешения сетевых имён
- Поиск информации в hosts.txt или в кеше;
- Попытка найти имя через DNS;
- Попытка найти NetBIOS-имя в кеше;
- Попытка найти NetBIOS-имя через WINS-сервер;
- Попытка найти NetBIOS-имя путём отправки широковещательных пакетов в локальную сеть;
- Попытка найти NetBIOS-имя в LMHOSTS-файле.
Согласно алгоритму разрешения сетевых имен, сначала comp1 попробует найти информацию о comp2 в hosts.txt — файле. Если этой информации там не окажется, то начинается процесс поиска узла через DNS. Вот только вопрос — DNS-имена же находятся в каком-то домене, верно? Какое доменное имя нужно «пристыковать» к comp2 при выполнении пинга?
Вот тут в дело и вступает настройка DHCP, которая называется «имя родительсокго домена». Это как раз тот суффикс, который будет автоматически «пристыкован» к имени comp2 при выполнении DNS-разрешения имени. Так что если имя родительского домена равно «mydomain.com», то команда ping comp2
неявно преобразуется в ping comp2.mydomain.com
.
Если же DNS-разрешение окажется неудачным, дальше начнутся попытки найти comp2 уже по NetBIOS-имени. Что такое WINS, и чем он отличается от Broadcast — информация будет чуть дальше по тексту.
Что ж, в нашем случае имя родительсокго домена должно быть mydomain.com (значение по-умолчанию), а нужный DNS-сервер уже находится в списке, так что в итоге просто кликаем «Далее».
Настройки DNS
Теперь нас попросят указать настройки WINS-сервера. WINS (Windows Internet Name Service) сервер участвует в разрешении NetBIOS-имён в сети (прямо как DNS-сервер для DNS-имён). Вот только, в отличие от DNS, WINS-сервер не обязательно должен присутствовать в сети, чтобы разрешение NetBIOS-имён работало. Так зачем же он нужен тогда?
Дело в том, что по-умолчанию разрешение NetBIOS-имен происходит через широковещательные запросы. С одной стороны, это очень простой механизм (проще не придумаешь), но, с другой стороны, обладает парой недостатков:
- При наличии большого количества NetBIOS-имён в сети широковещательный тафик может начать «зашумлять» канал;
- Широковещательные запросы не могут «выйти» за пределы текущей сети, поэтому узнать NetBIOS-имя из другой сети таким способом не выйдет.
Так вот, WINS-сервер позволяет решить обе этих проблемы. Этот сервер централизованно хранит NetBIOS-имена компьютеров, и обычные узлы в сети могут обращаться к нему для поиска IP-адреса интересующего их имени (как и для DNS). Такой подход, во-первых, резко уменьшает количество широковещательного трафика в сети, а, во-вторых, позволяет посылать NetBIOS-запросы в другие сети, а не только в текущую.
В нашей небольшой сети WINS-сервер нам ни к чему, поэтому просто пропускаем эту настройку и едем дальше.
WINS-серверы
В последнем шаге настройки вам предлагают сразу активировать настроенную область. Соглашаемся, и на этом заканчиваем настройку DHCP.
Активация области
Создаём нового пользователя в домене AD
Собственно настройка контроллера домена и различных сервисов уже фактически закончена, все параметры выставлены как надо. Теперь нужно просто зарегистрировать нового пользователя, от имени которого рабочая станция workstation будет выполнять вход в домен.
Для этого возвращаемся на панель мониторинга, кликаем на «Средства» и затем на «Пользователи и Компьютеры Active Directory»
В открывшемся меню можно заметить созданный домен mydomain.com и его состав. Видно, что помимо пользователей в домене созданы папочки для Computers, Domain Controllers и других сущностей. Но нас сейчас интересуют пользователи, поэтому кликаем правой кнопкой мышки на папке Users и выбираем «Создать» -> «Пользователь»
После этого появляется диалоговое окно с преложением ввести данные нового пользователя. По старой доброй традиции назовём пользователя Foo Bar. Обратите внимание, что пользователь отображается лишь как «Объект» в Active Directory наравне с другими объектами.
Новый объект — Пользователь
Теперь необходимо задать пароль и дополнительные параметры для пользователя. Пароль должен соответсовать политике паролей по-умолчанию, которая, в том числе, предписыват паролям в домене быть довольно сложными (должен использовать числа, буквы верхнего и нижнего регистра, а также спец символы).
Обычно администратор создаёт простой пароль для пользователя, а затем требует от пользователя сменить его при первом входе в систему (первая галочка в списке доступных опций). Это очень хорошая практика с точки зрения безопасности, ведь таким образом даже администратор AD не сможет узнать пароль пользователя. Также хорошей практикой считается ограничивать срок действия пароля. В этом туториале для простоты мы уберём требование о смене пароля пользователем при врходе в систему.
Параметры нового пользователя
После этого останется лишь подтвердить создание нового пользователя.
Подтверждение создания нового пользователя
Ну что ж, вот, кажется, и всё! Осталось лишь проверить ввод рабочей станции в домен.
Ввод рабочей станции в домен
Переключаемся на вторую машину workstation под управлением Windows 7 и заходим в свойства системы. Сейчас видно, что рабочая станция находится в рабочей группе (не в домене). Кстати говоря, WORKGROUP — это тоже NetBIOS-имя. Только в отличии от имени домена оно имеет суффикс 1E.
Щелкаем на кнопку «Изменить параметры», затем в появившемся окне ещё раз «Изменить…».
В окне изменения имени компьютера пишем, что он должен принадлежать домену mydomain.com.
Подключение к домену
Видим предупреждение о нестандартном имени компьютера (testo-ПК содержит кириллицу). Это связано с тем, что NetBIOS-имена не могут содеражать кириллицу. Но мы с вами настроили DNS-сервер (DNS настройки прилетели на рабочую станцию по DHCP), а DNS-механизм разрешения имён, как мы знаем, имеет приоритет перед NetBOIS. Так что в данном случае на работоспособность AD кириллица не влияет. Но на практике так делать не надо!
Нестандартное имя компьютера
Вводим логин-пароль от новой учетной записи FooBar и, наконец, видим заветное сообщение «Добро пожаловать в домен»
После ввода компьютера в домене необходимо перезагрузить компьютер, ну а дальше — вводим учётные данные пользователя в AD.
Логин в AD
И после успешного входа на рабочий стол перепроверяем свойства системы.
Новые свойства системы
Полное имя компьютера поменялось на testo-ПК.mydomain.com, а это значит, что мы успешно ввели рабочую станцию в домен mydomain.com.
Автоматизируем
Как вы могли заметить, весь туториал можно выполнить, пользуясь исключительно мышкой и клавиатурой. Больше того, нам даже не пригодились знания PowerShell, который позволяет выполнять бОльшую часть настройки контроллера домена AD с помощью скриптов.
Так почему бы не автоматизировать все действия с клавиатурой и мышкой, которые мы предпринимали? И нет, я говорю не об AutoIT, я говорю о платформе Testo, создателем которой я являюсь. Эта платформа позволяет фиксировать все действия, проводимые с виртуальными машинами, в виде скриптов на специальном языке Testo-lang. Ну а Testo затем превратит эти скрипты обратно в действия.
Я приведу лишь один скриншот с кусочком скрипта, чтобы у вас сложилось представление о том, о чём я говорю (да, именно скриншот, ведь хабр не умеет подсвечивать скриповый язык Testo-lang). Я даже не буду комментировать этот скрипт, т.к. верю, что код говорит сам за себя.
Секция скрипта на языке Testo-lang
Я не буду сейчас рассказывать о платформе Testo и о её возможностях. Для этого есть отдельная статья на хабре. Вместо этого предлагаю просто увидеть своими глазами, как это работает:
Всё, что Вам потребуется для создания собственного стенда с настроенной Active Directory — это:
- Установочный iso-образ Windows Server 2016 русской версии;
- Установочный iso-образ Windows 7 (придётся поискать самим);
- Скрипты на языке Testo-lang;
- Установленная платформа Testo (бесплатно);
- Выполнить команду.
sudo testo run ./tests.testo --param ISO_DIR /path/to/your/iso/dir
И всё. Как и я обещал — всего одна команда. Через пол часа — час (зависит от шустрости вашего компьютера) вы сможете наслаждаться своим готовым стендом.
Итоги
Надеюсь, вам понравился туториал, и вы нашли его полезным. Возможно, вас заинтересовала платформа Testo, в этом случае вот несколько полезных ссылок:
- сайт платформы Тесто.
- youtube-канал, где можно найти много примеров.
- основная статья на хабре
- статья, где я автоматизировал несколько системных тестов для Dr. Web
- скрипты на языке Testo-lang для этого туториала
Доменом в Windows Server называют отдельную область безопасности компьютерной сети.
В домене может быть один или несколько серверов выполняющих различные роли. Разрешения, применяемые администратором, распространяются на все компьютеры в домене.
Пользователь, имеющий учетную запись в домене, может войти в систему на любом компьютере, иметь учетную запись на локальном компьютере не требуется.
В домене могут работать несколько тысяч пользователей, при этом компьютеры могут принадлежать к разным локальным сетям.
Несколько доменов имеющих одну и ту же конфигурацию и глобальный каталог называют деревом доменов. Несколько деревьев могут быть объединены в лес.
В домене есть такое понятие как групповая политика. Под групповой политикой понимают настройки системы, которые применяются к группе пользователей. Изменения групповой политики затрагивают всех пользователей входящих в эту политику.
Параметры групповой политики хранятся в виде объектов групповой политики (Group Policy Object, GPO). Эти объекты хранятся в каталоге подобно другим объектам. Различают два вида объектов групповой политики – объекты групповой политики, создаваемые в контексте службы каталога, и локальные объекты групповой политики.
Не будем подробно вдаваться в теорию и перейдем к практике.
Запускаем Диспетчер серверов -> «Добавить роли и компоненты».
На первой странице мастер напоминает, что необходимо сделать перед началом добавления роли на сервер. Нажмите «Далее».
На втором шаге нужно выбрать «Установка ролей и компонентов» и нажать «Далее».
Выбираем сервер, на который нужно установить Active Directory (он у нас один), «Далее».
Теперь нужно выбрать роль, которую нужно добавить. Выбираем «Доменные службы Active Directory». После чего откроется окно, в котором будет предложено установить службы ролей или компоненты, необходимые для установки роли Active Directory, нажмите кнопку «Добавить компоненты», после чего кликните «Далее».
PЗатем нажимайте «Далее», «Далее» и «Установить».
Перезапустите компьютер.
После того, как роль была добавлена на сервер, необходимо настроить доменную службу, то есть установить и настроить контроллер домена.
Настройка контроллера домена Windows Server
Запустите «Мастер настройки доменных служб Active Directory», для чего нажмите на иконку «Уведомления» в диспетчере сервера, затем нажмите «Повысить роль этого сервера до уровня контроллера домена».
Выберите пункт «Добавить новый лес», затем введите имя домена в поле «Имя корневого домена». Домены в сети Windows имеют аналогичные названия с доменами в интернете. Я ввел имя домена buzov.com. Нажимаем «Далее».
На этом шаге можно изменить совместимость режима работы леса и корневого домена. Оставьте настройки по умолчанию. Задайте пароль для DSRM (Directory Service Restore Mode – режим восстановления службы каталога) и нажмите «Далее».
Затем нажимайте «Далее» несколько раз до процесса установки.
Когда контроллер домена установиться компьютер будет перезагружен.
Добавление и настройка групп и пользователей в домене Windows Server
Теперь нужно добавить пользователей домена, что бы присоединить к сети рабочие места сотрудников.
Отроем «Пользователи и компьютеры Active Directory». Для этого перейдите в Пуск –> Панель управления –> Система и безопасность –> Администрирование –> Пользователи и компьютеры Active Directory.
Создадим отдел «Бухгалтерия», для этого выделите название домена и вызовите контекстное меню, в котором выберите (Создать – Подразделение). Введите имя отдела (бухгалтерия) и нажмите «OK»
Подразделения служат для управления группами компьютеров пользователей. Как правило их именуют в соответствии с подразделениями организации.
Создайте учетную запись пользователя в новом подразделении. Для этого в контекстном меню нового подразделения выберите пункт Создать –> Пользователь. Пусть первым пользователем будет Бухгалтер.
После ввода имени пользователя и учетной записи нажмите «Далее». Теперь нужно ввести пароль. По умолчанию пароль должен соответствовать требованиям сложности, то есть содержать три из четырех групп символов: заглавные буквы, строчные буквы, цифры, специальные знаки ( . , + – = ? № $ и так далее). Установите параметр «Требовать смену пароля при следующем входе в систему».
Создайте учетную запись группы безопасности. Для этого в контекстном меню нового подразделения (бухгалтерия) выберите пункт (Создать – Группа). При создании новой группы безопасности необходимо ввести имя, область действия и тип группы. Область действия определяет видимость данной группы в службе каталога. Глобальная группа видна в любом домене службы каталога и ей могут назначаться привилегии доступа к ресурсам других доменов. Локальная группа видна только в своем домене, то есть ей будут доступны ресурсы только ее домена. Группы безопасности позволяют
объединять пользователей и другие группы для назначения им одинаковых привилегий на различные объекты. Группы распространения используются для рассылки сообщений, они не участвуют в разграничении прав доступа.
Теперь нужно ввести компьютер в домен и зайти под новым пользователем. Для этого на клиентском компьютере нужно указать DNS-адрес. Для этого откройте «Свойства сетевого подключения» (Пуск –> Панель управления –> Сеть и Интернет – >Центр управления сетями и общим доступом – Изменение параметров адаптера), вызовите контекстное меню подключения и выберите «Свойства».
Выделите «Протокол Интернета версии 4 (TCP/IPv4)», нажмите кнопку «Свойства», выберите «Использовать следующие адреса DNS-серверов» и в поле «Предпочитаемый DNS-сервер» укажите адрес вашего DNS-сервера. Проверьте, что задан IP-адрес и маска той же подсети, в которой находится сервер.
Присоединение компьютера к домену
Откройте свойства системы (Пуск –> Панель управления –> Система и безопасность –> Система –> Дополнительные параметры системы). Выберите вкладку «Имя компьютера» и нажмите «Изменить». Выберите «Компьютер является членом домена» и введите имя домена.
После этого необходимо ввести логин и пароль пользователя с правами присоединения к домену (обычно администратора домена). Если вы всё указали правильно, то появиться приветственное сообщение «Добро пожаловать в домен …».
Для того чтобы завершить присоединение, необходима перезагрузка.
После перезагрузки войдите в систему под доменной учётной записью пользователя, которая была создана ранее
После ввода пароля операционная система попросит вас сменить пароль.
Вернемся на сервер. Нажмите «Пуск» -> Администрирование и перейдите в окно Управления групповой политикой. Выбираем наш лес, домен, Объекты групповой политики, щелкаем правой кнопкой мыши -> создать. Называем его buh (это объект групповой политики для группы Бухгалтерия).
Теперь необходимо привязать данный объект групповой политики к созданной группе. Для этого нажмите правой кнопкой на созданное подразделение (Бухгалтерия) и выберите «Связать существующий объект групповой политики…», затем выберите созданный ранее объект в списке и нажмите «ОК».
Далее выбираем созданный объект.
Выбранный объект должен появиться в списке связанных объектов групповой политики. Для редактирования параметров, определяемых данным объектом, нажмите на него правой кнопкой и выберите «Изменить».
Установка параметров безопасности
Установка параметров безопасности — завершающий этап настройка домена и групповых политик в Windows Server.
Ограничения парольной защиты
Ограничение на параметры парольной системы защиты задаются в контексте «Конфигурация компьютера». Выберите Конфигурация Windows –> Параметры безопасности –> Политики учетных записей –> Политика паролей.
В данном разделе объекта групповой политики определяются следующие параметры:
- «Минимальный срок действия пароля» задает периодичность смены пароля.
- «Минимальная длина пароля» определяет минимальное количество знаков пароля.
- «Максимальный срок действия пароля» определяет интервал времени, через который разрешается менять пароль.
- «Пароль должен отвечать требованиям сложности» определяет требования к составу групп знаков, которые должен включать пароль.
- «Хранить пароли, используя обратимое шифрование» задает способ хранения пароля в базе данных учетных записей.
- «Вести журнал паролей» определяет количество хранимых устаревших паролей пользователя.
Тут нужно указать необходимые параметры (определите самостоятельно).
Политика ограниченного использования программ
Объекты групповой политики позволяют запретить запуск определенных программ на всех компьютерах, на которые распространяется действие политики. Для этого необходимо в объекте групповой политики создать политику ограниченного использования программ и создать необходимые правила. Как это сделать.
Выберите раздел Конфигурация пользователя –> Политики –> Конфигурация Windows –> Параметры безопасности –> Политики ограниченного использования программ. Нажмите правой кнопкой на «Политики ограниченного использования программ», далее заходим в «Дополнительные правила» и жмем правой кнопкой мыши, затем выбираем «Создать правило для пути».
После обновления объекта групповой политики на рабочей станции, политика ограниченного использования программ вступит в действие и запуск программ, соответствующих правилам, будет невозможен.
Давайте запретим использовать командную строку на клиентском компьютере.
Запрет запуска командной строки (cmd.exe).
На этом все. Если у вас остались вопросы, обязательно задайте их в комментариях.
При попытке запустить командную строку на клиентской машине вы получите сообщение.
В прошлой части нашей статьи мы разобрали тот минимум теоретического материала, который необходимо знать перед развертыванием доменных служб Active Directory. Сегодня мы начнем практическую часть цикла, в которой подробно рассмотрим создание и переход к доменной структуре сети. Начнем, как всегда, сначала — в данной статье мы расскажем как правильно развернуть контроллеры домена.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Перед тем как приступить к практическому воплощению в жизнь всех своих планов сделайте паузу и еще раз проверьте некоторые мелочи. Очень часто эти вещи ускользают от взгляда администратора, принося в дальнейшем довольно серьезные затруднения, особенно для начинающих.
Итак:
- Присвойте будущему доменному контроллеру удобочитаемое имя, например SRV-DC01, а не WIN-VAGNTE3N62T.
- Установите для сетевого адаптера статический IP адрес.
- Переименуйте встроенную учетную запись администратора, используйте только латинские буквы и символы.
Убедившись, что все вышеизложенные рекомендации выполнены, можно приступать к установке роли Доменные службы Active Directory, это можно сделать через оснастку Роли в Диспетчере сервера.
Установка данной роли еще не сделает данный сервер контроллером домена, для этого необходимо запустить Мастер установки доменных служб, что и будет предложено сделать по окончании установки, также вы можете сделать это позже, запустив dcpromo.exe.
Мы не будем разбирать подробно все настройки мастера, остановившись только на ключевых, кроме того стоит отметить, что в процессе установки будет выводиться довольно большое количество справочной информации и мы рекомендуем внимательно с ней ознакомиться.
Так как это наш первый контроллер домена, то выбираем Создать новый домен в новом лесу.
Следующим шагом следует указать имя вашего домена. Не рекомендуется давать домену интернет имя внешнего домена, также не рекомендуется давать имя в несуществующих зонах первого уровня, типа .local или .test и т.д. Оптимальным вариантом для домена AD будет поддомен в пространстве имен внешнего интернет домена, например corp.example.com. Так как наш домен используется исключительно в тестовых целях в рамках лаборатории, то мы назвали его interface31.lab, хотя правильно было бы назвать его lab.interface31.ru.
Затем указываем режим работы леса, на этом вопросе мы уже останавливались в предыдущей части статьи и в подробности вдаваться не будем.
В дополнительных параметрах обязательно укажите опцию DNS-сервер. Так как Active Directory и службы DNS тесно связаны между собой, то мы рекомендуем делать каждый контроллер домена DNS сервером и не видим веских оснований разносить эти роли.
Очень важный момент — укажите и запишите в надежном месте пароль администратора режима восстановления служб каталогов, при хорошем раскладе он вам понадобиться не должен, но гораздо хуже, если вы его не можете вспомнить.
В следующем окне еще раз перепроверьте все введенные данные и можете запускать процесс настройки доменных служб. Помните, с этого момента уже ничего изменить или исправить нельзя и если вы где-то ошиблись, то придется начать все заново. А пока мастер настраивает доменные службы можете сходить налить себе чашечку кофе.
По завершении работы мастера перезагрузите сервер и, если все сделано правильно, в вашем распоряжении первый контроллер домена, который также будет исполнять роль DNS-сервера для вашей сети. Здесь возникает еще один тонкий момент, данный сервер будет содержать записи о всех объектах вашего домена, при запросе записей, относящихся к другим доменам, которые он не сможет разрешить, они будут переданы вышестоящим серверам, т.н. серверам пересылки.
По умолчанию в качестве серверов пересылки указывается адрес DNS-сервера из свойств сетевого подключения, чтобы впоследствии избежать разного рода сбоев в работе сети следует явно указать доступные сервера во внешней сети. Для этого откройте оснастку DNS в Диспетчере сервера и выберите Сервера пересылки для своего сервера. Укажите не менее двух доступных внешних серверов, это могут быть как сервера провайдера, так и публичные DNS-службы.
Также обратите внимание, что в свойствах сетевого подключения контроллера домена, который является DNS-сервером, в качестве адреса DNS должно быть указано 127.0.0.1, любые другие варианты записи являются ошибочными.
Создав первый контроллер домена, не откладывая дело в долгий ящик, приступайте к развертыванию второго, без этого ваша структура AD не может считаться полноценной и отказоустойчивой. Также убедитесь, что сервер имеет удобочитаемое имя и статический IP-адрес, в качестве DNS-сервера укажите адрес первого контроллера и введите машину в домен.
После перезагрузки войдите доменным администратором и установите роль Доменные службы Active Directory, после чего также запустите мастер. Принципиальных отличий в настройке второго контроллера нет, разве что отвечать придется на меньшее число вопросов. Прежде всего укажите, что вы добавляете новый контроллер в существующий домен.
Как мы уже говорили, рекомендуем сделать этот сервер DNS-сервером и Глобальным каталогом. Помните, что при отсутствии глобального каталога ваш домен может оказаться неработоспособным, поэтому рекомендуется иметь как минимум два глобальных каталога и дополнительно добавлять ГК в каждый новый домен или сайт AD.
Остальные настройки полностью идентичны и, проверив все еще раз, приступайте к развертыванию второго контроллера, в процессе которого будет выполнена настройка соответствующих служб и произведена репликация с первым контроллером.
Закончив установку второго контроллера можете переходить к настройкам доменных служб: создавайте пользователей, разносите их по группам и подразделениям, настраивайте групповые политики и т.д. и т.п. Делать это можно на любом контроллере домена, для этого воспользуйтесь соответствующими пунктами меню Администрирование.
Следующим шагом будет введение в домен пользовательских ПК и рядовых серверов, а также миграция пользовательского окружения на доменные учетные записи, об этом мы поговорим в следующей части.
Дополнительные материалы:
- Службы каталогов. Часть 1 — Общие понятия
- Службы каталогов. Часть 2 — Реализации служб каталогов
- Службы каталогов. Часть 3 — Структура Active Directory
- Active Directory — от теории к практике. Часть 1 — общие вопросы
- Active Directory — от теории к практике. Часть 2 — разворачиваем доменную структуру
- Active Directory — от теории к практике. Часть 3 — настройка DHCP
- Active Directory — от теории к практике. Часть 4 — перенос учетных записей в домен
- Настраиваем высокодоступный DHCP-сервер в Windows Server 2012
- Быстрое развертывание Active Directory с отказоустойчивой конфигурацией DHCP
- Синхронизация времени Active Directory с внешним источником
- Обновление схемы Active Directory
- Управление ролями FSMO при помощи Ntdsutil
- Управление ролями FSMO с помощью PowerShell
- Восстанавливаем доверительные отношения в домене
- Очистка метаданных контроллера домена в Active Directory
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Установим роль контроллера домена на Windows Server 2019. На контроллере домена работает служба Active Directory (AD DS). С Active Directory связано множество задач системного администрирования.
AD DS в Windows Server 2019 предоставляет службу каталогов для централизованного хранения и управления пользователями, группами, компьютерами, а также для безопасного доступ к сетевым ресурсам с проверкой подлинности и авторизацией.
Подготовительные работы
Нам понадобится компьютер с операционной системой Windows Server 2019. У меня контроллер домена будет находиться на виртуальной машине:
Установка Windows Server 2019 на виртуальную машину VMware
После установки операционной системы нужно выполнить первоначальную настройку Windows Server 2019:
Первоначальная настройка Windows Server 2019
Хочется отметить обязательные пункты, которые нужно выполнить.
Выполните настройку сети. Укажите статический IP адрес. DNS сервер указывать не обязательно, при установке контроллера домена вместе с ним установится служба DNS. В настройках сети DNS сменится автоматически. Отключите IPv6, сделать это можно и после установки контроллера домена.
Укажите имя сервера.
Было бы неплохо установить последние обновления, драйвера. Указать региональные настройки, время. На этом подготовка завершена.
Установка роли Active Directory Domain Services
Работаем под учётной записью локального администратора Administrator (или Администратор), данный пользователь станет администратором домена.
Дополнительно будет установлена роль DNS.
Следующий шаг — установка роли AD DS. Открываем Sever Manager. Manage > Add Roles and Features.
Запускается мастер добавления ролей.
Раздел Before You Begin нас не интересует. Next.
В разделе Installation Type выбираем Role-based or feature-based installation. Next.
В разделе Server Selection выделяем текущий сервер. Next.
В разделе Server Roles находим роль Active Directory Domain Services, отмечаем галкой.
Для роли контроллера домена нам предлагают установить дополнительные опции:
- [Tools] Group Policy Management
- Active Directory module for Windows PowerShell
- [Tools] Active Directory Administrative Center
- [Tools] AD DS Snap-Ins and Command-Line Tools
Всё это не помешает. Add Features.
Теперь роль Active Directory Domain Services отмечена галкой. Next.
В разделе Features нам не нужно отмечать дополнительные опции. Next.
У нас появился раздел AD DS. Здесь есть пара ссылок про Azure Active Directory, они нам не нужны. Next.
Раздел Confirmation. Подтверждаем установку компонентов кнопкой Install.
Начинается установка компонентов, ждём.
Configuration required. Installation succeeded on servername. Установка компонентов завершена, переходим к основной части, повышаем роль текущего сервера до контроллера домена. В разделе Results есть ссылка Promote this server to domain controller.
Она же доступна в предупреждении основного окна Server Manager. Нажимаем на эту ссылку, чтобы повысить роль сервера до контроллера домена.
Запускается мастер конфигурации AD DS — Active Directory Domain Service Configuration Wizard. В разделе Deployment Configuration нужно выбрать один из трёх вариантов:
- Add a domain controller to an existing domain
- Add a new domain to an existing forest
- Add a new forest
Первый вариант нам не подходит, у нас нет текущего домена, мы создаём новый. По той же причине второй вариант тоже не подходит. Выбираем Add a new forest. Будем создавать новый лес.
Укажем в Root domain name корневое имя домена. Я пишу ilab.local, это будет мой домен. Next.
Попадаем в раздел Doman Controller Options.
В Forest functional level и Domain functional level нужно указать минимальную версию серверной операционной системы, которая будет поддерживаться доменом.
У меня в домене планируются сервера с Windows Server 2019, Windows Server 2016 и Windows Server 2012, более ранних версий ОС не будет. Выбираю уровень совместимости Windows Server 2012.
В Domain functional level также выбираю Windows Server 2012.
Оставляю галку Domain Name System (DNS) server, она установит роль DNS сервера.
Укажем пароль для Directory Services Restore Mode (DSRM), желательно, чтобы пароль не совпадал с паролем локального администратора. Он может пригодиться для восстановления службы каталогов в случае сбоя.
Next.
Не обращаем внимание на предупреждение «A delegation for this DNS server cannot be created because the authoritative parent zone cannot be found…». Нам не нужно делать делегирование, у нас DNS сервер будет на контроллере домена. Next.
В разделе Additional Options нужно указать NetBIOS name для нашего домена, я указываю «ILAB». Next.
В разделе Paths можно изменить пути к базе данных AD DS, файлам журналов и папке SYSVOL. Без нужды менять их не рекомендуется. По умолчанию:
- Database folder: C:WindowsNTDS
- Log files folder: C:WindowsNTDS
- SYSVOL folder: C:WindowsSYSVOL
Next.
В разделе Review Options проверяем параметры установки. Обратите внимание на кнопку View script. Если её нажать, то сгенерируется tmp файл с PowerShell скриптом для установки контроллера домена.
Сейчас нам этот скрипт не нужен, но он может быть полезен системным администраторам для автоматизации установки роли контроллера домена с помощью PowerShell.
Next.
Попадаем в раздел Prerequisites Check, начинаются проверки предварительных требований.
Проверки прошли успешно, есть два незначительных предупреждения про DNS, которое мы игнорируем и про безопасность, тож игнорируем. Пытался пройти по предложенной ссылке, она оказалась нерабочей.
Для начала установки роли контроллера домена нажимаем Install.
Начинается процесс установки.
Сервер будет перезагружен, о чём нас и предупреждают. Close.
Дожидаемся загрузки сервера.
Первоначальная настройка контроллера домена
Наша учётная запись Administrator теперь стала доменной — ILABAdministrator. Выполняем вход.
Видим, что на сервере автоматически поднялась служба DNS, добавилась и настроилась доменная зона ilab.local, созданы A-записи для контроллера домена, прописан NS сервер.
На значке сети отображается предупреждение, по сетевому адаптеру видно, что он не подключен к домену. Дело в том, что после установки роли контроллера домена DNS сервер в настройках адаптера сменился на 127.0.0.1, а данный адрес не обслуживается DNS сервисом.
Сменим 127.0.0.1 на статический IP адрес контроллера домена, у меня 192.168.1.14. OK.
Теперь сетевой адаптер правильно отображает домен, предупреждение в трее на значке сети скоро пропадёт.
Запускаем оснастку Active Directory Users and Computers. Наш контроллер домена отображается в разделе Domain Controllers. В папкe Computers будут попадать компьютеры и сервера, введённые в домен. В папке Users — учётные записи.
Правой кнопкой на корень каталога, New > Organizational Unit.
Создаём корневую папку для нашей компании. При создании можно установить галку, которая защищает от случайного удаления.
Внутри создаём структуру нашей компании. Можно создавать учётные записи и группы доступа. Создайте учётную запись для себя и добавьте её в группу Domain Admins.
Рекомендуется убедиться, что для публичного сетевого адаптера включен Firewall, а для доменной и частной сетей — отключен.
В этой статье будет рассмотрена установка и первоначальная настройка контроллера Active Directory. В цикле статей по миграци с Exchange Server 2010 на 2019 уже рассматривалась установка и добавление контроллеров домена. Например, установка контроллера на Windows Server 2008 R2. И добавление контроллера Windows Server 2012 R2. Однако, для кого-то такая операция является обыденной, но для других такая операция может оказаться совершенно новой и ранее не выполнявшейся задачей. Поэтому установка и первоначальная настройка контроллера выделена в отдельную статью. Дополнительно показан пример на базе одной из последней серверной операционной системе – Windows Server 2019.
Предварительные требования
Особых предварительных требований для установки нет, но крайне желательно установить все последние обновления операционной системы перед началом процесса установки.
Установка роли контроллера домена может быть выполнена как на сервер с GUI (Desktop Experience), так и без него (вариант Server Core).
Установка и первоначальная настройка контроллера Active Directory будет рассмотрена на базе Windows Server 2019. Редакция (Standard или Datacenter) роли не играет.
Немного теории
Непосредственно перед началом процесса установки разберем небольшой кусок теории.
Доменные службы Active Directory – это широко используемая технология для централизации хранения и управления учетными записями пользователей, нахождении ресурсов в сети предприятия, а также реализация механизма Single Sign-On (SSO) от компании Microsoft. В основе доменных служб Active Directory лежит реализация протокола LDAP. Грубо говоря Active Directory Domain Services – это реализация протокола LDAP от компании Microsoft.
По механизму и тонкостям работы Active Directory написаны отдельные книги. И даже кратко изложить основные момент – дело не простое. Однако, для понимания общей концепции в контексте установки контроллера домена необходимо ознакомится со следующими основными понятиями:
- Схема Active Directory. Нечто мифическое, которое обвешано кучей тайн и не редко вызывает трепещущий страх и ужас при сочетании слов “нужно выполнить обновление схемы” 🙂 А если серьезно, то это описание шаблонов всех возможных объектов в Active Directory – пользователей, компьютеров, принтеров и т.д. Содержит информацию о том, какие свойства есть у объектов и какие они могут иметь типы значений и непосредственно значения.
- Лес Active Directory. Это совокупность всех доменов, которые объединены общей конфигурацией схемы объектов Active Directory. Лес содержит как минимум один домен. Такие тяжелые продукты, как, например Microsoft Exchange или Skype for Business могут быть установлены только одни в пределах всего леса, т.к. он вносит необходимые ему изменения в схему Active Directory. Установить рядом еще один независимый экземпляр этих продуктов не получится.
- Домен. Граница, в пределах которой осуществляется управление настройками безопасности. Например, у вас есть два домена. В каждом из них администратор может управлять своим набором учетных записей пользователей, компьютеров, параметров безопасности и политики. Администратор Домена А не может управлять объектами в Домене Б (если не настроено необходимое делегирование).
- Дерево доменов. Совокупность всех доменов в пределах леса.
- Пространство имен. В передлах леса у вас может быть несколько имен. Например, один домен называется itproblog.ru, второй домен называется sale.itproblog.ru. В таком случае пространство имен продолженное (continuous). В тоже время у вас может быть еще один домен в том же лесу, например, hmmail.ru. Как видите – имя у него совершенно другое. Однако, это нисколько не мешает ему находится в том же лесу, что и домен с именем itproblog.ru.
Примеры топологий Active Directory
Рассмотрим немного примеров.
Ниже изображена схема одной из наиболее распространенной и простой топологии – один лес и один домен. Важно понимать, что в одном домене может быть установлено несколько контроллеров домена (для отказоустойчивости). Именно этот сценарий мы рассмотрен в данной статье. Пример схемы:
Следующей по уровню сложности следует топологи с несколькими доменами в одном лесу. Причем домены находятся в одном пространстве имен. Скажем, itproblog.ru. В каждом из доменов можем быть от одного до нескольких контроллером домена. Пример схемы:
Одна из наиболее комплексных топологий – это несколько доменов в одном лесу. Причем, не все домены используют одно пространство имен. Пример такой схемы ниже:
Домены в разных лесах Active Directory никак не заимосвязаны друг с другом (без установки дополнительных доверительных отношений). Домены в пределах одного леса автоматически доверяют друг другу, т.е. пользователям из Домена А могут быть назначены разрешения в домене Б. Пример схемы с несколькими отдельными лесами ниже:
Самым первым шагом нам необходимо создать лес и установить самый первый контроллер – корневой контроллер в лесу Active Directory. Лес будет создан автоматически в процессе установки самого первого контроллера в самом первом домене. Мы рассмотрим два варианта установки – через графический интерфейс и через командлеты PowerShell.
Установка первого контроллера через графический интерфейс
Для установки контроллера домена через графический интерфейс необходимо выполнить следующие действия:
1. Запустить Server Manager.
2. В меню сверху выбрать пункты “Manage” – “Add Roles and Features”:
3. Запустится мастер установки ролей и компонентов. На первой странице мастера нажмите кнопку “Next”.
4. На странице выбора сценария установки нужно выбрать пункт “Role-based or feature-based installation” и нажать кнопку “Next”.
5. В появившемся списке серверов выберите необходимый сервер (если он не один) и нажмите кнопку “Next”.
6. В появившемся списке ролей необходимо выбрать “Active Directory Domain Services”.
7. В появившемся диалоговом окне с запросом на установку дополнительных ролей и компонентов нажмите кнопку “Add Features”.
8. В окне мастера установки на шаге выбора ролей нажмите кнопку “Next”.
9. На шаге выбора компонентов нажмите кнопку “Next”.
10. На шаге с описание возможности интеграции с Azure AD нажмите кнопку “Next”.
11. На последнем шаге мастер установки предствит сводку по параметрам установки. Нажмите кнопку “Install”, чтобы начать процесс добавление необходимых для Active Directory компонентов.
12. Дождитесь окончания процесса установки компонентов. По окончанию процесса установки можете закрыть мастер добавления ролей и компонентов.
13. Следующим шагом необходимо повысить роль сервера до контроллера домена. В секции с последними событиями выберите пункт “Promote this server to a domain controller”:
14. Поскольку мы конфигурируем первый домен в лесу (т.е. создаем новый лес Active Directory), то нужно выбрать соответствующую опцию – “Add a new forest”. Также необходимо указать имя корневого домена. Далее нажмите кнопку “Next”.
15. На следующем шаге мастера необходимо выбрать функциональный уровень домена и леса. Например, в нашем случае это уровень “Windows Server 2016”. Что это значит? Если кратко, то мы не сможем добавить в Active Directory контроллеры домена с операционной системой ниже Windows Server 2016. Зачем это нужно? Чем выше функциональный уровень, тем больше доступно новых возможностей Active Directory. С полным перечнем всех возможностей для каждого из функционального уровня домена и леса можно ознакомится в документации Microsoft. Указываем пароль DSRM (своеобразный безопасный режим Active Directory) и нажимаем “Next”.
16. На странице настройки опций DNS нажмите кнопку “Next”.
17. На следующей странице мастера необходимо выбрать NetBIOS имя вашего домена и нажать “Next”.
18. На странице с выбором расположений файлов базы данных, транзакционных логов и папки SYSVOL вы можете выбрать иные директории, но, как правило, здесь оставляются значения по умолчанию. Нажмите кнопку “Next”.
19. На странице со сводкой по выбранным параметрам установки нажмите кнопку “Next”.
20. Мастер установки выполнит проверку предварительных требований. Если все проверки завершатся успешно, то будет активна кнопка “Install”. Нажмите её.
21. Запуститься процесс повышения роли сервера до контроллера домена. В процессе повышения сервер несколько раз перезагрузится. Дождитесь окончания процесса.
22. После завершения процесса повышения сервера до контроллера домена вы можете открыть оснастку “Active Directory Users and Computers” и убедиться, что оснастка запускается и отображает информацию об объектах вашего домена успешно.
Установка первого контроллера через Powershell
Вот за что я люблю процесс установки через PowerShell – так это за его лаконичность 🙂 Позволяет буквально за пару команд, например, быстро развернуть контроллер домена в тестовой среде. И в статье описывать процесс долго не приходится 🙂
Если вы используете вариант операционной системы Server Core, то это один из единственных способов повышения сервера до контроллера домена.
Итак, для повышения сервера до контроллера домена через PowerShell необходимо выполнить следующее:
1. Запустить консоль PowerShell от имени администратора.
2. Запустить следующий командлет для добавления роли контроллера домена (для сервера с GUI):
Add-WindowsFeature AD-Domain-Services -IncludeManagementTools
Для сервера в варианте Server Core запустите следующий командлет:
Add-WindowsFeature AD-Domain-Services
Разница лишь в том, что для сервера с GUI параметр -IncludeManagementTools установит соответствующие оснастки для управления. Например, Active Directory Users and Computers.
3. Дождитесь окончания процесса установки:
4. Теперь необходимо повысить роль сервера до контроллера домена и создать новый лес (и первый домен в лесу). Для этого выполните следующий командлет PowerShell:
Install-ADDSForest -DomainName itproblog.ru -InstallDNS
Функциональный уровень леса и домена автоматически будет установлен в значение “Windows Server 2016” (т.к. операционная система нашего сервер Windows Server 2019). Если вам необходимо указать другое значение, то можете использовать соответствующие параметры – DomainMode и ForestMode. Например:
Install-ADDSForest -DomainName itproblog.ru -InstallDNS -DomainMode Win2012R2 -ForestMode Win2012R2
5. Укажите пароль для DSRM (своеобразный безопасный режим Active Directory):
6. Далее нужно утвердительно ответить на запрос и том точно ли мы хотим повысить уровень сервера до контроллера домена. Нажмите клавишу Y, а затем Enter.
7. Запуститься процесс повышения сервера до контроллера домена. Сервер будет несколько раз перезагружен. Дождитесь окончания процесса установки.
8. После завершения процесса повышения сервера до контроллера домена вы можете открыть оснастку “Active Directory Users and Computers” и убедиться, что оснастка запускается и отображает информацию об объектах вашего домена успешно.
Установка дополнительного контроллера домена (при необходимости)
Добавление второго контроллера домена не обязательная процедура, но крайне желательная. Второй контроллер домена обеспечивает вам отказоустойчивость. Если что-то случится с один из контроллеров домена, то оставшийся в живых контроллер сможет обрабатывать запросы к Active Directory.
Добавление дополнительного контроллера домена через графический интерфейс
Для добавления еще одного контроллера домена через графический интерфейс необходимо выполнить следующие действия:
1. Запустить Server Manager.
2. В меню сверху выбрать пункты “Manage” – “Add Roles and Features”:
3. Запустится мастер установки ролей и компонентов. На первой странице мастера нажмите кнопку “Next”.
4. На странице выбора сценария установки нужно выбрать пункт “Role-based or feature-based installation” и нажать кнопку “Next”.
5. В появившемся списке серверов выберите необходимый сервер (если он не один) и нажмите кнопку “Next”.
6. В появившемся списке ролей необходимо выбрать “Active Directory Domain Services”.
7. В появившемся диалоговом окне с запросом на установку дополнительных ролей и компонентов нажмите кнопку “Add Features”.
8. В окне мастера установки на шаге выбора ролей нажмите кнопку “Next”.
9. На шаге выбора компонентов нажмите кнопку “Next”.
10. На шаге с описание возможности интеграции с Azure AD нажмите кнопку “Next”.
11. На последнем шаге мастер установки предствит сводку по параметрам установки. Нажмите кнопку “Install”, чтобы начать процесс добавление необходимых для Active Directory компонентов.
12. Дождитесь окончания процесса установки компонентов. По окончанию процесса установки можете закрыть мастер добавления ролей и компонентов.
13. Следующим шагом необходимо повысить роль сервера до контроллера домена. В секции с последними событиями выберите пункт “Promote this server to a domain controller”:
14. У нас уже создан домен Active Directory. Теперь нам нужно добавить дополнительный контроллер домена. Выбираем пункт “Add a domain controller to an existing domain” и в поле “Domain” указываем имя домена, в который будет добавлен дополнительный контроллер.
15. Также необходимо указать учетные данные администратора домена, от имени которого будет выполнена процедура добавления дополнительного контроллера. Для указания учетных данных нажмите кнопку “Change…”.
16. Появится диалоговое окно с указанием учетных данных. Укажите учетные данные администратора домена. Нажмите “ОК”, а затем “Next”.
17. Укажите, что вы планируете установить DNS сервер на дополнительном контроллере и глобальный каталог. Укажите пароль DSRM. Нажимаем “Next”.
18. На странице настройки опций DNS нажмите кнопку “Next”.
19. Отличительный шаг процедуры добавления еще одного контроллера – необходимость указать, откуда делать копию директории в процессе установки роли контроллера Active Directory. Вы можете либо оставить опцию “Any domain controller”, либо выбрать какой-то определенный контроллер (например, как в нашем случае). Выбор контроллера источника для репликации играет важную роль в том случае, если у вас географически распрtделенная инфраструктура, т.е. чтобы при добавлении контроллера в Москве он не побежал за данными на Сахалин. Нажимаем “Next”.
20. На странице с выбором расположений файлов базы данных, транзакционных логов и папки SYSVOL вы можете выбрать иные директории, но, как правило, здесь оставляются значения по умолчанию. Нажмите кнопку “Next”.
21. На странице со сводкой по выбранным параметрам установки нажмите кнопку “Next”.
22. Мастер установки выполнит проверку предварительных требований. Если все проверки завершатся успешно, то будет активна кнопка “Install”. Нажмите её.
23. Запуститься процесс повышения роли сервера до контроллера домена. В процессе повышения сервер несколько раз перезагрузится. Дождитесь окончания процесса.
24. После завершения процесса добавления еще одного контроллера домена вы можете открыть оснастку “Active Directory Users and Computers” и убедиться, что новый контроллер присутствует в списке контроллеров домена в соответствующей OU:
Так же список контроллером домена можно посмотреть через следующий PowerShell комендлет:
(Get-ADForest).Domains | %{ Get-ADDomainController -Filter * -Server $_ | ft HostName,Enabled,Forest}
Добавление дополнительного контроллера домена через PowerShell
Если вы используете вариант операционной системы Server Core, то PowerShell один из единственных способов добавления текущего сервера в качестве контроллера домена в уже существующий домен.
Итак, для повышения сервера до контроллера домена через PowerShell необходимо выполнить следущее:
1. Запустить консоль PowerShell от имени администратора.
2. Запустить следующий командлет для добавления роли контроллера домена (для сервера с GUI):
Add-WindowsFeature AD-Domain-Services -IncludeManagementTools
Для сервера в варианте Server Core запустите следующий командлет:
Add-WindowsFeature AD-Domain-Services
Разница лишь в том, что для сервера с GUI параметр -IncludeManagementTools установит соответствующие оснастки для управления. Например, Active Directory Users and Computers.
3. Дождитесь окончания процесса установки:
4. Теперь необходимо повысить роль сервера до контроллера домена и создать новый лес (и первый домен в лесу). Для этого выполните следующий командлет PowerShell:
Install-ADDSDomainController -InstallDns -Credential (Get-Credential "ITPROBLOGAdministrator") -DomainName "itproblog.ru" -ReplicationSourceDC sr-dc01.itproblog.ru
Параметр InstallDns указывает, что на сервере будет установлена роль сервера DNS. Параметр ReplicationSourceDC указывает с какого из контроллеров домена будет производиться репликация актуальной базы данных Active Directory в процессе установки.
5. Укажите пароль для учетной записи администратора домена.
6. Дважды укажите пароль для DSRM:
7. Далее нужно утвердительно ответить на запрос и том точно ли мы хотим повысить уровень сервера до контроллера домена. Нажмите клавишу Y, а затем Enter.
8. Запуститься процесс повышения сервера до контроллера домена. Сервер будет несколько раз перезагружен. Дождитесь окончания процесса установки.
9. После завершения процесса добавления еще одного контроллера домена вы можете открыть оснастку “Active Directory Users and Computers” и убедиться, что новый контроллер присутствует в списке контроллеров домена в соответствующей OU:
Так же список контроллером домена можно посмотреть через следующий PowerShell комендлет:
(Get-ADForest).Domains | %{ Get-ADDomainController -Filter * -Server $_ | ft HostName,Enabled,Forest}
Первоначальная настройка
После создания леса и домена, а также после добавления одного или нескольких контроллером домена я обычно, как минимум делаю две вещи:
1. Конфигурирую зону (или зоны) обратного просмотра в DNS.
2. Конфигурирую привязки подсетей в настройках топологии сайтов Active Directory.
Настройка DNS зоны обратного просмотра
Зона обратного просмотра необходима для того, чтобы можно было найти имя компьютера по его IP-адресу.
Для настойки зоны обратного просмотра необходимо:
1. Запустить оснастку управления DNS.
2. В контекстном меню узла “Reverse Lookup Zone” выбрать пункт “New zone”.
3. На странице приветствия мастера настройки зоны обратного просмотра нажмите “Next”.
4. На странице выбора типа зоны выберите основной тип зоны (Primary zone) и укажите, что необходимо хранить зону в Active Directory (Store the zone in Active Directory). Нажмите “Next”.
5. Теперь укажем область репликации зоны. Мы будем реплицировать зону на все контроллеры домена в пределах нашего домена. Нажмите “Next”.
6. Мы будем создавать зону обратного просмотра только для протокола IPv4. Нажмите “Next“.
7. Один из ключевых шагов – правильно указать ID вашей подсети. Например, в моем случае базовый адрес сети следующий – 10.10.10.0/24. На соответствующей странице мастера мы указываем адрес сети в прямой последовательности, как показано ниже. Мастер автоматически преобразуем этот адрес в адрес зоны обратного просмотра. Нажмите “Next:.
8. На странице настройки динамического обновления нажмите “Next”.
9. На последней странице мастера нажмите “Finish”.
Привязка подсетей в настройках сайтов Active Directory
Для того, чтобы компьютер или сервер мог определить к какому сайту Active Directory он принадлежит необходимо выполнить настройки подсетей в соответствующей оснастке.
Настройка подсетей – важный шаг, если у вас географически распределенная инфраструктура. При неверном сопоставлении IP-подсетей и сайтов (или отсутствии сопоставления) компьютеры и серверы могут бегать, например, за данными через весь континент, вместо того, что отправить запрос серверу в соседнем кабинете.
С тем, что такой сайты Active Directory можно ознакомиться в документации Microsoft.
Настроим привязку нашей подсети 10.10.10.0/24 к нашему единственному сайту Active Directory:
1. Запустим оснастку “Active Directory Sites and Services”.
2. В контекстном меню узла “Subnets” выберите пункт “New Subnet…”.
3. В появившемся диалоговом окне в поле “Prefix” укажите базовый адрес сети (в нашем случае 10.10.10.0/24) и выберите в какому сайту Active Directory необходимо привязать подсеть (в нашем случае всего один сайт). Нажмите “ОК”.
4. В свойствах конкретного сайта вы можете посмотреть список IP-подсетей, которые к нему привязаны:
Заключение
В этой статье была рассмотрена установка и первоначальная настройка контроллера Active Directory. Мы рассмотрели вариант установки на сервере с графическим интерфейсом, а также вариант установки через комендлеты PowerShell.
Так же мы рассмотрели процедуру добавление контроллера домена в уже существующий домен. Причем на примере сервера с графическим интерфейсов и через командлеты PowerShell.
Мы немного поговорили о терминологии Active Directory.
Последним шагом мы выполнили минимальные первоначальные настройки Active Directory: настроили сопоставление сайтов Active Directory и IP-подсетей, а также настроили зону обратного просмотра.
Надеюсь, статья окажется вам полезна.
В этой статье я бы хотел предложить вам пошаговый туториал по развёртыванию контроллера домена Active Directory на Windows Server 2016 (с графической оболочкой), а также по вводу рабочей станции в получившийся домен. Чем этот туториал может выделиться на фоне других:
- Вместо простого «Далее, Далее, кликаем сюда, вбиваем это» я постарался дать внятное объяснение каждому шагу, каждой настройке, которую предстоит выполнить. Помимо основных понятий Active Directory, DNS и DHCP вы также сможете найти много интересной информации по всем галочкам, которые вы часто видели, но не задумывались об их назначении.
- В конце статьи я предложу способ автоматизировать развёртывание получившегося стенда полностью с нуля, имея на компьютере только iso-образы ОС Windows 7 и Windows Server 2016. И никакого PowerShell. Всего одной командой.
Статья предполагает наличие у читателя лишь самых начальных знаний об устройстве сетей (на уровне «Что такое IP-адрес и DNS-адрес»).
Заинтересовало что-то из вышеперечисленного? Тогда погнали.
Туториал будет происходить не в вакууме, а на конкретном виртуальном стенде, состоящим из двух виртуальных машин:
Начальное состояние стенда:
- На машине windows_server уже установлена ОС Windows Server 2016 Standard Evaluation (с GUI). Машина находится в состоянии «сразу после установки ОС». В процессе туториала на ней будут развернуты службы Active Directory (с доменом mydomain.com), DNS и DHCP.
- Машина workstation выполняет роль рабочей станции. На ней установлена ОС Windows 7. Машина находится в состоянии «сразу после установки ОС». В процессе туториала она будет подключена к домену mydomain.com.
Туториал построен следующим образом (если вам интересен только конкретный пункт — смело кликайте прямо туда):
- Объясню, почему я выбрал именно такой стенд для туториала;
- Супер-краткое описание технологии Active Directory;
- Выполняется небольшая предварительная настройка windows_server;
- На windows_server производится включение необходимых компонентов;
- На windows_server происходит настройка контроллера домена AD (совместно с DNS);
- На windows_server происходит настройка сервера DHCP;
- На windows_server регистрируется новая учетная запись в AD;
- На workstation происходит подключение к домену.
В конце туториала вас ждет приятный бонус — я покажу вам как можно развернуть у себя на компьютере весь этот работающий стенд одной единственной командой. Вам понадобится только наличие двух установочных iso-образов (windows 7 и windows server 2016), да небольшой скрипт, ссылку на который я вам дам в конце статьи.
Почему такой стенд?
Такой стенд, с моей точки зрения, отлично подходит для первого самостоятельного «прощупывания» технологии Active Directory. Он минималистичен (всего 2 виртуальные машины), занимает минимум ресурсов, но при этом изолирован и самодостаточен. Его можно развернуть даже на довольно средненьком компьютере и ноутбуке. При этом на стенде уже присутствуют основные сетевые службы (AD + DNS). DHCP хоть и необязателен для функционирования AD, всё равно был добавлен в стенд в ознакомительных целях.
Disclaimer
Туториал предполагает подробный разбор всех шагов по настройке, с пояснениями «что, зачем и почему». Туториал ориентирован на людей, не слишком знакомых с технологиями Active Directory, DNS и DHCP, которые хотели бы немного узнать о внутренней кухне администрирования сетей с Active Directory.
Active Directory — это службы каталогов от компании Microsoft, как подсказывает нам Википедия. За этим сухим и невзрачным определением скрывается одна из важнейших технологий в администрировании сетей. Благодаря Active Directory администоратор сети получает очень удобное централизированное средство управления учетными записями пользователей, групповыми политиками (в т.ч. политиками безопасности) и объектами в сети (причём Active Directory без особых проблем справляется даже с гигантскими сетями). А благодаря встроенному механизму репликации, «положить» правильно настроенные сервисы AD не так-то просто. Ну и напоследок, благодаря Windows настроить Active Directory можно буквально мышкой, так что даже совсем начинающие IT-шники смогут с этим справиться.
Несмотря на то, что технологией заведует Microsoft, она вовсе не ограничивается управлением Windows-машин — все известные Linux-дистрибутивы уже давным давно научились работать с этой технологией. Повстречаться с Active Directory не просто, а очень просто — практически каждый офис предполагает наличие этой технологии, поэтому даже самым заядлым линуксоидам было бы неплохо разбираться в азах работы Active Directory.
Начинаем
Вы установили Windows Server 2016 и (надеюсь) видите следующий экран:
Эта панель — основное (графическое) средство администрирования Windows Server 2016. Здесь вы можете управлять компонентами и сервисами на вашем сервере (проще говоря, настраивать то, что умеет делать сервер). Эту же панель можно использовать и для базовых сетевых настроек Windows Server, для чего есть вкладка «Локальный сервер».
Базовые настройки Windows Server
Первое, что нужно сделать — это поменять сетевое имя сервера.
Сетевое имя (hostname) — это удобный способ идентификации узла в сети. Сетевое имя используется как альтернатива IP-адресу и позволяет не запоминать IP-адрес компьютера (при том, что этот адрес может меняться время от времени), а связываться с этим компьютером по его логическому названию.
Проблема в том, что по-умолчанию для Windows Server генерируется совершенно нечитаемое и неинформативное сетевое имя (я выделил его красным цветом на скриншоте).
Рабочии станции ещё могут позволить себе иметь нечитаемый Hostname, но никак не сервер. Поэтому я предлагаю поменять эту абракадабру его на что-то более разумное (например, на ADController), благо делается это быстро.
Смена сетевого имени
Нужно кликнуть на текущее имя сервера (отмечено красным цветом), затем во вкладке «Имя компьютера» нажать на кнопку «Изменить…», после чего ввести что-то более благоразумное:
После смены имени машину нужно будет перезагрузить.
Теперь зададим статический IP-адрес для сервера. В принципе это делать не обязательно, раз мы всё равно собрались поднимать DHCP службу, но на самом деле это хорошая практика, когда все ключевые элементы корпоративной сети имеют фиксированные адреса. Открыть меню по настройке сетевого адаптера можно из вкладки «Локальный сервер», кликнув на текущие настройки Ethernet-адаптера (тоже выделены красным цветом).
Настройки IP для интерфейса windows_server
Включаем нужные компоненты
Для нашего стенда нам понадобится включить следующие сервисы (или, как они тут называются, роли) на Windows Server:
- Доменные службы Active Directory;
- DNS-сервер;
- DHCP-сервер.
Пройдемся вкратце по каждому из них.
Доменные службы Active Directory
Эта роль фактически «включает» технологию Active Directory на сервере и делает его контроллером домена (под доменом в технологии AD понимается группа логически связанных объектов в сети). Благодаря этой роли администратор получает возможность управлять объектами в сети, а также хранить информацию о них в специальной распределенной базе данных.
Эта база данных содержит всю информацию об объектах в сети (например, именно в неё заносится информация об учётных записях пользователей). Когда человек подходит к рабочей станции и пытается выполнить вход в свою доменную учётную запись, эта рабочая станция связывается с контроллером домена с запросом на аутентификацию, и в случае успеха загружает пользовательский рабочий стол.
Однако, что же делать, если контроллер домена выйдет из строя (или просто будет недоступен для рабочих станций)? Если вы настроили только один контроллер домена, то дела ваши довольно плохи — без связи с рабочим контроллером домена пользователи не смогут выполнить вход на свои рабочие места. Поэтому в реальных сетях всегда рекомендуется устанавливать как минимум два контроллера на каждый домен. Каждый контроллер домена участвует в так называемом механизме репликации, благодаря чему все контроллеры домена имеют полную копию базы данных со всеми объектами в домене. Если по какой-то причине один из контроллеров выйдет из строя, его место всегда может занять резервный контроллер — и пользователи даже ничего не заметят.
Однако этот туториал рассчитан на простое ознакомление с технологией AD «на виртуалках», поэтому здесь не будет рассматриваться вопрос создания нескольких контроллеров AD в одном домене.
С этим пунктом все более менее понятно, а зачем же нам включать дополнительно ещё DNS-сервер?
DNS-сервер
Обычно протокол DNS (Domain Name System) используется для обращения к узлам в сети не по их IP-адресу, а по доменному имени (строковый идентификатор), что, конечно, гораздо удобнее. Другими словами, DNS чаще всего используется для разрешения доменных имен.
Но область применения протокола DNS не ограничивается только сопоставлением хостового имени и IP-адреса, что как раз подтверждает технология Active Directory. Дело в том, что Microsoft решила построить технологию Active Directory не с нуля, а на основе протокола DNS. В частности, протокол DNS используется при определении местонахождения всех ключевых сервисов Active Directory в сети. Другими словами, рабочая станция при подключении к контроллеру домена понимает, «куда» ей надо обращаться, именно с помощью протокола DNS.
Все DNS-записи (в том числе с информацией о сервисах Active Directory) хранятся на DNS-сервере, а это значит, что нам нужно заиметь свой собственный DNS-сервер! Вот только вопрос, откуда его взять? Есть два варианта:
- Использовать отдельную машину в роли DNS-сервера;
- Использовать саму машину windows_server в роли DNS-сервера.
Первый вариант, безусловно, самый правильный — именно так и надо поступать при реальном администрировании сетей (чем больше вы разносите логику по разным узлам в сети — тем лучше). Но в учебных целях я решил выбрать второй вариант (хотя бы потому, что не придётся создавать ещё одну виртуальную машину).
Именно поэтому эту роль (DNS-сервера) тоже нужно добавить к ролям машины windows_server.
Кстати, если не добавить роль «DNS-сервер» сейчас, то в будущем у вас ещё будет такая возможность при конфигурировании контроллера домена AD.
DHCP-сервер
Протокол DHCP (Dynamic Host Configuration Protocol) нужен для автоматической выдачи сетевых настроек узлам в сети. Под сетевыми настройками понимается IP-адрес, адрес шлюза по-умолчанию, адрес DNS-сервера, и ещё ряд других настроек. Этот протокол чрезвычайно удобен при администрировании сетей, особенно больших.
В этом туториале я использую протокол DHCP чтобы рабочая станция workstation могла получить сетевые настройки (в частности, адрес DNS-сервера) без каких-либо действий с моей стороны.
Протокол DHCP не имеет никакого отношения к технологии Active Directory, и можно было бы обойтись вовсе без него (достаточно прописать все сетевые настройки на рабочей станции самостоятельно), но я решил включить этот протокол в данный туториал просто для общего ознакомления. К тому же, такая связка «Контроллер AD — DNS-сервер — DHCP-сервер» довольно часто встречается в реальной жизни, потому что это очень удобный набор сервисов.
При этом вопрос о том, стоит ли выделять отдельную машину под DHCP-сервер, остаётся открытым. Для небольших сетей однозначно не стоит разносить DNS и DHCP-серверы по разным машинам, но для больших сетей, возможно, имеет все-таки смысл задуматься об этом. В нашей же крошечной сети мы абсолютно ничего не потеряем, если включим DHCP-сервер на той же машине, что и DNS-сервер.
Что ж, довольно теории, давайте лучше перейдём к включению этих самых ролей.
Мастер добавления ролей и компонентов
Возвращаемся на панель мониторинга (самый первый скриншот) и щелкаем на пункт «Добавить роли и компоненты». Вас поприветствует мастер добавления ролей и компонентов. Первый экран («Перед началом работы») пропускаем, он совсем неинтересный, а вот дальше идёт экран «Выбор типа установки»
Выбор типа установки
Нас устраивает значение по-умолчанию (Установка ролей или компонентов»), но интересен и второй пункт — он позволяет задействовать ещё одну возможность Windows Server — инфраструктуру виртуальных рабочих мест (Virtual Desktop Environment — VDI). Эта интереснейшая технология позволяет, буквально, виртуализировать рабочее место. То есть для пользователя создаётся виртуальное рабочее место, к которому он может подключаться через тонкий клиент. Пользователь лишь видит картинку, тогда как само рабочее место может совершенно прозрачно работать где угодно.
Впрочем, технология VDI это отдельная большая тема, а в этом туториале надо сосредоточиться на контроллере AD, так что кликаем «Далее» и видим экран выбора целевого сервера.
Выбор целевого сервера
Мастер добавления ролей позволяет устанавливать роль не только на текущую машину, но вообще на любой добавленный сервер, и даже на виртуальный жёсткий диск. Да, если ваша Windows Server развернута на виртуальной машине (а это довольно частое явление), то вы можете администрировать эту виртуальную машину даже не запуская её! Понаблюдать за этим процессом можно, например, здесь.
Нам же такая экзотика ни к чему, так что просто выбираем единственный возможный сервер (обратите внимание, что он теперь называется ADController место непонятной абракадабры), жмём «Далее» и, наконец, попадаем на экран выбора ролей, которые нужно добавить.
Выбор добавляемых ролей
Выбираем три роли, о которых уже говорили ранее, и продолжаем.
Выбор компонентов
Теперь необходимо выбрать дополнительные компоненты. В чём разница между ролью и компонентом, можете спросить вы? О, это не такой уж и лёгкий вопрос, честно говоря!
Согласно идеологии Microsoft, роль — это набор программ, которые позволяют компьютеру предоставлять некоторые функции для пользователей в сети. Например, DNS, DHCP, контроллер домена AD — это всё роли. А вот компоненты — это набор программ, которые улучшают либо возможности ролей сервера, либо самого сервера.
При этом глядя на список «Компонентов» так сходу и не скажешь, что какие-то вещи в списке лишь «вспомогательные». Вот например, DHCP-сервер расценивается как роль, а WINS-сервер — уже как компонент. А чем SMTP-сервер хуже DNS?
В общем-то, чёткой границы между ролью и компонентом не существует. Я лично предпочитаю относиться к ролям как к большим функциональным возможностям сервера, а к компонентам — как к небольшим дополнительным аддонам.
В любом случае, дополнительные компоненты нам не нужны, так что кликаем «Далее».
После этого идёт несколько пояснительных экранов с информацией по каждой добавленной роли, но эту информацию я уже разбирал, поэтому останавливаться лишний раз не буду.
Подтверждение устанавливаемых ролей и компонентов
На экране подтверждения ещё раз видим все устанавливаемые роли и компоненты, после чего жмём «Установить».
Остаётся лишь дождаться, когда заполнится progress-bar, и перейти к следующему пункту туториала — настройке контроллера домена AD.
Настраиваем контроллер домена Active Directory
Все роли и компоненты успешно добавлены, о чём свидетельствует следующий экран:
Вот только AD на сервере всё еще не работает — для этого его необходимо донастроить. Для этого нам настойчиво предлагают «Повысить роль этого сервера до уровня контроллера домена».
Погодите-ка, ЧТО?!
А чем же я занимался последние 15 минут? Я же добавлял роли, и судя по сообщению, они успешно добавились! И тут меня снова хотят заставить добавлять какие-то новые роли? В чем-то тут подвох.
Подвох тут действительно имеется, но вообще в не самом очевидном месте. Вот так выглядит предыдущий скриншот в английской версии Windows Server (картинка из интернета).
Английская версия скриншота
Видите разницу? В английской версии ни слова ни про какие роли! Про повышение есть, про роли — нет. Один из тех случаев, когда перевод вносит сумятицу на пустом месте. Согласно английской версии, никакими ролями мы дальше не занимаемся, что и логично, ведь мы их как раз только что добавили.
Что ж, тыкаем на предложение «Повысить роль этого сервера до уровня контроллера домена», и теперь нас приветствует мастер настройки доменных служб Active Directory с предложением выбрать конфигурацию развёртывания.
Конфигурация развёртывания
Всего тут есть 3 варианта развития событий. Для того, чтобы выбрать правильный пункт, давайте сначала разберёмся, что эти пункты означают. В этом нам поможет вот такая картинка (картинка, если что, отсюда):
Технология Active Directory (как и DNS) подразумевает иерархическое построение имён на основе доменов. Домены могут выстраиваться в доменные деревья по принципу «родительско-дочерних» отношений. В основе дерева лежит так называемый корневой домен (на картинке выше это sources.com, xyz.com и abc.com). При этом домен может иметь сколько угодно потомков. Домен-потомок располагается в просранстве имён родителя и является его «поддоменом» (subdomain). У доменного имени домена-потомка есть дополнительный префикс относительно доменного имени родителя (rus.abc.com, eng.abc.com). Один корневой домен основывает только одно доменное дерево со своим независимым пространством имён.
Теперь представьте, что таких независимых деревьев может быть много — в этом случае эти деревья образуют структуру, которая называется «лес». При этом в Active Directory доменные деревья не могут быть «сами по себе» — они обязательно должны находиться в лесу (даже если лес будет состоять всего из одного-единственного домена). Первый домен, который добавляется в лес, называется корневым доменом леса (на рисунке выше это sources.com). Корневой домен леса используется для идентификации всего леса (то есть если корневой домен называется sources.com, то и весь лес называется sources.com).
Теперь возвращаемся к мастеру настройки доменных имен. На этом этапе мастер предлагает следующие варианты:
- Добавить контроллер домена в существующий домен (помните про резервирование контроллеров в домене, так ведь?). Этот вариант не для нас, ведь домена ещё никакого нет;
- Добавить новый домен в лес. Этого мы тоже сделать не можем, т.к. и леса у нас тоже никакого нет;
- Добавить новый лес. Это вариант как раз для нас. При этом нам тут же предлагают выбрать корневой домен для этого леса (первый домен, который будет создан в лесу).
Назовём корневой домен mydomain.com и кликнем «Далее»
Параметры контроллера домена
Рассмотрим возможные параметры:
- Режим работы леса и домена. Домены в одном лесу могут работать в разных режимах в зависимости от версии Windows Server на борту. Лес должен иметь режим не выше, чем самый «старый» домен в его составе. Т.к. мы планируем использовать только Windows Server 2016, то оставим этот режим и для леса и для домена;
- DNS-сервер. Если ранее Вы не активировали роль DNS-сервера в мастере добавления ролей, то можете сделать это сейчас (вам даже предложат такой вариант по-умолчанию);
- Должен ли контроллер домена выступать в роли Global Catalog-сервера;
- Включить ли режим базы данных Active Directory «только на чтение». Основная задача, которую преследует технология RODC — возможность безопасной установки собственного контролера домена в удаленных филиалах и офисах, в которых сложно обеспечить физическую защиту сервера с ролью DC. Контроллер домена RODC содержит копию базы Active Directory, доступную только на чтение. Это означает, что никто, даже при получении физического доступа к такому контроллеру домена, не сможет изменить данные в AD (в том числе сбросить пароль администратора домена) (информация взята [отсюда].(https://winitpro.ru/index.php/2017/11/08/ustanovka-rodc-kontrollera-domena-na-windows-server-2016/))
А вот пункт 3 рассмотрим поподробнее, он довольно интересный.
Как я уже упоминал выше, каждый контроллер домена имеет полную и исчерпывающую информацию обо всех объектах в своём домене. Если же в домене несколько контроллеров, то они ещё и участвуют в механизме репликации, поддерживая несколько актуальных копий базы данных с объектами домена. Получается, что рабочая станция в домене может узнать информацию о любом объекте из этого домена от своего ближайшего контроллера домена.
Но что же делать, если рабочей станции нужно получить информацию об объекте из другого домена? И вот тут в дело вступает ещё один важнейший механизм технологии Active Directory, который называется глобальный каталог.
Что такое вообще «Глобальный каталог»? Согласно Miscrosoft — это распределенное хранилище данных, которое хранит частичное представление обо всех AD-объектах в лесу. Это хранилище располагается на котроллерах домена, которые имеют дополнительную роль «Global Catalog Server» (Сервер глобального каталога). От обычного контроллера домена GC-сервер отличается в первую очередь тем, что помимо полной копии всех объектов в своем домене, хранит также частичную информацию обо всех объектах в других доменах леса.
Чего это позволяет достичь? Давайте представим, что рабочая станция запросила информацию об объекте из другого домена. Она обращается на ближайший GC-сервер с просьбой предоставить ей информацию об этом объекте. GC-сервер, в свою очередь, может:
- Либо отдать рабочей станции нужную информацию сразу (если эта информация у GC-сервера имеется);
- Либо перенаправить запрос к нужному контроллеру домена, где эта информация точно будет находиться. Чтобы понять, какому контроллеру домена нужно перенаправить запрос, как раз и происходит поиск по GC.
Информация о том, какие атрибуты попадают в глобальный каталог, определена в Partial Attribute Set (PAS), который может настраивать администратор AD. Например, если администроатр понимает, что рабочие станции часто будут обращаться к атрибуту, который не содержится в глобальном каталоге, он может добавить туда этот атрибут. Тогда запросы рабочих станций при чтении этого атрибута будут выполняться значительно быстрее, т.к. уже ближайший GC-сервер сможет предоставить им всю нужную информацию
Однако, если в лесе всего один домен (как у нас), то Глобальный каталог содержит полную копию объектов в домене и всё.
Что ж, возвращаемся к галочке GC, которую за нас уже проставил мастер настройки доменных служб. Если вы попробуете её отключить, то убедитесь, что отключить её нельзя. Это связано с тем, что каждый домен в AD должен иметь хотя бы один GC-сервер, и при добавлении первого контроллера в домен этот контроллер сразу помечается как GC-сервер.
Что ж, давайте согласимся с этим «выбором» мастера и перейдём к последнему параметру на этом скриншоте — к паролю для режима восстановления служб каталогов. Это особый режим безопасной загрузки Windows Server, который позволяет администратору работать с базой данных AD. Этот режим применяется, например, в следующих случаях:
- база Active Directory повреждена и нуждается в исправлении;
- требуется выполнить обслуживание базы данных AD (сжатие, анализ на наличие ошибок);
- требуется восстановить резервную копию базы данных AD;
- требуется сменить пароль администратора.
Да да, вы не ослышались. Чтобы просто восстановить резервную копию базы данных, нужно перезагрузить машину и загрузиться в особом «безопасном» режиме. Это вам не Linux какой-нибудь.
Фух, вроде разобрались. Давайте перейдем дальше на шаг, где нам предложат настроить делегирование DNS.
Делегирование DNS
Что такое делегирование DNS? По большей части, это передача ответственности за некоторую DNS-зону отдельному DNS-серверу. Это распространенная практика в больших сетях, в которых требуется разграничить зоны ответственности за доменные зоны между различными серверами. При делегировании DNS в «главный» DNS-сервер вносится запись о том, что «вот за эту DNS-зону несёт ответственность вон тот DNS-сервер, обращайся туда».
Т.к. у нас всего одна зона DNS и DNS-сервер тоже один, то этот шаг нам необходимо пропустить и перейти к выбору NetBIOS-имени.
NetBIOS-имя
Мы видим, что мастер предложил нам на выбор сразу же имя для нашего домена — MYDOMAIN. Но вы можете (и должны) задать себе вопрос: а что такое вообще NetBIOS-имя и зачем оно нужно? И разве мы уже не настраивали сетевое имя узла (Hostname) в самом начале? Чего же от вас хотят?
NetBIOS (Network Basic Input/Output) — это ещё один способ разрешения имён узлов в сети (более древний и более примитивный, чем DNS). NetBIOS-имена не предполагают никакой иерархии, их длина ограничивается всего лишь 16 символами, и они применяются только для разрешения имён компьютеров в локальной сети. Когда мы в самом начале туториала выбрали сетевое имя ADController — мы, на самом деле, задали именно NetBIOS-имя для сервера. Но теперь от нас снова требуют выбрать NetBIOS-имя (да ещё и другое, отличное от ADContoller). Не много ли NetBIOS-имён для одного компьютера?
Дело в том, что Microsoft пошла ещё дальше — и ограничила длину NetBIOS-имен не 16 символами, а 15 символами. 16-ый символ при этом считается зарезервированным суффиксом, который может принимать фиксированные значения. В зависимости от значения 16-го байта получаются разные классы NetBIOS-имён. Например, если суффикс равен 00, то NetBIOS-имя относится к рабочей станции. Если суффикс равен 1С, то это имя относится к имени домена.
То есть, как вы понимаете, на первом шаге мы задавали NetBIOS-имя для компьютера Windows Server (с суффиком 00). А теперь задаём NetBIOS-имя домена mydomain.com (с суффиксом 1С).
Кстати, можете, ради интереса, отмотать туториал в самое начало и посчитать количество символов в «нечитаемом» автоматически сгенерированном сетевом имени windows_server. Будет как раз 15 символов (максимальная длина NetBIOS-имени).
И напоследок скажу, что вы не можете пропустить этот шаг. NetBIOS хоть и устаревшая технология, но до сих пор используется ради совместимости с некоторыми старыми службами. Настроить контроллер домена Active Directory без NetBIOS-имени нельзя.
Что ж, и с этим тоже разобрались. Оставляем NetBIOS-имя по-умолчанию и двигаемся дальше, к выбору места расположения базы данных AD. Можно оставить значение по-умолчанию, комментировать особо нечего.
Расположение базы данных
Все ваши настройки должны пройти предварительную проверку:
Проверка предварительных требований
Как только всё готово, жмите «Установить» и можете спокойно идти пить чай, потому что после установки автоматически начнётся очень-очень долгая перезагрузка. Зато настройка контроллера домена AD на этом закончена, поздравляю!
Настройка DHCP-сервера
Пришло время заняться настройкой DHCP-сервера. Настройка глобально состоит из двух частей:
- Авторизация DHCP-сервера в домене AD. Не каждый DHCP-сервер может раздавать сетевые настройки в домене AD — только авторизованные. Это сделано с целях безопасности, чтобы другие DHCP-серверы не могли «подсунуть» неправильные настройки компьютерам в домене;
- Настройка новой DHCP-области. Это уже непосредственно настройка самого DHCP-сервера, в ходе которой определяются какие сетевые настройки будут выдаваться компьютерам в сегменте сети.
Для того, чтобы авторизировать DHCP-сервер, нужно вернуться на панель мониторинга (она и так должна быть перед вами после перезагрузки), перейти на вкладку DHCP (слева) и кликнуть на предложение донастроить DHCP-сервер:
Запуск авторизации DHCP-сервера
В открывшемся мастере настройки DHCP после установки пропускаем первый приветственный экран и переходим к экрану авторизации
Авторизация DHCP-сервера в домене
На выбор предлагаются три варианта:
- Использовать учётные данные администратора (по-умолчанию)
- Использовать учётные данные другого пользователя;
- Пропустить авторизацию AD.
По-умолчанию авторизовать DHCP-сервер в домене могут только члены группы EnterpriseAdmins, куда как раз и входит пользователь MYDOMAINАдминистратор. При желании можно потратить немного времени и делегировать эту возможность админам «помельче» (региональным администраторам), почерпнуть больше информации по этой теме можно отсюда.
Итак, выбираем вариант по-умолчанию и завершаем первый этап настроки DHCP-сервера.
Завершение авторизации DHCP-сервера
Теперь переходим непосредственно к настройкам DHCP. Для этого на панели мониторинга кликаем вкладку «Средства» и выбираем пункт «DHCP»
В открывшемся окне с настройками DHCP нужно кликнуть правой кнопкой мышки на IPv4 и затем на пункт меню «Создать область». После этого откроется мастер создания новой области.
Открытие мастера создания новой области
Что такое DHCP-область? Под этим понимается некий диапазон IP-адресов, которые может выдавать DHCP-сервер другим компьютерам в сети. Каждая область помимо диапазона IP-адресов также содержит другие сетевые настройки, с которыми мы сейчас и познакомимся.
Назовём DHCP-область SCOPE1 и перейдём дальше.
На следующем экране вам предложат выбрать диапазон адресов, которые будут выдаваться компьютерам в сети. Ранее я настраивал сетевой интерфейс на Windows Server, выдав ему адрес 192.168.1.1/24. Это статический адрес и он зарезервирован, его выдавать другим компьютерам нельзя.
Зато никто не мешает выдавать все остальные адреса в сети 192.168.1.0/24 — так что задаём диапазон от 192.168.1.2 до 192.168.1.254 (192.168.1.255 — это зарезервированный широковещательный адрес, его выдавать тоже нельзя).
Настройка диапазона адресов
В целом, никто не мешает вам как администратору выдавать меньше IP-адресов, чем доступно в адресации сети. Например, можно было бы выделить в сети всего 100 адресов для автоматической выдачи: 192.168.1.101-192.168.1.200.
Переходим далее и видим предложение о выборе исключений из указанонного диапазона адресов, а также о настройке задержки при передаче сообщения DHCPOFFER
Исключения в диапазоне и задержка DHCPOFFER
С исключениями всё более-менее понятно: если вы не хотите выдавать некоторые адреса в указанном ранее диапазоне, то вы можете указать эти адреса здесь в виде исключений. А что за задержка в DHCPOFFER такая?
Эта настройка уже относится к довольно продвинутому администрированию сетей: если в вашей сети есть несколько DHCP-серверов, то с помощью этой задержки вы можете регулировать нагрузку между ними (подробнее можно прочитать, например, тут).
В любом случае, исключений в диапазоне у нас нет, да и задержка по-умолчанию нас устраивает, так что кликаем дальше и видим настройку сроков аренды адресов.
Настройка времени аренды адресов
Протокол DHCP предполагает выделение адресов только на определённое время, после чего компьютеры должны продлять аренду. Здесь можно настроить это время (по-умолчанию — 8 дней).
8 дней меня лично вполне устраивает, так что кликаем «Далее» и видим предложение настроить другие настройки, которые будут получать клиенты в сети (помимо IP-адреса). Соглашаемся.
Настроить дополнительные параметры
Первая сетевая настройка для клиентов — это шлюз по-умолчанию. В стенде из двух виртуальных машин эта настройка в принципе не нужна. Но можно представить, что windows_server будет играть роль шлюза во внешнюю сеть, и добавить адрес 192.168.1.1 как шлюз по-умолчанию.
Шлюз по-умолчанию
Далее идет настройка DNS. Здесь можно задать имя родительского домена и адреса DNS-серверов. С адресами DNS-серверов всё более-менее понятно — это IP-адреса серверов, куда следует обращаться клиентам за помощью в разрешении DNS-имён. Сейчас в этом списке фигурирует тот же адрес, что мы добавили как шлюз по-умолчанию.
А вот для понимания имени родительского домена, рассмотрим следующую ситуацию.
Допустим, есть домен mydomain.com и есть два компьютера в этом домене с именами comp1.mydomain.com и comp2.mydomain.com. Если comp1 хочет связаться с comp2, то он должен, по-хорошему, использовать следующую команду (обращение по Fully Qualified Domain Name — FQDN):
ping comp2.mydomain.com
Но задумывались ли вы когда-нибудь, что именно произойдет, если попытаться пропинговать другой узел следующим образом?
ping comp2
На самом деле, в этом случае начинается целая магия — очень хитрый процесс разрешения имён (картинка из интернетов).
Процесс разрешения сетевых имён
- Поиск информации в hosts.txt или в кеше;
- Попытка найти имя через DNS;
- Попытка найти NetBIOS-имя в кеше;
- Попытка найти NetBIOS-имя через WINS-сервер;
- Попытка найти NetBIOS-имя путём отправки широковещательных пакетов в локальную сеть;
- Попытка найти NetBIOS-имя в LMHOSTS-файле.
Согласно алгоритму разрешения сетевых имен, сначала comp1 попробует найти информацию о comp2 в hosts.txt — файле. Если этой информации там не окажется, то начинается процесс поиска узла через DNS. Вот только вопрос — DNS-имена же находятся в каком-то домене, верно? Какое доменное имя нужно «пристыковать» к comp2 при выполнении пинга?
Вот тут в дело и вступает настройка DHCP, которая называется «имя родительсокго домена». Это как раз тот суффикс, который будет автоматически «пристыкован» к имени comp2 при выполнении DNS-разрешения имени. Так что если имя родительского домена равно «mydomain.com», то команда ping comp2
неявно преобразуется в ping comp2.mydomain.com
.
Если же DNS-разрешение окажется неудачным, дальше начнутся попытки найти comp2 уже по NetBIOS-имени. Что такое WINS, и чем он отличается от Broadcast — информация будет чуть дальше по тексту.
Что ж, в нашем случае имя родительсокго домена должно быть mydomain.com (значение по-умолчанию), а нужный DNS-сервер уже находится в списке, так что в итоге просто кликаем «Далее».
Настройки DNS
Теперь нас попросят указать настройки WINS-сервера. WINS (Windows Internet Name Service) сервер участвует в разрешении NetBIOS-имён в сети (прямо как DNS-сервер для DNS-имён). Вот только, в отличие от DNS, WINS-сервер не обязательно должен присутствовать в сети, чтобы разрешение NetBIOS-имён работало. Так зачем же он нужен тогда?
Дело в том, что по-умолчанию разрешение NetBIOS-имен происходит через широковещательные запросы. С одной стороны, это очень простой механизм (проще не придумаешь), но, с другой стороны, обладает парой недостатков:
- При наличии большого количества NetBIOS-имён в сети широковещательный тафик может начать «зашумлять» канал;
- Широковещательные запросы не могут «выйти» за пределы текущей сети, поэтому узнать NetBIOS-имя из другой сети таким способом не выйдет.
Так вот, WINS-сервер позволяет решить обе этих проблемы. Этот сервер централизованно хранит NetBIOS-имена компьютеров, и обычные узлы в сети могут обращаться к нему для поиска IP-адреса интересующего их имени (как и для DNS). Такой подход, во-первых, резко уменьшает количество широковещательного трафика в сети, а, во-вторых, позволяет посылать NetBIOS-запросы в другие сети, а не только в текущую.
В нашей небольшой сети WINS-сервер нам ни к чему, поэтому просто пропускаем эту настройку и едем дальше.
WINS-серверы
В последнем шаге настройки вам предлагают сразу активировать настроенную область. Соглашаемся, и на этом заканчиваем настройку DHCP.
Активация области
Создаём нового пользователя в домене AD
Собственно настройка контроллера домена и различных сервисов уже фактически закончена, все параметры выставлены как надо. Теперь нужно просто зарегистрировать нового пользователя, от имени которого рабочая станция workstation будет выполнять вход в домен.
Для этого возвращаемся на панель мониторинга, кликаем на «Средства» и затем на «Пользователи и Компьютеры Active Directory»
В открывшемся меню можно заметить созданный домен mydomain.com и его состав. Видно, что помимо пользователей в домене созданы папочки для Computers, Domain Controllers и других сущностей. Но нас сейчас интересуют пользователи, поэтому кликаем правой кнопкой мышки на папке Users и выбираем «Создать» -> «Пользователь»
После этого появляется диалоговое окно с преложением ввести данные нового пользователя. По старой доброй традиции назовём пользователя Foo Bar. Обратите внимание, что пользователь отображается лишь как «Объект» в Active Directory наравне с другими объектами.
Новый объект — Пользователь
Теперь необходимо задать пароль и дополнительные параметры для пользователя. Пароль должен соответсовать политике паролей по-умолчанию, которая, в том числе, предписыват паролям в домене быть довольно сложными (должен использовать числа, буквы верхнего и нижнего регистра, а также спец символы).
Обычно администратор создаёт простой пароль для пользователя, а затем требует от пользователя сменить его при первом входе в систему (первая галочка в списке доступных опций). Это очень хорошая практика с точки зрения безопасности, ведь таким образом даже администратор AD не сможет узнать пароль пользователя. Также хорошей практикой считается ограничивать срок действия пароля. В этом туториале для простоты мы уберём требование о смене пароля пользователем при врходе в систему.
Параметры нового пользователя
После этого останется лишь подтвердить создание нового пользователя.
Подтверждение создания нового пользователя
Ну что ж, вот, кажется, и всё! Осталось лишь проверить ввод рабочей станции в домен.
Ввод рабочей станции в домен
Переключаемся на вторую машину workstation под управлением Windows 7 и заходим в свойства системы. Сейчас видно, что рабочая станция находится в рабочей группе (не в домене). Кстати говоря, WORKGROUP — это тоже NetBIOS-имя. Только в отличии от имени домена оно имеет суффикс 1E.
Щелкаем на кнопку «Изменить параметры», затем в появившемся окне ещё раз «Изменить…».
В окне изменения имени компьютера пишем, что он должен принадлежать домену mydomain.com.
Подключение к домену
Видим предупреждение о нестандартном имени компьютера (testo-ПК содержит кириллицу). Это связано с тем, что NetBIOS-имена не могут содеражать кириллицу. Но мы с вами настроили DNS-сервер (DNS настройки прилетели на рабочую станцию по DHCP), а DNS-механизм разрешения имён, как мы знаем, имеет приоритет перед NetBOIS. Так что в данном случае на работоспособность AD кириллица не влияет. Но на практике так делать не надо!
Нестандартное имя компьютера
Вводим логин-пароль от новой учетной записи FooBar и, наконец, видим заветное сообщение «Добро пожаловать в домен»
Авторизация в домене
После ввода компьютера в домене необходимо перезагрузить компьютер, ну а дальше — вводим учётные данные пользователя в AD.
Логин в AD
И после успешного входа на рабочий стол перепроверяем свойства системы.
Новые свойства системы
Полное имя компьютера поменялось на testo-ПК.mydomain.com, а это значит, что мы успешно ввели рабочую станцию в домен mydomain.com.
Автоматизируем
Как вы могли заметить, весь туториал можно выполнить, пользуясь исключительно мышкой и клавиатурой. Больше того, нам даже не пригодились знания PowerShell, который позволяет выполнять бОльшую часть настройки контроллера домена AD с помощью скриптов.
Так почему бы не автоматизировать все действия с клавиатурой и мышкой, которые мы предпринимали? И нет, я говорю не об AutoIT, я говорю о платформе Testo, создателем которой я являюсь. Эта платформа позволяет фиксировать все действия, проводимые с виртуальными машинами, в виде скриптов на специальном языке Testo-lang. Ну а Testo затем превратит эти скрипты обратно в действия.
Я приведу лишь один скриншот с кусочком скрипта, чтобы у вас сложилось представление о том, о чём я говорю (да, именно скриншот, ведь хабр не умеет подсвечивать скриповый язык Testo-lang). Я даже не буду комментировать этот скрипт, т.к. верю, что код говорит сам за себя.
Секция скрипта на языке Testo-lang
Всё, что Вам потребуется для создания собственного стенда с настроенной Active Directory — это:
- Установочный iso-образ Windows Server 2016 русской версии;
- Установочный iso-образ Windows 7 (придётся поискать самим);
- Скрипты на языке Testo-lang;
- Установленная платформа Testo (бесплатно);
- Выполнить команду.
sudo testo run ./tests.testo --param ISO_DIR /path/to/your/iso/dir
И всё. Как и я обещал — всего одна команда. Через пол часа — час (зависит от шустрости вашего компьютера) вы сможете наслаждаться своим готовым стендом.
Итоги
Надеюсь, вам понравился туториал, и вы нашли его полезным. Возможно, вас заинтересовала платформа Testo, в этом случае вот несколько полезных ссылок:
- сайт платформы Тесто.
- youtube-канал, где можно найти много примеров.
- основная статья на хабре
- статья, где я автоматизировал несколько системных тестов для Dr. Web
- скрипты на языке Testo-lang для этого туториала
Возможно вам будет интересно —Подборка бесплатных программ для мониторинга сети и серверов
источник
Обновлено 22.01.2019
Добрый день! Уважаемый читатель, рад что ты вновь на страницах компьютерного блога Pyatilistnik.org. Несколько лет назад я выкладывал у себя на сайте пост, о том как развернуть у себя домен на Windows Server 2008 R2. Идет время и на дворе уже 2019 год со своим флагманским серверным продуктом. В сегодняшней статье я бы хотел рассмотреть вопрос установки Active Directory на Windows Server 2019. Мы рассмотрим все методы и нюанса, а так же проведем настройку.
Перед тем как я покажу процесс установки AD в Windows Server 2019, я бы хотел вам напомнить, что ASctive Directory — это по сути создание централизованной базы данных в которой будут хранится и управляться компьютеры, пользователи, принтеры. Более подробно, что такое Active Directory читайте по ссылке слева.
Подготовительный этап
Что я сделал на начальном этапе, произвел установку Windows Server 2019 Standard на виртуальной машине VMware ESXI 6.5. Сделал начальную настройку сервера, так сказать оптимизировал, это включаем настройку IP-адреса, имени и еще некоторых моментов. Когда вы все это произвели, то можете приступать.
Установка и настройка Active Directory на 2019 сервере
Существует два метода выполнения нашей задачи:
- Классический метод с использованием оснастки «Диспетчер серверов»
- Использование утилиты Windows Admin Center
- Второй метод, это использование Power Shell
Установка AD через сервер менеджеров
Разберу для начала классический метод установки службы Active Directory. Открываем диспетчер серверов и в пункте «Управление» нажмите «Добавить роли и компоненты».
Тип установки оставьте «Установка ролей и компонентов».
Далее если у вас в пуле более одного сервера, то вы их можете добавить на этом шаге.
Находим в списке ролей «Доменные службы Active Directory» и нажимаем далее.
Дополнительных компонентов вам не потребуется, так что данное окно вы можете смело пропускать.
Теперь у вас откроется окно мастера установки AD DS. Тут вам напомнят, что в каждом домене желательно иметь, как минимум два контроллера домена, рабочий DNS-сервер. Тут же вы можете произвести синхронизацию с Azure Active Directory.
Подтверждаем установку компонентов AD DS. Вы списке вы увидите все устанавливаемые модули:
- Средства удаленного администрирования сервера
- Средства администрирования ролей
- Средства AD DS и AD LDS
- Модуль Active Directory для PowerShell
- Центр администрирования Active Directory
- Оснастки и программы командной строки AD DS
- Управление групповой политикой
Нажимаем «Установить». Обратите внимание, что тут можно выгрузить конфигурацию установки службы Active Directory.
Выгруженная конфигурация, это XML файл с таким вот содержанием.
Нужный каркас AD DS установлен, можно приступать к настройке домена Active Directory.
Тут у вас в окне сразу будет ссылка «Повысить роль этого сервера до уровня контроллера домена».
То же самое есть в самом верху уведомлений «Диспетчера серверов», у вас тут будет предупреждающий знак.
Вот теперь по сути и начинается установка и настройка службы Active Directory. Так как у нас, еще нет окружения AD, то мы выбираем пункт «Добавить новый лес», если у вас он уже есть, то вам нужно либо добавлять контроллер домена в существующий лес или добавить новый домен в существующий лес. В соответствующем поле указываем имя корневого домена, в моем примере, это partner.pyatilistnik.info.
На следующем окне вы должны выбрать параметры:
- Режим работы леса Active Directory, определяет какие функции и возможности есть на уровне леса.
- Режим работы домена, так же определяет какие функции будут доступны на уровне домена.
Хочу обратить внимание, что режимы работы леса и домена напрямую влияют на то, какие операционные системы могут быть на контроллерах домена, простой пример, если у вас режим работы домена Windows Server 2016, то вы в него уже не добавите контроллеры на ОС Windows Server 2012 R2
- DNS-сервер, лучше всегда совмещать эти роли
- Глобальный каталог, на начальной установке доменных служб Active Directory обязателен, когда вы ставите второй контроллер домена, то вы можете не выставлять, но я вам не советую.
- Контроллер домена только для чтения (RODC), активна не будет при первой установке. Подробнее про использование RODC читайте по ссылке.
- Далее вы задаете пароль восстановления DSRM (Режим восстановления служб каталогов), он может потребоваться, когда у вас будут проблемы с активным каталогом или вам нужно будет сбросить пароль доменного администратора
Далее будет момент с делегированием DNS, но так как, это у нас новый лес и домен, то мы этот пункт просто пропускаем, если интересно то читайте про делегирование DNS зон по ссылке слева.
Задаем короткое имя (NetBIOS), обычно оставляют то, что предлагается мастером установки домена Active Directory.
Далее вы должны указать расположение базы данных AD DS, файлов журналов и папки SYSVOL.По умолчанию все будет лежать по пути:
- Папка базы данных — C:WindowsNTDS
- Папка файлов журналов — C:WindowsNTDS
- Папка SYSVOL — C:WindowsSYSVOL
Если у вас контроллер домена на виртуальной машине и ее виртуальные диски лежат на одном СХД, то смысл переносить на разные диски базу и папку SYSVOL нет
Теперь вам мастер AD DS покажет сводные параметры, которые вы кстати можете выгрузить в сценарий PowerShell.
Выглядит сценарий вот так:
Import-Module ADDSDeployment
Install-ADDSForest `
-CreateDnsDelegation:$false `
-DatabasePath «C:WindowsNTDS» `
-DomainMode «WinThreshold» `
-DomainName «partner.pyatilistnik.info» `
-DomainNetbiosName «PARTNER» `
-ForestMode «WinThreshold» `
-InstallDns:$true `
-LogPath «C:WindowsNTDS» `
-NoRebootOnCompletion:$false `
-SysvolPath «C:WindowsSYSVOL» `
-Force:$true
Еще одна проверка предварительных требования, по результатам которой вам сообщат, можно ли на данную систему произвести инсталляцию роли AD DS и поднять ее до контроллера домена.
В момент установки будут созданы соответствующие разделы, такие как конфигурация и др.
После установки вам сообщат:
Ваш сеанс будет завершен. Выполняется перезагрузка этого компьютера, так как были установлены или удалены доменные службы Active Directory
Просматриваем логи Windows на предмет ошибок, так их можно посмотреть в диспетчере сервером, откуда можно запустить оснастку ADUC.
Еще маленький нюанс, когда вы загрузитесь, то обратите внимание, что у вас сетевой интерфейс может быть обозначен, как неизвестный, это проблема связана с тем, что в DNS-адрес подставился адрес петлевого интерфейса 127.0.0.1. Советую его поменять на основной ip адрес сервера DNS,
В итоге выключите и заново включите сетевой интерфейс или перезагрузитесь, после чего получите правильное отображение.
Установка контроллера домена Windows Server 2019 с помощью Powershell
Для начала я приведу вам пример работы скрипта PowerShell, который буквально за несколько минут установит доменные службы Active Directory, вам в нем лишь нужно будет вбить свои данные.
# Импорт модуля ServerManager
Import-Module ServerManager
# Установка роли AD DS со всеми зависимыми компонентами
Add-WindowsFeature –Name AD-Domain-Services –IncludeAllSubFeature –IncludeManagementTools
# Импорт модуля ADDSDeployment
Import-Module ADDSDeployment
# Установка нового леса
Install-ADDSForest `
# Не включать делегирование
-CreateDnsDelegation:$false `
# Путь к базе данных AD
-DatabasePath «C:WindowsNTDS» `
# Режим работы домена
-DomainMode «WinThreshold» `
# Задаем имя домена
-DomainName «partner.pyatilistnik.info» `
# Задаем короткое NetBIOS имя
-DomainNetbiosName «PARTNER» `
# Задаем режим работы леса
-ForestMode «WinThreshold» `
# Указываем, что будем устанавливать DNS-сервер
-InstallDns:$true `
# Задаем путь к NTDS
-LogPath «C:WindowsNTDS» `
# Если требуется перезагрузка, то перезагружаемся
-NoRebootOnCompletion:$false `
# Задаем путь до папки SYSVOL
-SysvolPath «C:WindowsSYSVOL» `
-Force:$true
Когда вы в скрипте подставите все свои данные, то запускаете его. У вас начнется сбор данных и установка AD DS.
Единственное, что у вас будет запрошено, так это задание пароля восстановления SafeModeAdministratorPassword, указываем его дважды, с точки зрения безопасности он должен быть отличный от пароля для доменного администратора.
Предварительная проверка.
Создание нового леса Active Directory. Далее последует перезагрузка. Не забываем поправить сетевой интерфейс и DNS на нем.
Полезные команды при установке доменных служб
- Переименовать сайт AD по умолчанию (Default-First-Site-Name) — Get-ADReplicationSite | Rename-ADObject -NewName “Новое имя сайта
- Добавление новой подсети в сайт AD — New-ADReplicationSubnet -Name “100.100.100.0/24″ -Site «Имя сайта»
- Просмотр подсетей — Get-ADReplicationSubnet -Filter *
- Включение корзины Active Directory — Enable-ADOptionalFeature “Recycle Bin Feature” -Scope Forest -Target ‘partner.pyatilistnik.info’-confirm:$false
- Для удаления леса и домена можно использовать — Uninstall-ADDSDomainController–LastDoaminControllerInDomain –RemoveApplicationPartitions
Полезные командлеты в модуле ADDSDeployment
- Установка RODC — Add-ADDSReadOnlyDomainControllerAccount
- Установка контроллера в дочернем домене или дереве — Install-ADDSDomain
- Установка дополнительного контроллера домена — Install-ADDSDomainController
- Необходимые условия для установки дополнительного контроллера домена — Test-ADDSDomainControllerInstallation Verify
- Проверка необходимых условий для установки контроллера только для чтения — Test-ADDSReadOnlyDomainControllerAccountCreation
Установка и настройка Active Directory Windows Admin Center
Windows Admin Center так же может помочь в установке роли AD DS, для этого в веб интерфейсе зайдите в пункт «Роли и компоненты», выбираем роль и нажимаем установить.
Появится мастер установки, если все верно, то нажмите да.
В правом верхнем углу у вас будет область уведомления, где вы увидите, что запустилось ваше задание.
Процесс установки доменных служб.
Все роль установлена, к сожалению далее вы не сможете из интерфейса Windows Admin Center в виде графического мастера настроить домен, но тут есть слева от колокольчика окно PowerShell, где можно закончить начатое.
На этом у меня все, если остались вопросы, то пишите их в комментариях, а с вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org.