Множество_лесов_active_directory

Несколько лесов с использованием AD DS и Azure AD

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

В этой статье рассматривается архитектура, описанная в статье Виртуальный рабочий стол Azure в корпоративном масштабе . Он поможет вам понять, как интегрировать несколько доменов и Виртуальный рабочий стол Azure с помощью Azure Active Directory (Azure AD) Connect для синхронизации пользователей из локальных доменные службы Active Directory (AD DS) с Azure AD.

Архитектура

Скачайте файл Visio этой архитектуры.

Поток данных

В этой архитектуре поток удостоверений работает следующим образом:

1. Azure AD Connect синхронизирует пользователей из CompanyA.com и CompanyB.com с клиентом Azure AD (NewCompanyAB.onmicrosoft.com).
2. Пулы узлов, рабочие области и группы приложений создаются в отдельных подписках и периферийных виртуальных сетях.
3. Пользователи назначаются группам приложений.
4. Узлы сеансов Виртуального рабочего стола Azure в пулах узлов присоединяются к доменам CompanyA.com и CompanyB.com с помощью контроллеров домена в Azure.
5. Пользователи выполняют вход с помощью приложения Виртуального рабочего стола Azure или веб-клиента с именем участника-пользователя (UPN) в следующем формате: user@NewCompanyA.com, user@CompanyB.comили user@NewCompanyAB.comв зависимости от настроенного суффикса имени участника-пользователя.
6. Пользователям предоставляются соответствующие виртуальные рабочие столы или приложения. Например, пользователям в CompanyA предоставляется виртуальный рабочий стол или приложение в рабочей области A, пул узлов 1 или 2.
7. Профили пользователей FSLogix создаются в общих папках Файлов Azure в соответствующих учетных записях хранения.
8. групповая политика объекты (GPO), синхронизированные из локальной среды, применяются к пользователям и узлам сеансов Виртуального рабочего стола Azure.

Компоненты

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

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

Сведения о сценарии

Эта схема архитектуры представляет типичный сценарий, содержащий следующие элементы:

• Клиент Azure AD доступен для новой компании с именем NewCompanyAB.onmicrosoft.com.
• Azure AD Connect синхронизирует пользователей из локальной службы AD DS с Azure AD.
• Компании A и B имеют отдельные подписки Azure. У них также есть подписка на общие службы, называемая на схеме подпиской 1 .
• Звездообразная архитектура Azure реализуется с помощью виртуальной сети концентратора общих служб.
• Сложные гибридные среды локальная служба Active Directory присутствуют с двумя или более лесами Active Directory. Домены находятся в разных лесах, каждый из которых имеет другой суффикс имени субъекта-пользователя. Например, CompanyA.local с суффиксом имени участника-пользователя CompanyA.com, CompanyB.local с суффиксом имени участника-пользователя CompanyB.com и дополнительный суффикс имени участника-пользователя NewCompanyAB.com.
• Контроллеры домена для обоих лесов находятся локально и в Azure.
• Проверенные домены находятся в Azure для CompanyA.com, CompanyB.com и NewCompanyAB.com.
• Используется объект групповой политики и устаревшая проверка подлинности, например Kerberos, NTLM (диспетчер локальной сети Windows New Technology) и LDAP (протокол доступа к упрощенным каталогам).
• Для сред Azure, которые по-прежнему зависят от локальной инфраструктуры, между локальной средой и Azure настраивается частное подключение (VPN типа «сеть — сеть» или Azure ExpressRoute).
• Среда Виртуального рабочего стола Azure состоит из рабочей области Виртуального рабочего стола Azure для каждого подразделения и двух пулов узлов для каждой рабочей области.
• Узлы сеансов Виртуального рабочего стола Azure присоединяются к контроллерам домена в Azure. То есть узлы сеансов CompanyA присоединяются к домену CompanyA.local, а узлы сеансов CompanyB присоединяются к домену CompanyB.local.
• Учетные записи хранения Azure могут использовать Файлы Azure для профилей FSLogix. Создается одна учетная запись для каждого домена компании (то есть CompanyA.local и CompanyB.local), а учетная запись присоединяется к соответствующему домену.

доменные службы Active Directory — это самостоятельно управляемый локальный компонент во многих гибридных средах, а azure доменные службы Active Directory (Azure AD DS) предоставляет управляемые доменные службы с подмножеством полностью совместимых традиционных функций AD DS, таких как присоединение к домену, групповая политика. ПРОТОКОЛ LDAP и проверка подлинности Kerberos/NTLM. Подробное сравнение этих компонентов см. в статье Сравнение самоуправляемых доменных служб Active Directory, Azure AD и управляемых Azure AD DS.

Потенциальные варианты использования

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

• Слияния и приобретения, ребрендинг организации и несколько локальных удостоверений
• Сложные локальные среды Active Directory (несколько лесов, несколько доменов, требования групповой политики (или GPO) и устаревшая проверка подлинности)
• Инфраструктура локального объекта групповой политики с Виртуальным рабочим столом Azure

Рекомендации

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

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

• Чтобы расширить инфраструктуру объектов групповой политики для Виртуального рабочего стола Azure, локальные контроллеры домена должны синхронизироваться с контроллерами домена IaaS (инфраструктура как услуга).
• Для расширения инфраструктуры GPO на контроллеры домена IaaS Azure требуется частное подключение.

Сеть и подключения

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

Служба хранилища Azure

Следующие рекомендации по проектированию применимы к контейнерам профилей пользователей, контейнерам облачного кэша и пакетам MSIX:

• В этом сценарии можно использовать как Файлы Azure, так и Azure NetApp Files. Вы выбираете правильное решение на основе таких факторов, как ожидаемая производительность, затраты и т. д.
• Учетные записи хранения Azure и Azure NetApp Files могут быть присоединены к одной ad ds за раз. В таких случаях требуется несколько учетных записей хранения Azure или экземпляров Azure NetApp Files.

Azure Active Directory

В сценариях с пользователями в нескольких локальных лесах Active Directory к клиенту Azure AD подключается только один сервер синхронизации Azure AD Connect. Исключением является сервер Azure AD Connect, который используется в промежуточном режиме.

Поддерживаются следующие топологии удостоверений:

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально она была написана следующими участниками.

Дальнейшие действия

Дополнительные сведения см. в следующих статьях:

Связанные ресурсы

Источник

Модели архитектуры леса

Вы можете применить одну из следующих трех моделей проектирования леса в среде Active Directory:

• Модель леса организации
• Модель леса ресурсов
• Модель леса ограниченного доступа

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

Модель леса организации

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

Если пользователям в лесу организации требуется доступ к ресурсам в других лесах (или обратном), отношения доверия можно установить между одним лесом организации и другими лесами. Это позволяет администраторам предоставлять доступ к ресурсам в другом лесу. На следующем рисунке показана модель леса организации.

Каждый проект Active Directory включает по крайней мере один лес организации.

Модель леса ресурсов

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

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

Модель леса ограниченного доступа

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

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

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

Источник