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

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

  • Высокая доступность. Возможности групп доступности Azure помогают обеспечить высокодоступную инфраструктуру.
  • Простота масштабирования . Если вам требуется более высокий уровень производительности, вы можете с легкостью перенести данные в более мощные виртуальные машины, выполнив всего несколько действий в Azure.
  • Перекрестная геоизбыточность. Благодаря перекрестной геоизбыточности Azure ваша инфраструктура будет доступна по всему миру.
  • Простота управления. Благодаря упрощенным параметрам управления на портале Azure можно очень просто и без проблем управлять своей инфраструктурой.

Принципы проектирования

Deployment design

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

  • Серверы DC/AD FS: если у вас менее 1000 пользователей, вы можете просто установить роль AD FS на контроллерах домена. Если необходимо предотвратить какое-либо влияние на производительность контроллеров домена или если у вас более 1000 пользователей, разверните AD FS на отдельных серверах.
  • Сервер WAP. Необходимо развернуть прокси-серверы веб-приложений таким образом, чтобы пользователи могли получать доступ к AD FS вне локальной сети.
  • Зона DMZ. Прокси-серверы веб-приложений будут помещены в DMZ. Доступ между DMZ и внутренней подсетью разрешен ТОЛЬКО через TCP-порт 443.
  • Балансировщики нагрузки. Чтобы обеспечить высокий уровень доступности, для серверов AD FS рекомендуется использовать внутренний балансировщик нагрузки, а для прокси-серверов веб-приложений — Azure Load Balancer.
  • Группы доступности. Чтобы обеспечить избыточность для развертывания AD FS, рекомендуется сгруппировать две или несколько виртуальных машин в группе доступности для аналогичных рабочих нагрузок. Эта конфигурация обеспечит доступность не менее одной виртуальной машины при событиях как запланированного, так и незапланированного обслуживания.
  • Учетные записи хранения. Рекомендуется использовать две учетные записи хранения. При наличии одной учетной записи хранения создается только одна точка сбоя. Таким образом, если эта учетная запись выйдет из строя (маловероятный сценарий), развертывание может стать недоступным. При наличии двух учетных записей хранения одну из них можно связать с отдельным сбоем.
  • Разделение сети: прокси-серверы веб-приложений должны быть развернуты в отдельной сети периметра. Одну виртуальную сеть можно разделить на две подсети, а затем развернуть прокси-серверы веб-приложений в изолированной подсети. Можно просто настроить параметры группы безопасности сети для каждой подсети и разрешить только требуемый обмен данными между двумя подсетями. Дополнительные сведения приведены в следующем сценарии развертывания.

Действия по развертыванию AD FS в Azure

Действия, описанные в этом разделе, представляют собой руководство по развертыванию показанной ниже инфраструктуры AD FS в Azure.

1. Развертывание сети

Как описано выше, можно создать две подсети в одной виртуальной сети или две совершенно разные виртуальные сети (VNet). В этой статье рассматривается развертывание одной виртуальной сети и ее разделение на две подсети. Сейчас это более простой подход, так как для обмена данными между двумя отдельными виртуальными сетями требуется шлюз типа "виртуальная сеть — виртуальная сеть".

1.1. Создание виртуальной сети

Create virtual network

Выберите виртуальную сеть на портале Azure. Ее и одну подсеть можно развернуть сразу же всего одним щелчком. При этом также определяется подсеть INT. Она готова для добавления виртуальных машин. Теперь необходимо добавить еще одну подсеть в сеть, т. е. подсеть DMZ. Чтобы создать подсеть DMZ, сделайте следующее:

  • Выберите созданную сеть.
  • В окне "Свойства" выберите подсеть.
  • На панели "Подсети" щелкните "Добавить".
  • Введите имя подсети и сведения об адресном пространстве, чтобы создать подсеть.

Subnet

Subnet DMZ

1.2. Создание сетевых групп безопасности

Группа безопасности сети (NSG) содержит перечень правил списка управления доступом, которые разрешают или запрещают сетевой трафик на экземпляры виртуальных машин в виртуальной сети. Группы безопасности сети можно связать с подсетями или отдельными экземплярами виртуальных машин в одной из подсетей. Если NSG связана с подсетью, правила ACL применяются ко всем экземплярам виртуальных машин в этой подсети. В этом руководстве мы создадим две группы NSG: одну для внутренней сети и одну для DMZ. Они будут называться NSG_INT и NSG_DMZ соответственно.

Create NSG

После создания NSG в ней будет 0 входящих и 0 исходящих правил. Когда роли на соответствующих серверах будут установлены и начнут работать, можно создать входящие и исходящие правила согласно требуемому уровню безопасности.

Initialize NSG

После создания групп NSG свяжите NSG_INT с подсетью INT, а NSG_DMZ — с подсетью DMZ. Ниже приведен снимок экрана для примера.

NSG configure

  • Щелкните "Подсети", чтобы открыть панель подсетей.
  • Выберите подсеть для связывания с NSG.

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

Subnets after NSG

1.3. Создание подключения к локальной среде

Для развертывания контроллера домена в Azure нам понадобится подключение к локальной среде. Azure предоставляет различные варианты подключения локальной инфраструктуры к инфраструктуре Azure:

  • Подключение "точка — сеть"
  • "сеть — сеть" между виртуальными сетями;
  • ExpressRoute

Рекомендуется использовать ExpressRoute. ExpressRoute позволяет создавать частные подключения между центрами обработки данных Azure и инфраструктурой, которая находится в локальной среде или в среде совместного расположения. Подключения ExpressRoute не проходят через общедоступный Интернет. Они отличаются повышенной надежностью, более высокой скоростью, меньшей задержкой и дополнительной безопасностью по сравнению с обычными подключениями через Интернет. Хотя рекомендуется использовать ExpressRoute, вы можете выбрать любой метод подключения, который лучше всего подходит для вашей организации. Дополнительные сведения об ExpressRoute и различных вариантах подключения с помощью ExpressRoute см. в статье Технический обзор ExpressRoute.

2. Создание учетных записей хранения

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

Create storage accounts

3. Создание групп доступности

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

  • Домены сбоя. Для виртуальных машин в одном и том же домене сбоя используется один источник питания и физический сетевой коммутатор. Рекомендуется использовать не менее 2 доменов сбоя. Значение по умолчанию — 3. Для этого развертывания его можно оставить без изменений.
  • Домены обновления. Во время обновления виртуальные машины, принадлежащие к одному домену обновления, перезапускаются вместе. Необходимо не менее 2 доменов обновления. Значение по умолчанию — 5. Для этого развертывания его можно оставить без изменений.

Availability sets

Создайте следующие группы доступности.

Группа доступности Роль Домены сбоя Домены обновления
contosodcset DC/AD FS 3 5
contosowapset WAP 3 5

4. Развертывание виртуальных машин

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

Компьютер Роль Подсеть Группа доступности Учетная запись хранения IP-адрес
contosodc1 DC/AD FS INT contosodcset contososac1 Статические
contosodc2 DC/AD FS INT contosodcset contososac2 Статические
contosowap1 WAP DMZ contosowapset contososac1 Статические
contosowap2 WAP DMZ contosowapset contososac2 Статические

Как можно заметить, группы NSG не указаны. Это объясняется тем, что в Azure можно использовать группы NSG на уровне подсети. Сетевым трафиком виртуальной машины можно управлять с помощью отдельной группы NSG, связанной с подсетью или объектом сетевой карты. Дополнительные сведения см. в статье Группа безопасности сети. При управлении DNS рекомендуется использовать статический IP-адрес. Вы можете применять Azure DNS и ссылаться на новые виртуальные машины, используя их полные доменные имена Azure, а не записи DNS для домена. После завершения развертывания панель вашей виртуальной машины должна выглядеть следующим образом:

Virtual Machines deployed

5. Настройка контроллера домена или серверов AD FS

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

Контроллер домена Роль Учетная запись хранения
contosodc1 Реплика contososac1
contosodc2 Реплика contososac2
  • Повысьте уровень двух серверов до контроллеров домена реплики с DNS.
  • Настройте серверы AD FS, установив роли AD FS с помощью диспетчера серверов.

6. Развертывание внутренней подсистемы балансировки нагрузки (ILB)

6.1. Создание внутреннего балансировщика нагрузки

Чтобы развернуть внутренний балансировщик нагрузки, выберите элемент "Балансировщики нагрузки" на портале Azure и щелкните "Добавить" (+).

Примечание

Если пункт Подсистемы балансировки нагрузки не отображается в меню, щелкните Обзор в левом нижнем углу портала и прокрутите список до пункта Подсистемы балансировки нагрузки. Щелкните желтую звездочку, чтобы добавить его в меню. Затем щелкните значок балансировщика нагрузки, чтобы открыть панель и начать настройку балансировщика нагрузки.

Browse load balancer

  • Имя. Присвойте балансировщику нагрузки любое подходящее имя.
  • Схема. Так как эта подсистема балансировки нагрузки будет размещена перед серверами AD FS и предназначена только для внутренних сетевых подключений, выберите "Внутренний".
  • Виртуальная сеть. Выберите виртуальную сеть, где развертывается AD FS.
  • Подсеть. Выберите внутреннюю подсеть.
  • Назначение IP-адресов: статический

Internal load balancer

После нажатия кнопки "Создать" развернутый внутренний балансировщик нагрузки отобразится в соответствующем списке.

Load balancers after ILB

Следующий шаг — настройка серверного пула и серверной пробы.

6.2. Настройка серверного пула внутреннего балансировщика нагрузки

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

  1. Выберите на открывшейся панели серверные пулы.
  2. На панели "Добавить серверный пул" щелкните "Добавить виртуальную машину".
  3. Откроется панель, на которой можно выбрать группу доступности.
  4. Выберите группу доступности AD FS.

Configure ILB backend pool

6.3. Настройка пробы

На панели "Параметры" внутренней подсистемы балансировки нагрузки выберите пробы работоспособности.

  1. Щелкните "Добавить".
  2. Введите сведения о пробе: а) Имя — имя пробы; б) Протокол — HTTP; в) Порт —80 (HTTP); г) Путь — /adfs/probe; д) Интервал (значение по умолчанию: 5) — это интервал, через который внутренняя подсистема балансировки нагрузки проверяет компьютеры в серверном пуле); е) Unhealthy threshold limit (Предельное пороговое значение состояния неработоспособности) — значение по умолчанию, 2 (это предельное число последовательных сбоев проверки, после которого внутренний балансировщик нагрузки объявит виртуальную машину в серверном пуле как неотвечающую и прекратит направлять к ней трафик).

Мы используем конечную точку /adfs/probe, которая была создана явно для проверки работоспособности в среде AD FS, где не поддерживается проверка полного пути HTTPS. Это значительно лучше, чем базовая проверка порта 443, которая не точно отражает состояние современного развертывания AD FS. Дополнительные сведения см. по этой ссылке https://blogs.technet.microsoft.com/applicationproxyblog/2014/10/17/hardware-load-balancer-health-checks-and-web-application-proxy-ad-fs-2012-r2/.

6.4. Создание правил балансировки нагрузки.

Чтобы обеспечить эффективную балансировку трафика, необходимо настроить во внутреннем балансировщике нагрузки правила балансировки нагрузки. Чтобы создать правило балансировки нагрузки, сделайте следующее:

  1. Выберите правило балансировки нагрузки на панели "Параметры" внутреннего балансировщика нагрузки.
  2. Щелкните "Добавить" на панели "Правила балансировки нагрузки".
  3. На панели "Добавить правило балансировки нагрузки" сделайте следующее: а) Имя — укажите имя правила; б) Протокол — выберите тип TCP; в) Порт — 443; г) Внутренний порт — 443; д) Серверный пул — выберите пул, созданный ранее для кластера AD FS; е) Проба — выберите пробу, созданную ранее для серверов AD FS.

Configure ILB balancing rules

6.5. Указание внутреннего балансировщика нагрузки для DNS

С помощью внутреннего DNS-сервера создайте запись A для внутренней подсистемы балансировки нагрузки. Запись A должна быть для службы федерации с IP-адресом, указывающим на IP-адрес внутренней подсистемы балансировки нагрузки. Например, если IP-адрес ILB равен 10.3.0.8, а установленная служба федерации fs.contoso.com, создайте запись A для fs.contoso.com, указывающую на 10.3.0.8. Это гарантирует, что все данные, преобразуемые в fs.contoso.com в конечном итоге на ILB, и они будут правильно перенаправлены.

Предупреждение

Если вы используете WID (внутренняя база данных Windows) для базы данных AD FS, это значение должно быть временно установлено для указания на основной сервер AD FS или прокси-сервер веб-приложения завершится сбоем регистрации. После успешной регистрации всех прокси-серверов web Appplication измените эту запись DNS, чтобы она указывала на подсистему балансировки нагрузки.

Примечание

Если развертывание также использует IPv6, обязательно создайте соответствующую запись AAAA.

7. Настройка прокси-сервера веб-приложения

7.1. Настройка прокси-серверов веб-приложений для получения доступа к серверам AD FS

Чтобы обеспечить доступ прокси-серверов веб-приложений к серверам AD FS за пределами внутреннего балансировщика нагрузки, создайте запись в папке %systemroot%\system32\drivers\etc\hosts для внутреннего балансировщика нагрузки. Обратите внимание, что различающееся имя должно соответствовать имени службы федерации, например fs.contoso.com, А запись IP-адреса должна быть ip-адресом подсистемы балансировки нагрузки (10.3.0.8, как показано в примере).

Предупреждение

Если вы используете WID (внутренняя база данных Windows) для базы данных AD FS, это значение следует временно задать для указания на основной сервер AD FS, или прокси-сервер веб-приложения завершится ошибкой регистрации. После успешной регистрации всех прокси-серверов web Appplication измените эту запись DNS, чтобы она указывала на подсистему балансировки нагрузки.

7.2. Установка роли прокси-сервера веб-приложения

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

8. Развертывание подсистемы балансировки нагрузки с выходом в Интернет (общедоступная версия)

8.1. Создание балансировщика нагрузки с выходом в Интернет (общедоступного)

На портале Azure выберите "Балансировщики нагрузки", а затем щелкните "Добавить". На панели "Создание подсистемы балансировки нагрузки" введите следующие сведения.

  1. Имя— имя балансировщика нагрузки.
  2. Схема — выберите "Общедоступная". Этот параметр сообщает Azure, что для балансировщика нагрузки необходим общедоступный адрес.
  3. IP-адрес— создайте IP-адрес (динамический).

Internet facing load balancer

После развертывания балансировщик нагрузки появится в списке "Балансировщики нагрузки".

Load balancer list

8.2. Назначение DNS-метки для общедоступного IP-адреса

Щелкните только что созданную запись балансировщика нагрузки на панели "Балансировщик нагрузки", чтобы открыть панель для настройки. Чтобы настроить DNS-метку для общедоступного IP-адреса, сделайте следующее:

  1. Щелкните общедоступный IP-адрес. Откроется панель общедоступного IP-адреса и его параметров.
  2. Щелкните "Конфигурация".
  3. Укажите DNS-метку. Это будет общедоступная DNS-метка, к которой можно получить доступ из любого места, например contosofs.westus.cloudapp.azure.com. Вы можете добавить запись во внешней службе DNS для службы федерации (например, fs.contoso.com), которая будет указывать на DNS-метку внешнего балансировщика нагрузки (contosofs.westus.cloudapp.azure.com).

Configure internet facing load balancer

Configure internet facing load balancer (DNS)

8.3. Настройка серверного пула для балансировщика нагрузки с выходом в Интернет (общедоступного)

Чтобы настроить серверный пул для балансировщика нагрузки с выходом в Интернет (общедоступного) в качестве группы доступности для серверов WAP, сделайте то же самое, что и при создании внутреннего балансировщика нагрузки. Например, contosowapset.

Configure backend pool of Internet Facing Load Balancer

8.4. Настройка пробы

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

Configure probe of Internet Facing Load Balancer

8.5. Создание правил балансировки нагрузки

Чтобы настроить правило балансировки нагрузки для TCP-порта 443, сделайте то же самое, что и при настройке внутреннего балансировщика нагрузки.

Configure balancing rules of Internet Facing Load Balancer

9. Защита сети

9.1. Обеспечение безопасности внутренней подсети

В целом для эффективной защиты внутренней подсети требуются следующие правила (в порядке, как показано ниже).

Правило Описание Поток
AllowHTTPSFromDMZ Разрешение взаимодействия с DMZ по протоколу HTTPS Входящий трафик
DenyInternetOutbound Нет доступа к Интернету Исходящий трафик

INT access rules (inbound)

9.2. Обеспечение защиты подсети DMZ

Правило Описание Поток
AllowHTTPSFromInternet Разрешение обмена данными между DMZ и Интернетом по протоколу HTTPS Входящий трафик
DenyInternetOutbound Блокирование всего, кроме HTTPS-трафика, поступающего в Интернет Исходящий трафик

EXT access rules (inbound)

Примечание

Если требуется проверка подлинности сертификата пользователя клиента (проверка подлинности clientTLS с использованием сертификатов пользователей X.509), ad FS требует включения tcp-порта 49443 для входящего доступа.

10. Проверка входа AD FS

Самый простой способ тестировать вход AD FS — использовать страницу IdpInitiatedSignon.aspx. Для этого необходимо включить IdpInitiatedSignOn в свойствах AD FS. Чтобы проверить установку AD FS, сделайте следующее:

  1. Запустите указанный ниже командлет на сервере AD FS с помощью PowerShell, чтобы включить страницу входа: Set-AdfsProperties -EnableIdPInitiatedSignonPage $true.
  2. Доступ к любому внешнему компьютеру https://adfs-server.contoso.com/adfs/ls/IdpInitiatedSignon.aspx.
  3. Должна появиться страница AD FS, как показано ниже.

Test login page

Если вход будет выполнен успешно, отобразится сообщение об успешном выполнении, как показано ниже.

Test success

Шаблон для развертывания AD FS в Azure

Шаблон развертывает 6 виртуальных машин, по 2 для контроллеров домена, серверов AD FS и WAP.

Шаблон для развертывания AD FS в Azure

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

Параметр Описание
Расположение Регион, в котором будут развернуты ресурсы, например East US.
StorageAccountType Тип создаваемой учетной записи хранения.
VirtualNetworkUsage Указывает, какая виртуальная сеть будет использоваться: новая или существующая.
VirtualNetworkName Имя создаваемой виртуальной сети. Это обязательный параметр как при использовании существующей виртуальной сети, так и при создании новой.
VirtualNetworkResourceGroupName Имя группы ресурсов, в которую входит существующая виртуальная сеть. Это обязательный параметр при использовании существующей виртуальной сети, так как при развертывании нужно определить идентификатор этой сети.
VirtualNetworkAddressRange Диапазон адресов новой виртуальной сети. Обязательный параметр при создании новой виртуальной сети.
InternalSubnetName Имя внутренней подсети. Это обязательный параметр как при использовании существующей виртуальной сети, так и при создании новой.
InternalSubnetAddressRange Диапазон адресов внутренней подсети, содержащей контроллеры домена и серверы AD FS, обязательный при создании новой виртуальной сети.
DMZSubnetAddressRange Диапазон адресов подсети DMZ, содержащий прокси-серверы приложения Windows. Обязательный параметр при создании новой виртуальной сети.
DMZSubnetName Имя внутренней подсети. Это обязательный параметр как при использовании существующей виртуальной сети, так и при создании новой.
ADDC01NICIPAddress Внутренний IP-адрес первого контроллера домена. Это должен быть допустимый IP-адрес в пределах внутренней подсети. Он назначается контроллеру домена статически.
ADDC02NICIPAddress Внутренний IP-адрес второго контроллера домена. Это должен быть допустимый IP-адрес в пределах внутренней подсети. Он назначается контроллеру домена статически.
ADFS01NICIPAddress Внутренний IP-адрес первого сервера AD FS, этот IP-адрес будет статически назначен серверу AD FS и должен быть допустимым IP-адресом во внутренней подсети.
ADFS02NICIPAddress Внутренний IP-адрес второго сервера AD FS, этот IP-адрес будет статически назначен серверу AD FS и должен быть допустимым IP-адресом во внутренней подсети.
WAP01NICIPAddress Внутренний IP-адрес первого сервера WAP. Это должен быть допустимый IP-адрес в пределах подсети DMZ. Он назначается серверу WAP статически.
WAP02NICIPAddress Внутренний IP-адрес второго сервера WAP. Это должен быть допустимый IP-адрес в пределах подсети DMZ. Он назначается серверу WAP статически.
ADFSLoadBalancerPrivateIPAddress Внутренний IP-адрес подсистемы балансировки нагрузки AD FS, этот IP-адрес будет статически назначен подсистеме балансировки нагрузки и должен быть допустимым IP-адресом во внутренней подсети.
ADDCVMNamePrefix Префикс имени виртуальной машины для контроллеров домена.
ADFSVMNamePrefix Префикс имени виртуальной машины для серверов AD FS
WAPVMNamePrefix Префикс имени виртуальной машины для серверов WAP.
ADDCVMSize Размер виртуальной машины контроллеров домена
ADFSVMSize Размер виртуальной машины серверов AD FS
WAPVMSize Размер виртуальной машины серверов WAP
AdminUserName Имя локального администратора виртуальных машин.
AdminPassword Имя учетной записи локального администратора виртуальных машин.

Дополнительные ресурсы

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