Active directory доступ руководство

По мере роста сложности сетевых ресурсов службы каталогов становятся все более важными для управления ИТ-инфраструктурой. Нет службы каталогов с большим именем, чем Active Directory. Служба каталогов Microsoft была признана основным инструментом среди сетевых администраторов. В этом учебном руководстве по Active Directory мы рассмотрим, что такое Active Directory, как его использовать, а также такие инструменты Active Directory, как SolarWinds Access Rights Manager. Темы включают в себя:

• Что такое Active Directory?
• Что делает Active Directory?
• Как настроить Active Directory
• Как использовать Active Directory: настройка контроллера домена, создание пользователей каталога
• События Active Directory для мониторинга
• Доверительные отношения (и типы доверия)
• Обзор лесов и деревьев Active Directory
• Отчеты Active Directory (с помощью диспетчера прав доступа SolarWinds)

Contents

• 1 Что такое Active Directory? 
• 2 Что делает Active Directory? 
• 3 Как настроить Active Directory (с помощью RSAT) 
• 4 Как использовать Active Directory: как настроить контроллер домена, создать пользователей каталога 
• 5 События Active Directory для мониторинга 
• 6 Обзор лесов и деревьев Active Directory 
• 7 Доверительные отношения (и типы доверия) 
• 8 Отчеты Active Directory с помощью диспетчера прав доступа SolarWinds (БЕСПЛАТНАЯ пробная версия)
• 9 Учебник Active Directory: основы 

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

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

Что делает Active Directory? 

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

Как настроить Active Directory (с помощью RSAT) 

Для начала вам нужно сначала убедиться, что у вас есть Windows Professional или Windows Enterprise установлен, иначе вы не сможете установить Инструменты удаленного администрирования сервера. Затем сделайте следующее:

Для Windows 10 версии 1809:

1. Щелкните правой кнопкой мыши на Начало Кнопка и перейти к настройки > Программы > Управление дополнительными функциями > Добавить функцию.
2. Теперь выберите RSAT: доменные службы Active Directory и облегченные инструменты каталогов.
3. Наконец, выберите устанавливать затем перейдите к Начало > Средства администрирования Windows получить доступ к Active Directory после завершения установки.

Для Windows 8 (и Windows 10 версии 1803) 

1. Загрузите и установите правильную версию средств администрирования сервера для вашего устройства: Windows 8, Windows 10.
2. Затем щелкните правой кнопкой мыши Начало кнопку и выберите Панель управления > программы > Программы и особенности > Включить или отключить функции Windows.
3. Сдвиньте вниз и нажмите на Инструменты удаленного администрирования сервера вариант.
4. Теперь нажмите на Инструменты администрирования ролей.
5. Нажмите на Инструменты AD DS и AD LDS и проверить Инструменты AD DS был проверен.
6. Нажмите Ok.
7. Перейти к Начало > Инструменты управления на Начало меню для доступа к Active Directory.

Как использовать Active Directory: как настроить контроллер домена, создать пользователей каталога 

Как настроить контроллер домена

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

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

Процесс настройки контроллера домена относительно прост. Назначьте статический IP-адрес вашему контроллеру домена и установить доменные службы Active Directory или ADDS. Теперь следуйте этим инструкциям:

1. открыто Диспетчер серверов и нажмите Резюме ролей > Добавить роли и функции.
2. щелчок следующий.
3. Выбрать Службы удаленных рабочих столов установка если вы развертываете контроллер домена на виртуальной машине или выберите установка на основе ролей или функций.
4. Выберите сервер из пул серверов.
5. Выбрать Доменная служба Active Directorys из списка и нажмите следующий.
6. Оставьте Функции отмеченными по умолчанию и нажмите следующий.
7. щелчок Перезапустите целевой сервер автоматически, если требуется и нажмите устанавливать. Закройте окно после завершения установки.
8. Как только роль ADDS будет установлена, рядом с управлять меню. Нажмите Продвинуть этот сервер в контроллер домена.
9. Теперь нажмите Добавить новый лес и введите Корневое доменное имя. Нажмите следующий.
10. Выберите Функциональный уровень домена Вы хотите и введите пароль в Введите режим восстановления служб каталогов (пароль DSRM) раздел. щелчок следующий.
11. Когда откроется страница параметров DNS, нажмите следующий опять таки.
12. Введите домен в NetBios доменное имя поле (желательно совпадает с именем корневого домена). Нажмите следующий.
13. Выберите папку для хранения базы данных и файлов журнала. щелчок следующий.
14. Нажмите устанавливать заканчивать. Ваша система теперь перезагрузится.

Создание пользователей Active Directory

пользователей и компьютеры это два самых основных объекта, которыми вы должны будете управлять при использовании Active Directory. В этом разделе мы рассмотрим, как создавать новые учетные записи пользователей. Процесс относительно прост, и самый простой способ управлять пользователями через Active Directory — пользователи и компьютер или инструмент ADUC, который поставляется с Инструменты удаленного администрирования сервера или RSAT пакет. Вы можете установить ADUC, следуя приведенным ниже инструкциям:

Установите ADUC в Windows 10 версии 1809 и выше:

1. Щелкните правой кнопкой мыши на Начало кнопка и нажмите настройки > Программы, затем нажмите Управление дополнительными функциями > Добавить функцию.
2. Выбрать RSAT: доменные службы Active Directory и облегченные инструменты каталогов.
3. Выбрать устанавливать и дождитесь завершения установки.
4. Перейти к Начало > Средства администрирования Windows чтобы получить доступ к функции.

Установите ADUC в Windows 8 и Windows 10 версии 1803 или ниже: 

1. Загрузите и установите средства удаленного администрирования сервера для вашей версии Windows. Вы можете сделать это по одной из этих ссылок здесь:
   Средства удаленного администрирования сервера для Windows 10, Средства удаленного администрирования сервера для Windows 8 или Средства удаленного администрирования сервера для Windows 8.1.

1. Щелкните правой кнопкой мыши на Начало > Панель управления > программы > Программы и особенности > Включить или отключить функции Windows.
2. Прокрутите вниз и выберите Инструменты удаленного администрирования сервера.
3. расширять Инструменты администратора ролей > Инструменты AD DS и AD LDS.
4. Проверьте Инструменты AD DS и нажмите Ok.
5. Перейти к Начало > Инструменты управления и выберите Active Directory — пользователи и компьютеры.

Как создать новых пользователей с ADUC 

1. Открой Диспетчер серверов, перейти к инструменты меню и выберите Active Directory — пользователи и компьютеры.
2. Разверните домен и нажмите пользователей.
3. Щелкните правой кнопкой мыши на правой панели и нажмите новый > пользователь.
4. Когда появится окно New Object-User, введите Имя, Фамилия, Имя пользователя и нажмите следующий.
5. Введите пароль и нажмите следующий.
6. щелчок Конец.
7. Новая учетная запись пользователя может быть найдена в пользователей раздел ADUC.

События Active Directory для мониторинга 

Как и все виды инфраструктуры, Active Directory необходимо отслеживать, чтобы оставаться защищенным. Мониторинг службы каталогов имеет важное значение для предотвращения кибератак и обеспечения наилучшего взаимодействия с конечным пользователем..

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

Текущее событие Windows IDLegacy Описание события Windows ID

4618	N / A	Шаблон событий безопасности был распознан.
4649	N / A	Обнаружена повторная атака (возможно, ложноположительный).
4719	612	Политика системного аудита была изменена.
4765	N / A	История SID добавлена ​​в аккаунт.
4766	N / A	Не удалось добавить историю SID в учетную запись.
4794	N / A	Попытка запустить режим восстановления служб каталогов.
4897	801	Разделение ролей включено.
4964	N / A	Специальным группам был назначен новый вход.
5124	N / A	Безопасность обновлена ​​в службе ответов OCSP.
N / A	550	Потенциальная DoS-атака.
+1102	517	Журнал аудита был очищен.

Обзор лесов и деревьев Active Directory 

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

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

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

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

Доверительные отношения (и типы доверия) 

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

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

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

Типы доверия 

Существует несколько типов доверия в Active Directory. Мы перечислили их в таблице ниже:

Trust TypeTransit TypeDirectionDefault? Описание

Родитель и ребенок	переходный	Двусторонний	да	Родительское и дочернее доверие устанавливается при добавлении дочернего домена в дерево доменов..
Дерево-корень	переходный	Двусторонний	да	Доверие к корню дерева устанавливается в момент создания дерева домена в лесу.
внешний	Нетранзитивных	Односторонний или двусторонний	нет	Предоставляет доступ к ресурсам в домене Windows NT 4.0 или домене, расположенном в другом лесу, который не поддерживается доверием леса.
область	Транзитивный или нетранзитивный	Односторонний или двусторонний	нет	Формирует доверительные отношения между областью Kerberos, отличной от Windows, и доменом Windows Server 2003.
лес	переходный	Односторонний или двусторонний	нет	Делит ресурсы между лесами.
кратчайший путь	переходный	Односторонний или двусторонний	нет	Сокращает время входа пользователей между двумя доменами в лесу Windows Server 2003.

Отчеты Active Directory с помощью диспетчера прав доступа SolarWinds (БЕСПЛАТНАЯ пробная версия)

Генерация отчетов в Active Directory необходима для оптимизации производительности и обеспечения соответствия нормативным требованиям. Одним из лучших инструментов отчетности Active Directory является SolarWinds Access Rights Manager (ARM). Инструмент был создан, чтобы повысить наглядность того, как используются и управляются учетные данные каталога. Например, вы можете просматривать учетные записи с небезопасными конфигурациями и злоупотреблениями учетными данными, которые могут указывать на кибератаку.

Использование стороннего инструмента, такого как SolarWinds Access Rights Manager это выгодно, потому что предоставляет вам информацию и функции, к которым было бы гораздо сложнее или невозможно получить доступ напрямую через Active Directory.

Помимо создания отчетов вы можете автоматически удалять неактивные или просроченные аккаунты что цель киберпреступников. SolarWinds Access Rights Manager начинается с 3444 долларов (2829 фунтов). Также есть 30-дневная бесплатная пробная версия версия, которую вы можете скачать.

SolarWinds Access Rights ManagerЗагрузить 30-дневную бесплатную пробную версию

Учебник Active Directory: основы 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое Active Directory

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

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

Начинаем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DNS-сервер

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

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

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

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

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

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

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

DHCP-сервер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ping comp2.mydomain.com

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

ping comp2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итоги

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

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

Одно из важнейших достоинств Active Directory (AD) состоит в том, что в этом каталоге администраторы могут делегировать разрешения другим пользователям с желаемой степенью детализации. Реализованная в AD модель делегирования разрешений в сфере безопасности позволяет предоставлять разрешения на выполнение рутинных задач — таких, как изменение пароля, разблокирование учетной записи или даже создание объектов и управление ими — обычным пользователям, которых по такому случаю необязательно наделять правами администратора каталога. В состав оснастки Active Directory Users and Computers (ADUC) консоли управления Microsoft Management Console (MMC) входит мастер, облегчающий решение ряда типичных задач, но он годится не на все случаи жизни. .

Все о списках управления доступом

Список управления доступом (ACL) сопоставляется со всеми объектами каталога и управляет средствами защиты каждого из них. Список управления доступом, известный также как дескриптор безопасности, хранится в формате двоичных данных в атрибуте nTSecurityDescriptor соответствующего объекта. Начиная с версии Windows Server 2003, для хранения в базе данных AD списков управления доступом в структуре AD предусмотрен внутренний механизм, обеспечивающий хранение одного экземпляра каждого списка. Этого вполне достаточно, поскольку почти все объекты каталога совместно используют общий набор списков ACL. Фактический объем данных ACL довольно велик, и при сведении числа копий к одной обеспечивается существенная экономия дискового пространства.

Списки ACL состоят из двух компонентов: разграничительный список ACL (Discretionary ACL, DACL) и системный список ACL (System ACL, SACL). Компонент SACL используется в случаях, когда для соответствующего объекта проводится аудит безопасности (скажем, когда объект модифицируется). Оба компонента включают в себя ряд записей управления доступом access control entries (ACE), которые представляют фактические разрешения доступа в данном ACL. В дальнейшем при упоминании термина ACL мы будем иметь в виду компонент DACL.

Чтобы просмотреть компонент ACL с использованием оснастки ADUC, нужно прежде всего активировать в консоли режим просмотра Advanced Features; для этого следует выбрать пункт View, а затем Advanced Features. Теперь правой кнопкой мыши щелкните на одном из объектов, откройте вкладку Properties и перейдите на вкладку Security, показанную на экране 1. Вы увидите, что пользовательский интерфейс оснастки и интерфейс, используемый при управлении системными разрешениями, в общих чертах одинаковые, просто в первом случае назначаются одни разрешения доступа, а во втором — другие. Более подробно структура ACL описана во врезке «Внутри абстракций ACL».

Подобно разрешениям в файловой системе, разрешения в каталоге AD наследуются объектами-потомками, если пользователь не дает каталогу инструкцию отменить такое наследование. Благодаря этому обстоятельству процедура предоставления администратору разрешений на выполнение той или иной операции (скажем, изменения пароля) во всех объектах заданной организационной единицы organizational unit (OU) или в иерархии OU выполняется очень легко. Если бы такой функции не было, нам приходилось бы предоставлять разрешения каждому пользователю в индивидуальном порядке.

Для применения унаследованных разрешений к дочерним объектам в AD используется внутренний фоновый процесс, именуемый распространителем дескрипторов безопасности Security Descriptor Propagator (SDProp). В очень больших сетях унаследованные разрешения обычно применяются с некоторой задержкой. Кстати, если в AD вам попадался атрибут dSCorePropagationData и вы задавались вопросом, для чего он нужен, имейте в виду, что данный атрибут используется с целью хранения информации о состоянии процесса SDProp.

Что делегировать

На высоком уровне имеется ограниченный набор операций, разрешения на выполнение которых могут быть делегированы, причем их можно применять как для всех классов объектов, так и для отдельного класса, например для класса users. Если вы незнакомы с основными принципами функционирования схемы AD, рекомендую прочитать статью «Расширяем схему Active Directory» (опубликованную в Windows IT Pro/RE № 1 за 2011 год), поскольку ниже мы будем использовать некоторые термины из этой статьи. Метод делегирования разрешений доступа можно применять для предоставления разрешений пользователям или группам. С функциональной точки зрения нет ничего дурного в том, чтобы делегировать разрешения непосредственно пользователям, однако в любом случае будет правильнее делегировать разрешения группе, а затем уже включать в эту группу тех или иных пользователей. В этом случае вы сможете управлять разрешениями пользователей, вводя или выводя их из состава соответствующих групп. Решать подобную задачу гораздо проще, чем управлять разрешениями.

Самое типичное полномочие из тех, что вам предстоит предоставлять, это, пожалуй, разрешение на запись в том или ином атрибуте либо в наборе атрибутов. Если, к примеру, вы намереваетесь предоставить кому-то разрешение отменять блокировку учетных записей пользователей, вы предоставите этому лицу разрешение записи (Write Property) в атрибуте lockoutTime.

Некоторые операции, сводящиеся на первый взгляд к предоставлению разрешения Write Property на один-два атрибута, фактически предполагают делегирование одного или нескольких расширенных разрешений. Два расширенных разрешения, с которыми вам придется сталкиваться чаще всего, — это разрешения Reset Password и Change Password. В случае поступления через стандартные интерфейсы прикладного программирования запроса на выполнение той или иной операции, AD и другие приложения могут выяснять, имеются ли разрешения на пользование расширенными разрешениями, причем приложения могут даже определять в каталоге специализированные расширенные разрешения. Если в вашей сети развернута система Microsoft Exchange Server, вы обнаружите, что в ней предусмотрен целый ряд расширенных разрешений, таких как Send-As и Receive-As.

Если присмотреться к компоненту ACL в учетной записи пользователя (подобному на экране 1), можно увидеть, что участнику безопасности SELF делегировано расширенное разрешение Change Password. Кроме того, вы заметите, что этому участнику делегировано разрешение вводить ряд дополнительных записей, таких как Personal Information. Personal Information — пример объекта Property Set, коллекции атрибутов, сведенных вместе. Этот объект позволяет предоставлять разрешения не на уровне индивидуальных атрибутов, а на уровне всего их набора. AD допускает включение каждого атрибута в один набор Property Set. Достоинство этого набора состоит в том, что администратору нет нужды создавать индивидуальные записи управления доступом с целью предоставления разрешений на чтение или запись в большое количество атрибутов; он может выполнить одну-единственную процедуру делегирования для всего набора Property Set, и необходимые разрешения будут предоставлены всем входящим в этот набор атрибутам.

Экран 1. Редактор ACL оснастки Active Directory Users and Computers

В упомянутом выше примере делегирование разрешений для участника безопасности SELF дает пользователю возможность вводить данные в ряд атрибутов, указанных в его учетной записи. Администраторы многих организаций отзовут эти разрешения в связи с нежеланием подвергать сеть опасности в случае обновления пользователями тех данных, которые управляются через центральную систему. К счастью, пользователи редко доходят до понимания того, как вносятся изменения в упомянутые атрибуты. Для этого им пришлось бы воспользоваться редактором LDAP или другой подобной программой.

Если вас интересует, какие атрибуты включаются в набор Property Set, вы можете получить ответ на этот вопрос с помощью инструмента, поставляемого со службой Active Directory Lightweight Directory Service (AD LDS). На системе, где установлены средства удаленного администрирования сервера Remote Server Administration Tools (RSAT) системы Windows Server 2008 или более новой версии и активированы средства доменных служб Active Directory (AD DS), а также служб Active Directory облегченного доступа к каталогам (AD LDS), перейдите в каталог C:WindowsADAM и запустите программу ADSchemaAnalyzer.exe. После этого откройте меню File, выберите пункт Load Target Schema, укажите один из контроллеров домена (DC) в своем лесу и введите действительные учетные данные пользователя. Анализатор схемы Active Directory загрузит схему AD и отобразит ее в графическом представлении, так что вы сможете уяснить отношения между классами, атрибутами и наборами свойств (экран 2). Атрибуты каждого набора свойств перечислены в контейнере Dependents.

Экран 2. Атрибуты набора свойств, отображаемые анализатором схемы Active Directory

Еще одна типичная задача, разрешения на выполнение которой вы, вероятно, захотите делегировать, — задача формирования определенного набора объектов, скажем, чтобы сотрудники службы поддержки могли создавать объекты user. Делегировать такие разрешения в высшей степени просто; однако важно при этом тщательно проанализировать некоторые скрытые последствия для системы безопасности в связи с предоставлением пользователям разрешения создавать объекты. В момент создания объекта создавшему его пользователю в одном из полей ACL присваивается статус владельца данного объекта. Владелец объекта имеет над ним полный контроль и может обойти ограничения, содержащиеся в детализированных разрешениях, полученных этим владельцем на доступ к объекту. Вот наглядный пример того, как делегирование разрешения на создание объектов создает для администратора неожиданные проблемы. Допустим, вы делегировали пользователю разрешение на создание организационных единиц (OU) и сверх того — разрешение на создание учетных записей пользователей внутри этих OU. Поскольку упомянутый пользователь имеет полный контроль над созданными им OU, он может создавать внутри них объекты любых типов, скажем компьютеры или группы. После того как ваш домен будет переведен в режим работы Windows Server 2008 Domain Functional Level (DFL) 3 или более современный, вы сможете решить эту проблему с помощью средств Owner Access Rights.

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

Разрешения Password Reset и Account Unlock

Одна из задач, разрешения на выполнение которых часто делегируются (как правило, сотрудникам службы поддержки либо службы поддержки), — это переустановка паролей пользователей в случаях, когда последние их забывают, и снятие блокировки учетных записей этих пользователей. Здесь нужно осуществить несколько процедур делегирования: делегировать разрешение на использование расширенного разрешения Reset Password, а также разрешение Write Property для атрибутов pwdLastSet и lockoutTime.

В атрибуте pwdLastSet хранится метка времени, указывающая на момент, когда пароль пользователя устанавливался в последний раз; она нужна для того, чтобы служба AD могла отменить пароль по истечении срока его действия. В атрибуте lockoutTime хранятся сведения о том, в какое время учетная запись пользователя была отключена. Когда вы выставляете флажок с указанием пользователю сменить пароль при следующей процедуре регистрации в системе, вы фактически устанавливаете значение pwdLastSet равным 0. Подобным же образом, когда вы устанавливаете флажок разблокирования учетной записи в оснастке ADUC, вы фактически устанавливаете значение параметра lockoutTime равным 0.

Далее на протяжении всей статьи мы будем выполнять операции делегирования, о которых пойдет речь, с использованием редактора ACL в оснастке ADUC. Часть задач, выполняемых средствами этого редактора, можно решать и с помощью мастера Delegate Control Wizard оснастки ADUC. Но если действовать без дополнительных ухищрений только с помощью редактора ACL, мы получим гораздо более полное представление о вносимых изменениях. Если вы следуете предлагаемым мной инструкциям, используя версию ADUC, которая была выпущена до появления системы Windows Server 2008 R2, отдельные надписи на экранах и ряд этапов процесса будут несколько отличаться от описываемых мной. При работе со старыми версиями AD вы можете смело использовать более новые версии ADUC и других средств удаленного администрирования сервера.

В рамках данной статьи мы будем исходить из того, что вам предстоит делегировать членам группы Service Desk Users разрешения на переустановку паролей всех пользователей, входящих в организационную единицу People OU. Для решения этой задачи выполните следующие действия.

1. В окне оснастки ADUC откройте вкладку Properties организационной единицы People, перейдите на вкладку Security и щелкните на элементе Advanced.
2. Нажмите кнопки Add и Find Service Desk Users.
3. На вкладке Object выберите параметр Apply onto Descendant User objects.
4. На вкладке Allow for the Reset Password permission выставьте флажок Allow for the Reset Password permission.
5. На вкладке Properties выберите настройку Apply onto Descendant User objects.
6. На вкладке Properties выберите настройку Allow for Write lockoutTime and for Write pwdLastSet.
7. Нажмите кнопку ОК.
8. Зарегистрируйтесь в системе с учетной записью члена группы Service Desk Users и убедитесь, что у вас имеются разрешения на переустановку пароля пользователя, входящего в организационную единицу People.

Вы увидите три дополнительные записи управления доступом, представленные на экране 3. Редактор ACL оснастки ADUC позволяет с легкостью предоставлять несколько разрешений одновременно — даже в ситуациях, когда для делегирования таких разрешений необходимо использовать несколько записей управления доступом. Если бы вы выполняли описанные выше действия с помощью программы редактирования с минимумом необходимых функций, такой как LDP, вам пришлось бы создавать три индивидуальные записи управления доступом: одну для осуществления операции Reset Password, другую для операции Write Property pwdLastSet и третью — для операции Write Property lockoutTime.

Экран 3. Заполнение списка ACL после предоставления разрешений Password Reset и Unlock Account

Добавление компьютеров в домен

Еще одна типичная задача — делегирование группе пользователей разрешений по включению компьютеров в домен. Служба AD позволяет любому прошедшему процедуру аутентификации пользователю в любое время без предварительной подготовки добавлять в домен до десяти систем. Разработчики AD реализовали это ограничение с помощью функции, известной как «квоты на объекты». Она дает администратору возможность определять число объектов определенного типа, которые пользователь может иметь в каталоге в любой момент времени. AD определяет, сколько объектов входит в квоту того или иного пользователя, на основании сведений о принадлежности, которые хранятся в списке ACL наряду с компонентами DACL и SACL.

Вы можете предоставить другому лицу (возможно, младшему администратору) разрешение добавлять в домен неограниченное число компьютеров. Задача решается двумя способами. Первый способ — воспользоваться унаследованным от прежних систем разрешением NT Security Privilege (SeMachineAccount­Privilege); обладающий им пользователь может добавлять компьютеры в домен. Это разрешение предоставляется на контроллерах доменов через групповую политику и включается в маркер безопасности пользователя, когда тот регистрируется в системе. Если вы просто хотите дать пользователям возможность добавлять системы в контейнер Computers, эта задача, по-видимому, легче всего решается посредством предоставления рассматриваемого разрешения с помощью групповой политики. Чтобы предоставить это разрешение пользователям группы Service Desk Users через групповую политику, выполните следующие действия.

1. Запустите консоль Group Policy Management Console. Для этого нужно открыть меню Start, выбрать пункт Run и ввести имя gpmc.msc.
2. Правой кнопкой мыши щелкните на элементе Default Domain Controller Policy и в открывшемся меню выберите пункт Edit.
3. Перейдите в папку PoliciesWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assign­ment.
4. Откройте запись Add Workstations to Domain.
5. Добавьте пользователей службы техподдержки (Service Desk Users), как показано на экране 4.
6. Если вы хотите лишить того или иного пользователя возможности добавлять рабочие станции в домен, удалите Authenticated Users.

Экран 4. Делегирование разрешений Add Workstations to Domain

Если вместо этого вы хотите определить, к каким организационным единицам может быть присоединен тот или иной компьютер, вам придется воспользоваться собственными списками ACL каталога Active Directory, подобными тем, что упоминались в предыдущей пошаговой инструкции. В данном примере мы делегируем группе Service Desk Users разрешения по присоединению компьютеров к организационной единице Desktops, а кроме того, предоставляем членам этой группы возможность менять пароли учетных записей машин на тот случай, если у них возникнет необходимость вновь ввести ту или иную систему в состав домена. С целью выполнения этих задач мы делегируем группе Service Desk Users разрешение создавать объекты computer в организационной единице Desktops, а затем предоставим членам этой группы разрешение Reset Password, а также разрешение Write to pwdLastSet применительно к объектам computer.

Атрибуты и разрешения, доступные в редакторе ADUC ACL Editor, загружаются не из каталога, а из файла dssec.dat на локальной системе. Один из атрибутов, который вам придется модифицировать в процессе выполнения указанной задачи, по умолчанию не указывается в файле dssec.dat. Чтобы редактировать файл dssec.dat, выполните следующие действия на компьютере, где выполняется оснастка ADUC.

1. Откройте окно командной строки с повышенными привилегиями и перейдите в каталог %windir%system32.
2. В окне командной строки с повышенными привилегиями откройте файл dssec.dat в редакторе notepad.
3. Найдите в этом файле раздел computer.
4. В разделе computer найдите строку pwdLastSet=7 и придайте ей вид pwdLastSet=0.
5. Перезагрузите оснастку ADUC.

Для предоставления указанных разрешений выполните следующие действия.

1. В окне ADUC откройте свойства организационной единицы Desktops, перейдите на вкладку Security и выберите элемент Advanced.
2. Нажмите кнопку Add и щелкните на пункте Find Service Desk Users.
3. На вкладке Object выберите параметр Apply to This object only. Отметим, что, если в вашей сети в организационной единице Desktops имеются другие организационные единицы, стоит настроить программу таким образом, чтобы присоединяемые к домену компьютеры вместо этого указывали на объекты «организационная единица».
4. Переключатель Allow установите в положение Create Computer objects.
5. Нажмите ОК.
6. Нажмите кнопку Add и еще раз щелкните на пункте Find Service Desk Users.
7. Выберите элемент Apply to Descendant Computer objects.
8. Для разрешения Reset Password укажите параметр Allow.
9. На вкладке Properties выберите настройку Apply to Computer objects.
10. Щелкните на пункте Allow for Write pwdLastSet.
11. Нажмите кнопку ОК.

Теперь нужно выяснить, каков результат процедуры делегирования разрешений. Попытайтесь присоединить тестовый компьютер к домену с использованием учетной записи пользователя, входящего в группу Service Desk Users. Задачу включения компьютера в состав домена с указанием, в какую организационную единицу он будет при этом входить, можно решить двумя способами. Первый метод состоит в том, чтобы заранее создать учетную запись компьютера с помощью оснастки ADUC. Запустите оснастку и щелкните правой кнопкой мыши внутри организационной единицы Desktops, затем нажмите кнопку New и выберите элемент Computer. Укажите имя компьютера и предоставьте членам группы Service Desk Users разрешения на присоединение системы к домену, как показано на экране 5.

Экран 5. Диалоговое окно New Computer

Второй метод предусматривает добавление системы к домену с помощью средства командной строки netdom; имя надлежащей организационной единицы указывается при этом в качестве составной части команды. Чтобы включить систему TEST-PC02 в состав организационной единицы Desktops, расположенной в корневом каталоге домена contoso.com, введите следующую команду:

netdom add test-pc02/domain: contoso
   . com/userd:"contosojohn.doe"
   /passwordd:*/OU:"ou=desktops, dc
   =contoso, dc=com"

Вы получите приглашение ввести пароль для учетной записи John.Doe. Если вы хотите использовать смарт-карту, добавьте переключатель /Secure-PasswordPrompt.

Сначала упражнения

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

Брайан Десмонд (brian@briandesmond.com) — старший консультант компании Moran Technology Consulting (Чикаго). Имеет сертификат Directory Services MVP, ведет блог www.briandesmond.com