Windows active directory domains — Ваш верный помощник с OS Windows

В этой статье я бы хотел предложить вам пошаговый туториал по развёртыванию контроллера домена Active Directory на Windows Server 2016 (с графической оболочкой), а также по вводу рабочей станции в получившийся домен. Чем этот туториал может выделиться на фоне других:

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

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

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

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

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

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

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

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

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

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

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

Disclaimer

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

Туториал предполагает подробный разбор всех шагов по настройке, с пояснениями «что, зачем и почему». Туториал ориентирован на людей, не слишком знакомых с технологиями Active Directory, DNS и DHCP, которые хотели бы немного узнать о внутренней кухне администрирования сетей с Active Directory.

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

Что такое Active Directory

Active Directory — это службы каталогов от компании Microsoft, как подсказывает нам Википедия. За этим сухим и невзрачным определением скрывается одна из важнейших технологий в администрировании сетей. Благодаря Active Directory администратор сети получает очень удобное централизованное средство управления учетными записями пользователей, групповыми политиками (в т.ч. политиками безопасности) и объектами в сети (причём Active Directory без особых проблем справляется даже с гигантскими сетями). А благодаря встроенному механизму репликации, «положить» правильно настроенные сервисы AD не так-то просто. Ну и напоследок, благодаря Windows настроить Active Directory можно буквально мышкой, так что даже совсем начинающие IT-шники смогут с этим справиться.

Несмотря на то, что технологией заведует Microsoft, она вовсе не ограничивается управлением Windows-машин — все известные Linux-дистрибутивы уже давным давно научились работать с этой технологией. Повстречаться с Active Directory не просто, а очень просто — практически каждый офис предполагает наличие этой технологии, поэтому даже самым заядлым линуксоидам было бы неплохо разбираться в азах работы Active Directory.

Начинаем

Вы установили Windows Server 2016 и (надеюсь) видите следующий экран:

Эта панель — основное (графическое) средство администрирования Windows Server 2016. Здесь вы можете управлять компонентами и сервисами на вашем сервере (проще говоря, настраивать то, что умеет делать сервер). Эту же панель можно использовать и для базовых сетевых настроек Windows Server, для чего есть вкладка «Локальный сервер».

Базовые настройки Windows Server

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

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

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

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

Смена сетевого имени

Нужно кликнуть на текущее имя сервера (отмечено красным цветом), затем во вкладке «Имя компьютера» нажать на кнопку «Изменить…», после чего ввести что-то более благоразумное:

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

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

Настройки IP для интерфейса windows_server

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

Для нашего стенда нам понадобится включить следующие сервисы (или, как они тут называются, роли) на Windows Server:

Доменные службы Active Directory;
DNS-сервер;
DHCP-сервер.

Пройдемся вкратце по каждому из них.

Доменные службы Active Directory

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

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

Однако, что же делать, если контроллер домена выйдет из строя (или просто будет недоступен для рабочих станций)? Если вы настроили только один контроллер домена, то дела ваши довольно плохи — без связи с рабочим контроллером домена пользователи не смогут выполнить вход на свои рабочие места. Поэтому в реальных сетях всегда рекомендуется устанавливать как минимум два контроллера на каждый домен. Каждый контроллер домена участвует в так называемом механизме репликации, благодаря чему все контроллеры домена имеют полную копию базы данных со всеми объектами в домене. Если по какой-то причине один из контроллеров выйдет из строя, его место всегда может занять резервный контроллер — и пользователи даже ничего не заметят.

Однако этот туториал рассчитан на простое ознакомление с технологией AD «на виртуалках», поэтому здесь не будет рассматриваться вопрос создания нескольких контроллеров AD в одном домене.

С этим пунктом все более менее понятно, а зачем же нам включать дополнительно ещё DNS-сервер?

DNS-сервер

Обычно протокол DNS (Domain Name System) используется для обращения к узлам в сети не по их IP-адресу, а по доменному имени (строковый идентификатор), что, конечно, гораздо удобнее. Другими словами, DNS чаще всего используется для разрешения доменных имен.

Но область применения протокола DNS не ограничивается только сопоставлением хостового имени и IP-адреса, что как раз подтверждает технология Active Directory. Дело в том, что Microsoft решила построить технологию Active Directory не с нуля, а на основе протокола DNS. В частности, протокол DNS используется при определении местонахождения всех ключевых сервисов Active Directory в сети. Другими словами, рабочая станция при подключении к контроллеру домена понимает, «куда» ей надо обращаться, именно с помощью протокола DNS.

Все DNS-записи (в том числе с информацией о сервисах Active Directory) хранятся на DNS-сервере, а это значит, что нам нужно заиметь свой собственный DNS-сервер! Вот только вопрос, откуда его взять? Есть два варианта:

Использовать отдельную машину в роли DNS-сервера;
Использовать саму машину windows_server в роли DNS-сервера.

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

Именно поэтому эту роль (DNS-сервера) тоже нужно добавить к ролям машины windows_server.

Кстати, если не добавить роль «DNS-сервер» сейчас, то в будущем у вас ещё будет такая возможность при конфигурировании контроллера домена AD.

DHCP-сервер

Протокол DHCP (Dynamic Host Configuration Protocol) нужен для автоматической выдачи сетевых настроек узлам в сети. Под сетевыми настройками понимается IP-адрес, адрес шлюза по-умолчанию, адрес DNS-сервера, и ещё ряд других настроек. Этот протокол чрезвычайно удобен при администрировании сетей, особенно больших.

В этом туториале я использую протокол DHCP чтобы рабочая станция workstation могла получить сетевые настройки (в частности, адрес DNS-сервера) без каких-либо действий с моей стороны.

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

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

Что ж, довольно теории, давайте лучше перейдём к включению этих самых ролей.

Мастер добавления ролей и компонентов

Возвращаемся на панель мониторинга (самый первый скриншот) и щелкаем на пункт «Добавить роли и компоненты». Вас поприветствует мастер добавления ролей и компонентов. Первый экран («Перед началом работы») пропускаем, он совсем неинтересный, а вот дальше идёт экран «Выбор типа установки»

Выбор типа установки

Нас устраивает значение по-умолчанию (Установка ролей или компонентов»), но интересен и второй пункт — он позволяет задействовать ещё одну возможность Windows Server — инфраструктуру виртуальных рабочих мест (Virtual Desktop Environment — VDI). Эта интереснейшая технология позволяет, буквально, виртуализировать рабочее место. То есть для пользователя создаётся виртуальное рабочее место, к которому он может подключаться через тонкий клиент. Пользователь лишь видит картинку, тогда как само рабочее место может совершенно прозрачно работать где угодно.

Впрочем, технология VDI это отдельная большая тема, а в этом туториале надо сосредоточиться на контроллере AD, так что кликаем «Далее» и видим экран выбора целевого сервера.

Выбор целевого сервера

Мастер добавления ролей позволяет устанавливать роль не только на текущую машину, но вообще на любой добавленный сервер, и даже на виртуальный жёсткий диск. Да, если ваша Windows Server развернута на виртуальной машине (а это довольно частое явление), то вы можете администрировать эту виртуальную машину даже не запуская её! Понаблюдать за этим процессом можно, например, здесь

Нам же такая экзотика ни к чему, так что просто выбираем единственный возможный сервер (обратите внимание, что он теперь называется ADController место непонятной абракадабры), жмём «Далее» и, наконец, попадаем на экран выбора ролей, которые нужно добавить.

Выбор добавляемых ролей

Выбираем три роли, о которых уже говорили ранее, и продолжаем.

Выбор компонентов

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

Согласно идеологии Microsoft, роль — это набор программ, которые позволяют компьютеру предоставлять некоторые функции для пользователей в сети. Например, DNS, DHCP, контроллер домена AD — это всё роли. А вот компоненты — это набор программ, которые улучшают либо возможности ролей сервера, либо самого сервера.

При этом глядя на список «Компонентов» так сходу и не скажешь, что какие-то вещи в списке лишь «вспомогательные». Вот например, DHCP-сервер расценивается как роль, а WINS-сервер — уже как компонент. А чем SMTP-сервер хуже DNS?

В общем-то, чёткой границы между ролью и компонентом не существует. Я лично предпочитаю относиться к ролям как к большим функциональным возможностям сервера, а к компонентам — как к небольшим дополнительным аддонам.

В любом случае, дополнительные компоненты нам не нужны, так что кликаем «Далее».

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

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

На экране подтверждения ещё раз видим все устанавливаемые роли и компоненты, после чего жмём «Установить».

Остаётся лишь дождаться, когда заполнится progress-bar, и перейти к следующему пункту туториала — настройке контроллера домена AD.

Настраиваем контроллер домена Active Directory

Все роли и компоненты успешно добавлены, о чём свидетельствует следующий экран:

Вот только AD на сервере всё еще не работает — для этого его необходимо донастроить. Для этого нам настойчиво предлагают «Повысить роль этого сервера до уровня контроллера домена».

Погодите-ка, ЧТО?!

А чем же я занимался последние 15 минут? Я же добавлял роли, и судя по сообщению, они успешно добавились! И тут меня снова хотят заставить добавлять какие-то новые роли? В чем-то тут подвох.

Подвох тут действительно имеется, но вообще в не самом очевидном месте. Вот так выглядит предыдущий скриншот в английской версии Windows Server (картинка из интернета).

Английская версия скриншота

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

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

Конфигурация развёртывания

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

Технология Active Directory (как и DNS) подразумевает иерархическое построение имён на основе доменов. Домены могут выстраиваться в доменные деревья по принципу «родительско-дочерних» отношений. В основе дерева лежит так называемый корневой домен (на картинке выше это sources.com, xyz.com и abc.com). При этом домен может иметь сколько угодно потомков. Домен-потомок располагается в пространстве имён родителя и является его «поддоменом» (subdomain). У доменного имени домена-потомка есть дополнительный префикс относительно доменного имени родителя (rus.abc.com, eng.abc.com). Один корневой домен основывает только одно доменное дерево со своим независимым пространством имён.

Теперь представьте, что таких независимых деревьев может быть много — в этом случае эти деревья образуют структуру, которая называется «лес». При этом в Active Directory доменные деревья не могут быть «сами по себе» — они обязательно должны находиться в лесу (даже если лес будет состоять всего из одного-единственного домена). Первый домен, который добавляется в лес, называется корневым доменом леса (на рисунке выше это sources.com). Корневой домен леса используется для идентификации всего леса (то есть если корневой домен называется sources.com, то и весь лес называется sources.com).

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

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

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

Параметры контроллера домена

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

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

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

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

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

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

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

Либо отдать рабочей станции нужную информацию сразу (если эта информация у GC-сервера имеется);
Либо перенаправить запрос к нужному контроллеру домена, где эта информация точно будет находиться. Чтобы понять, какому контроллеру домена нужно перенаправить запрос, как раз и происходит поиск по GC.

Информация о том, какие атрибуты попадают в глобальный каталог, определена в Partial Attribute Set (PAS), который может настраивать администратор AD. Например, если администратор понимает, что рабочие станции часто будут обращаться к атрибуту, который не содержится в глобальном каталоге, он может добавить туда этот атрибут. Тогда запросы рабочих станций при чтении этого атрибута будут выполняться значительно быстрее, т.к. уже ближайший GC-сервер сможет предоставить им всю нужную информацию.

Однако, если в лесе всего один домен (как у нас), то Глобальный каталог содержит полную копию объектов в домене и всё.

Что ж, возвращаемся к галочке GC, которую за нас уже проставил мастер настройки доменных служб. Если вы попробуете её отключить, то убедитесь, что отключить её нельзя. Это связано с тем, что каждый домен в AD должен иметь хотя бы один GC-сервер, и при добавлении первого контроллера в домен этот контроллер сразу помечается как GC-сервер.

Что ж, давайте согласимся с этим «выбором» мастера и перейдём к последнему параметру на этом скриншоте — к паролю для режима восстановления служб каталогов. Это особый режим безопасной загрузки Windows Server, который позволяет администратору работать с базой данных AD. Этот режим применяется, например, в следующих случаях:

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

Да да, вы не ослышались. Чтобы просто восстановить резервную копию базы данных, нужно перезагрузить машину и загрузиться в особом «безопасном» режиме. Это вам не Linux какой-нибудь.

Фух, вроде разобрались. Давайте перейдем дальше на шаг, где нам предложат настроить делегирование DNS.

Делегирование DNS

Что такое делегирование DNS? По большей части, это передача ответственности за некоторую DNS-зону отдельному DNS-серверу. Это распространенная практика в больших сетях, в которых требуется разграничить зоны ответственности за доменные зоны между различными серверами. При делегировании DNS в «главный» DNS-сервер вносится запись о том, что «вот за эту DNS-зону несёт ответственность вон тот DNS-сервер, обращайся туда».

Т.к. у нас всего одна зона DNS и DNS-сервер тоже один, то этот шаг нам необходимо пропустить и перейти к выбору NetBIOS-имени.

NetBIOS-имя

Мы видим, что мастер предложил нам на выбор сразу же имя для нашего домена — MYDOMAIN. Но вы можете (и должны) задать себе вопрос: а что такое вообще NetBIOS-имя и зачем оно нужно? И разве мы уже не настраивали сетевое имя узла (Hostname) в самом начале? Чего же от вас хотят?

NetBIOS (Network Basic Input/Output) — это ещё один способ разрешения имён узлов в сети (более древний и более примитивный, чем DNS). NetBIOS-имена не предполагают никакой иерархии, их длина ограничивается всего лишь 16 символами, и они применяются только для разрешения имён компьютеров в локальной сети. Когда мы в самом начале туториала выбрали сетевое имя ADController — мы, на самом деле, задали именно NetBIOS-имя для сервера. Но теперь от нас снова требуют выбрать NetBIOS-имя (да ещё и другое, отличное от ADContoller). Не много ли NetBIOS-имён для одного компьютера?

Дело в том, что Microsoft пошла ещё дальше — и ограничила длину NetBIOS-имен не 16 символами, а 15 символами. 16-ый символ при этом считается зарезервированным суффиксом, который может принимать фиксированные значения. В зависимости от значения 16-го байта получаются разные классы NetBIOS-имён. Например, если суффикс равен 00, то NetBIOS-имя относится к рабочей станции. Если суффикс равен 1С, то это имя относится к имени домена.

То есть, как вы понимаете, на первом шаге мы задавали NetBIOS-имя для компьютера Windows Server (с суффиком 00). А теперь задаём NetBIOS-имя домена mydomain.com (с суффиксом 1С).

Кстати, можете, ради интереса, отмотать туториал в самое начало и посчитать количество символов в «нечитаемом» автоматически сгенерированном сетевом имени windows_server. Будет как раз 15 символов (максимальная длина NetBIOS-имени).

И напоследок скажу, что вы не можете пропустить этот шаг. NetBIOS хоть и устаревшая технология, но до сих пор используется ради совместимости с некоторыми старыми службами. Настроить контроллер домена Active Directory без NetBIOS-имени нельзя.

Что ж, и с этим тоже разобрались. Оставляем NetBIOS-имя по-умолчанию и двигаемся дальше, к выбору места расположения базы данных AD. Можно оставить значение по-умолчанию, комментировать особо нечего.

Расположение базы данных

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

Проверка предварительных требований

Как только всё готово, жмите «Установить» и можете спокойно идти пить чай, потому что после установки автоматически начнётся очень-очень долгая перезагрузка. Зато настройка контроллера домена AD на этом закончена, поздравляю!

Настройка DHCP-сервера

Пришло время заняться настройкой DHCP-сервера. Настройка глобально состоит из двух частей:

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

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

Запуск авторизации DHCP-сервера

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

Авторизация DHCP-сервера в домене

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

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

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

Итак, выбираем вариант по-умолчанию и завершаем первый этап настроки DHCP-сервера.

Завершение авторизации DHCP-сервера

Теперь переходим непосредственно к настройкам DHCP. Для этого на панели мониторинга кликаем вкладку «Средства» и выбираем пункт «DHCP»

В открывшемся окне с настройками DHCP нужно кликнуть правой кнопкой мышки на IPv4 и затем на пункт меню «Создать область». После этого откроется мастер создания новой области.

Открытие мастера создания новой области

Что такое DHCP-область? Под этим понимается некий диапазон IP-адресов, которые может выдавать DHCP-сервер другим компьютерам в сети. Каждая область помимо диапазона IP-адресов также содержит другие сетевые настройки, с которыми мы сейчас и познакомимся.

Назовём DHCP-область SCOPE1 и перейдём дальше.

На следующем экране вам предложат выбрать диапазон адресов, которые будут выдаваться компьютерам в сети. Ранее я настраивал сетевой интерфейс на Windows Server, выдав ему адрес 192.168.1.1/24. Это статический адрес и он зарезервирован, его выдавать другим компьютерам нельзя.

Зато никто не мешает выдавать все остальные адреса в сети 192.168.1.0/24 — так что задаём диапазон от 192.168.1.2 до 192.168.1.254 (192.168.1.255 — это зарезервированный широковещательный адрес, его выдавать тоже нельзя).

Настройка диапазона адресов

В целом, никто не мешает вам как администратору выдавать меньше IP-адресов, чем доступно в адресации сети. Например, можно было бы выделить в сети всего 100 адресов для автоматической выдачи: 192.168.1.101-192.168.1.200.

Переходим далее и видим предложение о выборе исключений из указанонного диапазона адресов, а также о настройке задержки при передаче сообщения DHCPOFFER

Исключения в диапазоне и задержка DHCPOFFER

С исключениями всё более-менее понятно: если вы не хотите выдавать некоторые адреса в указанном ранее диапазоне, то вы можете указать эти адреса здесь в виде исключений. А что за задержка в DHCPOFFER такая?

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

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

Настройка времени аренды адресов

Протокол DHCP предполагает выделение адресов только на определённое время, после чего компьютеры должны продлять аренду. Здесь можно настроить это время (по-умолчанию — 8 дней).

8 дней меня лично вполне устраивает, так что кликаем «Далее» и видим предложение настроить другие настройки, которые будут получать клиенты в сети (помимо IP-адреса). Соглашаемся.

Настроить дополнительные параметры

Первая сетевая настройка для клиентов — это шлюз по-умолчанию. В стенде из двух виртуальных машин эта настройка в принципе не нужна. Но можно представить, что windows_server будет играть роль шлюза во внешнюю сеть, и добавить адрес 192.168.1.1 как шлюз по-умолчанию.

Шлюз по-умолчанию

Далее идет настройка DNS. Здесь можно задать имя родительского домена и адреса DNS-серверов. С адресами DNS-серверов всё более-менее понятно — это IP-адреса серверов, куда следует обращаться клиентам за помощью в разрешении DNS-имён. Сейчас в этом списке фигурирует тот же адрес, что мы добавили как шлюз по-умолчанию.

А вот для понимания имени родительского домена, рассмотрим следующую ситуацию.

Допустим, есть домен mydomain.com и есть два компьютера в этом домене с именами comp1.mydomain.com и comp2.mydomain.com. Если comp1 хочет связаться с comp2, то он должен, по-хорошему, использовать следующую команду (обращение по Fully Qualified Domain Name — FQDN):

ping comp2.mydomain.com

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

ping comp2

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

Процесс разрешения сетевых имён

Поиск информации в hosts.txt или в кеше;
Попытка найти имя через DNS;
Попытка найти NetBIOS-имя в кеше;
Попытка найти NetBIOS-имя через WINS-сервер;
Попытка найти NetBIOS-имя путём отправки широковещательных пакетов в локальную сеть;
Попытка найти NetBIOS-имя в LMHOSTS-файле.

Согласно алгоритму разрешения сетевых имен, сначала comp1 попробует найти информацию о comp2 в hosts.txt — файле. Если этой информации там не окажется, то начинается процесс поиска узла через DNS. Вот только вопрос — DNS-имена же находятся в каком-то домене, верно? Какое доменное имя нужно «пристыковать» к comp2 при выполнении пинга?

Вот тут в дело и вступает настройка DHCP, которая называется «имя родительсокго домена». Это как раз тот суффикс, который будет автоматически «пристыкован» к имени comp2 при выполнении DNS-разрешения имени. Так что если имя родительского домена равно «mydomain.com», то команда ping comp2 неявно преобразуется в ping comp2.mydomain.com.

Если же DNS-разрешение окажется неудачным, дальше начнутся попытки найти comp2 уже по NetBIOS-имени. Что такое WINS, и чем он отличается от Broadcast — информация будет чуть дальше по тексту.

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

Настройки DNS

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

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

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

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

В нашей небольшой сети WINS-сервер нам ни к чему, поэтому просто пропускаем эту настройку и едем дальше.

WINS-серверы

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

Активация области

Создаём нового пользователя в домене AD

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

Для этого возвращаемся на панель мониторинга, кликаем на «Средства» и затем на «Пользователи и Компьютеры Active Directory»

В открывшемся меню можно заметить созданный домен mydomain.com и его состав. Видно, что помимо пользователей в домене созданы папочки для Computers, Domain Controllers и других сущностей. Но нас сейчас интересуют пользователи, поэтому кликаем правой кнопкой мышки на папке Users и выбираем «Создать» -> «Пользователь»

После этого появляется диалоговое окно с преложением ввести данные нового пользователя. По старой доброй традиции назовём пользователя Foo Bar. Обратите внимание, что пользователь отображается лишь как «Объект» в Active Directory наравне с другими объектами.

Новый объект — Пользователь

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

Обычно администратор создаёт простой пароль для пользователя, а затем требует от пользователя сменить его при первом входе в систему (первая галочка в списке доступных опций). Это очень хорошая практика с точки зрения безопасности, ведь таким образом даже администратор AD не сможет узнать пароль пользователя. Также хорошей практикой считается ограничивать срок действия пароля. В этом туториале для простоты мы уберём требование о смене пароля пользователем при врходе в систему.

Параметры нового пользователя

После этого останется лишь подтвердить создание нового пользователя.

Подтверждение создания нового пользователя

Ну что ж, вот, кажется, и всё! Осталось лишь проверить ввод рабочей станции в домен.

Ввод рабочей станции в домен

Переключаемся на вторую машину workstation под управлением Windows 7 и заходим в свойства системы. Сейчас видно, что рабочая станция находится в рабочей группе (не в домене). Кстати говоря, WORKGROUP — это тоже NetBIOS-имя. Только в отличии от имени домена оно имеет суффикс 1E.

Щелкаем на кнопку «Изменить параметры», затем в появившемся окне ещё раз «Изменить…».

В окне изменения имени компьютера пишем, что он должен принадлежать домену mydomain.com.

Подключение к домену

Видим предупреждение о нестандартном имени компьютера (testo-ПК содержит кириллицу). Это связано с тем, что NetBIOS-имена не могут содеражать кириллицу. Но мы с вами настроили DNS-сервер (DNS настройки прилетели на рабочую станцию по DHCP), а DNS-механизм разрешения имён, как мы знаем, имеет приоритет перед NetBOIS. Так что в данном случае на работоспособность AD кириллица не влияет. Но на практике так делать не надо!

Нестандартное имя компьютера

Вводим логин-пароль от новой учетной записи FooBar и, наконец, видим заветное сообщение «Добро пожаловать в домен»

После ввода компьютера в домене необходимо перезагрузить компьютер, ну а дальше — вводим учётные данные пользователя в AD.

Логин в AD

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

Новые свойства системы

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

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

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

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

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

Секция скрипта на языке Testo-lang

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

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

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

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

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

Итоги

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

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

Источник

Настройка домена и групповых политик в Windows Server

Доменом в Windows Server называют отдельную область безопасности компьютерной сети.

В домене может быть один или несколько серверов выполняющих различные роли. Разрешения, применяемые администратором, распространяются на все компьютеры в домене.

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

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

Несколько доменов имеющих одну и ту же конфигурацию и глобальный каталог называют деревом доменов. Несколько деревьев могут быть объединены в лес.

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

Параметры групповой политики хранятся в виде объектов групповой политики (Group Policy Object, GPO). Эти объекты хранятся в каталоге подобно другим объектам. Различают два вида объектов групповой политики – объекты групповой политики, создаваемые в контексте службы каталога, и локальные объекты групповой политики.

Не будем подробно вдаваться в теорию и перейдем к практике.

Запускаем Диспетчер серверов -> «Добавить роли и компоненты».

На первой странице мастер напоминает, что необходимо сделать перед началом добавления роли на сервер. Нажмите «Далее».

На втором шаге нужно выбрать «Установка ролей и компонентов» и нажать «Далее».

Выбираем сервер, на который нужно установить Active Directory (он у нас один), «Далее».

Теперь нужно выбрать роль, которую нужно добавить. Выбираем «Доменные службы Active Directory». После чего откроется окно, в котором будет предложено установить службы ролей или компоненты, необходимые для установки роли Active Directory, нажмите кнопку «Добавить компоненты», после чего кликните «Далее».

PЗатем нажимайте «Далее», «Далее» и «Установить».

Перезапустите компьютер.

После того, как роль была добавлена на сервер, необходимо настроить доменную службу, то есть установить и настроить контроллер домена.

Настройка контроллера домена Windows Server

Запустите «Мастер настройки доменных служб Active Directory», для чего нажмите на иконку «Уведомления» в диспетчере сервера, затем нажмите «Повысить роль этого сервера до уровня контроллера домена».

Повысить роль этого сервера до уровня контроллера домена

Выберите пункт «Добавить новый лес», затем введите имя домена в поле «Имя корневого домена». Домены в сети Windows имеют аналогичные названия с доменами в интернете. Я ввел имя домена buzov.com. Нажимаем «Далее».

Добавление нового леса в контроллере домена Windows Server

На этом шаге можно изменить совместимость режима работы леса и корневого домена. Оставьте настройки по умолчанию. Задайте пароль для DSRM (Directory Service Restore Mode – режим восстановления службы каталога) и нажмите «Далее».

Затем нажимайте «Далее» несколько раз до процесса установки.

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

Добавление и настройка групп и пользователей в домене Windows Server

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

Отроем «Пользователи и компьютеры Active Directory». Для этого перейдите в Пуск –> Панель управления –> Система и безопасность –> Администрирование –> Пользователи и компьютеры Active Directory.

Создадим отдел «Бухгалтерия», для этого выделите название домена и вызовите контекстное меню, в котором выберите (Создать – Подразделение). Введите имя отдела (бухгалтерия) и нажмите «OK»

Подразделения служат для управления группами компьютеров пользователей. Как правило их именуют в соответствии с подразделениями организации.

Создайте учетную запись пользователя в новом подразделении. Для этого в контекстном меню нового подразделения выберите пункт Создать –> Пользователь. Пусть первым пользователем будет Бухгалтер.

Создание нового пользователя в подразделении домена

После ввода имени пользователя и учетной записи нажмите «Далее». Теперь нужно ввести пароль. По умолчанию пароль должен соответствовать требованиям сложности, то есть содержать три из четырех групп символов: заглавные буквы, строчные буквы, цифры, специальные знаки ( . , + – = ? № $ и так далее). Установите параметр «Требовать смену пароля при следующем входе в систему».

Создайте учетную запись группы безопасности. Для этого в контекстном меню нового подразделения (бухгалтерия) выберите пункт (Создать – Группа). При создании новой группы безопасности необходимо ввести имя, область действия и тип группы. Область действия определяет видимость данной группы в службе каталога. Глобальная группа видна в любом домене службы каталога и ей могут назначаться привилегии доступа к ресурсам других доменов. Локальная группа видна только в своем домене, то есть ей будут доступны ресурсы только ее домена. Группы безопасности позволяют
объединять пользователей и другие группы для назначения им одинаковых привилегий на различные объекты. Группы распространения используются для рассылки сообщений, они не участвуют в разграничении прав доступа.

Теперь нужно ввести компьютер в домен и зайти под новым пользователем. Для этого на клиентском компьютере нужно указать DNS-адрес. Для этого откройте «Свойства сетевого подключения» (Пуск –> Панель управления –> Сеть и Интернет – >Центр управления сетями и общим доступом – Изменение параметров адаптера), вызовите контекстное меню подключения и выберите «Свойства».

Выделите «Протокол Интернета версии 4 (TCP/IPv4)», нажмите кнопку «Свойства», выберите «Использовать следующие адреса DNS-серверов» и в поле «Предпочитаемый DNS-сервер» укажите адрес вашего DNS-сервера. Проверьте, что задан IP-адрес и маска той же подсети, в которой находится сервер.

Присоединение компьютера к домену

Откройте свойства системы (Пуск –> Панель управления –> Система и безопасность –> Система –> Дополнительные параметры системы). Выберите вкладку «Имя компьютера» и нажмите «Изменить». Выберите «Компьютер является членом домена» и введите имя домена.

После этого необходимо ввести логин и пароль пользователя с правами присоединения к домену (обычно администратора домена). Если вы всё указали правильно, то появиться приветственное сообщение «Добро пожаловать в домен …».

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

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

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

Вернемся на сервер. Нажмите «Пуск» -> Администрирование и перейдите в окно Управления групповой политикой. Выбираем наш лес, домен, Объекты групповой политики, щелкаем правой кнопкой мыши -> создать. Называем его buh (это объект групповой политики для группы Бухгалтерия).

Теперь необходимо привязать данный объект групповой политики к созданной группе. Для этого нажмите правой кнопкой на созданное подразделение (Бухгалтерия) и выберите «Связать существующий объект групповой политики…», затем выберите созданный ранее объект в списке и нажмите «ОК».

Связать существующий объект групповой политики

Далее выбираем созданный объект.

Выбранный объект должен появиться в списке связанных объектов групповой политики. Для редактирования параметров, определяемых данным объектом, нажмите на него правой кнопкой и выберите «Изменить».

Установка параметров безопасности

Установка параметров безопасности — завершающий этап настройка домена и групповых политик в Windows Server.

Ограничения парольной защиты

Ограничение на параметры парольной системы защиты задаются в контексте «Конфигурация компьютера». Выберите Конфигурация Windows –> Параметры безопасности –> Политики учетных записей –> Политика паролей.

Редактор управления групповыми политиками

В данном разделе объекта групповой политики определяются следующие параметры:

«Минимальный срок действия пароля» задает периодичность смены пароля.
«Минимальная длина пароля» определяет минимальное количество знаков пароля.
«Максимальный срок действия пароля» определяет интервал времени, через который разрешается менять пароль.
«Пароль должен отвечать требованиям сложности» определяет требования к составу групп знаков, которые должен включать пароль.
«Хранить пароли, используя обратимое шифрование» задает способ хранения пароля в базе данных учетных записей.
«Вести журнал паролей» определяет количество хранимых устаревших паролей пользователя.

Тут нужно указать необходимые параметры (определите самостоятельно).

Политика ограниченного использования программ

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

Выберите раздел Конфигурация пользователя –> Политики –> Конфигурация Windows –> Параметры безопасности –> Политики ограниченного использования программ. Нажмите правой кнопкой на «Политики ограниченного использования программ», далее заходим в «Дополнительные правила» и жмем правой кнопкой мыши, затем выбираем «Создать правило для пути».

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

Давайте запретим использовать командную строку на клиентском компьютере.

Запрет запуска командной строки (cmd.exe).

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

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

Источник

This room will introduce the basic concepts and functionality provided by Active Directory.

Introduction

Microsoft’s Active Directory is the backbone of the corporate world. It simplifies the management of devices and users within a corporate environment. In this room, we’ll take a deep dive into the essential components of Active Directory.

Room Objectives

In this room, we will learn about Active Directory and will become familiar with the following topics:

What Active Directory is
What an Active Directory Domain is
What components go into an Active Directory Domain
Forests and Domain Trust
And much more!

Room Prerequisites

General familiarity with Windows.

Windows Domains

Picture yourself administering a small business network with only five computers and five employees. In such a tiny network, you will probably be able to configure each computer separately without a problem. You will manually log into each computer, create users for whoever will use them, and make specific configurations for each employee’s accounts. If a user’s computer stops working, you will probably go to their place and fix the computer on-site.

While this sounds like a very relaxed lifestyle, let’s suppose your business suddenly grows and now has 157 computers and 320 different users located across four different offices. Would you still be able to manage each computer as a separate entity, manually configure policies for each of the users across the network and provide on-site support for everyone? The answer is most likely no.

To overcome these limitations, we can use a Windows domain. Simply put, a Windows domain is a group of users and computers under the administration of a given business. The main idea behind a domain is to centralise the administration of common components of a Windows computer network in a single repository called Active Directory (AD). The server that runs the Active Directory services is known as a Domain Controller (DC).

The main advantages of having a configured Windows domain are:

Centralised identity management: All users across the network can be configured from Active Directory with minimum effort.
Managing security policies: You can configure security policies directly from Active Directory and apply them to users and computers across the network as needed.

A Real-World Example

If this sounds a bit confusing, chances are that you have already interacted with a Windows domain at some point in your school, university or work.

In school/university networks, you will often be provided with a username and password that you can use on any of the computers available on campus. Your credentials are valid for all machines because whenever you input them on a machine, it will forward the authentication process back to the Active Directory, where your credentials will be checked. Thanks to Active Directory, your credentials don’t need to exist in each machine and are available throughout the network.

Active Directory is also the component that allows your school/university to restrict you from accessing the control panel on your school/university machines. Policies will usually be deployed throughout the network so that you don’t have administrative privileges over those computers.

Welcome to THM Inc.

During this task, we’ll assume the role of the new IT admin at THM Inc. As our first task, we have been asked to review the current domain “THM.local” and do some additional configurations. You will have administrative credentials over a pre-configured Domain Controller (DC) to do the tasks.

Be sure to click the Start Machine button now, as you’ll use the same machine for all tasks. This should open a machine in your browser. Should you prefer to connect to it via RDP, you can use the following credentials:

Username: Administrator
Password: Password321

Note: When connecting via RDP, use THM\Administrator as the username to specify you want to log in using the user Administrator on the THM domain.

In a Windows domain, credentials are stored in a centralised repository called… Active Directory

The server in charge of running the Active Directory services is called… Domain Controller

Active Directory

AD Objects

The core of any Windows Domain is the Active Directory Domain Service (AD DS). This service acts as a catalogue that holds the information of all of the “objects” that exist on your network. Amongst the many objects supported by AD, we have users, groups, machines, printers, shares and many others. Let’s look at some of them:

Users

Users are one of the most common object types in Active Directory. Users are one of the objects known as security principals, meaning that they can be authenticated by the domain and can be assigned privileges over resources like files or printers. You could say that a security principal is an object that can act upon resources in the network.

Users can be used to represent two types of entities:

People: users will generally represent persons in your organisation that need to access the network, like employees.
Services: you can also define users to be used by services like IIS or MSSQL. Every single service requires a user to run, but service users are different from regular users as they will only have the privileges needed to run their specific service.

Machines

Machines are another type of object within Active Directory; for every computer that joins the Active Directory domain, a machine object will be created. Machines are also considered “security principals” and are assigned an account just as any regular user. This account has somewhat limited rights within the domain itself.

The machine accounts themselves are local administrators on the assigned computer, they are generally not supposed to be accessed by anyone except the computer itself, but as with any other account, if you have the password, you can use it to log in.

Note: Machine Account passwords are automatically rotated out and are generally comprised of 120 random characters.

Identifying machine accounts is relatively easy. They follow a specific naming scheme. The machine account name is the computer’s name followed by a dollar sign. For example, a machine named DC01 will have a machine account called DC01$.

Security Groups

If you are familiar with Windows, you probably know that you can define user groups to assign access rights to files or other resources to entire groups instead of single users. This allows for better manageability as you can add users to an existing group, and they will automatically inherit all of the group’s privileges. Security groups are also considered security principals and, therefore, can have privileges over resources on the network.

Groups can have both users and machines as members. If needed, groups can include other groups as well.

Several groups are created by default in a domain that can be used to grant specific privileges to users. As an example, here are some of the most important groups in a domain:

Security Group	Description
Domain Admins	Users of this group have administrative privileges over the entire domain. By default, they can administer any computer on the domain, including the DCs.
Server Operators	Users in this group can administer Domain Controllers. They cannot change any administrative group memberships.
Backup Operators	Users in this group are allowed to access any file, ignoring their permissions. They are used to perform backups of data on computers.
Account Operators	Users in this group can create or modify other accounts in the domain.
Domain Users	Includes all existing user accounts in the domain.
Domain Computers	Includes all existing computers in the domain.
Domain Controllers	Includes all existing DCs on the domain.

You can obtain the complete list of default security groups from the Microsoft documentation.

Active Directory Users and Computers

To configure users, groups or machines in Active Directory, we need to log in to the Domain Controller and run “Active Directory Users and Computers” from the start menu:

This will open up a window where you can see the hierarchy of users, computers and groups that exist in the domain. These objects are organised in Organizational Units (OUs) which are container objects that allow you to classify users and machines. OUs are mainly used to define sets of users with similar policing requirements. The people in the Sales department of your organisation are likely to have a different set of policies applied than the people in IT, for example. Keep in mind that a user can only be a part of a single OU at a time.

Checking our machine, we can see that there is already an OU called THM with four child OUs for the IT, Management, Marketing and Sales departments. It is very typical to see the OUs mimic the business’ structure, as it allows for efficiently deploying baseline policies that apply to entire departments. Remember that while this would be the expected model most of the time, you can define OUs arbitrarily. Feel free to right-click the THM OU and create a new OU under it called Students just for the fun of it.

If you open any OUs, you can see the users they contain and perform simple tasks like creating, deleting or modifying them as needed. You can also reset passwords if needed (pretty useful for the helpdesk):

You probably noticed already that there are other default containers apart from the THM OU. These containers are created by Windows automatically and contain the following:

Builtin: Contains default groups available to any Windows host.
Computers: Any machine joining the network will be put here by default. You can move them if needed.
Domain Controllers: Default OU that contains the DCs in your network.
Users: Default users and groups that apply to a domain-wide context.
Managed Service Accounts: Holds accounts used by services in your Windows domain.

Security Groups vs OUs

You are probably wondering why we have both groups and OUs. While both are used to classify users and computers, their purposes are entirely different:

OUs are handy for applying policies to users and computers, which include specific configurations that pertain to sets of users depending on their particular role in the enterprise. Remember, a user can only be a member of a single OU at a time, as it wouldn’t make sense to try to apply two different sets of policies to a single user.
Security Groups, on the other hand, are used to grant permissions over resources. For example, you will use groups if you want to allow some users to access a shared folder or network printer. A user can be a part of many groups, which is needed to grant access to multiple resources.

Which group normally administrates all computers and resources in a domain? Domain Admins

What would be the name of the machine account associated with a machine named TOM-PC? TOM-PC$

Suppose our company creates a new department for Quality Assurance. What type of containers should we use to group all Quality Assurance users so that policies can be applied consistently to them? Organizational Units

Managing Users in AD

Your first task as the new domain administrator is to check the existing AD OUs and users, as some recent changes have happened to the business. You have been given the following organisational chart and are expected to make changes to the AD to match it:

Deleting extra OUs and users

The first thing you should notice is that there is an additional department OU in your current AD configuration that doesn’t appear in the chart. We’ve been told it was closed due to budget cuts and should be removed from the domain. If you try to right-click and delete the OU, you will get the following error:

By default, OUs are protected against accidental deletion. To delete the OU, we need to enable the Advanced Features in the View menu:

This will show you some additional containers and enable you to disable the accidental deletion protection. To do so, right-click the OU and go to Properties. You will find a checkbox in the Object tab to disable the protection:

Be sure to uncheck the box and try deleting the OU again. You will be prompted to confirm that you want to delete the OU, and as a result, any users, groups or OUs under it will also be deleted.

After deleting the extra OU, you should notice that for some of the departments, the users in the AD don’t match the ones in our organisational chart. Create and delete users as needed to match them.

Delegation

One of the nice things you can do in AD is to give specific users some control over some OUs. This process is known as delegation and allows you to grant users specific privileges to perform advanced tasks on OUs without needing a Domain Administrator to step in.

One of the most common use cases for this is granting IT support the privileges to reset other low-privilege users’ passwords. According to our organisational chart, Phillip is in charge of IT support, so we’d probably want to delegate the control of resetting passwords over the Sales, Marketing and Management OUs to him.

For this example, we will delegate control over the Sales OU to Phillip. To delegate control over an OU, you can right-click it and select Delegate Control:

This should open a new window where you will first be asked for the users to whom you want to delegate control:

Note: To avoid mistyping the user’s name, write “phillip” and click the Check Names button. Windows will autocomplete the user for you.

Click OK, and on the next step, select the following option:

Click next a couple of times, and now Phillip should be able to reset passwords for any user in the sales department. While you’d probably want to repeat these steps to delegate the password resets of the Marketing and Management departments, we’ll leave it here for this task. You are free to continue to configure the rest of the OUs if you so desire.

Now let’s use Phillip’s account to try and reset Sophie’s password. Here are Phillip’s credentials for you to log in via RDP:

Username: phillip
Password: Claire2008

While you may be tempted to go to Active Directory Users and Computers to try and test Phillip’s new powers, he doesn’t really have the privileges to open it, so you’ll have to use other methods to do password resets. In this case, we will be using Powershell to do so:






1
2
3
4
5



PS C:\Users\phillip> Set-ADAccountPassword sophie -Reset -NewPassword (Read-Host -AsSecureString -Prompt 'New Password') -Verbose

New Password: *********

VERBOSE: Performing the operation "Set-ADAccountPassword" on target "CN=Sophie,OU=Sales,OU=THM,DC=thm,DC=local".

Since we wouldn’t want Sophie to keep on using a password we know, we can also force a password reset at the next logon with the following command:






1
2
3



PS C:\Users\phillip> Set-ADUser -ChangePasswordAtLogon $true -Identity sophie -Verbose

VERBOSE: Performing the operation "Set" on target "CN=Sophie,OU=Sales,OU=THM,DC=thm,DC=local".

What was the flag found on Sophie’s desktop? THM{thanks_for_contacting_support}

The process of granting privileges to a user over some OU or other AD Object is called… delegation

Managing Computers in AD

By default, all the machines that join a domain (except for the DCs) will be put in the container called “Computers”. If we check our DC, we will see that some devices are already there:

We can see some servers, some laptops and some PCs corresponding to the users in our network. Having all of our devices there is not the best idea since it’s very likely that you want different policies for your servers and the machines that regular users use on a daily basis.

While there is no golden rule on how to organise your machines, an excellent starting point is segregating devices according to their use. In general, you’d expect to see devices divided into at least the three following categories:

1. Workstations

Workstations are one of the most common devices within an Active Directory domain. Each user in the domain will likely be logging into a workstation. This is the device they will use to do their work or normal browsing activities. These devices should never have a privileged user signed into them.

2. Servers

Servers are the second most common device within an Active Directory domain. Servers are generally used to provide services to users or other servers.

3. Domain Controllers

Domain Controllers are the third most common device within an Active Directory domain. Domain Controllers allow you to manage the Active Directory Domain. These devices are often deemed the most sensitive devices within the network as they contain hashed passwords for all user accounts within the environment.

Since we are tidying up our AD, let’s create two separate OUs for Workstations and Servers (Domain Controllers are already in an OU created by Windows). We will be creating them directly under the thm.local domain container. In the end, you should have the following OU structure:

Now, move the personal computers and laptops to the Workstations OU and the servers to the Servers OU from the Computers container. Doing so will allow us to configure policies for each OU later.

After organising the available computers, how many ended up in the Workstations OU? 7

Is it recommendable to create separate OUs for Servers and Workstations? (yay/nay) yay

Group Policies

So far, we have organised users and computers in OUs just for the sake of it, but the main idea behind this is to be able to deploy different policies for each OU individually. That way, we can push different configurations and security baselines to users depending on their department.

Windows manages such policies through Group Policy Objects (GPO). GPOs are simply a collection of settings that can be applied to OUs. GPOs can contain policies aimed at either users or computers, allowing you to set a baseline on specific machines and identities.

To configure GPOs, you can use the Group Policy Management tool, available from the start menu:

The first thing you will see when opening it is your complete OU hierarchy, as defined before. To configure Group Policies, you first create a GPO under Group Policy Objects and then link it to the GPO where you want the policies to apply. As an example, you can see there are some already existing GPOs in your machine:

We can see in the image above that 3 GPOs have been created. From those, the Default Domain Policy and RDP Policy are linked to the thm.local domain as a whole, and the Default Domain Controllers Policy is linked to the Domain Controllers OU only. Something important to have in mind is that any GPO will apply to the linked OU and any sub-OUs under it. For example, the Sales OU will still be affected by the Default Domain Policy.

Let’s examine the Default Domain Policy to see what’s inside a GPO. The first tab you’ll see when selecting a GPO shows its scope, which is where the GPO is linked in the AD. For the current policy, we can see that it has only been linked to the thm.local domain:

As you can see, you can also apply Security Filtering to GPOs so that they are only applied to specific users/computers under an OU. By default, they will apply to the Authenticated Users group, which includes all users/PCs.

The Settings tab includes the actual contents of the GPO and lets us know what specific configurations it applies. As stated before, each GPO has configurations that apply to computers only and configurations that apply to users only. In this case, the Default Domain Policy only contains Computer Configurations:

Feel free to explore the GPO and expand on the available items using the “show” links on the right side of each configuration. In this case, the Default Domain Policy indicates really basic configurations that should apply to most domains, including password and account lockout policies:

Since this GPO applies to the whole domain, any change to it would affect all computers. Let’s change the minimum password length policy to require users to have at least 10 characters in their passwords. To do this, right-click the GPO and select Edit:

This will open a new window where we can navigate and edit all the available configurations. To change the minimum password length, go to Computer Configurations -> Policies -> Windows Setting -> Security Settings -> Account Policies -> Password Policy and change the required policy value:

As you can see, plenty of policies can be established in a GPO. While explaining every single of them would be impossible in a single room, do feel free to explore a bit, as some of the policies are straightforward. If more information on any of the policies is needed, you can double-click them and read the Explain tab on each of them:

GPO distribution

GPOs are distributed to the network via a network share called SYSVOL, which is stored in the DC. All users in a domain should typically have access to this share over the network to sync their GPOs periodically. The SYSVOL share points by default to the C:\Windows\SYSVOL\sysvol\ directory on each of the DCs in our network.

Once a change has been made to any GPOs, it might take up to 2 hours for computers to catch up. If you want to force any particular computer to sync its GPOs immediately, you can always run the following command on the desired computer:






1



PS C:\> gpupdate /force

Creating some GPOs for THM Inc.

As part of our new job, we have been tasked with implementing some GPOs to allow us to:

Block non-IT users from accessing the Control Panel.
Make workstations and servers lock their screen automatically after 5 minutes of user inactivity to avoid people leaving their sessions exposed.

Let’s focus on each of those and define what policies we should enable in each GPO and where they should be linked.

Restrict Access to Control Panel

We want to restrict access to the Control Panel across all machines to only the users that are part of the IT department. Users of other departments shouldn’t be able to change the system’s preferences.

Let’s create a new GPO called Restrict Control Panel Access and open it for editing. Since we want this GPO to apply to specific users, we will look under User Configuration for the following policy:

Notice we have enabled the Prohibit Access to Control Panel and PC settings policy.

Once the GPO is configured, we will need to link it to all of the OUs corresponding to users who shouldn’t have access to the Control Panel of their PCs. In this case, we will link the Marketing, Management and Sales OUs by dragging the GPO to each of them:

Auto Lock Screen GPO

For the first GPO, regarding screen locking for workstations and servers, we could directly apply it over the Workstations, Servers and Domain Controllers OUs we created previously.

While this solution should work, an alternative consists of simply applying the GPO to the root domain, as we want the GPO to affect all of our computers. Since the Workstations, Servers and Domain Controllers OUs are all child OUs of the root domain, they will inherit its policies.

Note: You might notice that if our GPO is applied to the root domain, it will also be inherited by other OUs like Sales or Marketing. Since these OUs contain users only, any Computer Configuration in our GPO will be ignored by them.

Let’s create a new GPO, call it Auto Lock Screen, and edit it. The policy to achieve what we want is located in the following route:

We will set the inactivity limit to 5 minutes so that computers get locked automatically if any user leaves their session open. After closing the GPO editor, we will link the GPO to the root domain by dragging the GPO to it:

Once the GPOs have been applied to the correct OUs, we can log in as any users in either Marketing, Sales or Management for verification. For this task, let’s connect via RDP using Mark’s credentials:

If we try opening the Control Panel, we should get a message indicating this operation is denied by the administrator. You can also wait 5 minutes to check if the screen is automatically locked if you want.

Since we didn’t apply the control panel GPO on IT, you should still be able to log into the machine as any of those users and access the control panel.

Note: If you created and linked the GPOs, but for some reason, they still don’t work, remember you can run gpupdate /force to force GPOs to be updated.

What is the name of the network share used to distribute GPOs to domain machines? SYSVOL

Can a GPO be used to apply settings to users and computers? (yay/nay) yay

Authentication Methods

When using Windows domains, all credentials are stored in the Domain Controllers. Whenever a user tries to authenticate to a service using domain credentials, the service will need to ask the Domain Controller to verify if they are correct. Two protocols can be used for network authentication in windows domains:

Kerberos: Used by any recent version of Windows. This is the default protocol in any recent domain.
NetNTLM: Legacy authentication protocol kept for compatibility purposes.

While NetNTLM should be considered obsolete, most networks will have both protocols enabled. Let’s take a deeper look at how each of these protocols works.

Kerberos Authentication

Kerberos authentication is the default authentication protocol for any recent version of Windows. Users who log into a service using Kerberos will be assigned tickets. Think of tickets as proof of a previous authentication. Users with tickets can present them to a service to demonstrate they have already authenticated into the network before and are therefore enabled to use it.

When Kerberos is used for authentication, the following process happens:

The user sends their username and a timestamp encrypted using a key derived from their password to the Key Distribution Center (KDC), a service usually installed on the Domain Controller in charge of creating Kerberos tickets on the network.

The KDC will create and send back a Ticket Granting Ticket (TGT), which will allow the user to request additional tickets to access specific services. The need for a ticket to get more tickets may sound a bit weird, but it allows users to request service tickets without passing their credentials every time they want to connect to a service. Along with the TGT, a Session Key is given to the user, which they will need to generate the following requests.

Notice the TGT is encrypted using the krbtgt account’s password hash, and therefore the user can’t access its contents. It is essential to know that the encrypted TGT includes a copy of the Session Key as part of its contents, and the KDC has no need to store the Session Key as it can recover a copy by decrypting the TGT if needed.

When a user wants to connect to a service on the network like a share, website or database, they will use their TGT to ask the KDC for a Ticket Granting Service (TGS). TGS are tickets that allow connection only to the specific service they were created for. To request a TGS, the user will send their username and a timestamp encrypted using the Session Key, along with the TGT and a Service Principal Name (SPN), which indicates the service and server name we intend to access.

As a result, the KDC will send us a TGS along with a Service Session Key, which we will need to authenticate to the service we want to access. The TGS is encrypted using a key derived from the Service Owner Hash. The Service Owner is the user or machine account that the service runs under. The TGS contains a copy of the Service Session Key on its encrypted contents so that the Service Owner can access it by decrypting the TGS.

The TGS can then be sent to the desired service to authenticate and establish a connection. The service will use its configured account’s password hash to decrypt the TGS and validate the Service Session Key.

NetNTLM Authentication

NetNTLM works using a challenge-response mechanism. The entire process is as follows:

The client sends an authentication request to the server they want to access.
The server generates a random number and sends it as a challenge to the client.
The client combines their NTLM password hash with the challenge (and other known data) to generate a response to the challenge and sends it back to the server for verification.
The server forwards the challenge and the response to the Domain Controller for verification.
The domain controller uses the challenge to recalculate the response and compares it to the original response sent by the client. If they both match, the client is authenticated; otherwise, access is denied. The authentication result is sent back to the server.
The server forwards the authentication result to the client.

Note that the user’s password (or hash) is never transmitted through the network for security.

Note: The described process applies when using a domain account. If a local account is used, the server can verify the response to the challenge itself without requiring interaction with the domain controller since it has the password hash stored locally on its SAM.

Will a current version of Windows use NetNTLM as the preferred authentication protocol by default? (yay/nay) nay

When referring to Kerberos, what type of ticket allows us to request further tickets known as TGS? Ticket Granting Ticket

When using NetNTLM, is a user’s password transmitted over the network at any point? (yay/nay) nay

Trees, Forests and Trusts

So far, we have discussed how to manage a single domain, the role of a Domain Controller and how it joins computers, servers and users.

As companies grow, so do their networks. Having a single domain for a company is good enough to start, but in time some additional needs might push you into having more than one.

Trees

Imagine, for example, that suddenly your company expands to a new country. The new country has different laws and regulations that require you to update your GPOs to comply. In addition, you now have IT people in both countries, and each IT team needs to manage the resources that correspond to each country without interfering with the other team. While you could create a complex OU structure and use delegations to achieve this, having a huge AD structure might be hard to manage and prone to human errors.

Luckily for us, Active Directory supports integrating multiple domains so that you can partition your network into units that can be managed independently. If you have two domains that share the same namespace (thm.local in our example), those domains can be joined into a Tree.

If our thm.local domain was split into two subdomains for UK and US branches, you could build a tree with a root domain of thm.local and two subdomains called uk.thm.local and us.thm.local, each with its AD, computers and users:

This partitioned structure gives us better control over who can access what in the domain. The IT people from the UK will have their own DC that manages the UK resources only. For example, a UK user would not be able to manage US users. In that way, the Domain Administrators of each branch will have complete control over their respective DCs, but not other branches’ DCs. Policies can also be configured independently for each domain in the tree.

A new security group needs to be introduced when talking about trees and forests. The Enterprise Admins group will grant a user administrative privileges over all of an enterprise’s domains. Each domain would still have its Domain Admins with administrator privileges over their single domains and the Enterprise Admins who can control everything in the enterprise.

Forests

The domains you manage can also be configured in different namespaces. Suppose your company continues growing and eventually acquires another company called MHT Inc. When both companies merge, you will probably have different domain trees for each company, each managed by its own IT department. The union of several trees with different namespaces into the same network is known as a forest.

Trust Relationships

Having multiple domains organised in trees and forest allows you to have a nice compartmentalised network in terms of management and resources. But at a certain point, a user at THM UK might need to access a shared file in one of MHT ASIA servers. For this to happen, domains arranged in trees and forests are joined together by trust relationships.

In simple terms, having a trust relationship between domains allows you to authorise a user from domain THM UK to access resources from domain MHT EU.

The simplest trust relationship that can be established is a one-way trust relationship. In a one-way trust, if Domain AAA trusts Domain BBB, this means that a user on BBB can be authorised to access resources on AAA:

The direction of the one-way trust relationship is contrary to that of the access direction.

Two-way trust relationships can also be made to allow both domains to mutually authorise users from the other. By default, joining several domains under a tree or a forest will form a two-way trust relationship.

It is important to note that having a trust relationship between domains doesn’t automatically grant access to all resources on other domains. Once a trust relationship is established, you have the chance to authorise users across different domains, but it’s up to you what is actually authorised or not.

What is a group of Windows domains that share the same namespace called? Tree

What should be configured between two domains for a user in Domain A to access a resource in Domain B? A trust relationship

Conclusion

In this room, we have shown the basic components and concepts related to Active Directories and Windows Domains. Keep in mind that this room should only serve as an introduction to the basic concepts, as there’s quite a bit more to explore to implement a production-ready Active Directory environment.

If you are interested in learning how to secure an Active Directory installation, be sure to check out the Active Directory Hardening Room (To be released soon). If, on the other hand, you’d like to know how attackers can take advantage of common AD misconfigurations and other AD hacking techniques, the Compromising Active Directory module is the way to go.

Источник

Active Directory («Активный каталог», AD) — службы каталогов корпорации Microsoft для операционных систем Windows Server. Первоначально создавалась как LDAP-совместимая реализация службы каталогов, однако, начиная с Windows Server 2008, включает возможности интеграции с другими службами авторизации, выполняя для них интегрирующую и объединяющую роль. Позволяет администраторам использовать групповые политики для обеспечения единообразия настройки пользовательской рабочей среды, разворачивать программное обеспечение на множестве компьютеров через групповые политики или посредством System Center Configuration Manager (ранее — Microsoft Systems Management Server), устанавливать обновления операционной системы, прикладного и серверного программного обеспечения на всех компьютерах в сети, используя Службу обновления Windows Server. Хранит данные и настройки среды в централизованной базе данных. Сети Active Directory могут быть различного размера: от нескольких десятков до нескольких миллионов объектов.

Задача: Развернуть сервер с ролью контроллера домена на виртуальной машине.

Шаг 1 — Подготовка и требования к оборудованию

Основные минимальные требования к аппаратному и программному обеспечению:

Наличие хотя бы одного узла (аппаратного или виртуального) под управлением MS Windows Server
64-битный процессор с тактовой частотой не менее 1.4 Ггц
ОЗУ не менее 512 МБ
Системный диск не менее 40 ГБ

Тестовый стенд представляет из себя виртуальную машину под управлением MS Windows Server 2016 Standard, развернутую на сервере с ролью Hyper-V.

Шаг 2 — Установка и настройка контроллера домена

Необходимо зайти на сервер под учетной записью локального администратора. В связи с тем, что на сервер помимо роли Active Directory Domain Services будет установлена служба DNS, нам нужно изменить настройки сетевого интерфейса на ВМ, указав в поле первичного DNS сервера ip-адрес нашего шлюза по умолчанию.

Рисунок 1 – Настройка сетевого интерфейса

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

Рисунок 2 – Главная страница консоли диспетчера серверов

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

Рисунок 3 – Мастер добавления ролей и компонентов. Выбор типа установки

В данном окне выбираем наш сервер, на котором будет поднята роль Контроллера Домена и нажимаем Далее.

Рисунок 4 – Мастер добавления ролей и компонентов. Выбор целевого сервера

На данном этапе кликаем по чекбоксу с наименованием Доменные службы Active Directory.

Рисунок 5 – Мастер добавления ролей и компонентов. Выбор ролей сервера

В появившемся окне нажимаем на кнопку Добавить компоненты и пропускаем окна выбора компонентов и описания AD DS по нажатию кнопки Далее.

Рисунок 6 – Мастер добавления ролей и компонентов. Выбор служб ролей или компонентов

Прожимаем чекбокс в котором написано Автоматический перезапуск сервера, если потребуется и нажимаем на кнопку установить.

Рисунок 7 – Мастер добавления ролей и компонентов. Подтверждение установки компонентов

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

Рисунок 8 – Мастер добавления ролей и компонентов. Ход установки

В окне Мастер настройки доменных служб Active Directory Выбираем опцию Добавить новый лес и указываем имя корневого домена.

Рисунок 9 – Мастер настройки доменных служб Active Directory. Конфигурация

В пункте Параметры контроллера домена необходимо указать функциональный уровень домена и леса AD. Выбираем схему соответствующую редакции нашего сервера. Так как на данном сервере будет поднята роль DNS сервера нужно прожать следующие чекбоксы и указать пароль администратора для входа в DSRN режим.

Рисунок 10 – Мастер настройки доменных служб Active Directory. Параметры контроллера домена

Наш сервер будет первым DNS сервером в лесу, поэтому мы не настраиваем делегацию DNS. Нажимаем Далее.

Рисунок 11 – Мастер настройки доменных служб Active Directory. Параметры DNS

В следующем окне оставляем NETBIOS имя домена без изменений и нажимаем Далее.
Указываем расположение баз данных AD DS, файлов журналов и папки SYSVOL. После выбора нажимаем Далее.

Рисунок 12 – Мастер настройки доменных служб Active Directory. Пути

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

Рисунок 13 – Мастер настройки доменных служб Active Directory. Проверка предварительных требований

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

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

Источник

Active Directory (AD) was introduced in 1999, and understanding this core technology is a key requirement for most IT administrators today. In this part of the tutorial, we provide an overview of AD basics, including what an Active Directory domain is.

AD Fundamentals

What is AD?

Active Directory is the directory service used in Microsoft networks. A directory service (or name service) connects network resources (such as volumes, folders, files, printers, users, groups and devices) with their respective network addresses, and provides that information to entities in the network. In other words, AD is a set of databases and services that are used to organize, locate and manage network resources.

What does AD do?

The Active Directory database stores information about users and computers, including their names and access rights. The Active Directory schema defines the objects that can be stored in the directory.

Active Directory Domain Services (AD DS) controls many of the operations of your IT environment and helps ensure directory security by managing the following processes:

Authentication — Ensuring that each security principal is who they say they are, usually by verifying credentials such as a user ID and password during a logon process.
Authorization — Ensuring that each security principal can use only the data and services they are permitted to access.
Name resolution — Enabling clients and domain controllers to locate and communicate with each other. AD DS uses DNS as its main name resolution method.
Centralized management — Controlling a wide variety of settings from a single location via a feature called Group Policy.

What does AD include?

A fundamental unit of Active Directory is the domain. An AD domain is a logical group of objects that share common administration, security and replication settings. Using Active Directory domains, IT teams can define administrative boundaries and manage sets of devices, services and systems in a centralized manner.

A domain controller (DC) is a server that runs Active Directory Domain Services and uses data stored in AD for user authentication and authorization, group management, policy administration, and additional functions. In practice, organizations typically have multiple domain controllers in on-premises datacenters and/or in the cloud. Each DC in a domain maintains a copy of the AD database, and they synchronize data between themselves using Active Directory replication. DCs can also store the global catalog — a read-only registry of all objects in the domain’s directory and a partial copy of all objects in all other domains in the forest to facilitate searches for information about objects. A DC with this feature enabled is called a global catalog server. The primary access protocol for Active Directory is Lightweight Directory Access Protocol (LDAP).

How is AD managed?

Active Directory management can be performed on domain controllers via native tools, such as:

Active Directory Administrative Center
Active Directory Domains and Trusts
Active Directory Sites and Services
Active Directory Users and Computers
ADSI Edit
Active Directory module for Windows PowerShell

These tools can also be installed on workstations as part of Remote Server Administration Tools (RSAT) to enable admins to manage AD remotely.

AD Structure

Now that we have covered the basic concepts of AD, let’s review the Active Directory structure. Active Directory contains multiple logical units, organized hierarchically. From smallest to largest, they are:

Objects
Organizational units (OUs)
Domains
Trees
Forests

Objects

An Active Directory object is the smallest logical unit. Examples include:

User account
Computer account
Group
Printer
Share

Objects have one or more attributes that define their properties, limits and format. Attribute values can be multi-valued, strings, integers, Boolean (true or false), or other types. The attributes that each object has are specified in the schema.

Organizational units (OUs)

AD objects within a domain can be grouped into logical containers called organizational units (OUs). OUs are objects too, which allows administrators to create nested OUs. All objects in any given OU must have unique names, and each object can be in only one OU at any given time.

Be careful not to confuse OUs with AD groups. A group is a collection of AD objects, such as users, whose membership in the group grants them certain permissions. A given user can be (and usually is) a member of multiple groups. The confusion typically arises because Group Policy objects (GPOs) can be linked to OUs (but not to groups), which also affects what users, computers and other objects can and cannot do.

Domains

An Active Directory domain is a logical group of objects (users, computers, OUs and so on) that is managed by the same administrative team and is usually located on the same physical network.

Trees

Domains are organized into trees. An AD DS tree consists of multiple domains connected by two-way transitive trusts. Each domain in an AD DS tree shares a common schema and global catalog.

Forests

The Active Directory forest is the highest level of the hierarchy. While domains represent administrative boundaries, forests are the main security boundary for AD DS; it is assumed that all domain administrators within a forest are trusted to some degree. Objects in separate forests are not able to interact with each other unless the administrators of each of those forests create a trust between them.

Physical Structure

Let’s briefly touch on the physical structure of Active Directory. It can be divided into:

Hosts — Devices connected to the domain network
Subnets — Network groups with a specified range of IP addresses and a network mask
Sites — Groups of one or more subnets used to optimize bandwidth use by the DC replication service

Active Directory Services

Finally, Active Directory services consist of multiple directory services. We already talked about Active Directory Domain Services (AD DS). AD DS uses information about objects stored in the directory to authenticate users and authorize them to perform actions according to their access rights.

When people talk about Active Directory, they usually mean Active Directory Domain Services. However, there are other Active Directory services, including:

Active Directory Lightweight Directory Services (AD LDS) — Provides directory services for applications
Active Directory Certificate Services (AD CS) — Creates and maintains digital certificates used in security systems that use public key technologies
Active Directory Federation Services (AD FS) — Provides single sign-on (SSO) capabilities to systems and applications across organizational boundaries
Active Directory Rights Management Services (AD RMS) — Provides granular control over access to documents by providing management and development tools for working with insider threat prevention and other security technologies, such as encryption, certificates and authentication

For More Information

You can learn more about core Active Directory concepts by reading our eBook, What is Active Directory.

Jeff is a former Director of Global Solutions Engineering at Netwrix. He is a long-time Netwrix blogger, speaker, and presenter. In the Netwrix blog, Jeff shares lifehacks, tips and tricks that can dramatically improve your system administration experience.

Источник