active directory с нуля обучение
Разворачиваем Active Directory всеми возможными методами
Одним из реально полезных нововведений в Windows Server 2019 является возможность вводить серверы, не делая Sysprep или чистую установку. Развернуть инфраструктуру на виртуальных серверах с Windows Server никогда еще не было так просто.
Устанавливаем роль
RSAT или локальный сервер с GUI:
Переходим в добавление компонентов и выбираем AD DS.
Если вы не знаете, как называется компонент системы, можно выполнить команду и получить список доступных компонентов, их зависимостей и их имена.
Копируем имя компонента и приступаем к установке.
Windows Admin Center:
Переходим в «Роли и компоненты» и выбираем ADDS (Active Directory Domain Services).
И это буквально всё. Управлять Active Directory через Windows Admin Center на текущий момент невозможно. Его упоминание не более чем напоминание о том, насколько он пока что бесполезен.
Повышаем сервер до контроллера домена
А для этого создаем новый лес.
RSAT или локальный серверс GUI:
Очень рекомендуем оставлять все по умолчанию, все компоненты из коробки прекрасно работают и их не нужно трогать без особой на то необходимости.
Сначала нужно создать лес и установить пароль от него. В Powershell для паролей есть отдельный тип переменной – SecureString, он используется для безопасного хранения пароля в оперативной памяти и безопасной его передачи по сети.
Любой командлет который использует чей угодно пароль нужно вводит таким образом. Сначала записываем пароль в SecureString, а затем указываем эту переменную в командлет.
Как и в установке через GUI, даже вывод в консоль один и тот же. В отличие от сервера с GUI, как установка роли, так и установка сервера в качестве контроллера домена не требует перезагрузки.
Установка контроллера с помощью RSAT занимает больше времени, чем через Powershell.
Управляем доменом
Теперь, чтобы понять насколько сильно различается управление Active Directory через Powershell и AD AC (Active Directory Administrative Center), рассмотрим пару рабочих примеров.
Создание нового пользователя
Отличий между AD DC и Powershell никаких.
Включить пользователя
RSAT или локальный серверс GUI:
Через GUI пользователю нужно сначала задать пароль отвечающий GPO и только после этого его можно будет включить.
Через Powershell почти то же самое, только пользователя можно сделать активным даже без пароля.
Добавляем пользователя в группу
RSAT или локальный сервер с GUI:
С помощью AD DC нужно перейти в свойства пользователя, найти графу с членством пользователя в группах, найти группу в которую мы хотим его поместить и добавить его наконец, а затем кликнуть OK.
Если мы не знаем как называется нужная нам группа, получить их список мы можем с помощью:
Получить группу со всеми свойствами можно так:
Ну и наконец добавляем пользователя в группу:
Далее, из-за того, что в Powershell все является объектами, мы как и через AD DC должны сначала получить группу пользователя, а затем добавить его в неё.
Затем добавляем этот объект в группу:
Как видим, отличий в управлении AD через AD AC и Powershell почти нет.
Вывод:
Если вы уже сталкивались с развертыванием AD и других служб, то вы, возможно подмечали сходство развертывания через RSAT и Powershell, и насколько на самом деле все похоже. GUI в ядре, как никак.
Надеемся, статья была полезна или интересна.
Ну и напоследок пару дельных советов:
Предлагаем обновлённый тариф UltraLite Windows VDS за 99 рублей с установленной Windows Server 2019 Core.
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Полное руководство по Active Directory, от установки и настройки до аудита безопасности. Ч. 7: Понимание инфраструктуры Active Directory
Оглавление
8. Групповые политики
9. Управление пользователями и компьютерами Active Directory. Группы. Организационные подразделения
10. Настройка траста и сайта доменов
11. Другие службы и роли Active Directory
12. Настройка Samba (Active Directory для Linux)
13. Инструменты для аудита безопасности Active Directory
Как соотносятся Active Directory, домен и контроллер домена
Главной единицей, в которой происходят основные процессы по управлению пользователями, компьютерами, оборудованием, процессами и прочим является домен. Ядром домена является контроллер домена, который, собственно, и отвечает за управление перечисленными элементами. Поэтому при изучении Active Directory фокус направлен на объекты, которыми управляет контроллер домена. Наиболее часто используемые объекты:
Каждый объект уникально идентифицируется своим именем и атрибутами.
Эти объекты могут быть сгруппированы в организационные подразделения (OU) по любому количеству логических или бизнес-потребностей. Затем объекты групповой политики (GPO) можно связать с организационным подразделением, чтобы централизованно настроить различных пользователей или компьютеры в организации.
Думается, что без особых объяснений понятно, что такое тип объектов «пользователи», «компьютеры» и прочее. И именно с ними происходит большая часть работы. Но Active Directory не ограничивается только объектами домена, в зависимости от потребностей, системный администратор может оперировать несколькими доменами, либо для одного домена создать несколько контроллеров домена. Домены могут находиться в самых разнообразных связях между собой: от полной изоляции до полного доверия со всеми промежуточными вариантами. Для настройки отношений используются лес, дерево и другие элементы, на которых системный администратор, работающий с единственным доменом, не фокусируется, даже если в его домене тысячи компьютеров и пользователей. По этой причине мы начнём со знакомства с объектами домена, а затем перейдём к структуре Active Directory в целом, описывающей взаимосвязь между несколькими доменами и контроллерами доменов. В дальнейшем некоторые из этих вопросов будут изучены в отдельных главах.
Объекты домена Active Directory
Прежде чем углубиться в абстрактные понятия «лес», «дерево», «домен», остановимся на более конкретных: «пользователи», «компьютеры», «группы». Все они являются объектами домена.
Имеются следующие виды объектов:
Мы ограничимся изучением и работой со следующими типами объектов:
Чем различаются организационные подразделения и контейнеры
В следующем окне «Пользователи и компьютеры Active Directory» вы можете видеть такие элементы как контейнер (Container) и организационные подразделения (Organizational units).
На самом деле, они схожи: оба этих типа используются для упорядочения объектов. Их можно рассматривать как папки, в которых размещены другие папки и объекты. Их главное различие в том, что как только сервер становится контроллером домена, создаётся несколько контейнеров по умолчанию. Эти контейнеры по умолчанию уникальны, они не могут быть переименованы, удалены, созданы или связаны с объектом групповой политики (GPO).
В свою очередь организационные подразделения могут быть переименованы, созданы, связаны с объектом групповой политики (GPO) администраторами домена.
Примечание: про объекты групповой политики (GPO) будет рассказано ниже.
Не каждый контейнер по умолчанию нужен для повседневной работы системного администратора. Из-за этого по умолчанию некоторые контейнеры скрыты. Одна из причин, по которой эти контейнеры скрыты, заключается в том, чтобы пользователи AD и компьютерные оснастки не выглядели запутанными. Чтобы показать эти по умолчанию скрытые контейнеры, включите опцию Advanced Features в меню View.
Полный список контейнеров:
Обратите внимание, что в других утилитах сразу показываются все контейнеры. Например, это скриншот Центра администрирования Active Directory.
А это скриншот с обзором контейнеров по умолчанию из Windows Admin Center.
Поэтому если вы пользуетесь каким-либо из этих инструментов, то вам нет необходимости активировать показ скрытых контейнеров по умолчанию.
Контейнеры по умолчанию
Имеющиеся контейнеры по умолчанию (обратите внимание, что Computers и Users это не типы объектов здесь, а имена контейнеров!):
Организационные подразделения
Как уже было сказано, вы можете воспринимать Организационные подразделения как папки, в которых находятся объекты различных типов, например, там могут быть пользователи и компьютеры. Кроме того, допускаются вложенные организационные подразделения, то есть внутри одного организационного подразделения может быть другое и так далее.
Одной из важнейших функций организационных подразделений является возможность применить к ней объект(ы) групповой политики (GPO). Как можно догадаться, объекты групповых политик содержат разнообразные наборы правил и разрешений (политик), которые будут распространены на все объекты, размещённые внутри организационного подразделения, к которой применён объект групповой политики.
Пример сложной структуры организационных подразделения, в которой в основу положено разделение филиалов по странам, затем по регионам страны, при этом для каждого региона создана структура типичных подразделений.
В данном примере пользователи, компьютеры и другие объекты не только организованно структурированы, но и для любой организационного подразделения, на любом уровне может быть применена отдельная политика.
Организационные подразделения должны быть созданы таким образом, чтобы отражать потребность вашей организации в делегировании полномочий и применении групповой политики. Многонациональная компания может иметь подразделения верхнего уровня в Северной Америке, Европе, Азии, Южной Америке, Африке, чтобы они могли делегировать административные привилегии в зависимости от континента. В других организациях могут быть подразделения верхнего уровня по кадрам, бухгалтерскому учёту, продажам и так далее, если для них это имеет больше смысла. Другие организации имеют минимальные потребности в политике и используют «плоский» макет только с пользователями-сотрудниками и компьютерами сотрудников. Нет универсального решения и единственного правильного ответа. Организационные подразделения должны отвечать потребностям вашей компании и удобству управления компьютерами и пользователями с помощью объектов групповой политики.
К объектам групповой политики мы ещё вернёмся позже, а пока продолжим знакомство с типами объектов Active Directory.
Пользователи, компьютеры, группы
Если вы зайдёте в контейнеры Users и Computers, то вы увидите объекты трёх типов:
Для доступа к сетевым службам используются учётные записи пользователей и компьютеров. В сетях на базе Windows Server сделано так, что и пользователи, и учётные записи компьютеров находятся в AD. В такой централизованной среде используются ещё и группы для облегчения процесса назначения прав и разрешений.
Учётные записи (объекты пользователи и компьютеры)
Технически domain account (доменная учётная запись) пользователя является частью AD и как таковая аутентифицируется тем же самым объектом (то есть AD). Доменной учётной записи пользователя разрешён доступ как к локальным, так и к сетевым службам на основе доступа, предоставленного учётной записи или группе, к которой принадлежит данный аккаунт.
Примеры создания учётных записей пользователей домена даны в предыдущей части.
В отличие от учётных записей домена, локальные учётные записи являются частью компьютеров, на которых эта учётная запись была создана, и поэтому за их аутентификацию отвечает Windows SAM. Локальная учётная запись авторизована для доступа к локальным службам на основе доступа, предоставленного учётной записи. Кроме того, локальная учётная запись может получить доступ к общим ресурсам в сети P2P, если у неё есть на это разрешения.
Вы не можете создать локальную учётную запись в контроллере домена (на сервере Windows Server, которому назначена роль контроллер домена).
В AD computer account (учётная запись компьютера) идентифицирует компьютер в домене. Перед присоединением компьютера к домену его имя хоста должно быть уникальным в сети. После того, как компьютер присоединяется к домену, он продолжает использовать своё имя компьютера для связи с другими компьютерами и серверами в сети. Учётные записи компьютеров управляются через оснастку «Active Directory Users and Computers» («Пользователи и компьютеры Active Directory»):
Когда пользователь пытается войти в компьютер, который присоединён к AD, используя свои учётные данные AD, объединённое и хешированное сочетание имени пользователя и пароля отправляется на контроллер домена как для учётной записи пользователя, так и для учётной записи компьютера, на котором выполняется вход. Да, компьютер тоже входит в систему. Это важно, потому что если что-то произойдёт с учётной записью компьютера в AD, например, кто-то сбрасывает учётную запись или удаляет её, вы можете получить сообщение об ошибке, в котором говорится, что между компьютером и доменом не существует доверительных отношений. Несмотря на то, что учётные данные пользователя являются действительными, компьютеру больше не доверяют для входа в домен.
Группы
В AD группа представляет собой набор объектов AD. Вместо того, чтобы назначать разрешения и права каждому объекту AD индивидуально, группы используются для более структурированного администрирования. Обратите внимание, что группа также является объектом, а это означает, что её также можно переместить в OU (при этом объекты групповой политики (GPO) не могут применяться напрямую к группам).
Группы используются для облегчения администрирования объектов AD. Следовательно, как только сервер становится контроллером домена, создаётся значительное количество групп по умолчанию.
Группы также могут быть созданы администратором домена.
Независимо от того, это группа безопасности или универсальная группа, нужно помнить об области действия группы как параметре расширения группы в лесу, дереве домена или дочернем домене (обо всём этом позже). В AD есть три вида групп с различными сферами действия:
Группы AD — это объекты, которые также можно объединить в группы. Нужно знать правило, что добавление групп в другие группы приводит к минимизации количества индивидуально назначаемых разрешений пользователям или группам. То есть из всего набора разрешений выбираются самые строгие.
Структура Active Directory
Как связаны между собой домен, лес, дерево доменов и дочерний домен
Домен — это логическая группа пользователей, компьютеров, периферийных устройств и сетевых служб. С точки зрения сетевой архитектуры, как правило, домены представляют собой централизованные сетевые среды, в которых аутентификацией управляет контроллер домена. В сетях на базе Windows Server домен обслуживается ролью AD DS.
Вы можете вспомнить, что на этапе повышения сервера до уровня контроллера домена, мы выбрали опцию добавить новый лес.
Лес, условно говоря, это оболочка, которая разграничивает домены. Домены в разных лесах являются полностью отграниченными друг от друга (если иное не настроено с помощью траста). На практике обычно один лес содержит один домен — эта самая простая и распространённая конфигурация.
Кроме одиночных доменов, лес может содержать деревья доменов. Такие домены автоматически доверяют друг другу, но могут использовать разное пространство имён, например, один домен может использовать имя ad-dom.loc, а другой mydomain.com.
У домена может быть дочерний домен, который, соответственно, включается в тот же лес. От деревьев доменов дочерние домены отличаются тем, что используют одно пространство имён, например, если родительский домен имеет имя ad-dom.loc, то дочерний должен иметь имя вида *.ad-dom.loc, например, train.ad-dom.loc.
На практике системные администраторы редко используют деревья и дочерние домены, поскольку в современной Active Directory в этом нет необходимости — всё, что надо, можно настроить в рамках одного домена через организационные подразделения.
Тем не менее, рассмотрим элементы структуры домена более подробно.
Что такое домен и что такое лес
Лес — это граница безопасности. Объекты в отдельных лесах не могут взаимодействовать друг с другом, если администраторы каждого отдельного леса не создают между ними отношения доверия. Например, учётная запись администратора предприятия для domain1.com, которая обычно является самой привилегированной учётной записью леса, не будет иметь никаких разрешений во втором лесу с именем domain2.com, даже если эти леса существуют в той же локальной сети. Если необходимо, чтобы разрешения были, то это настраивается через trust (доверие).
Если у вас есть несколько несвязанных бизнес-единиц или вам нужны отдельные границы безопасности, вам понадобится несколько лесов.
Новый лес создают когда нужна граница безопасности. Например, у вас может быть сеть периметра (DMZ), которой вы хотите управлять с помощью AD, но вы не хотите, чтобы ваш внутренний AD был доступен в сети периметра из соображений безопасности. В этом случае вам нужно создать новый лес для этой безопасносной зоны. Вы также можете захотеть подобного разделения, если у вас есть несколько организаций, которые не доверяют друг другу – например, корпорация-оболочка, которая включает в себя отдельные предприятия, которые работают независимо. В этом случае вам нужно, чтобы у каждой сущности был свой лес.
Домен — это граница управления. Домены являются частью леса. Первый домен в лесу известен как корневой домен леса. Во многих малых и средних организациях (и даже в некоторых крупных) вы найдёте только один домен в одном лесу. Корневой домен леса определяет пространство имён по умолчанию для леса. Например, если первый домен в новом лесу называется domain1.com, то это корневой домен леса. Если у вас есть бизнес-потребность в дочернем домене, например, в филиале в Чикаго, вы можете назвать дочерний домен chi. FQDN (полностью определённое доменное имя) дочернего домена будет chi.domain1.com. Вы можете видеть, что имя дочернего домена было добавлено к имени корневого домена леса. В одном лесу может быть несколько доменов и могут быть непересекающиеся пространства имён.
В большинстве случаев системные администраторы делают всё возможное, чтобы иметь один домен AD. Это упрощает управление, а современные версии AD позволяют очень легко делегировать управление основанное на организационных подразделениях (OU), что снижает потребность в дочерних доменах.
Роли FSMO (Flexible single master operation, роли хозяина операций)
Когда устанавливается роль AD DS и сервер становится контроллером домена, AD DS автоматически назначает пять ролей хозяина операций (operations master roles).
FSMO (англ. Flexible single-master operations «операции с одним исполнителем») – типы выполняемых контроллерами домена Active Directory операций, требующие обязательной уникальности сервера, выполняющего данные операции.
В зависимости от типа операции уникальность FSMO подразумевается в пределах или леса доменов, или домена.
Фактически, существует 5 ролей Flexible Single Master Operations (FSMO). Их также называют ролями хозяина операций. Эти два термина взаимозаменяемы.
Первые две являются ролями хозяина операций в масштабе леса:
Тогда как оставшиеся три представляют собой роли хозяина операций в масштабе дерева (если домен один, то фактически в масштабе домена):
Существует два типа контроллеров домена: read-only (доступны только для чтения) и read-write (для чтения-записи). Версия только для чтения содержит копию базы данных ADDS, доступную только для чтения. Как следует из названия, контроллеры домена для чтения и записи дополнительно могут выполнять ещё и запись в базу данных ADDS. Schema Master (Мастер схемы) и Domain Naming Master (Мастер именования доменов) управляют схемой AD, они запущены на контроллере домена с доступном для чтения и записи, который заботится о том, чтобы в лесу находился только один уникальный домен. С другой стороны, Relative ID Master (Мастер RID) заботится о назначении Security Identifiers (SIDs) (идентификаторов безопасности) контроллерам домена, Primary Domain Controller Emulator (PDC Emulator) (Эмулятор основного контроллера домена) занимается обновлением паролей, а Infrastructure Master (Мастер инфраструктуры) отслеживает изменения, внесённые в другие объекты домена.
Пример получения информации о лесе для текущего пользователя:
Получение информации о лесе для удалённого компьютера:
Как можно увидеть, домен, корневой домен и лес названы одинаково: ds.hackware.ru. Обратите внимание на значение полей SchemaMaster и DomainNamingMaster которые являются ролями хозяина операций в масштабе леса.
Получение информации о домене для текущего пользователя:
Получение информации о домене для удалённого компьютера:
В этом выводе (тот же самый) домен назван ds, а лес по-прежнему назван ds.hackware.ru. Здесь же обратите внимание на значение RIDMaster, PDCEmulator и InfrastructureMaster которые представляют собой роли хозяина операций в масштабе дерева (домена).
Важно помнить, что серверы, на которых работают эти роли, не высечены из камня. Обычно перемещать эти роли тривиально, поэтому, хотя некоторые DC делают немного больше, чем другие, если они выходят из строя на короткие периоды времени, всё обычно будет работать нормально. Если они не работают в течение длительного времени, то легко прозрачно передать роли.
Контроллеры домена и глобальные каталоги (Global Catalogs)
Если структура Active Directory содержит несколько доменов, для решения задачи поиска объектов используется глобальный каталог: контроллер домена, содержащий все объекты леса, но с ограниченным набором атрибутов (неполная реплика). Каталог хранится на указанных серверах глобального каталога и обслуживает междоменные запросы.
Напомним, что сервер, который отвечает на запросы аутентификации или авторизации, является контроллером домена (DC). В большинстве случаев контроллер домена будет хранить копию глобального каталога. Глобальный каталог (GC) — это частичный набор объектов во всех доменах леса. Он доступен для прямого поиска, что означает, что междоменные запросы обычно могут выполняться на GC без необходимости обращения к DC в целевом домене.
Проблемы доступности контроллера домена
Несколько контроллеров домена могут одновременно отвечать на запросы аутентификации от разных пользователей и компьютеров. Если один выйдет из строя, остальные продолжат предлагать услуги аутентификации. Теперь нет такого понятия как «первичный» или «вторичный» сервер. Но для правильной работы домена, эти контроллеры домена должны быть ещё и DNS-серверами, которые также содержат копию интегрированных DNS-зон Active Directory для вашего домена.
Данные между серверами синхронизуются с помощью репликации. По умолчанию контроллеры домена, принадлежащие к одному домену на одном сайте, будут реплицировать свои данные друг другу с интервалом в 15 секунд. Это гарантирует, что всё относительно актуально. Есть некоторые «срочные» события, запускающие немедленную репликацию. Примеры срочных событий: учетная запись заблокирована из-за слишком большого количества неудачных попыток входа, изменение пароля домена или политики блокировки, изменение секрета LSA, изменение пароля учётной записи компьютера контроллера домена или передача роли RID Master в новый DC. Любое из этих событий вызовет немедленное событие репликации.
Изменение пароля находится где-то между срочными и несрочными событиями. Если пароль пользователя изменён на DC01 и пользователь пытается войти в компьютер, который аутентифицируется на DC02 до того, как произойдёт репликация, вы ожидаете, что это не удастся, верно? К счастью, это не так. Предположим, что здесь также есть третий DC с именем DC03, который выполняет роль эмулятора PDC (первичного контроллера домена). Когда на DC01 обновляется пароль пользователя, это изменение немедленно реплицируется и на DC03. В случае если ваша попытка аутентификации на DC02 не удалась, то затем DC02 пересылает эту попытку аутентификации на DC03, который проверяет, действительно ли с ней всё в порядке, и если так, то вход в систему разрешается.
Сайт должен представлять физическую или логическую границу в вашей сети. Например, филиалы. Сайты используются для интеллектуального выбора партнёров по репликации для контроллеров домена в различных расположениях. Без определения сайтов все контроллеры домена будут обрабатываться так, как если бы они находились в одном физическом месте, и реплицироваться в топологии ячеистой сети. На практике большинство организаций логически настроены по принципу hub-and-spoke «ступица и луч», то есть централизованный сервер или несколько связанных между собой серверов к которым подключены клиентские машины. Поэтому сайты и службы должны быть настроены таким образом, чтобы это отражать.
Другие приложения также используют Сайты и Сервисы. Distributed File System (DFS) использует его для ссылок на пространство имён и выбора партнёра по репликации. Exchange и Outlook используют его для поиска «ближайшего» глобального каталога для запроса. Компьютеры, присоединённые к домену, используют его для определения «ближайшего» контроллера домена(ов) для аутентификации. Без этого ваш трафик репликации и аутентификации будет похож на Дикий Запад и выбирать неэффективные маршруты.
Объекты групповой политики
Что такое групповая политика и объекты групповой политики
Групповая политика — это инструмент, доступный администраторам, использующим домен Active Directory Windows 2000 или более поздней версии. Он позволяет централизованно управлять настройками на клиентских компьютерах и серверах, присоединённых к домену, а также обеспечивает рудиментарный способ распространения программного обеспечения.
Настройки сгруппированы в объекты, называемые Group Policy Objects (GPO), то есть объектами групповой политики. Объекты групповой политики сопрягаются с организационным подразделением Active Directory (OU) и могут применяться к пользователям и компьютерам. Объекты групповой политики нельзя применять к группам напрямую, хотя вы можете использовать фильтрацию безопасности или таргетинг на уровне элементов для фильтрации применения политики на основе членства в группе.
Что могут делать организационные политики
Серьёзно, вы можете делать всё, что захотите, с пользователями или компьютерами в вашем домене. Существуют сотни предопределённых настроек для таких вещей, как перенаправление папок, сложность пароля, параметры питания, сопоставление дисков, шифрование дисков, обновление Windows и так далее. Все настройки, которые вы можете сделать для одного компьютера или пользователя, вы можете с лёгкостью распространить на десятки или сотни компьютеров с помощью организационных подразделений.
Всё, что вы не сможете настроить с помощью предустановленных параметров, вы можете контролировать с помощью скриптов, в том числе на PowerShell.
Значение объектов групповой политики для Active Directory
Объекты групповой политики это и есть тот мощнейший инструмент, который позволяет очень гибко и эффективно управлять Active Directory.
Схема типичного механизма управления:
Групповые политики очень важны и им будет посвящена отдельная глава, в которой будет рассмотрен процесс редактирования объектов групповых политик и их спряжение с организационными подразделения.
После детального знакомства с групповыми политиками, мы углубимся в управление пользователями, компьютерами и другими типами объектов с помощью групповых политик и групп.
Также в этой части мы лишь поверхностно затронули вопросы траста (доверия) между доменами и контроллерами доменов — и этой теме будет посвящена отдельная глава.