Развертывание локальных служб федерации Active Directory в Azure

Microsoft Entra ID
Microsoft Entra
Azure Load Balancer

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

Архитектура

Diagram showing an example of a secure hybrid network architecture with Active Directory Federation Services.

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

Примечание.

Файл Visio содержит 4 вкладки схем. Перейдите на вкладку AD FS , чтобы просмотреть соответствующую схему архитектуры для этой статьи.

Workflow

  • Подсеть AD DS. Серверы AD DS содержатся в собственной подсети с правилами группы сетевой безопасности (NSG), действующими в качестве брандмауэра.

  • Серверы AD DS. Контроллеры домена, выполняющие функции виртуальных машин в Azure. Эти серверы предоставляют проверку подлинности локальных удостоверений в домене.

  • Подсеть AD FS. Серверы AD FS расположены в своей собственной подсети с правилами NSG, действующими в качестве брандмауэра.

  • Серверы AD FS. Серверы AD FS предоставляют федеративную авторизацию и проверку подлинности. В этой архитектуре они выполняют следующие задачи:

    • Получение маркеров безопасности, содержащих утверждения, сделанные сервером федерации партнера от имени пользователя партнера. Службы федерации Active Directory проверяют действительность токенов, прежде чем передавать утверждения в веб-приложение, запущенное в Azure, для авторизации запросов.

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

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

    Серверы AD FS настроены как ферма, доступ к которой осуществляется через подсистему балансировки нагрузки Azure. Эта реализация позволяет повысить доступность и масштабируемость. Серверы AD FS не предоставляются непосредственно в Интернете. Весь интернет-трафик фильтруется через прокси-серверы веб-приложений AD FS и промежуточную сеть (также называемую сетью периметра).

    Дополнительные сведения о работе служб федерации Active Directory см. в статье Active Directory Federation Services Overview (Службы федерации Active Directory). Подробные пошаговые инструкции по реализации см. в статье Развертывание служб федерации Active Directory в Azure.

  • Подсеть прокси-сервера AD FS. Прокси-серверы AD FS могут содержаться в собственной подсети с правилами NSG, обеспечивающими защиту. Серверы этой подсети доступны в Интернете через набор сетевых виртуальных устройств, которые обеспечивают брандмауэр между вашей виртуальной сетью Azure и Интернетом.

  • Прокси-серверы веб-приложения (WAP) AD FS. Эти виртуальные машины действуют как серверы AD FS для входящих запросов от партнерских организаций и внешних устройств. WAP-серверы действуют как фильтр, защищая серверы AD FS от прямого доступа из Интернета. Как и для серверов AD FS, развертывание WAP-серверов в ферме с подсистемой балансировки нагрузки обеспечивает большую доступность и масштабируемость, чем развертывание коллекции автономных серверов.

    Примечание.

    Подробные сведения об установке WAP-серверов см. в статье Установка и настройка прокси-сервера веб-приложений.

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

    Примечание.

    Вы также можете настроить VPN-туннель с помощью шлюза Azure для предоставления прямого доступа к AD FS доверенным партнерам. Запросы, полученные от этих партнеров, не проходят через WAP-серверы.

Компоненты

Эта архитектура расширяет реализацию, описанную в статье Расширение доменных служб Active Directory в Azure. Он содержит следующие компоненты.

Подробности сценария

AD FS можно размещать в локальной среде, но если приложение является гибридным, в котором некоторые части реализованы в Azure, это может оказаться более эффективным для реплика te AD FS в облаке.

На предыдущей схеме показаны следующие сценарии:

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

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

Дополнительные сведения см. в статье "Выбор решения для интеграции локальная служба Active Directory с Azure".

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

Типичные способы использования этой архитектуры:

  • Гибридные приложения, в которых рабочие нагрузки выполняются частично локально и частично в Azure.
  • Решения, использующие федеративную авторизацию для публикации веб-приложений в партнерских организациях.
  • Системы, которые поддерживают доступ из веб-браузеров за пределами брандмауэра организации.
  • Системы, которые позволяют пользователям получать доступ к веб-приложениям, подключаясь к авторизованным внешним устройствам, таким как удаленные компьютеры, ноутбуки и другие мобильные устройства.

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

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

Рекомендации по сети

Настройте сетевой интерфейс для каждой виртуальной машины, на которой размещены AD FS и WAP-серверы со статическими частными IP-адресами.

Не предоставляйте общедоступные IP-адреса виртуальных машин AD FS. Дополнительные сведения см. в разделе Вопросы безопасности.

Задайте IP-адрес основных и вторичных серверов служб доменных имен (DNS) для сетевых интерфейсов каждой виртуальной машины AD FS и WAP, чтобы указать виртуальные машины AD DS. На виртуальных машинах AD DS должен быть запущен DNS. Этот шаг является обязательным для подключения каждой виртуальной машины к домену.

Установка AD FS

В статье Развертывание служб федерации Active Directory в Azure приведены подробные инструкции по установке и настройке служб федерации Active Directory. Выполните следующие задачи перед началом настройки первого сервера AD FS в ферме:

  1. Получите общедоступный доверенный сертификат для проверки подлинности сервера. Имя субъекта должно содержать имя, используемое клиентами для доступа к службе федерации. Это может быть DNS-имя, зарегистрированное для подсистемы балансировки нагрузки, например adfs.contoso.com (из соображений безопасности не используйте подстановочные имена, такие как *.contoso.com ). Используйте один сертификат на всех виртуальных машинах сервера AD FS. Вы можете приобрести сертификат в доверенном центре сертификации, но если ваша организация использует службы сертификатов Active Directory, вы можете создать собственный.

    Альтернативное имя субъекта используется службой регистрации устройств (DRS) для разрешения доступа с внешних устройств. Оно должно указываться в формате enterpriseregistration.contoso.com.

    Дополнительные сведения см. в статье Managing SSL Certificates in AD FS and WAP in Windows Server 2016 (Управление SSL-сертификатами в AD FS и WAP в Windows Server 2016).

  2. На контроллере домена создайте корневой ключ для службы распределения ключей. Установите срок действия на текущее время минус 10 часов (эта конфигурация уменьшает задержку, которая может возникать при распространении и синхронизации ключей по всему домену). Этот шаг необходим для поддержки создания групповой учетной записи службы, используемой для запуска службы AD FS. В следующей команде PowerShell показан пример того, как это сделать:

    Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
    
  3. Добавьте все виртуальные машины сервера AD FS в домен.

Примечание.

Чтобы установить AD FS, контроллер домена, на котором выполняется роль FSMO эмулятора основного контроллера домена, должен быть запущен и доступен из виртуальных машин AD FS.

Доверие AD FS

Установите доверие федерации между установкой AD FS и серверами федерации любых партнерских организаций. Настройте требуемую фильтрацию и сопоставление утверждений.

  • Сотрудники отдела DevOps в каждой партнерской организации должны добавить доверие проверяющей стороны для веб-приложений, доступных через ваши серверы AD FS.
  • Сотрудники отдела DevOps в вашей организации должны настроить доверие поставщика утверждений, чтобы ваши серверы AD FS могли доверять утверждениям, предоставляемым партнерскими организациями,
  • а также настроить в AD FS передачу утверждений в веб-приложения вашей организации.

Дополнительные сведения см. в статье Establishing Federation Trust (Настройка доверия федерации).

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

Службы федерации Active Directory поддерживают преобразования токенов и приращение. Идентификатор Microsoft Entra не предоставляет эту функцию. В AD FS при настройке отношения доверия вы можете:

  • Настраивать преобразования утверждений для правил авторизации. Например, можно сопоставить групповую безопасность из представления, используемого партнерской организацией майкрософт, с тем, что Active Directory DS может авторизовать в вашей организации.
  • Преобразовывать утверждения из одного формата в другой. Например, вы можете сопоставить SAML 2.0 с SAML 1.1, если ваше приложение поддерживает только утверждения SAML 1.1.

Мониторинг AD FS

Пакет управления Microsoft System Center для AD FS 2012 R2 предоставляет средства активного и реактивного мониторинга развертывания сервера федерации AD FS. Этот пакет управления отслеживает:

  • События, которые служба AD FS записывает в свои журналы событий.
  • Данные о производительности, которые собирают счетчики производительности AD FS.
  • Общую работоспособность системы AD FS и веб-приложений (проверяющих сторон), а также оповещения о критических проблемах и предупреждения.

Другим вариантом является мониторинг AD FS с помощью Microsoft Entra Подключение Health. Microsoft Entra Подключение Health обеспечивает надежный мониторинг локальной инфраструктуры удостоверений. Это решение обеспечивает надежное подключение к службам Microsoft 365 и Microsoft Online Services. Надежность достигается за счет мониторинга ключевых компонентов идентификации. С помощью этой службы пользователи могут с легкостью получить доступ к общим сведениям об этих компонентах.

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

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Уровень производительности

Уровень производительности — это способность вашей рабочей нагрузки эффективно масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями. Дополнительные сведения см. в разделе "Общие сведения о эффективности производительности".

Следующие аспекты, изложенные в статье Планирование развертывания служб федерации Active Directory, позволяют приступить к изменению размера ферм AD FS:

  • Если у вас меньше 1000 пользователей, не создавайте выделенные серверы, а установите AD FS на каждом из серверов DS Active Directory в облаке. Убедитесь, что у вас есть как минимум два сервера AD DS для обеспечения доступности. Создайте один сервер WAP.
  • Если у вас есть от 1000 до 15 000 пользователей, создайте два выделенных сервера AD FS и два выделенных WAP-сервера.
  • Если у вас от 15 000 до 60 000 пользователей, создайте между тремя и пятью выделенными серверами AD FS и по крайней мере двумя выделенными WAP-серверами.

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

Если вы используете внутренняя база данных Windows для хранения данных конфигурации AD FS, в ферме ограничено восемь серверов AD FS. Если вы ожидаете, что вам потребуется больше в будущем, используйте SQL Server. Дополнительные сведения см. в статье The Role of the AD FS Configuration Database (Роль базы данных конфигурации AD FS).

Надежность

Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см. в разделе "Обзор основы надежности".

Создайте ферму AD FS с как минимум двумя серверами, чтобы увеличить доступность службы. Используйте разные учетные записи для каждой виртуальной машины AD FS в ферме. Этот подход помогает убедиться, что сбой в одной учетной записи хранения не делает всю ферму недоступной.

Создайте отдельные группы доступности Azure для виртуальных машин AD FS и WAP. Убедитесь, что в каждой группе есть по крайней мере две виртуальные машины. Для каждой группы доступности нужно настроить по крайней мере два домена обновления и два домена сбоя.

Настройте подсистемы балансировки нагрузки для виртуальных машин AD FS и WAP следующим образом:

  • Используйте подсистему балансировки нагрузки Azure для обеспечения внешнего доступа к виртуальным машинам WAP и внутреннюю систему балансировки нагрузки для распределения нагрузки между серверами AD FS в ферме.

  • Передавайте на серверы AD FS и WAP только трафик с порта 443 (HTTPS).

  • Предоставьте статический IP-адрес подсистеме балансировки нагрузки.

  • Создайте проверку работоспособности для /adfs/probe с помощью HTTP. Дополнительные сведения см. в статье Hardware Load Balancer Health Checks and Web Application Proxy / AD FS 2012 R2 (Проверки работоспособности аппаратной подсистемы балансировки нагрузки и прокси-службы веб-приложения или AD FS 2012 R2).

    Примечание.

    Серверы AD FS используют протокол указания имени сервера (SNI), поэтому попытка проверки с использованием конечной точки HTTPS из подсистемы балансировки нагрузки не выполняется.

  • Добавьте запись A DNS в домен для подсистемы балансировки нагрузки AD FS. Укажите IP-адрес подсистемы балансировки нагрузки и присвойте ей имя домена (например, adfs.contoso.com). Это имя, которое клиенты и серверы WAP используют для доступа к ферме серверов AD FS.

Вы можете использовать SQL Server или внутреннюю базу данных Windows для хранения данных о конфигурации AD FS. Внутренняя база данных Windows обеспечивает основную избыточность. Изменения записываются непосредственно только в одну из баз данных AD FS в кластере AD FS, в то время как другие серверы используют репликацию по запросу, чтобы обновлять свои базы данных. Использование SQL Server обеспечивает избыточность и высокую доступность всей базы данных за счет отказоустойчивой кластеризации или зеркального отображения.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

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

Предотвратите прямой доступ серверов AD FS к Интернету. Серверы AD FS — это компьютеры, присоединенные к доменам, которые имеют полную авторизацию для предоставления маркеров безопасности. Если сервер взломан, злоумышленник может выдавать маркеры доступа всем веб-приложениям и всем серверам федерации, которые защищены AD FS. Если ваша система должна обрабатывать запросы от внешних пользователей, не подключающихся с сайтов доверенных партнеров, используйте WAP-серверы для обработки этих запросов. Дополнительные сведения см. в статье Where to Place a Federation Server Proxy (Место размещения прокси-сервера федерации).

Поместите серверы AD FS и WAP-серверы в отдельные подсети со своими брандмауэрами. Для определения правил брандмауэра можно использовать правила NSG. Все брандмауэры должны пропускать трафик через порт 443 (HTTPS).

Ограничьте прямой вход на серверы AD FS и WAP. Только сотрудники DevOps должны иметь возможность подключения. Не присоединяйте серверы WAP к домену.

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

Оптимизация затрат

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

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

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

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

службы федерации Active Directory;

Сведения о выпусках, предлагаемых идентификатором Microsoft Entra, см. в ценах на Microsoft Entra. Функция служб федерации AD доступна во всех выпусках.

Эффективность работы

Сотрудники DevOps должны быть готовы выполнить следующие задачи:

  • Управление серверами федерации, включая управление фермой AD FS, управление политикой доверия на серверах федерации и управление сертификатами, используемыми службами федерации.
  • Управление серверами WAP, включая управление фермой WAP и сертификатами.
  • Управление веб-приложениями, включая настройку проверяющих сторон, методов проверки подлинности и сопоставлений утверждений.
  • Резервное копирование компонентов AD FS.

Дополнительные сведения о DevOps см. в статье DevOps: расширение служб домен Active Directory (AD DS) в Azure.

Соавторы

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

Автор субъекта:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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