Развертывание служб федерации Active Directory в Azure
В службах федерации Active Directory (AD FS) представлены возможности упрощенной безопасной федерации удостоверений и единого входа. Федерация с Azure AD или O365 дает пользователям возможность выполнять проверку подлинности с использованием локальных учетных данных и получать доступ ко всем ресурсам в облаке. В связи с этим требуется высокодоступная инфраструктура AD FS, обеспечивающая доступ к ресурсам как в локальной, так и в облачной средах. С помощью развертывания AD FS в Azure можно достичь необходимого уровня доступности с минимальными усилиями. Ниже перечислены некоторые преимущества развертывания AD FS в Azure.
- Высокая доступность. Возможности групп доступности Azure помогают обеспечить высокодоступную инфраструктуру.
- Простота масштабирования . Если вам требуется более высокий уровень производительности, вы можете с легкостью перенести данные в более мощные виртуальные машины, выполнив всего несколько действий в Azure.
- Перекрестная геоизбыточность. Благодаря перекрестной геоизбыточности Azure ваша инфраструктура будет доступна по всему миру.
- Простота управления. Благодаря упрощенным параметрам управления на портале Azure можно очень просто и без проблем управлять своей инфраструктурой.
Принципы проектирования
На приведенной выше схеме показана рекомендуемая базовая топология для начала развертывания инфраструктуры 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. Создание виртуальной сети
Выберите виртуальную сеть на портале Azure. Ее и одну подсеть можно развернуть сразу же всего одним щелчком. При этом также определяется подсеть INT. Она готова для добавления виртуальных машин. Теперь необходимо добавить еще одну подсеть в сеть, т. е. подсеть DMZ. Чтобы создать подсеть DMZ, сделайте следующее:
- Выберите созданную сеть.
- В окне "Свойства" выберите подсеть.
- На панели "Подсети" щелкните "Добавить".
- Введите имя подсети и сведения об адресном пространстве, чтобы создать подсеть.
1.2. Создание сетевых групп безопасности
Группа безопасности сети (NSG) содержит перечень правил списка управления доступом, которые разрешают или запрещают сетевой трафик на экземпляры виртуальных машин в виртуальной сети. Группы безопасности сети можно связать с подсетями или отдельными экземплярами виртуальных машин в одной из подсетей. Если NSG связана с подсетью, правила ACL применяются ко всем экземплярам виртуальных машин в этой подсети. В этом руководстве мы создадим две группы NSG: одну для внутренней сети и одну для DMZ. Они будут называться NSG_INT и NSG_DMZ соответственно.
После создания NSG в ней будет 0 входящих и 0 исходящих правил. Когда роли на соответствующих серверах будут установлены и начнут работать, можно создать входящие и исходящие правила согласно требуемому уровню безопасности.
После создания групп NSG свяжите NSG_INT с подсетью INT, а NSG_DMZ — с подсетью DMZ. Ниже приведен снимок экрана для примера.
- Щелкните "Подсети", чтобы открыть панель подсетей.
- Выберите подсеть для связывания с NSG.
После завершения настройки панель подсетей будет выглядеть следующим образом:
1.3. Создание подключения к локальной среде
Для развертывания контроллера домена в Azure нам понадобится подключение к локальной среде. Azure предоставляет различные варианты подключения локальной инфраструктуры к инфраструктуре Azure:
- Подключение "точка — сеть"
- "сеть — сеть" между виртуальными сетями;
- ExpressRoute
Рекомендуется использовать ExpressRoute. ExpressRoute позволяет создавать частные подключения между центрами обработки данных Azure и инфраструктурой, которая находится в локальной среде или в среде совместного расположения. Подключения ExpressRoute не проходят через общедоступный Интернет. Они отличаются повышенной надежностью, более высокой скоростью, меньшей задержкой и дополнительной безопасностью по сравнению с обычными подключениями через Интернет. Хотя рекомендуется использовать ExpressRoute, вы можете выбрать любой метод подключения, который лучше всего подходит для вашей организации. Дополнительные сведения об ExpressRoute и различных вариантах подключения с помощью ExpressRoute см. в статье Технический обзор ExpressRoute.
2. Создание учетных записей хранения
Чтобы обеспечить высокий уровень доступности и избежать зависимости от одной учетной записи, следует создать две учетные записи хранения. Разделите виртуальные машины в каждой группе доступности на две группы, а затем назначьте для каждой группы отдельную учетную запись хранения.
3. Создание групп доступности
Для каждой роли (контроллер домена или AD FS и WAP) создайте группы доступности, содержащие как минимум две виртуальные машины. Это поможет обеспечить более высокий уровень доступности для каждой роли. При создании групп доступности крайне важно учесть следующее:
- Домены сбоя. Для виртуальных машин в одном и том же домене сбоя используется один источник питания и физический сетевой коммутатор. Рекомендуется использовать не менее 2 доменов сбоя. Значение по умолчанию — 3. Для этого развертывания его можно оставить без изменений.
- Домены обновления. Во время обновления виртуальные машины, принадлежащие к одному домену обновления, перезапускаются вместе. Необходимо не менее 2 доменов обновления. Значение по умолчанию — 5. Для этого развертывания его можно оставить без изменений.
Создайте следующие группы доступности.
| Группа доступности | Роль | Домены сбоя | Домены обновления |
|---|---|---|---|
| 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 для домена. После завершения развертывания панель вашей виртуальной машины должна выглядеть следующим образом:
5. Настройка контроллера домена или серверов AD FS
Для проверки подлинности всех входящих запросов AD FS необходимо связаться с контроллером домена. Чтобы сэкономить на дорогостоящем маршруте из Azure в локальный контроллер домена для проверки подлинности, рекомендуется развертывать реплику контроллера домена в Azure. Для обеспечения высокой доступности рекомендуется создать группу доступности, содержащую не менее 2 контроллеров домена.
| Контроллер домена | Роль | Учетная запись хранения |
|---|---|---|
| contosodc1 | Реплика | contososac1 |
| contosodc2 | Реплика | contososac2 |
- Повысьте уровень двух серверов до контроллеров домена реплики с DNS.
- Настройте серверы AD FS, установив роли AD FS с помощью диспетчера серверов.
6. Развертывание внутренней подсистемы балансировки нагрузки (ILB)
6.1. Создание внутреннего балансировщика нагрузки
Чтобы развернуть внутренний балансировщик нагрузки, выберите элемент "Балансировщики нагрузки" на портале Azure и щелкните "Добавить" (+).
Примечание
Если пункт Подсистемы балансировки нагрузки не отображается в меню, щелкните Обзор в левом нижнем углу портала и прокрутите список до пункта Подсистемы балансировки нагрузки. Щелкните желтую звездочку, чтобы добавить его в меню. Затем щелкните значок балансировщика нагрузки, чтобы открыть панель и начать настройку балансировщика нагрузки.
- Имя. Присвойте балансировщику нагрузки любое подходящее имя.
- Схема. Так как эта подсистема балансировки нагрузки будет размещена перед серверами AD FS и предназначена только для внутренних сетевых подключений, выберите "Внутренний".
- Виртуальная сеть. Выберите виртуальную сеть, где развертывается AD FS.
- Подсеть. Выберите внутреннюю подсеть.
- Назначение IP-адресов: статический
После нажатия кнопки "Создать" развернутый внутренний балансировщик нагрузки отобразится в соответствующем списке.
Следующий шаг — настройка серверного пула и серверной пробы.
6.2. Настройка серверного пула внутреннего балансировщика нагрузки
Выберите только что созданный внутренний балансировщик нагрузки на панели "Балансировщики нагрузки". Откроется панель "Параметры".
- Выберите на открывшейся панели серверные пулы.
- На панели "Добавить серверный пул" щелкните "Добавить виртуальную машину".
- Откроется панель, на которой можно выбрать группу доступности.
- Выберите группу доступности AD FS.
6.3. Настройка пробы
На панели "Параметры" внутренней подсистемы балансировки нагрузки выберите пробы работоспособности.
- Щелкните "Добавить".
- Введите сведения о пробе: а) Имя — имя пробы; б) Протокол — 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. Создание правил балансировки нагрузки.
Чтобы обеспечить эффективную балансировку трафика, необходимо настроить во внутреннем балансировщике нагрузки правила балансировки нагрузки. Чтобы создать правило балансировки нагрузки, сделайте следующее:
- Выберите правило балансировки нагрузки на панели "Параметры" внутреннего балансировщика нагрузки.
- Щелкните "Добавить" на панели "Правила балансировки нагрузки".
- На панели "Добавить правило балансировки нагрузки" сделайте следующее: а) Имя — укажите имя правила; б) Протокол — выберите тип TCP; в) Порт — 443; г) Внутренний порт — 443; д) Серверный пул — выберите пул, созданный ранее для кластера AD FS; е) Проба — выберите пробу, созданную ранее для серверов AD FS.
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 выберите "Балансировщики нагрузки", а затем щелкните "Добавить". На панели "Создание подсистемы балансировки нагрузки" введите следующие сведения.
- Имя— имя балансировщика нагрузки.
- Схема — выберите "Общедоступная". Этот параметр сообщает Azure, что для балансировщика нагрузки необходим общедоступный адрес.
- IP-адрес— создайте IP-адрес (динамический).
После развертывания балансировщик нагрузки появится в списке "Балансировщики нагрузки".
8.2. Назначение DNS-метки для общедоступного IP-адреса
Щелкните только что созданную запись балансировщика нагрузки на панели "Балансировщик нагрузки", чтобы открыть панель для настройки. Чтобы настроить DNS-метку для общедоступного IP-адреса, сделайте следующее:
- Щелкните общедоступный IP-адрес. Откроется панель общедоступного IP-адреса и его параметров.
- Щелкните "Конфигурация".
- Укажите DNS-метку. Это будет общедоступная DNS-метка, к которой можно получить доступ из любого места, например contosofs.westus.cloudapp.azure.com. Вы можете добавить запись во внешней службе DNS для службы федерации (например, fs.contoso.com), которая будет указывать на DNS-метку внешнего балансировщика нагрузки (contosofs.westus.cloudapp.azure.com).
8.3. Настройка серверного пула для балансировщика нагрузки с выходом в Интернет (общедоступного)
Чтобы настроить серверный пул для балансировщика нагрузки с выходом в Интернет (общедоступного) в качестве группы доступности для серверов WAP, сделайте то же самое, что и при создании внутреннего балансировщика нагрузки. Например, contosowapset.
8.4. Настройка пробы
Чтобы настроить пробу для серверного пула серверов WAP, сделайте то же самое, что и при настройке внутреннего балансировщика нагрузки.
8.5. Создание правил балансировки нагрузки
Чтобы настроить правило балансировки нагрузки для TCP-порта 443, сделайте то же самое, что и при настройке внутреннего балансировщика нагрузки.
9. Защита сети
9.1. Обеспечение безопасности внутренней подсети
В целом для эффективной защиты внутренней подсети требуются следующие правила (в порядке, как показано ниже).
| Правило | Описание | Поток |
|---|---|---|
| AllowHTTPSFromDMZ | Разрешение взаимодействия с DMZ по протоколу HTTPS | Входящий трафик |
| DenyInternetOutbound | Нет доступа к Интернету | Исходящий трафик |
9.2. Обеспечение защиты подсети DMZ
| Правило | Описание | Поток |
|---|---|---|
| AllowHTTPSFromInternet | Разрешение обмена данными между DMZ и Интернетом по протоколу HTTPS | Входящий трафик |
| DenyInternetOutbound | Блокирование всего, кроме HTTPS-трафика, поступающего в Интернет | Исходящий трафик |
Примечание
Если требуется проверка подлинности сертификата пользователя клиента (проверка подлинности clientTLS с использованием сертификатов пользователей X.509), ad FS требует включения tcp-порта 49443 для входящего доступа.
10. Проверка входа AD FS
Самый простой способ тестировать вход AD FS — использовать страницу IdpInitiatedSignon.aspx. Для этого необходимо включить IdpInitiatedSignOn в свойствах AD FS. Чтобы проверить установку AD FS, сделайте следующее:
- Запустите указанный ниже командлет на сервере AD FS с помощью PowerShell, чтобы включить страницу входа: Set-AdfsProperties -EnableIdPInitiatedSignonPage $true.
- Доступ к любому внешнему компьютеру https://adfs-server.contoso.com/adfs/ls/IdpInitiatedSignon.aspx.
- Должна появиться страница AD FS, как показано ниже.
Если вход будет выполнен успешно, отобразится сообщение об успешном выполнении, как показано ниже.
Шаблон для развертывания 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 | Имя учетной записи локального администратора виртуальных машин. |
Дополнительные ресурсы
- Группы доступности
- Azure Load Balancer
- Внутренняя подсистема балансировки нагрузки
- Приступая к созданию балансировщика нагрузки для Интернета в диспетчере ресурсов с помощью PowerShell
- Учетные записи хранения
- Виртуальные сети Azure
- AD FS and Web Application Proxy Links (Ссылки на ресурсы по AD FS и прокси веб-приложений)