Концепции леса ресурсов для доменных служб Azure AD
- Статья
- Чтение занимает 7 мин
Доменные службы Azure Active Directory (Azure AD DS) предоставляют возможность входа для устаревших локальных бизнес-приложений. Пользователи, группы и хэши паролей локальных и облачных пользователей синхронизируются с управляемым доменом Azure AD DS. Эти синхронизированные хэши паролей дают пользователям единый набор учетных данных, которые они могут использовать для локальных AD DS, Microsoft 365 и Azure Active Directory.
Хотя это защищенный метод с дополнительными преимуществами безопасности, некоторые организации не могут синхронизировать эти хэши паролей пользователей с Azure AD или Azure AD DS.
В связи с этими потребностями и ограничениями можно создать управляемый домен, использующий лес ресурсов. В этой статье объясняется, что собой представляют леса и как они доверяют другим ресурсам, чтобы обеспечить безопасный метод проверки подлинности.
Что такое леса?
Лес — это логическая конструкция, используемая доменными службами Active Directory (AD DS) для группирования одного или нескольких доменов. Затем домены сохраняют объекты для пользователей или групп и предоставляют службы проверки подлинности.
На управляемых доменах Azure AD DS лес содержит только один домен. Локальные леса AD DS часто содержат много доменов. В крупных организациях, особенно после слияния и приобретения, у вас может быть несколько локальных лесов, каждый из которых будет содержать несколько доменов.
По умолчанию управляемый домен создается как лес объектов пользователя. Лес этого типа синхронизирует все объекты из Azure AD, включая учетные записи пользователей, созданные в локальной среде AD DS. Учетные записи пользователей могут напрямую проходить проверку подлинности в управляемом домене, например для входа в виртуальную машину, присоединенную к домену. Лес пользователей работает, когда хэши паролей можно синхронизировать и пользователи не используют единственный метод входа, например проверку подлинности с помощью смарт-карты. В дополнение к пользователям, которые могут выполнять аутентификацию напрямую, пользователи в других локальных средах AD DS также могут выполнять аутентификацию через одностороннее отношение доверие леса из своих локальных экземпляров AD DS для доступа к ресурсам в лесу пользователей управляемого домена.
В лесу ресурсов управляемого домена аутентификация пользователей также осуществляется с помощью одностороннего отношения доверия леса из локальных экземпляров AD DS.
При таком подходе пользовательские объекты и хэши паролей не синхронизируются с управляемым доменом. Пользовательские объекты и учетные данные существуют только в локальных AD DS. Такой подход позволяет предприятиям размещать в Azure ресурсы и платформы приложений, которым требуется классическая проверка подлинности, например LDAPS, Kerberos или NTLM, при этом устраняются проблемы проверки подлинности.
Леса ресурсов также предоставляют возможность переноса приложений методом lift-and-shift по одному компоненту за раз. Многие устаревшие локальные приложения являются многоуровневыми, часто используют веб-сервер или внешний интерфейс и множество компонентов, связанных с базами данных. Эти уровни затрудняют перемещение всего приложения в облако за один шаг. С помощью лесов ресурсов вы можете переносить приложение в облако поэтапно, чтобы упростить задачу.
Что такое отношения доверия?
Организациям, имеющим более одного домена, часто требуется, чтобы у пользователей был доступ к общим ресурсам в другом домене.
Для доступа к этим общим ресурсам пользователи из одного домена должны пройти проверку подлинности в другом домене. Чтобы обеспечить эти возможности проверки подлинности и авторизации для клиентов и серверов в разных доменах, между двумя доменами должно быть установлено доверие.
Когда отношения доверия установлены, механизмы проверки подлинности для каждого домена доверяют проверки подлинности другого домена. Отношения доверия обеспечивают управляемый доступ к общим ресурсам в домене ресурсов (доверяющий домен) путем проверки того, что входящие запросы на проверку подлинности поступают из доверенного центра (доверенного домена). Отношения доверия действуют как мосты, которые пропускают только проверенные запросы проверки подлинности между доменами.
Способ передачи запросов на проверку подлинности в рамках отношений доверия зависит от настройки. Отношения доверия можно настроить одним из следующих способов:
- Одностороннее — обеспечивает доступ из доверенного домена к ресурсам в доверяющем домене.
- Двустороннее — обеспечивает доступ из одного домена к ресурсам второго.
Отношения доверия также можно настроить на обработку дополнительных отношений одним из следующих способов:
- Нетранзитивные — доверие существует только между двумя доменами.
- Транзитивные — доверие автоматически распространяется на любые другие домены, которым доверяет один из партнеров.
В некоторых случаях отношения доверия автоматически устанавливаются при создании доменов. В других случаях необходимо выбрать тип доверия и явно установить соответствующие связи. Конкретные типы отношений доверия и структура этих отношений зависят от того, как организована служба AD DS и существуют ли в сети разные версии Windows.
Отношения доверия между двумя лесами
Вы можете расширить доверительные отношения доменов в пределах одного леса на другой лес, вручную создав одностороннее или двустороннее доверие лесов. Доверие леса — это транзитивное доверие, существующее только между корневым доменом одного леса и корневым доменом второго.
- Одностороннее доверие лесов позволяет всем пользователям в одном лесу доверять всем доменам в другом.
- Двустороннее доверие между лесами образует транзитивное отношение доверия между всеми доменами в обоих лесах.
Транзитивность доверия между лесами распространяется только на два леса-партнера. Доверие между лесами не распространяется на другие леса, которым доверяет один из партнеров.
Можно создавать различные конфигурации доверия между доменами и лесами в зависимости от структуры AD DS в организации. Azure AD DS поддерживает только односторонние отношения доверия между лесами. В этой конфигурации ресурсы управляемого домена могут доверять всем доменам в локальном лесу.
Поддержка технологии для отношений доверия
Отношения доверия используют различные службы и функции, такие как DNS, для поиска контроллеров домена в партнерских лесах. Отношения доверия также используют протоколы проверки подлинности NTLM и Kerberos и механизмы управления доступом и авторизации на основе Windows, чтобы обеспечить безопасную инфраструктуру связи между доменами и лесами в AD DS.
Следующие службы и компоненты помогают поддерживать успешные отношения доверия.
DNS
AD DS требуется DNS для расположения и именования контроллера домена. Для успешной работы AD DS предоставляется следующая поддержка DNS:
- Служба разрешения имен, которая позволяет сетевым узлам и службам находить контроллеры домена.
- Структура именования, которая позволяет организации отражать организационную структуру в именах доменов службы каталогов.
Обычно развертывается пространство имен домена DNS, отражающее пространство имен домена AD DS. Если перед развертыванием AD DS существует пространство имен DNS, это пространство имен DNS обычно секционируется для AD DS, а также создается поддомен DNS и делегирование для корня леса AD DS. Затем добавляются дополнительные доменные имена DNS для каждого дочернего домена AD DS.
DNS также используется для поддержки расположения контроллеров домена AD DS. Зоны DNS заполняются записями ресурсов DNS, которые позволяют узлам и службам сети обнаруживать контроллеры домена AD DS.
Приложения и сетевой вход в систему
Приложения и служба сетевого входа в систему являются компонентами модели распределенного канала безопасности Windows. Приложения, интегрированные с Windows Server и AD DS, используют протоколы проверки подлинности для взаимодействия со службой сетевого входа в систему, чтобы можно было установить защищенный путь для проверки подлинности.
Протоколы проверки подлинности
Контроллеры домена AD DS проверяют подлинность пользователей и приложений с помощью одного из следующих протоколов:
Проверка подлинности и управление доступом
Технологии авторизации и доверия работают совместно, чтобы обеспечить безопасную инфраструктуру связи между доменами и лесами в AD DS. Авторизация определяет уровень доступа пользователя к ресурсам в домене. Отношения доверия упрощают междоменную авторизацию пользователей, предоставляя путь для проверки подлинности пользователей в других доменах, чтобы их запросы к общим ресурсам в этих доменах можно было авторизовать.
Когда запрос на проверку подлинности, сделанный в доверяющем домене, проверяется доверенным доменом, он передается целевому ресурсу. Затем целевой ресурс определяет, следует ли авторизовать конкретный запрос, сделанный пользователем, службой или компьютером, в доверенном домене на основе конфигурации контроля доступа.
Отношения доверия предоставляют механизм для проверки запросов проверки подлинности, передаваемых в доверяющий домен. Механизмы управления доступом на компьютере ресурса определяют окончательный уровень доступа, предоставленный запрашивающему объекту в доверенном домене.
Дальнейшие действия
Дополнительные сведения о доверии см. в статье Как отношения доверия между лесами работают в Azure AD DS?
Чтобы приступить к созданию управляемого домена с помощью леса ресурсов, см. статью Создание и настройка управляемого домена Azure AD DS. Затем можно создать исходящее отношение доверия леса с локальным доменом.
Использование модели леса домена организации
Twitter LinkedIn Facebook Адрес электронной почты
- Статья
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
В модели леса домена организации несколько автономных групп имеют каждый домен в лесу.
Каждая группа управляет администрированием служб на уровне домена, что позволяет им управлять определенными аспектами управления службами автономно, а владелец леса управляет управлением службами на уровне леса.
На следующем рисунке показана модель леса домена организации.
Автономия службы на уровне домена
Модель леса домена организации позволяет делегированию полномочий для управления службами на уровне домена. В следующей таблице перечислены типы управления службами, которые можно контролировать на уровне домена.
| Тип управления службами | Связанные задачи |
|---|---|
| Управление операциями контроллера домена | — Создание и удаление контроллеров домена — Мониторинг функционирования контроллеров домена; — управление службами, работающими на контроллерах домена. — резервное копирование и восстановление каталога |
| Настройка параметров на уровне домена | — создание политик учетных записей пользователей домена и домена, таких как пароль, Kerberos и политики блокировки учетных записей. — Создание и применение групповая политика на уровне домена |
| Делегирование администрирования на уровне данных | — Создание подразделений (ЕЗ) и делегирование администрирования — Устранение проблем в структуре подразделения, у владельцев которых недостаточно прав доступа для устранения |
| Управление внешними отношениями доверия | — установление отношений доверия с доменами за пределами леса |
Другие типы управления службами, такие как управление схемой или топологией репликации, отвечают за владельца леса.
Владелец домена
В модели леса домена организации владельцы доменов отвечают за задачи управления службами на уровне домена. Владельцы домена имеют полномочия по всему домену, а также доступ ко всем остальным доменам в лесу. По этой причине владельцы доменов должны быть доверенными лицами, выбранными владельцем леса.
Делегируйте управление службами уровня домена владельцу домена, если выполняются следующие условия:
Все группы, участвующие в лесу, доверяют новому владельцу домена и методам управления службами нового домена.
Новый владелец домена доверяет владельцу леса и всем остальным владельцам домена.
Все владельцы доменов в лесу согласны с тем, что новый владелец домена имеет политики и политики выбора администраторов служб, которые равны или более строги, чем их собственные.
Все владельцы доменов в лесу согласны с тем, что контроллеры домена, управляемые новым владельцем домена в новом домене, физически защищены.
Обратите внимание, что если владелец леса делегирует управление службами уровня домена владельцу домена, другие группы могут отказаться от присоединения к нему, если они не доверяют владельцу домена.
Все владельцы доменов должны помнить, что если какое-либо из этих условий изменится в будущем, может потребоваться переместить домены организации в несколько развертываний леса.
Примечание
Еще один способ свести к минимуму риски безопасности для домена Active Directory Windows Server 2008 — использовать разделение ролей администратора, которое требует развертывания контроллера домена только для чтения (RODC) в инфраструктуре Active Directory.
в статье AD DS: Read-Only контроллеров домена.
Что такое лес Active Directory?
Блог о внутренней безопасности / Безопасность данных / Активный каталог
Лес Active Directory (лес AD) — это самый верхний логический контейнер в конфигурации Active Directory, содержащий домены, пользователей, компьютеры и групповые политики.
«Но подождите?» ты говоришь. «Я думал, что Active Directory — это всего лишь один домен?»
Одна конфигурация Active Directory может содержать более одного домена, и мы называем уровень выше домена лесом AD. Под каждым доменом у вас может быть несколько деревьев, и может быть сложно увидеть лес за деревьями
Этот дополнительный уровень верхнего уровня создает проблемы с безопасностью и увеличивает потенциал для эксплуатации, но он также может означать большую изоляцию и автономию, когда это необходимо: хитрость заключается в том, чтобы понять леса AD и различные стратегии их защиты.
Получите бесплатный видеокурс PowerShell и Active Directory Essentials
Как создать дизайн леса?
Допустим, вы хотите создать лес или (что более вероятно) вы унаследовали лес, который вам нужно очистить. Часто можно увидеть несколько разных доменов и объектов групповой политики в одном или нескольких лесах, которые пытаются сосуществовать из-за более ранних попыток консолидации или приобретения.
Сначала определите, существуют ли какие-либо организационные требования, требующие совершенно отдельного набора политик безопасности. Сформулируйте разговор с акцентом на безопасность данных:
- Существуют ли всеобъемлющие политики, которые можно установить на уровне леса AD?
- Вам нужны дополнительные домены с другими политиками безопасности или отдельные сетевые подключения?
- Существуют ли юридические или прикладные требования, требующие отдельных доменов в лесу?
После того, как вы задокументируете требования «автономии и изоляции», группа разработчиков может создать лес, домены и объекты групповой политики в соответствии с потребностями каждой группы или организации.
Сколько лесов требуется?
В некоторых случаях может потребоваться создание отдельных лесов AD на основе требований к автономии или изоляции. Добавление дополнительных лесов увеличивает сложность управления схемой AD. Если вы решите добавить еще один лес в схему AD, необходимо принять во внимание некоторые соображения:
- Можно ли добиться достаточной изоляции без создания второго леса?
- Все ли заинтересованные стороны понимают разветвления отдельных лесов?
- Управление двумя отдельными лесами означает, что у вас будет вдвое больше серверов приложений и затрат на ИТ.
- У вас есть ресурсы для управления другим лесом?
- Одна ИТ-группа не должна управлять обоими лесами AD. Специалисты по безопасности рекомендуют одну (1) ИТ-группу на лес для разделения обязанностей.
- Передовой практикой является миграция новых или приобретенных доменов в один лес AD.
Дизайн Active Directory с одним или несколькими лесами
Единый лес AD — это более простое решение в долгосрочной перспективе и, как правило, считается лучшей практикой.
Можно создать безопасную среду без дополнительных затрат на второй лес AD с несколькими доменами, используя объекты групповой политики, установленных владельцев данных и модель наименьших привилегий.
Несколько лесов обеспечивают дополнительный уровень безопасности для двух доменов, но при значительном увеличении затрат на ИТ. Мультилеса по умолчанию не делают вас более безопасным. Вам по-прежнему необходимо правильно настроить объекты групповой политики и разрешения для каждого леса AD.
Модели для проектирования леса
Существует три основных способа проектирования леса AD: вы можете комбинировать эти схемы в соответствии с требованиями безопасности вашей организации. Каждая Active Directory имеет по крайней мере один лес AD, и бывают случаи, когда требуется несколько лесов AD для достижения целей бизнеса и безопасности. Вот несколько разных моделей леса. Каждая модель имеет свои преимущества и недостатки, а также уникальные варианты использования.
Модель организационного леса
В организационном лесу учетные записи пользователей и ресурсы хранятся и управляются вместе. Это стандартная конфигурация.
Характеристики организационной модели леса:
- Обеспечивает автономность пользователям и ресурсам в лесу
- Изолирует службы и данные от всех, кто находится за пределами леса
- Доверительные отношения между лесами могут разрешить доступ к некоторым ресурсам, которые находятся за пределами лесов
Ресурсный лес Модель
Лес ресурсов разделяет учетные записи пользователей и ресурсы на разные леса. Эту конфигурацию можно использовать для отделения производственной системы или критически важной системы от основного леса, чтобы любые проблемы с одним лесом позволяли продолжить работу другого.
Характеристики модели ресурсного леса:
- Пользователи живут в организационном лесу
- Ресурсы живут в одном или нескольких дополнительных лесах
- Только альтернативные административные учетные записи пользователей живут в лесах ресурсов
- Доверительные отношения позволяют совместно использовать ресурсы с пользователями
- Эта модель обеспечивает изоляцию служб, поэтому, если один лес выходит из строя, другие продолжают работать в обычном режиме.
Модель леса с ограниченным доступом
Лес с ограниченным доступом полностью изолирует пользователей и ресурсы в нем от других лесов. Вы можете использовать эту конфигурацию для полной защиты данных и ограничения пользователей определенными наборами данных.
Характеристики леса с ограниченным доступом Модель:
- Доверительных отношений с другими лесами не существует
- Пользователи из других лесов не могут получить доступ к ресурсам в лесу с ограниченным доступом
- Пользователям нужен второй компьютер для доступа к ограниченному лесу
- При необходимости может быть размещен в отдельной сети
Рекомендации по работе с лесами Active Directory
ЛесаAD существуют с 2000 года, поэтому существует множество различных теорий о том, как лучше настроить Active Directory и леса. Текущие лучшие практики включают:
- По возможности объединить в один лес
- Защита ресурсов и данных с помощью объекта групповой политики и применение модели с наименьшими привилегиями
- Используйте объекты групповой политики для дальнейшего ограничения возможности пользователей создавать новые папки без выполнения установленного процесса. Наименее привилегированная модель разрешений.
- Предоставьте администраторам домена вторую учетную запись администратора, которую они будут использовать только при необходимости в процессе управления изменениями.
- Если у вас есть несколько лесов AD с доверительными отношениями, рассмотрите возможность консолидации.
- Если вам нужно создать лес с ограниченным доступом, убедитесь, что он действительно ограничен. Каким бы безопасным ни был основной лес, лесом с ограниченным доступом должен быть Castle Black. Поставьте 700-футовую стену вокруг него и держите там.
Наименее привилегированная модель разрешений.Если Active Directory содержит ключи от королевства, лес AD является связкой ключей для некоторых из этих ключей: важно не только защитить Active Directory, но и понять, как настраивать и управлять лесом AD, чтобы предотвратить утечку данных и уменьшить уязвимости безопасности.
Хотите узнать больше о том, как защитить Active Directory независимо от того, сколько у вас лесов AD? Узнайте о 5 ролях FSMO в Active Directory.
Вместо этого предпочитаете аудио/визуальный опыт? Мы обеспечим вас: просмотрите вебинар по запросу «4 совета по обеспечению безопасности Active Directory».
Мы Варонис.
С 2005 года мы защищаем самые ценные в мире данные от врагов с помощью нашей ведущей на рынке платформы защиты данных.
Как это работаетМайкл Бакби
Майкл работал системным администратором и разработчиком программного обеспечения в стартапах Силиконовой долины, ВМС США и во всем, что между ними.
Продолжайте читать
Использование модели организационного доменного леса
Обратная связь Редактировать
Твиттер LinkedIn Фейсбук Эл. адрес
- Статья
- 3 минуты на чтение
Применяется к: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
В модели леса домена организации несколько автономных групп владеют доменом в лесу. Каждая группа контролирует администрирование службы на уровне домена, что позволяет им автономно управлять некоторыми аспектами управления службами, в то время как владелец леса контролирует управление службами на уровне леса.
На следующем рисунке показана модель леса домена организации.
Автономия службы на уровне домена
Модель леса домена организации позволяет делегировать полномочия для управления службами на уровне домена. В следующей таблице перечислены типы управления службами, которыми можно управлять на уровне домена.
| Тип управления услугами | Связанные задачи |
|---|---|
| Управление операциями контроллера домена | — Создание и удаление контроллеров домена — Мониторинг функционирования контроллеров домена — Управление службами, работающими на контроллерах домена — Резервное копирование и восстановление каталога |
| Настройка параметров домена | — Создание политик домена и учетных записей пользователей домена, таких как политики паролей, Kerberos и блокировки учетных записей — Создание и применение групповой политики домена |
| Делегирование управления уровнем данных | — Создание организационных единиц (OU) и делегирование администрирования — Исправление проблем в структуре OU, для устранения которых у владельцев OU нет достаточных прав доступа |
| Управление внешними трастами | — Установление доверительных отношений с доменами за пределами леса |
Другие типы управления службами, такие как управление схемой или топологией репликации, являются обязанностью владельца леса.
Владелец домена
В модели доменного леса организации владельцы доменов несут ответственность за задачи управления службами на уровне домена. Владельцы доменов имеют полномочия на весь домен, а также доступ ко всем другим доменам в лесу. По этой причине владельцы доменов должны быть доверенными лицами, выбранными владельцем леса.
Делегирование управления службами на уровне домена владельцу домена при соблюдении следующих условий:
Все группы, участвующие в лесу, доверяют новому владельцу домена и методам управления службами нового домена.
Новый владелец домена доверяет владельцу леса и всем остальным владельцам домена.
Все владельцы доменов в лесу соглашаются с тем, что у нового владельца домена есть политики и методы управления и выбора администратора службы, которые равны или даже более строги, чем их собственные.
Все владельцы доменов в лесу согласны с тем, что контроллеры домена, управляемые новым владельцем домена в новом домене, физически безопасны.
Обратите внимание: если владелец леса делегирует управление службами на уровне домена владельцу домена, другие группы могут решить не присоединяться к этому лесу, если они не доверяют этому владельцу домена.
Все владельцы доменов должны знать, что если какое-либо из этих условий изменится в будущем, может возникнуть необходимость переместить домены организации в развертывание с несколькими лесами.
Примечание
Еще один способ минимизировать риски безопасности для домена Windows Server 2008 Active Directory — использовать разделение ролей администратора, что требует развертывания контроллера домена только для чтения (RODC) в вашей инфраструктуре Active Directory. Контроллер домена только для чтения — это новый тип контроллера домена в операционной системе Windows Server 2008, на котором размещаются доступные только для чтения разделы базы данных Active Directory. До выпуска Windows Server 2008 любые работы по обслуживанию сервера на контроллере домена должны были выполняться администратором домена.