Полное руководство по Active Directory, от установки и настройки до аудита безопасности. Ч. 7: Понимание инфраструктуры Active Directory

Оглавление

1. Введение в Active Directory (понятия, применение, отличие от Workgroup)

2. Установка Windows Server 2022 и Windows Server Core 2022

3. Инструменты настройки Windows Server 2022 и Windows Server Core 2022

4. Установка Active Directory Domain Services в Windows Server 2022

5. Добавление компьютеров в Active Directory. Проверка и удаление из Active Directory

6. Инструменты настройки и оснастка Active Directory

7. Понимание инфраструктуры Active Directory

7.1 Как соотносятся Active Directory, домен и контроллер домена

7.2 Объекты домена Active Directory

7.2.1 Чем различаются организационные подразделения и контейнеры

7.2.2 Контейнеры по умолчанию

7.2.3 Организационные подразделения

7.2.4 Пользователи, компьютеры, группы

7.2.5 Учётные записи (объекты пользователи и компьютеры)

7.2.6 Группы

7.3. Структура Active Directory

7.3.1 Как связаны между собой домен, лес, дерево доменов и дочерний домен

7.3.2 Что такое домен и что такое лес

7.3.3 Роли FSMO (Flexible single master operation, роли хозяина операций)

7.3.4 Контроллеры домена и глобальные каталоги (Global Catalogs)

7.3.5 Проблемы доступности контроллера домена

7.3.6 Сайт

7.4 Объекты групповой политики

7.4.1 Что такое групповая политика и объекты групповой политики

7.4.2 Что могут делать организационные политики

7.4.3 Значение объектов групповой политики для 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

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

Имеются следующие виды объектов:

• пользователь (User)
• компьютеры (Computer)
• группы (Group)
• контейнер (Container)
• организационные подразделения (Organizational units, OU)
• периферийные устройства
• сетевые службы
• контакт (Contact)
• сетевые папки (Shared folder)
• принтер (Printer)
• встроенный участник безопасности (Built-in security principal)
• Foreign security principal
• прочее (Other)

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

• пользователь (User)
• компьютеры (Computer)
• группы (Group)
• контейнер (Container)
• организационные подразделения (Organizational units, OU)

Чем различаются организационные подразделения и контейнеры

В следующем окне «Пользователи и компьютеры Active Directory» вы можете видеть такие элементы как контейнер (Container) и организационные подразделения (Organizational units).

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

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

Примечание: про объекты групповой политики (GPO) будет рассказано ниже.

Не каждый контейнер по умолчанию нужен для повседневной работы системного администратора. Из-за этого по умолчанию некоторые контейнеры скрыты. Одна из причин, по которой эти контейнеры скрыты, заключается в том, чтобы пользователи AD и компьютерные оснастки не выглядели запутанными. Чтобы показать эти по умолчанию скрытые контейнеры, включите опцию Advanced Features в меню View.

Полный список контейнеров:

Обратите внимание, что в других утилитах сразу показываются все контейнеры. Например, это скриншот Центра администрирования Active Directory.

А это скриншот с обзором контейнеров по умолчанию из Windows Admin Center.

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

Контейнеры по умолчанию

Имеющиеся контейнеры по умолчанию (обратите внимание, что Computers и Users это не типы объектов здесь, а имена контейнеров!):

• Computers (Компьютеры) — это контейнер по умолчанию для учётных записей компьютеров.
• Domain Controllers (Контроллеры домена) — это контейнер по умолчанию для контроллеров домена.
• ForeignSecurityPrincipals — это контейнер по умолчанию для идентификаторов безопасности (SID).
• Keys (Ключи) — это контейнер по умолчанию для объектов ключей.
• LostandFound — это контейнер по умолчанию для осиротевших объектов.
• Managed Service Accounts (Управляемые учётные записи служб) — это контейнер по умолчанию для управляемых учётных записей служб.
• Users (Пользователи) — это контейнер по умолчанию для учётных записей пользователей.

Организационные подразделения

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

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

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

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

Организационные подразделения должны быть созданы таким образом, чтобы отражать потребность вашей организации в делегировании полномочий и применении групповой политики. Многонациональная компания может иметь подразделения верхнего уровня в Северной Америке, Европе, Азии, Южной Америке, Африке, чтобы они могли делегировать административные привилегии в зависимости от континента. В других организациях могут быть подразделения верхнего уровня по кадрам, бухгалтерскому учёту, продажам и так далее, если для них это имеет больше смысла. Другие организации имеют минимальные потребности в политике и используют «плоский» макет только с пользователями-сотрудниками и компьютерами сотрудников. Нет универсального решения и единственного правильного ответа. Организационные подразделения должны отвечать потребностям вашей компании и удобству управления компьютерами и пользователями с помощью объектов групповой политики.

К объектам групповой политики мы ещё вернёмся позже, а пока продолжим знакомство с типами объектов Active Directory.

Пользователи, компьютеры, группы

Если вы зайдёте в контейнеры Users и Computers, то вы увидите объекты трёх типов:

• пользователь (User)
• компьютеры (Computer)
• группы (Group)

Для доступа к сетевым службам используются учётные записи пользователей и компьютеров. В сетях на базе 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) не могут применяться напрямую к группам).

Группы управляются через оснастку «Active Directory Users and Computers» («Пользователи и компьютеры Active Directory»). В AD есть два типа групп:

• Security Groups (Группы безопасности) явно используются для назначения разрешений на общие ресурсы в сети.
• Distribution Groups (Группы распределения) особенно используются для распространения списков адресов электронной почты в сети организации:

Группы используются для облегчения администрирования объектов AD. Следовательно, как только сервер становится контроллером домена, создаётся значительное количество групп по умолчанию.

Группы также могут быть созданы администратором домена.

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

• Domain local group (локальная группа домена) включает учётные записи, локальные группы домена, глобальные группы и универсальные группы из домена локальной группы родительского домена.
• Global group (глобальная группа) включает учётные записи и глобальные группы из родительского домена глобальной группы.
• Universal group (универсальная группа) включает учётные записи, глобальные группы и универсальные группы из любого домена в лесу, к которому принадлежит универсальная группа:

Группы 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). Их также называют ролями хозяина операций. Эти два термина взаимозаменяемы.

Первые две являются ролями хозяина операций в масштабе леса:

• Schema Master (Мастер схемы) — Отвечает за внесение изменений в схему Active Directory. Эта роль необходима для предотвращения противоречивых изменений с двух серверов. В лесу есть только один мастер схемы. Он отвечает за обновление схемы Active Directory. Задачи, для которых это требуется, например подготовка AD к новой версии Windows Server, работающей как контроллер домена, или установка Exchange, требуют изменения схемы. Эти изменения должны выполняться мастером схемы.
• Domain Naming Master (Мастер именования доменов) — Отвечает за состав леса, принимает и удаляет домены. В каждом лесу есть только один мастер именования доменов. Мастер именования доменов гарантирует, что при добавлении нового домена в лес он будет уникальным. Если сервер, выполняющий эту роль, отключён, вы не сможете вносить изменения в пространство имён AD, включая такие вещи, как добавление новых дочерних доменов.

Тогда как оставшиеся три представляют собой роли хозяина операций в масштабе дерева (если домен один, то фактически в масштабе домена):

• Relative ID Master (Мастер RID) — Выдаёт пулы RID контроллерам домена. В случае, когда контроллер домена исчерпывает свой пул RID при очередном создании объекта, он запрашивает новый пул у RID-мастера. Мастер относительных идентификаторов отвечает за выдачу пулов RID контроллерам домена. На каждый домен приходится один мастер RID. Любой объект в домене AD имеет уникальный идентификатор безопасности (SID). Он состоит из комбинации идентификатора домена и относительного идентификатора. Каждый объект в данном домене имеет один и тот же идентификатор домена, поэтому относительный идентификатор делает объекты уникальными. Каждый DC имеет пул относительных идентификаторов для использования, поэтому, когда этот DC создаёт новый объект, он добавляет RID, который он ещё не использовал. Поскольку для контроллеров домена используются неперекрывающиеся пулы, каждый RID должен оставаться уникальным в течение всего срока существования домена. Когда в пуле контроллера домена остаётся ~100 RID, он запрашивает новый пул у мастера RID. Если мастер RID отключён в течение длительного периода времени, создание объекта может завершиться ошибкой.
• Primary Domain Controller Emulator (PDC Emulator) (Эмулятор основного контроллера домена) — Эмулирует основной контроллер домена для приложений, работающих с возможностями домена Windows NT. Это наиболее часто неправильно понимаемая роль из них всех — роль эмулятора PDC. На каждый домен приходится один эмулятор PDC. Если имела место неудачная попытка аутентификации, она перенаправляется на эмулятор PDC. Эмулятор основного контроллера домена функционирует как «средство разрешения конфликтов», если пароль был обновлён на одном контроллере домена и ещё не реплицирован на другие. Эмулятор PDC также является сервером, который управляет синхронизацией времени в домене. Все остальные контроллеры домена синхронизируют своё время с эмулятором основного контроллера домена. Все клиенты синхронизируют своё время с контроллером домена, в который они вошли. Важно, чтобы все оставалось в пределах 5 минут друг от друга, иначе Kerberos сломается, а это повлечёт большие последствия.
• Infrastructure Master (Мастер инфраструктуры) — Поддерживает идентификаторы удаляемых или перемещаемых объектов на время репликации изменений (с удалением или перемещением) между контроллерами домена. Для каждого домена существует один мастер инфраструктуры. Если в вашем лесу всего один домен, вам не о чем беспокоиться. Если у вас несколько лесов, вы должны убедиться, что эта роль не принадлежит серверу, который также является держателем Global Catalog (GC), если только каждый DC в лесу не является GC. Хозяин инфраструктуры отвечает за правильную обработку междоменных ссылок. Если пользователь в одном домене добавляется в группу в другом домене, хозяин инфраструктуры для рассматриваемых доменов следит за тем, чтобы с ним правильно обращались. Эта роль не будет работать правильно, если она находится в глобальном каталоге.

Существует два типа контроллеров домена: 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 (Мастер инфраструктуры) отслеживает изменения, внесённые в другие объекты домена.

Пример получения информации о лесе для текущего пользователя:

Get-ADForest

Получение информации о лесе для удалённого компьютера:

Get-ADForest -Server ds.hackware.ru -Credential Administrator

Как можно увидеть, домен, корневой домен и лес названы одинаково: ds.hackware.ru. Обратите внимание на значение полей SchemaMaster и DomainNamingMaster которые являются ролями хозяина операций в масштабе леса.

Получение информации о домене для текущего пользователя:

Get-ADDomain

Получение информации о домене для удалённого компьютера:

Get-ADDomain -Server ds.hackware.ru -Credential Administrator

В этом выводе (тот же самый) домен назван 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.

Схема типичного механизма управления:

1. Создаются организационные подразделения, в которые добавляются компьютеры и пользователи, а также другие типы объектов
2. С организационными подразделениями спрягаются те или иные объекты групповых политик, в результате чего выбранные настройки начинают применяться сразу ко всем элементам организационного подразделения.
3. Права и разрешения пользователей могут также настраиваться с помощью групп (например, если добавить пользователя в группу «Администраторы домена», то такой пользователь получит полномочия администратора домена).

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

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

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