Контроллер домена на базе windows server

Установим роль контроллера домена на 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:\Windows\NTDS
• Log files folder: C:\Windows\NTDS
• SYSVOL folder: C:\Windows\SYSVOL

Next.

В разделе Review Options проверяем параметры установки. Обратите внимание на кнопку View script. Если её нажать, то сгенерируется tmp файл с PowerShell скриптом для установки контроллера домена.

Сейчас нам этот скрипт не нужен, но он может быть полезен системным администраторам для автоматизации установки роли контроллера домена с помощью PowerShell.

Next.

Попадаем в раздел Prerequisites Check, начинаются проверки предварительных требований.

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

Для начала установки роли контроллера домена нажимаем Install.

Начинается процесс установки.

Сервер будет перезагружен, о чём нас и предупреждают. Close.

Дожидаемся загрузки сервера.

Первоначальная настройка контроллера домена

Наша учётная запись Administrator теперь стала доменной — ILAB\Administrator. Выполняем вход.

Видим, что на сервере автоматически поднялась служба 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 на Windows Server 2016 (с графической оболочкой), а также по вводу рабочей станции в получившийся домен. Чем этот туториал может выделиться на фоне других:

1. Вместо простого «Далее, Далее, кликаем сюда, вбиваем это» я постарался дать внятное объяснение каждому шагу, каждой настройке, которую предстоит выполнить. Помимо основных понятий Active Directory, DNS и DHCP вы также сможете найти много интересной информации по всем галочкам, которые вы часто видели, но не задумывались об их назначении.
2. В конце статьи я предложу способ автоматизировать развёртывание получившегося стенда полностью с нуля, имея на компьютере только iso-образы ОС Windows 7 и Windows Server 2016. И никакого PowerShell. Всего одной командой.

Статья предполагает наличие у читателя лишь самых начальных знаний об устройстве сетей (на уровне «Что такое IP-адрес и DNS-адрес»).

Заинтересовало что-то из вышеперечисленного? Тогда погнали.

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

Начальное состояние стенда:

1. На машине windows_server уже установлена ОС Windows Server 2016 Standard Evaluation (с GUI). Машина находится в состоянии «сразу после установки ОС». В процессе туториала на ней будут развернуты службы Active Directory (с доменом mydomain.com), DNS и DHCP.

2. Машина workstation выполняет роль рабочей станции. На ней установлена ОС Windows 7. Машина находится в состоянии «сразу после установки ОС». В процессе туториала она будет подключена к домену mydomain.com.

Туториал построен следующим образом (если вам интересен только конкретный пункт — смело кликайте прямо туда):

1. Объясню, почему я выбрал именно такой стенд для туториала;
2. Супер-краткое описание технологии Active Directory;
3. Выполняется небольшая предварительная настройка windows_server;
4. На windows_server производится включение необходимых компонентов;
5. На windows_server происходит настройка контроллера домена AD (совместно с DNS);
6. На windows_server происходит настройка сервера DHCP;
7. На windows_server регистрируется новая учетная запись в AD;
8. На workstation происходит подключение к домену.

В конце туториала вас ждет приятный бонус — я покажу вам как можно развернуть у себя на компьютере весь этот работающий стенд одной единственной командой. Вам понадобится только наличие двух установочных iso-образов (windows 7 и windows server 2016), да небольшой скрипт, ссылку на который я вам дам в конце статьи.

Почему такой стенд?

Такой стенд, с моей точки зрения, отлично подходит для первого самостоятельного «прощупывания» технологии Active Directory. Он минималистичен (всего 2 виртуальные машины), занимает минимум ресурсов, но при этом изолирован и самодостаточен. Его можно развернуть даже на довольно средненьком компьютере и ноутбуке. При этом на стенде уже присутствуют основные сетевые службы (AD + DNS). DHCP хоть и необязателен для функционирования AD, всё равно был добавлен в стенд в ознакомительных целях.

Туториал предполагает подробный разбор всех шагов по настройке, с пояснениями «что, зачем и почему». Туториал ориентирован на людей, не слишком знакомых с технологиями 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, для чего есть вкладка «Локальный сервер».

Первое, что нужно сделать — это поменять сетевое имя сервера.

Сетевое имя (hostname) — это удобный способ идентификации узла в сети. Сетевое имя используется как альтернатива IP-адресу и позволяет не запоминать IP-адрес компьютера (при том, что этот адрес может меняться время от времени), а связываться с этим компьютером по его логическому названию.

Проблема в том, что по-умолчанию для Windows Server генерируется совершенно нечитаемое и неинформативное сетевое имя (я выделил его красным цветом на скриншоте).

Рабочие станции ещё могут позволить себе иметь нечитаемый Hostname, но никак не сервер. Поэтому я предлагаю поменять эту абракадабру его на что-то более разумное (например, на ADController), благо делается это быстро.

После смены имени машину нужно будет перезагрузить.

Теперь зададим статический IP-адрес для сервера. В принципе это делать не обязательно, раз мы всё равно собрались поднимать DHCP службу, но на самом деле это хорошая практика, когда все ключевые элементы корпоративной сети имеют фиксированные адреса. Открыть меню по настройке сетевого адаптера можно из вкладки «Локальный сервер», кликнув на текущие настройки Ethernet-адаптера (тоже выделены красным цветом).

Включаем нужные компоненты

Для нашего стенда нам понадобится включить следующие сервисы (или, как они тут называются, роли) на 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-сервер! Вот только вопрос, откуда его взять? Есть два варианта:

1. Использовать отдельную машину в роли DNS-сервера;
2. Использовать саму машину 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).

Теперь возвращаемся к мастеру настройки доменных имен. На этом этапе мастер предлагает следующие варианты:

1. Добавить контроллер домена в существующий домен (помните про резервирование контроллеров в домене, так ведь?). Этот вариант не для нас, ведь домена ещё никакого нет;
2. Добавить новый домен в лес. Этого мы тоже сделать не можем, т.к. и леса у нас тоже никакого нет;
3. Добавить новый лес. Это вариант как раз для нас. При этом нам тут же предлагают выбрать корневой домен для этого леса (первый домен, который будет создан в лесу).

Назовём корневой домен mydomain.com и кликнем «Далее»

Рассмотрим возможные параметры:

1. Режим работы леса и домена. Домены в одном лесу могут работать в разных режимах в зависимости от версии Windows Server на борту. Лес должен иметь режим не выше, чем самый «старый» домен в его составе. Т.к. мы планируем использовать только Windows Server 2016, то оставим этот режим и для леса и для домена;
2. DNS-сервер. Если ранее Вы не активировали роль DNS-сервера в мастере добавления ролей, то можете сделать это сейчас (вам даже предложат такой вариант по-умолчанию);
3. Должен ли контроллер домена выступать в роли Global Catalog-сервера;
4. Включить ли режим базы данных Active Directory «только на чтение». Основная задача, которую преследует технология RODC — возможность безопасной установки собственного контролера домена в удаленных филиалах и офисах, в которых сложно обеспечить физическую защиту сервера с ролью DC. Контроллер домена RODC содержит копию базы Active Directory, доступную только на чтение. Это означает, что никто, даже при получении физического доступа к такому контроллеру домена, не сможет изменить данные в AD (в том числе сбросить пароль администратора домена) (информация взята отсюда)

А вот пункт 3 рассмотрим поподробнее, он довольно интересный.

Как я уже упоминал выше, каждый контроллер домена имеет полную и исчерпывающую информацию обо всех объектах в своём домене. Если же в домене несколько контроллеров, то они ещё и участвуют в механизме репликации, поддерживая несколько актуальных копий базы данных с объектами домена. Получается, что рабочая станция в домене может узнать информацию о любом объекте из этого домена от своего ближайшего контроллера домена.

Но что же делать, если рабочей станции нужно получить информацию об объекте из другого домена? И вот тут в дело вступает ещё один важнейший механизм технологии Active Directory, который называется глобальный каталог.

Что такое вообще «Глобальный каталог»? Согласно Miscrosoft — это распределенное хранилище данных, которое хранит частичное представление обо всех AD-объектах в лесу. Это хранилище располагается на котроллерах домена, которые имеют дополнительную роль «Global Catalog Server» (Сервер глобального каталога). От обычного контроллера домена GC-сервер отличается в первую очередь тем, что помимо полной копии всех объектов в своем домене, хранит также частичную информацию обо всех объектах в других доменах леса.

Чего это позволяет достичь? Давайте представим, что рабочая станция запросила информацию об объекте из другого домена. Она обращается на ближайший GC-сервер с просьбой предоставить ей информацию об этом объекте. GC-сервер, в свою очередь, может:

1. Либо отдать рабочей станции нужную информацию сразу (если эта информация у GC-сервера имеется);
2. Либо перенаправить запрос к нужному контроллеру домена, где эта информация точно будет находиться. Чтобы понять, какому контроллеру домена нужно перенаправить запрос, как раз и происходит поиск по 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-сервер тоже один, то этот шаг нам необходимо пропустить и перейти к выбору 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-сервера. Настройка глобально состоит из двух частей:

1. Авторизация DHCP-сервера в домене AD. Не каждый DHCP-сервер может раздавать сетевые настройки в домене AD — только авторизованные. Это сделано с целях безопасности, чтобы другие DHCP-серверы не могли «подсунуть» неправильные настройки компьютерам в домене;
2. Настройка новой DHCP-области. Это уже непосредственно настройка самого DHCP-сервера, в ходе которой определяются какие сетевые настройки будут выдаваться компьютерам в сегменте сети.

Для того, чтобы авторизировать DHCP-сервер, нужно вернуться на панель мониторинга (она и так должна быть перед вами после перезагрузки), перейти на вкладку DHCP (слева) и кликнуть на предложение донастроить DHCP-сервер:

В открывшемся мастере настройки DHCP после установки пропускаем первый приветственный экран и переходим к экрану авторизации

На выбор предлагаются три варианта:

1. Использовать учётные данные администратора (по-умолчанию)
2. Использовать учётные данные другого пользователя;
3. Пропустить авторизацию AD.

По-умолчанию авторизовать DHCP-сервер в домене могут только члены группы EnterpriseAdmins, куда как раз и входит пользователь MYDOMAIN\Администратор. При желании можно потратить немного времени и делегировать эту возможность админам «помельче» (региональным администраторам), почерпнуть больше информации по этой теме можно отсюда.

Итак, выбираем вариант по-умолчанию и завершаем первый этап настроки 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 такая?

Эта настройка уже относится к довольно продвинутому администрированию сетей: если в вашей сети есть несколько 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

На самом деле, в этом случае начинается целая магия — очень хитрый процесс разрешения имён (картинка из интернетов).

Согласно алгоритму разрешения сетевых имен, сначала 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-сервер уже находится в списке, так что в итоге просто кликаем «Далее».

Теперь нас попросят указать настройки WINS-сервера. WINS (Windows Internet Name Service) сервер участвует в разрешении NetBIOS-имён в сети (прямо как DNS-сервер для DNS-имён). Вот только, в отличие от DNS, WINS-сервер не обязательно должен присутствовать в сети, чтобы разрешение NetBIOS-имён работало. Так зачем же он нужен тогда?

Дело в том, что по-умолчанию разрешение NetBIOS-имен происходит через широковещательные запросы. С одной стороны, это очень простой механизм (проще не придумаешь), но, с другой стороны, обладает парой недостатков:

1. При наличии большого количества NetBIOS-имён в сети широковещательный тафик может начать «зашумлять» канал;
2. Широковещательные запросы не могут «выйти» за пределы текущей сети, поэтому узнать NetBIOS-имя из другой сети таким способом не выйдет.

Так вот, WINS-сервер позволяет решить обе этих проблемы. Этот сервер централизованно хранит NetBIOS-имена компьютеров, и обычные узлы в сети могут обращаться к нему для поиска IP-адреса интересующего их имени (как и для DNS). Такой подход, во-первых, резко уменьшает количество широковещательного трафика в сети, а, во-вторых, позволяет посылать NetBIOS-запросы в другие сети, а не только в текущую.

В нашей небольшой сети 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.

И после успешного входа на рабочий стол перепроверяем свойства системы.

Полное имя компьютера поменялось на testo-ПК.mydomain.com, а это значит, что мы успешно ввели рабочую станцию в домен mydomain.com.

Автоматизируем

Как вы могли заметить, весь туториал можно выполнить, пользуясь исключительно мышкой и клавиатурой. Больше того, нам даже не пригодились знания PowerShell, который позволяет выполнять бОльшую часть настройки контроллера домена AD с помощью скриптов.

Так почему бы не автоматизировать все действия с клавиатурой и мышкой, которые мы предпринимали? И нет, я говорю не об AutoIT, я говорю о платформе Testo, создателем которой я являюсь. Эта платформа позволяет фиксировать все действия, проводимые с виртуальными машинами, в виде скриптов на специальном языке Testo-lang. Ну а Testo затем превратит эти скрипты обратно в действия.

Я приведу лишь один скриншот с кусочком скрипта, чтобы у вас сложилось представление о том, о чём я говорю (да, именно скриншот, ведь хабр не умеет подсвечивать скриповый язык Testo-lang). Я даже не буду комментировать этот скрипт, т.к. верю, что код говорит сам за себя.

Я не буду сейчас рассказывать о платформе Testo и о её возможностях. Для этого есть отдельная статья на хабре. Вместо этого предлагаю просто увидеть своими глазами, как это работает:

Всё, что Вам потребуется для создания собственного стенда с настроенной Active Directory — это:

1. Установочный iso-образ Windows Server 2016 русской версии;
2. Установочный iso-образ Windows 7 (придётся поискать самим);
3. Скрипты на языке Testo-lang;
4. Установленная платформа Testo (бесплатно);
5. Выполнить команду.

sudo testo run ./tests.testo --param ISO_DIR /path/to/your/iso/dir

И всё. Как и я обещал — всего одна команда. Через пол часа — час (зависит от шустрости вашего компьютера) вы сможете наслаждаться своим готовым стендом.

Итоги

Надеюсь, вам понравился туториал, и вы нашли его полезным. Возможно, вас заинтересовала платформа Testo, в этом случае вот несколько полезных ссылок:

• сайт платформы Тесто.
• youtube-канал, где можно найти много примеров.
• основная статья на хабре
• статья, где я автоматизировал несколько системных тестов для Dr. Web
• скрипты на языке Testo-lang для этого туториала

В статье подробно разберем процесс развертывания контроллер домена на базе Windows Server 2012 R2 и настройка служб AD DS, DNS, DHCP.

Наша задача:

• Установить Windows Server 2012 R2 и подготовить систему к развертыванию служб.
• Развернуть службы Active Directory + DNS, выполнить настройку служб.
• Развернуть службу DHCP, выполнить настройку обслуживания подсети 192.168.0.0/24.

Проделываться все действия будут на виртуальной машине.

Установка Windows Server 2012 R2 и настройка

При выборе типа устанавливаемой системы, выбираем Windows Server 2012 R2 Standart with GUI. Далее саму установку я пропущу, т.к. она полностью тривиальная.

После установки системы, обязательно обновляем систему до актуального состояния. Изменяем имя ПК (прим. DC1).

В настройках TCP/IP указываем статические IP-адреса (прим. как на скриншоте ниже)

Изменяем временную зону, выбираем относящуюся к нам зону (+03:00 Moscow, St. Petersburg, Volgograd).

На этом базовая подготовка системы выполнена, можно приступать к развертыванию служб.

Разворачиваем службы Active Directory + DNS

Добавляем новую роль Server Manager — Manage — Add Roles and Features. Отмечаем галочкой пункт Skip this page by default (чтобы в будущем не видеть эту страницу) и нажимаем Next.

Выбираем первый пункт Role-based or feature-based installation (Базовая установка ролей и компонентов). Второй пункт Remote Desktop Service installtion предназначен только для установки роли удаленных рабочих столов. Нажимаем Next.

Выбираем Select a server from the server pool и выбираем сервер на котором будет развернута роль. Пункт Select a virtual hard disk позволяет указать сервер расположенный на VHD-диске. Нажимаем Next.

Отмечаем галочкой роль Active Directory Domain Services, в подтверждающем запросе добавления роли и компонентов, необходимых для установки AD нажимаем Add Features и после нажимаем Next.

В этом окне предлагается выбрать дополнительные компоненты, в моем случае дополнительные компоненты не нужны, поэтому нажимаю Next.

Информационная страница на которой обращается внимание на то что желательно иметь несколько контроллеров домена, на случай выхода из строя основного. Служба AD DS требует установленного в сети DNS-сервера, если он не установлен, то будет предложено его установить, а так же AD DS требует установки дополнительных служб DFS Namesspases (пространства имен), DFS Replication (DFS репликации) и File Replication (Файловой репликации). Нажимаем Next. 

На завершающей странице мастера отображается информация по устанавливаемым компонентам. Так же здесь можно экспортировать конфигурацию в  xml-файл (Export configuration settings), на случай если нужно развернуть идентичный сервер. Нажимаем Install.

После установки Роли, в Server Manager нажимаем на значок Флажка с восклицательным знаком и выбираем Promote this server to a domain controller (Повысить этот сервер до контроллера домена). Запустится мастер конфигурирования AD DS.

Необходимо выбрать вариант развертывания AD DS.

• Add a domain controller to an existing domain — добавить дополнительный контроллер домена в существующем домене.
• Add a new domain to an existing forest — добавить новый домен в существующем лесу:

• Tree Domain —  корневой домен нового дерева в существующем лесу
• Child Domain — дочерний домен в существующем лесу

• Add New Forest — создать новый корневой домен в новом лесу.

Выбираем вариант Add New Forest, указываем корневое имя домена, нажимаем Next.

В параметрах контроллера домена оставляем по умолчанию функционал леса и домена, проверяем отмечен ли галочкой пункт Domain Name System (DNS), будет автоматически поднята роль DNS и задаем пароль для режима восстановления служб каталогов. Нажимаем Next.

Не обращаем внимание на предупреждение ошибки делегирования для этого DNS-сервера, т.к. роль DNS поднимается в процессе конфигурации AD DS. Нажимаем Next.

Оставляем подставленное мастером NetBIOS имя. Нажимаем Next.

Пути к каталогам оставляем по-умолчанию. Нажимаем Next.

Вывод сводной информации по настройке AD DS. Нажимаем Next.

Дожидаемся выполнения предварительной проверки и если проверка прошла успешно, то мастер нам сообщит об этом: All prerequisite checks are passed successfully. Click «install» to begin installation. (Все предварительные проверки пройдены успешно. Нажмите кнопку «установить», чтобы начать установку.). Нажимаем Install.

В ходе установки конфигурации AD DS, система будет перезагружена. После перезагрузки добавим зону обратного просмотра в DNS. Зоны обратного просмотра служат для разрешения IP-адресов в имена устройств.

Запускаем Server Manager, выбираем роль DNS и на сервере жмем правой кнопкой мыши. Выбираем пункт DNS Manager (Диспетчер DNS).

Выделяем вкладку Reverse Lookup Zones, нажимаем правой кнопкой и выбираем New Zone.

Задаем тип добавляемой зоны:

• Primary zone — Основная зона. Зона хранится на DNS-сервере, является основной. DNS-сервер становится основным источником сведений об этой зоне.
• Secondary zone — Дополнительная зона. DNS-сервер становится дополнительным источником сведений о зоне. Зона на этом сервере должна быть получена от другого удаленного компьютера DNS-сервера, который также хранит зону.
• Stub zone — Зона заглушка. DNS-сервер становится источником сведений только о полномочных серверах имен для этой зоны.

Выбираем Primary zone и нажимаем Next.

Предлагается выбрать как будет выполнятся репликация добавляемой зоны:

• То all DNS servers running on domain controllers in this forest — Репликации во всем лесу AD включая все деревья доменов.
• То all DNS servers running on domain controllers in this domain — Репликация внутри текущего домена и его дочерних доменов.
• То all domain controllers in this domain — Репликация на все контроллеры домена внутри текущего домена и его дочерних доменов.
• To all domain controllers specified in the scope of this directory partition — Репликация на все контроллеры домена, но DNS-зона располагается в специальном каталоге приложений. Поле будет доступно для выбора, после создания каталога.

Выбираем То all DNS servers running on domain controllers in this domain. Нажимаем Next.

Выбираем протокол заданный по умолчанию IPv4 Reverse Lookup Zone. Нажимаем Next.

Задаем параметр Network ID. В моем случае 192.168.0. В поле Reverse Lookup Zone Name автоматически подставится адрес зоны обратного просмотра. Нажимаем Next.

Выбор параметра динамического обновления:

• Allow only secure dynamic updates (recommended for Active Directory) — Разрешить только безопасные динамические обновления.
• Allow both nonsecure and secure dynamic updates — Разрешить любые динамические обновления, как безопасные так и нет.
• Do not allow dynamic updates — Не разрешать динамические обновления.

Выбираем Allow both nonsecure and secure dynamic updates. Нажимаем Next.

В завершении добавлении зоны обратного просмотра нажимаем Finish.

Теперь укажем Forwarders (Серверы пересылки). Серверы пересылки служат для того чтобы кэшировать и перенаправлять DNS-запросы с локального DNS-сервера на внешний DNS-сервер в сети интернет. Это нужно для того чтобы локальные компьютеры доменной сети смогли получить доступ в интернет.

В оснастке DNS Manage (Диспетчер DNS) выделяем наш сервер и нажимаем правой кнопкой мыши. Выбираем Properties. Переходим во вкладку Forwarders и нажимаем на Edit.

В поле <Click here to add an IP Address or DNS Name> вбиваем IP-адрес или DNS имя, например провайдера или можно 8.8.8.8 (DNS Google). Нажимаем OK.

Теперь локальные компьютеры состоящие в доменной сети, смогут выходить в интернет.

Поднимаем службу DHCP и выполняем настройку ее

Добавляем новую роль Server Manager — Manage — Add Roles and Features. Выбираем первый пункт Role-based or feature-based installation (Базовая установка ролей и компонентов). Нажимаем Next.

Выбираем Select a server from the server pool и выбираем сервер на котором будет развернута роль. Нажимаем Next.

Отмечаем галочкой роль DHPC Server, в подтверждающем запросе добавления роли и компонентов, необходимых для установки DHCP Server нажимаем Add Features и после нажимаем Next.

В моем случае дополнительные компоненты не нужны, поэтому нажимаю Next.

Информационная страница на которой обращается внимание на то что необходимо настроить на компьютере статический IP-адрес и перед установкой DHCP сервера нужно спланировать подсеть, области и исключения. Нажимаем Next.

На завершающем этапе установки, нажимаем Install.

После установки Роли, в Server Manager нажимаем на значок Флажка с восклицательным знаком и выбираем Complete DHCP configuration (Завершить конфигурацию DHCP). Запустится мастер после установочной конфигурации DHCP.

Информационная страница, на которой сообщается что будут созданы группы безопасности администратора и пользователя DHCP-сервера, и будет произведена авторизация в AD. Нажимаем Next.

На следующем экране нажимаем Commit что бы завершить процесс авторизации в Active Directory.

Если процесс создания групп безопасности и авторизация в AD прошли успешно, то получим вывод Done. Нажимаем Close.

Запускаем Server Manager, выбираем роль DHCP и на сервере жмем правой кнопкой мыши. Выбираем пункт DHCP Manager (Диспетчер DHCP).

Выполним настройку DHCP. Создадим рабочий диапазон адресов из которого будут выдаваться адреса клиентам. Создавать диапазон будем в зоне IPv4. Выбираем протокол IPv4 и нажимаем Action — New Scope… или на иконку отмеченную ниже.

Задаем имя области и ее описание. Нажимаем Next.

Определяем начальный и конечный адрес диапазона подсети. Нажимаем Next.

По желанию можно задать диапазон адресов которые не будут выдаваться клиентам. Для задания диапазона исключения указываем начальный адрес и конечный и нажимаем Add. По окончании нажимаем Next.

Задаем время аренды выданного IP-адреса. Нажимаем Next.

Указываем Yes, I want to configure these options now (Да, я хочу настроить опции сейчас). Нажимаем Next.

Указываем адрес шлюза. Нажимаем Next.

Параметры задания доменного имени, DNS сервера и WINS Servers пропускаем, оставляем указанных значения по-умолчанию. Нажимаем Next.

Соглашаемся с активацией заданной области, выбираем Yes, I want to activate thisscope now. Нажимаем Next.

На этом установка и настройка AD DS, DNS, DHCP завершена.

Сервер готов к работе, можно заводить компьютеры в домен.

Понравилась или оказалась полезной статья, поблагодари автора

 

ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА

Службы Active Directory – решение от компании Microsoft позволяющее объединить различные объекты сети (компьютеры, сервера, принтеры и различные сервисы) в единую систему. Благодаря Active Directory администратор сети получает очень удобное централизованное средство управления учетными записями пользователей, групповыми политиками  и объектами в сети.

Шаг 1. Подготовка сервера и развертывание Active Directory

Для начала нам необходимо подготовить главный контроллер домена, для этого нам понадобится сервер с установленной на нем Windows Server, в данной статье все манипуляции будем производить на Windows Server 2022, но это будет так же актуально и для Windows Server 2016 и 2019.

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

Первым делом обязательно переименуйте ваш сервер, дав ему какое ни будь логичное для контроллера имя, например DC-1. Вторым делом, установите на сервер статический IP-адрес.

Теперь установим необходимые роли на наш будущий контроллер, выберем роль “DNS-сервер” и “Доменные службы Active Directory”.

Нажимаем несколько раз “Далее” и в конце нажимаем “Установить”, ждем завершения установки новых ролей.

После завершения установки ролей можно нажать кнопку “Закрыть”. Далее в диспетчере серверов необходимо щелкнуть по флажку сверху и выбрать “Повысить роль этого сервера до уровня контроллера домена”.

Запустится конфигуратор развертывания Active Directory. Выберем параметр “Добавить новый лес” и укажем имя нашего создаваемого домена, например KONTORA.ORG.

На следующей странице выбираем режим работы леса (рекомендую оставить Windows Server 2016), а так же укажите пароль для режима восстановления служб каталогов. Главное, не забудьте потом этот пароль.

Дальше нам предлагается указать параметры делегирования DNS, но сделать этого сейчас не получится, так как у нас еще не настроен DNS сервер, пропускаем этот шаг – жмем “Далее”.

Дальше нас просят проверить NetBIOS имя вашего домена, ничего не трогаем, нажимаем “Далее”.

Далее нас попросят указать расположение базы данных Active Directory, файлов журналов и папки SYSVOL. Оставляем все по умолчанию и нажимаем “Далее”.

Затем нам предлагается посмотреть параметры, которые мы указали на этапах мастера развертывания AD, если хотите можете полистать. Нажимаем “Далее”.

На этом этапе мастер говорит нам, что все готово к начале развертывания AD. Нажимаем кнопку “Установить” и ждем, в конце сервер сам уйдет в перезагрузку.

Теперь нам надо авторизоваться на сервере уже под доменной учетной записью. Так как ранее у нас на сервере был один пользователь, он же администратор, с именем “Администратор”, используем то же самое имя и тот же пароль, только при этом заходим в домен KONTORA.ORG.

Если вы подключаетесь к серверу через RDP, то указывать имя пользователя надо так: Администратор@KONTORA (.ORG можно не писать). Если авторизация под доменной учеткой прошла успешно, значит контроллер работает.

Откроем оснастку диспетчера DNS на контроллере домена командой dnsmgmt.msc или через ярлык в меню “Пуск” – “Средства администрирования Windows” – “DNS”. Как видим, мастер развертывания AD за нас уже подготовил и создал зону прямого просмотра, назвав ее именем нашего домена. Данная зона содержит в себе всю информацию о доменных именах компьютерах и прочих устройствах, добавленных в домен.

Откроем свойства нашего DNS-сервера и перейдем на вкладку “Сервер пересылки”. Сервер пересылки нужен для того, чтобы пересылать DNS-запросы внешних DNS-имен на DNS-серверы за пределами локальной сети. Сюда мастер по умолчанию добавит IP-адрес DNS-сервера, который был указан в статичных настройках IPv4 перед началом развертывания AD, у меня здесь указан IP-адрес моего маршрутизатора на котором работает DNS. По идее сюда можно прописать IP-адреса различных публичных DNS-серверов, например Google, Cloudflare и т.д.

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

Перейдем на вкладку “Передачи зон” и заранее поставим галочку “Разрешить передачи зон” и выберем “только на серверы, перечисленные на странице серверов имен”. Данной настройкой мы заранее разрешим репликацию зоны на другие DNS-серверы в домене, если они будут добавлены. Если вы добавите в домен новый контроллер домена, не забудьте в свойствах этой же зоны на его DNS-сервере сделать такие же настройки, чтобы репликация была двухсторонняя.

Так же рекомендую открыть вкладку “Дополнительно” и поставить галочку “Разрешить автоматическое удаление устаревших записей”, это поможет избавиться от старых, неактуальных DNS записей.

При желании можно создать зону обратного просмотра. Зона обратного просмотра нужна для определения имен хостов имен по их IP -адресу. Нажимаем правой кнопкой мыши по зоне обратного просмотра и выбираем “Создать новую зону”, откроется мастер. Нажимаем “Далее”, выбираем “Основная зона”, далее указываем репликацию для всех DNS-серверов работающих на контроллерах домена в этом домене, выбираем зону обратного просмотра IPv4, указываем идентификатор сети (первые три октета вашей подсети), выбираем “Разрешить только безопасные динамические обновления” и “Готово”. Зона обратного просмотра создана. Зайдем в свойства зоны и тоже включим передачу имен на вкладке “Передачи зон”, как мы делали с зоной прямого просмотра.

Проверить работоспособность DNS-сервера можно командой:

dcdiag /test:dns

В случае ошибок при работе DNS инициируйте регистрацию или удаление записей DNS, выполнив команду:

nltest.exe /dsregdns

Выполнять обе команды необходимо в командной строке контроллера домена от имени администратора.

Шаг 2. Поднятие роли DHCP-сервера на контроллере домена и его настройка

У вас уже наверняка имеется в сети свой DHCP-сервер, скорее всего это классическая его реализация на вашем маршрутизаторе. Если вы используете маршрутизатор MikroTik, вы вполне можете продолжать использовать и его. Главное, необходимо указать в его параметрах, чтобы он выдавал клиентам сетевые настройки используя в качестве DNS-сервера IP-адрес вашего контроллера домена, поскольку именно контроллер будет нашим главным DNS-сервером в сети, иначе клиентские компьютеры просто не увидят наш домен. Еще в параметрах DHCP-сервера необходимо будет указать имя вашего домена.

У MikroTik это выглядит так:

Но лучше все таки будет отдать роль DHCP-сервера самому контроллеру. Дело в том, что штатная роль DHCP на Windows Server умеет сама править зону прямого просмотра DNS, когда выдает тому или иному хосту новый IP-адрес. Плюс, можно будет настроить любое время аренды и не бояться, что в вашей прямой зоне DNS будут устаревшие сведения. В случае использования стороннего DHCP, того же MikroTik, необходимо будет выставлять время аренды вдвое больше, чем указано в параметрах автоматического удаления устаревших записей на вашем DNS-сервере. В нашем случае необходимо будет выставлять 14 дней.

Если вы не планируете разворачивать DHCP на Windows Server и планируете использовать DHCP на вашем маршрутизаторе, можете пропустить этот шаг.

Для развертывания DHCP-сервера на контроллере домена, необходимо добавить новую роль.

Нажимаем несколько раз “Далее” и в конце “Установить”. Ждем завершения установки новой роли. Затем щелкнем на флажок в правой верхней части диспетчера серверов и выберем “Завершение настройки DHCP”.

Запустится мастер настройки конфигурации DHCP, нажимаем “Далее”.

Указываем учетные записи для авторизации DHCP-сервера. Можно оставить администратора домена, а можно создать отдельную учетную запись и внести ее в группу “Администраторы DHCP”. Я оставлю администратора домена.

Нажимаем кнопку “Фиксировать” и “Закрыть”.

Теперь откроем диспетчер DHCP командой dhcpmgmt.msc или вызовем его из меню “Пуск” – “Средства администрирования Windows” – “DHCP”, откроется оснастка.

Развернем дерево нашего DHCP-сервера, щелкнем правой кнопкой мыши на “IPv4” и выберем “Создать область”, откроется мастер создания области.

Нажимаем “Далее”, задаем имя области, можно указать имя нашего домена.

Нажимаем далее и указываем диапазон выдаваемых адресов, а так же маску подсети.

Нажимаем “Далее”. Здесь нам предлагается указать диапазон IP-адресов, которые DHCP-сервер не будет выдавать. Если таковых у вас нет, просто нажимаем “Далее”. Я же внесу сюда адрес, который сейчас предоставлен нашему контроллеру – 192.168.12.200. Вообще, правильнее было бы назначить контроллеру домена IP-адрес вне диапазона адресов, выдаваемых DHCP, например 192.168.12.2. Просто в моем случае я развернул стенд в своей действующей сети, где часть IP-адресов была уже занята и поэтому я назначил контроллеру IP-адрес из доступного участка адресов.

Теперь нас просят указать имя аренды IP-адресов, по умолчанию 8 дней. Можете оставить как есть, или указать свое значение. Я оставляю по умолчанию.

Идем дальше, нам предлагают настроить другие параметры, которые DHCP-сервер будет назначать клиентам, такие как IP-адрес маршрутизатора, DNS-сервера и т.д. Можем настроить позже, можем сейчас. Давайте сделаем.

Указываем IP-адрес вашего маршрутизатора (шлюза).

Далее нас просят указать имя домена и адрес DNS-сервера, мастер автоматически пропишет имя нашего домена и предложит в качестве DNS использовать IP-адрес контроллера домена, который у нас и будет основным DNS в сети.

Далее нас просят указать адрес WINS сервера. Он у нас не используется, поэтому пропускаем данный шаг. В конце нас спросят, хотим ли мы активировать данную область? Выбираем “Да”, нажимаем “Далее” и “Готово”.

Как видим у нас создалась новая область IPv4 с заданным пулом адресов и необходимыми параметрами. На вкладке “Арендованные адреса” можно посмотреть список клиентов.

DHCP-сервер настроен и готов к работе. Для проверки работоспособности запросите новые настройки DHCP на клиентской машине, в Windows это можно сделать командой:

ipconfig /renew

Обязательно отключите DHCP-сервер на вашем маршрутизаторе, он нам больше не пригодится.

Шаг 3. Создание пользователей в домене

И так, у нас теперь есть домен и собственно первый его контроллер, он же основной. Но у нас пока нет пользователей, приступим к их созданию.

Для создания пользователей в AD используется оснастка “Active Directory – пользователи и компьютеры”, запустить ее можно командой dsa.msc или открыть с помощью ярлыка из меню “Пуск”, во вкладке “Средства администрирования”.

В данной оснастке можно создавать и удалять пользователей, группы, подразделения, компьютеры. Если у вас в организации много пользователей и отделов, удобнее всего для каждого отдела создать свое подразделение и всех его сотрудников помещать туда. Так же для отдельных подразделений будет удобно создавать персональные групповые политики.

Для примера создадим подразделение “Отдел продаж” и создадим в нем учетные записи сотрудников – Петрова Ивана и Иванова Михаила.

Для создания подразделения щелкните правой кнопкой мыши по имени домена в оснастке “Пользователи и компьютеры” и выбирите “Создать” – “Подразделение”, затем введите имя подразделения и нажмите “ОК”.

Теперь щелкаем правой кнопкой мыши по значку нашего подразделения, выбираем “Создать” – “Пользователь”. Пишем имя и фамилию – Иван Петров, создадим ему логин ipetrov.

Нажимаем “Далее” и придумываем ему пароль. По стандартной политике использования паролей, он должен иметь минимум 8 символов, содержать буквы, цифры и хотя бы одна буква должна быть другого регистра, например – Pass1234. Ставим галочку “Срок действия пароля не ограничен”, если хотим создать постоянный пароль, и убираем галочку “Требовать смены пароля при следующем входе в систему”, если не хотим обременять пользователя лишними действиями при первом входе в систему. Нажимаем “Далее” и “Готово”, один пользователь в домене у нас есть.

Далее, опять же для нашего удобства, создадим еще одно подразделение и назовем его “Группы”, в нем мы будем создавать наши группы пользователей и компьютеров, чтобы они все были в одном месте. В новом подразделении создадим первую группу “Отдел продаж”, в эту группу мы внесем пользователей из этого отдела.

Переходим обратно в наше подразделение “Отдел продаж”, щелкаем дважды по пользователю Иван Петров, переходим на вкладку “Член групп” и добавляем группу “Отдел продаж”. Первый пользователь в группе у нас уже есть.

Теперь создадим в подразделении “Отдел продаж” второго пользователя – Михаил Иванов. Чтобы нам не указывать все параметры заново и не добавлять этого сотрудника в нужную группу, мы просто скопируем параметры из пользователя Иван Петров. Щелкаем по пользователю правой кнопкой мыши и выбираем “Копировать”.

Отроется уже знакомая нам форма которую нужно заполнить. Вводим имя и фамилию пользователя, придумываем логин, нажимем “Далее”, задаем пароль и “Готово”. Обратите внимание, что на этапе установки пароля все галочки уже были проставлены в том порядке, как мы это делали у прошлого пользователя. Так же новый пользователь уже будет включен в группу “Отдел продаж”.

Теперь у нас есть два пользователя в подразделении.

Действуя по аналогии можно создавать другие подразделения, группы и пользователей.

Шаг 4. Присоединение компьютеров в домен

После того как пользователи созданы, необходимо завести компьютеры в домен. Подключить к домену получится только те компьютеры, на которых Windows имеет редакцию “Профессиональная”, “Корпоративная”, “Embedded” и т.д. Домашнюю версию завести в домен не получится.

Переходим к компьютеру, который мы будем заводить в домен. Открываем дополнительные параметры системы, нажимаем “Изменить”.

Выбираем, что компьютер является членом домена, вводим домен KONTORA.ORG, при желании можем указать новое имя компьютеру.

Нажимаем “ОК”, далее нас попросят ввести данные администратора домена, вводим и ждем появления уведомления о том, что компьютер добавлен в домен.

Если во время присоединения к домену вышла ошибка, что указанный домен не найден, проверяйте, правильные ли настройки DNS указаны на клиентском компьютере. В качестве предпочитаемого DNS-сервера должен быть указан IP-адрес контроллера домена. Если вы вносили изменения в настройки DHCP-сервера, проверьте, что клиентский компьютер получил новые настройки.

Теперь необходимо перезагрузить компьютер. После перезагрузки на компьютере можно будет авторизоваться под доменной учетной записью администратора, либо пользователя из числа тех, что мы создали. Попробуем авторизоваться под именем Ивана Петрова, вводим его логин ipetrov и пароль Pass1234.

Как видим у нас прекрасно получилось авторизоваться под данным пользователем и даже имя и фамилия отображается во время входа в профиль.

В системе так же видно, что мы работаем под данным пользователем.

Перейдем в оснастку “Пользователи и компьютеры” на контроллере домена и откроем раздел Computers. Видим, что наш новый компьютер отображается в списке.

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

Чтобы этим не заморачиваться, нам нужно конвертировать локальную учетную запись пользователя в доменную, или другими словами – сделать миграцию профиля. Как делать миграцию профиля в Active Directory я описывал в этой статье.

Шаг 5. Примеры использования групповых политик в домене

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

Запустить оснастку для работы с групповыми политиками можно командой gpms.msc или вызвать ее через ярлык в меню “Пуск” – “Средства администрирования Windows” – “Управление групповой политикой”.

По умолчанию используется политика “Default Domain Policy”, рекомендую не трогать ее и создать свою политику, которую в случае чего можно будет потом удалить.

Щелкаем правой кнопкой мыши по имени нашего домена в оснастке и выбираем “Создать объект групповой политики в этом домене и связать его”, вводим имя нашей политики.

Щелкаем на нашу созданную политику и смотрим на “Фильтр безопасности”. Видим, что политика применяется к группе “Прошедшие проверку”, это означает, что политика будет применять ко всем пользователям и компьютерам домена. В случае чего эту группу можно убрать из фильтра и добавить туда какую ни будь другую, например “Отдел продаж”, которую мы создавали ранее. В таком случае параметры этой политики будут распространяться только на пользователей, которые были добавлены в группу “Отдел продаж”. Но есть один нюанс. Если мы убираем из фильтра безопасности группу “Прошедшие проверку” и добавляем туда любую другую группу, политика не будет применяться пока на вкладке “Делегирование” мы не добавим группу “Компьютеры домена.

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

Для редактирования групповой политики, щелкнем по нашей политике правой кнопкой мыши и выберем “Изменить”, откроется редактор групповой политики.

Давайте для примера сделаем следующие настройки:

• Создадим на рабочих столах всех пользователей ярлык на сайт https://evs.msk.ru/
• Запретим запуск командной строки и редактора реестра.
• Отключим на компьютерах автоматические обновления.

Первые две настройки делаются в конфигурации пользователя.

Для создания ярлыков перейдем в “Настройка” – “Конфигурация Windows” – “Ярлыки” и создадим новый ярлык. В качестве действия выбираем “Обновить”, это создаст ярлык заново при следующем входе в профиль, если пользователь решит удалить его. В качестве места размещения ярлыка выбираем “Рабочий стол”.

Для запрета использования командной строки и редактора реестра, перейдем в “Политики” – “Административные шаблоны” – “Система” и включим параметры “Запретить использование командной строки” и “Запретить доступ к средствам редактирования реестра”.

Теперь авторизуемся под одним из наших пользователей на клиентской машине.

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

А при попытке открыть командную строку у него она откроется с сообщением “Приглашение командной строки отключено вашим администратором”.

При попытке открыть редактор реестра тоже выйдет предупреждение.

Теперь отключим обновления Windows. Для этого мы перейдем в конфигурацию компьютера в нашей политике. Откроем “Политики” – “Административные шаблоны” – “Компоненты Windows” – “Центр обновления Windows”. Далее выберем параметр “Настройка автоматического обновления”.

Выберем “Отключено” и нажмем “ОК”.

Проверим на нашей клиентской машине. Для этого перезагрузим клиентский компьютер, а затем откроем центр обновления Windows.

Как видим, система сообщаем нам, что “Ваша организация отключила автоматические обновления”.

Кстати, большинство новых групповых политик можно применить не прибегая к перезагрузке или завершению сеанса пользователя. Достаточно выполнить команду:

gpupdate /force

Таким образом можно создавать разные групповые политики, причем можно на каждую задачу создавать отдельную политику и в случае необходимости временно выключать ее. Для этого надо щелкнуть правой кнопкой мыши по нужно политике и снять галочку “Связь включена”. Для включения политики необходимо вернуть галочку.

Так как в нашем примере мы создали политику, которая делегируется всем пользователям в домене, она так же будет действовать и для администраторов и для них так же будут действовать ограничения, которые мы установили. Поэтому, если вы создаете политики с различными запретами и ограничениями, обязательно делегируйте их только для тех пользователей и групп, для которых данные ограничения должны действовать.

Шаг 6. Добавление в действующий домен второго контроллера

Теперь, когда вы создали домен, научились подключать к домену новые компьютеры, создавать пользователей, группы и научились работать с групповыми политиками, стоит побеспокоиться об отказоустойчивости построенной системы. В Active Directory это достигается созданием дополнительных контроллеров домена, которые реплицируются с главным контроллером и имеют в себе всегда актуальную базу Active Directory. Так, если один из контроллеров выйдет из строя, ваша инфраструктура продолжит функционировать в штатном режиме, а в случае восстановления вышедшего из строя контроллера, или добавления нового, он быстро обновит в себе актуальность вашей базы Active Directory.

Добавлять дополнительные контроллеры можно в двух режимах:

• Полноценный дополнительный контроллер домена, на котором как и на главном контроллере можно изменять настройки AD, создавать/удалять пользователей, группы, работать с редактором групповых политик и т.д. Все действия будут синхронизироваться со всеми контроллерами в домене.
• Режим “Только для чтения (RODC)”. Актуально, если вы планируете использовать такой контроллер на удаленном филиале, где у вас не будет к нему постоянного физического доступа. В таком режиме контроллер будет всегда поддерживать актуальную базу AD, синхронизируя ее с вашим основным контроллером, например, через VPN, и с помощью него смогут авторизовываться пользователи данного филиала не прибегая к необходимости обращаться каждый раз к вашему основном контроллеру. И при всем этом никто не сможет на таком контроллере внести какие либо изменения в вашу структуру AD.

Мы будем использовать первый режим.

Если первый контроллер домена вы разворачивали на “железном” сервере, а не на виртуальной машине, второй вполне можно развернуть на виртуалке. Главное, чтобы в сети был хотя бы один “железный” контроллер. Поэтому, если первый контроллер вы развернули на виртуальной машине, второй рекомендуется развернуть на “железном” сервере. Дело в том, что при использовании “железного” сервера, при развертывании AD по умолчанию отключается кэш диска, чтобы избежать потери информации при внезапных отключениях, а на виртуальной машине такая возможность отсутствует. Так, если на виртуальном сервере произойдет внештатная ситуация и часть данных будет потеряна, контроллер благополучно восстановит ее, загрузив с “железного” контроллера.

Для начала подготовим сервер для второго контроллера. Поменяем ему имя на DC-2 и введем его в наш домен. Далее установим, как в случае с первым нашим контроллером, роли “DNS-сервер” и “Доменные службы Active Directory”, а так же роль DHCP-сервера. Таким образом у нас будет второй, резервный контроллер домена со своим DNS-сервером и резервный DHCP-сервер.

Если вы используете свой отдельный DHCP-сервер, то роль DHCP-сервера разворачивать не нужно.

После установки ролей так же повышаем наш сервер до уровня контроллера домена и в мастере развертывания AD выбираем “Добавить контроллер домена в существующий домен”.

Далее, как и в случае с первым контроллером, указываем пароль для режима восстановления служб каталогов, на этом же этапе можно поставить галочку “Контроллер домена только для чтения (RODC)”. Мы будем делать полноценный контроллер, поэтому галочку ставить не будем. Здесь же предлагается выбрать сайт в который мы будем добавлять данный контроллер домена, что такое сайты в Active Directory я расскажу чуть ниже. Пока сайт у нас один, созданный по умолчанию, оставляем его и идем дальше.

Далее пропускаем страницу “Делегирование DNS” и на странице параметров репликации нам необходимо выбрать источник репликации. Можно выбрать наш основной контроллер домена, однако я рекомендую оставить параметр “Любой контроллер домена”, на случай если у нас их в сети будет несколько. В таком случае наш подготавливаемый контроллер сможет реплицировать базу со всех контроллеров в домене, а не только с одного.

Дальше нас, как и в случае с настройкой первого контроллера, попросят указать пути к базе данных, файлам журналов и папке SYSVOL, оставляем все по умолчанию, нажимаем несколько раз “Далее” и “Установить”. Дожидаемся завершения работы мастера, по окончании ваш сервер уйдет в перезагрузку.

Зайдем на наш главный контроллер домена DC-1 и откроем оснастку “Active Directory – сайты и службы” по команда dssite.msc или через ярлык в меню “Пуск” – “Средства администрирования Windows” – “Active Directory – сайты и службы”. Развернем “Default-First-Site-Name”, затем “Servers” и увидим, что у нас в домене теперь два контроллера, DC-1 и DC-2.

Название сайта “Default-First-Site-Name” можно переименовать без каких либо опасений, можно ему дать имя вашей организации. Так же можно создавать другие сайты, если у вас, например, несколько филиалов и в каждом филиале используется своя подсеть. В настройках каждого сайта указываются параметры подсети, для которой он создается и это поможет мастеру развертывания AD добавлять новые контроллеры сразу в нужные сайты. С помощью сайтов можно оптимизировать трафик между филиалами в разных городах. Так, компьютеры филиала, подсеть которого ссылается на определенный сайт в котором есть свой контроллер домена, будет взаимодействовать в первую очередь с этим контроллером домена, а потом уже с остальными.

Для сопоставления подсетей с сайтами в Active Directory, в оснастке “Active Directory – сайты и службы” щелкните правой кнопкой по “Subnets” и выберете “Создать подсеть”. Укажите адрес подсети с маской и выберите мышкой сайт для которого создается данная подсеть.

После данной операции подсеть появится в разделе Subnets.

Переходим на наш второй контроллер DC-2 и открываем оснастку DNS. Видим, что зона основного просмотра реплицировалась с нашим DNS-сервером на первом контроллере. Так же видим в записях DNS наш новый контроллер.

Зайдем в свойства этой зоны и включим передачу зон на серверы, перечисленные на странице серверов имен. Далее перейдем на вкладку “Серверы имен” и убедимся, что у нас теперь там отображаются два наших DNS-сервера: DC-1 и DC-2.

Можно еще перейти в оснастку DNS на первом контроллере и проверить, что там так же отображаются оба сервера.

И так, репликация DNS у нас работает. Проверим работает ли репликация между самими контроллерами, для этого существует команда:

repadmin /replsummary

Выполняем ее в командной строке от имени администратора, должны получить такой результат:

Как видим, репликация работает. Если значение наиб. дельты не боле часа – с репликацией всё в порядке. Количество сбоев должно быть равно 0.

Если же в работе репликации возникли ошибки то можно использовать следующую команду чтобы посмотреть какой контекст наименования не реплицируется:

repadmin /showreps

Теперь настроим DHCP-сервер на втором контроллере и изменим настройки на DHCP-сервере нашего главного контроллера.

Для начала на DHCP-сервере нашего главного контроллера надо изменить диапазон выдаваемых адресов. Нужно сделать так, чтобы диапазоны выдаваемых адресов не пересекались между первым и вторым DHCP серверами. Например, чтобы первый DHCP выдавал IP-адреса в диапазоне 192.168.12.50-192.168.12.150, а второй DHCP в диапазоне 192.168.12.151-192.168.12.254. Таким образом диапазоны DHCP серверов не будут пересекаться между собой в тот момент, когда в сети они будут работать одновременно. Если вам не будет хватать адресов в пуле, можно расширить вашу сеть, сделав ее, например, с 22 маской (255.255.252.000). В таком случае у вас будут доступны подсети 192.168.12.0, 192.168.13.0, 192.168.14.0 и 192.168.15.0, разгуляться будет где.

Чтобы поменять диапазон выдаваемых адресов, нужно перейти в свойства вашей области IPv4 и поменять там значения:

Так же, если IP-адрес вашего второго контроллера пересекается с диапазоном выдаваемых адресов, добавьте его в исключения, однако я уже говорил, что лучше назначать контроллерам IP-адреса не из области выдаваемых DHCP.

Последним немаловажным изменением в настройках DHCP-сервера является добавление в параметрах области второго DNS-сервера – IP-адреса второго контроллера.

Теперь, используя инструкцию по настройке DHCP-сервера из этой статьи, завершите его настройку на втором контроллере домена.

Заключение

И так, мы сделали основные шаги в развертывании отказоустойчивой системы Active Directory в вашей сети. Теперь у вас в руках имеется мощный инструмент, благодаря которому администрирование огромных сетей теперь можно выполнять буквально в несколько кликов вышкой. Сломать отказоустойчивую систему AD очень сложно, но тем не менее не забывайте проверять техническое состояние ваших контроллеров, вовремя производите обслуживание серверов и конечно не забывайте про резервное копирование.

Обновлено: 16.09.2023
Опубликовано: 01.10.2016

Что такое Active Directory простыми словами.

1. Подготовка системы

Для контроллера домена необходимо заранее задать имя компьютера и настроить статический IP-адрес. Это важно, так как смена этих настроек на рабочем активном каталоге может привести к потери работоспособности системы.

Проверяем настройку системного времени и часового пояса. Данный параметр также важен для устанавливаемой роли.

2. Установка роли AD DS

Открываем Диспетчер серверов

Нажимаем Управление — Добавить роли и компоненты:

Если откроется окно с приветствием, просто нажимаем Далее. В следующем окне оставляем Установка ролей и компонентов и нажимаем Далее:

Выбираем сервер, на который будет установлена роль контроллера домена (по умолчанию выбран локальный сервер) и нажимаем Далее:

Среди всех ролей выбираем следующие:

• DNS-сервер.
• Доменные службы Active Directory.
• DHCP-сервер (чаще всего используется, но не обязательно).

* на самом деле, для работы роли контроллера домена не обязательна установка первых двух. Они могут быть настроены на других серверах.

В следующем окне Выбор компонентов просто нажимаем Далее.

Досчелкиваем Далее до конца и нажимаем Установить:

Те же действия можно выполнить командой Powershell:

Install-WindowsFeature -Name DNS, DHCP, AD-Domain-Services -IncludeManagementTools

Или без DHCP:

Install-WindowsFeature -Name DNS, AD-Domain-Services -IncludeManagementTools

После завершения установки роли не торопимся закрывать окно. Кликаем по пункту меню Повысить роль этого сервера до уровня контроллера домена:

* если мы перезагрузим сервер, повысить роль можно вернувшись в диспетчер серверов.

В открывшемся окне выбираем операцию развертывания. Если разворачивается первый контроллер домена в сети, оставляем выбор на Добавить новый лес, вводим имя домена и нажимаем Далее:

В следующем окне оставляем все как есть и вводим надежный пароль для режима восстановления:

В окне Параметры DNS нажимаем Далее.

В окне Дополнительные параметры автоматически будет подобрано имя NetBIOS. Его менять не обязательно — просто нажимаем Далее:

В окне Пути стоит оставить все, как есть. Нажимаем Далее. В окне Просмотреть параметры проверяем правильность введенных данных и нажимаем Далее.

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

Настройка после развертывания сервиса

После развертывания контроллера домера, выполняем следующие действия.

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

На контроллере домена с ролью PDC Emulator необходимо настроить источник синхронизации времени. Для этого открываем командную строку от администратора и вводим команду:

w32tm /config /manualpeerlist:»time.nist.gov,0x8 time.windows.com,0x8″ /syncfromflags:manual /reliable:yes /update

* данная команда задаст в качестве источника времени 2 сервера — time.nist.gov и time.windows.com.
* если мы не знаем, на каком контроллере у нас роль PDC Emulator, воспользуемся инструкцией Управление FSMO через powershell.

Соответствие рекомендациям Best Practice

1. Создание коротких имен файлов должно быть отключено

Ранее в DOS все файлы называли в формате 8.3 — 8 символов под имя, 3 для расширения. Необходимость такого подхода сильно устарело, однако по умолчанию для обеспечения совместимости может быть включено.

В командной строке от имени администратора вводим:

fsutil 8dot3name set 1

Готово — поддержка создания коротких имен отключено.

2. Файл Srv.sys должен быть настроен на запуск по требованию.

В обычной командной строке от имени администратора вводим:

sc config srv start= demand

3. Некоторые сетевые адаптеры поддерживают RSS, но эта возможность отключена.

Необходимо для сетевого адаптера, который используется для подключения к сети, включить RSS.

Вводим команду в Powershell:

Enable-NetAdapterRss -Name *

4. Некоторые сетевые адаптеры поддерживают IPsec TOv2, но эта возможность отключена.

Вводим команду в Powershell:

Enable-NetAdapterIPsecOffload -Name *

5. Некоторые сетевые адаптеры поддерживают LSO, но эта возможность отключена.

Вводим команду в Powershell:

Enable-NetAdapterLso -Name *

6. Значение … не соответствует рекомендуемому на этом сервере.

Система может предложить более оптимальные параметры для опций:

• Smb2CreditsMin — 512.
• Smb2CreditsMax — 8192.
• DurableHandleV2TimeoutInSeconds — 180.
• AutoDisconnectTimeout — 15.
• CachedOpenLimit — 10.
• AsynchronousCredits — 512.

Данные значения могут различаться в разных версиях Windows.

Выставить данные опции можно командой Set-SmbServerConfiguration:

Set-SmbServerConfiguration -Smb2CreditsMin 512 -Smb2CreditsMax 8192 -DurableHandleV2TimeoutInSeconds 180 -AutoDisconnectTimeout 15 -CachedOpenLimit 10 -AsynchronousCredits 512 -Confirm:$false

7. Для повышения производительности SmbDirect отключите подписывание и шифрование.

Вводим команду в Powershell:

Disable-NetAdapterRdma *

Настройка DNS

Как правило, на один сервер с ролью контроллера домена устанавливается DNS. В этом случае необходимо выполнить ряд действий.

1. Настройка перенаправления.

Если наш сервер DNS не может ответить на запрос, он должен передавать его на внешний сервер. Для настройки перенаправления открываем консоль управления сервером имен и кликаем правой кнопкой по названию сервера — выбираем Свойства:

Переходим на вкладку Сервер пересылки:

Кликаем по кнопке Изменить:

Вводим адреса серверов, на которые хотим переводить запросы:

* это могут быть любые DNS, например, глобальные от Google или Яндекса, а также серверы от Интернет-провайдера.

2. Удаление корневых ссылок

Если наш сервер не работает по Ipv6, стоит удалить корневые ссылки, которые работают по этой адресации. Для этого заходим в свойства нашего сервера DNS:

Переходим во вкладку Корневые ссылки:

Мы увидим список серверов имен — удаляем все с адресами IPv6.

3. Включение очистки

Чтобы в DNS не хранилось много ненужных записей, настраиваем автоматическую читску. Для этого открываем настройки сервера имен:

Переходим на вкладку Дополнительно:

Ставим галочку Разрешить автоматическое удаление устаревших записей и ставим количество дней, по прошествию которых считать запись устаревшей:

Готово.

Проверка корректности работы AD

После выполнения всех процедур по настройке сервера, ждем около 15 минут. После открываем командную строку от администратора и вводим:

dcdiag /a /q

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

Читайте также

Дополнительные сведения по работе с контроллерами домена:

1. Как добавить компьютер с Windows к домену.

2. Понижение контроллера домена и удаление роли AD DS.

3. Как перенести групповые политики на новый контроллер домена.

4. Ручное удаление контроллера домена.