В обзоре служб федерации Active Directory (ADFS) было дано развернутое объяснение назначения и принципов работы данного сервиса. Сейчас же, пришло время познакомится с практической стороной вопроса, а именно с установкой служб ADFS. Ранее, мной уже рассматривался этот процесс, но тогда фокус статьи был смещен в сторону Exchange Server и, по прошествии времени, у меня появились замечания к качеству проработки материала.
Архитектура развертывания служб федерации Active Directory (ADFS)
Прежде чем приступить, необходимо четко представлять архитектуру разворачиваемого решения. Ниже, я выделил самые важные аспекты, которые обязательны к проработке:
- Высокая доступность
- Планирование пространства имен DNS
- Использование сертификатов безопасности
- Размещение хранилище конфигурации
Высокая доступность
Службы федерации, как и службы каталога Active Directory, выполняют роль аутентификации пользователей в приложениях. В случае отсутствия сервиса веб аутентификации, аутентификации в приложениях не будет. Этот факт сразу же диктует требование к резервированию компонентов решения. Базовый дизайн служб федерации выглядит следующим образом:
Установка служб федерации Active Directory (ADFS)
В обзоре служб федерации Active Directory (ADFS) было дано развернутое объяснение назначения и принципов работы данного сервиса. Сейчас же, пришло время познакомится с практической стороной вопроса, а именно с установкой служб ADFS. Ранее, мной уже рассматривался этот процесс, но тогда фокус статьи был смещен в сторону Exchange Server и, по прошествии времени, у меня появились замечания к качеству проработки материала.
Архитектура развертывания служб федерации Active Directory (ADFS)
Прежде чем приступить, необходимо четко представлять архитектуру разворачиваемого решения. Ниже, я выделил самые важные аспекты, которые обязательны к проработке:
- Высокая доступность
- Планирование пространства имен DNS
- Использование сертификатов безопасности
- Размещение хранилище конфигурации
Высокая доступность
Службы федерации, как и службы каталога Active Directory, выполняют роль аутентификации пользователей в приложениях. В случае отсутствия сервиса веб аутентификации, аутентификации в приложениях не будет. Этот факт сразу же диктует требование к резервированию компонентов решения. Базовый дизайн служб федерации выглядит следующим образом:
Он обусловлен дублированием компонентов, как серверов федерации, так и пограничных северов (Web Application Proxy). Внешние и внутренние запросы от клиентов будут терминироваться на балансировщиках сетевой нагрузки NLB. Это важный момент, так как игнорирование подобного дизайна может привести к серьезным последствиям. Например, если аутентификация в Office 365 или G Suite связана с ADFS и архитектура не предполагает высокую доступность, во время отказа все новые аутентификации будут провальными. Те, кто успел аутентифицироваться до отказа продолжат работу пока не истечет время жизни токена.
Планирование пространства имен DNS
Еще одним важным вопросом будет планирование DNS имен. Лучшим решение будет использование DNS Split зоны. Будет происходить дублирование внешней доменной зоны на DNS серверах контроллеров домена. Это позволит разрешать один и тот же FQDN фермы серверов федерации в разные IP (публичный и приватный). Публичный для внешних клиентов, приватный для внутренних. Схематически, это будет выглядеть следующим образом:
FQDN фермы служб федерации задается на этапе создания новой фермы ADFS, после чего потребуется настройка NLB и DNS.
Использование сертификатов безопасности
Для функционирования сервиса необходимы сертификаты безопасности. Они будут служить для поддержки SSL/TLS сессий между клиентами и сервисом, а также для внутренней коммуникации компонентов ADFS. Рекомендуется использовать сертификаты, подписанные внутренними и внешними центрами сертификатов. Сертификаты с внутреннего ЦС будут использоваться для работы серверов ADFS в периметре организации. Доверие клиентов к ним будет обеспечено PKI инфраструктурой. Внешние сертификаты, выданные внешними ЦС, должны обеспечивать работу клиентов внешних клиентов. Например, не доменные рабочие станции или мобильные телефоны.
Размещение хранилище конфигурации
Вся конфигурация фермы ADFS хранится в MSSQL базе данных. Во время развертывания сервиса, мастер предлагает один из способов ее хранения — внутренняя база Windows Internal Database (WID) или на выделенная MSSQL инфраструктура. Для подавляющего большинства установок ADFS, первый вариант является предпочтительным. Это обусловлено легкостью развертывания, отсутствием дополнительных задач по обеспечению работы SQL и маленьким количеством запросов. Именно последние является ключевым фактом при выборе размещения хранилища конфигурации. При работе с WID, будет определена master и slave ноды. Изменения в конфигурацию могут быть внесены только на master ноде. В последствии, они будут реплицированы средствами внутренней репликации ADFS на все slave ноды. В случае использования выделенной SQL инфраструктуры, изменения возможно вносить на любой из нод фермы, остальные члены их увидят и применят.
Установка служб федерации Active Directory (ADFS)
Согласно дизайну, для минимальной установки сервиса потребуется минимум 4-е сервера:
В качестве серверной ОС, я буду использовать Windows Server 2019 на борту которого службы федерации версии 5.0. Сразу же стоит сделать ремарку — более удобное администрирование сервиса предоставит редакция с GUI. Это обусловлено тем, что в пакете RSAT отсутствует GUI консоль управления сервисом. Службы ADFS можно поставить в Core редакции, но тогда все последующее управление необходимо выполнять сугубо через PowerShell.
Установка первого сервера и создание фермы ADFS
На первом сервере служб федерации выполняем установку бинарный файлов. Для этого воспользуемся следующим PowerShell командлетом:
Add-WindowsFeature ADFS-Federation
После установки, из Server Manager запускаем мастер установки служб федерации Active Directory (ADFS)
На следующем шаге необходимо задать учетные данные администратора домена Active Directory:
Перед тем как перейти к следующему шагу необходимо озвучить пару слов касаемо технических характеристик сертификата безопасности, который будет использоваться службами и клиентами ADFS для шифрования передаваемых данных:
- Сертификат должен обладать EKU «Server Authentication» и возможностью экспорта закрытого ключа. Это важно, так как на всех серверах фермы должен использоваться единый сертификат. Другими словами, после установки первого сервера фермы, сертификат подлежит экспорту и импорту на последующий сервер. Использовать разные сертификаты с не совпадающими thumbprint не представляется возможным.
- Для создания сертификата может служить шаблон веб сервера или другой на его основе. Главное, чтобы EKU был верным. Я предпочитаю использовать его более стойкую модифицированную версию с новой криптографией. Еще одним важным моментом будет правильные subject name и subject alternative name:
- В subject name и subject alternative name должно присутствовать полное доменное имя фермы ADFS, например, sts.ithelpspb.blogspot.com;
- В subject alternative name должны присутствовать записи enterpriseregistration и certauth в таком виде: enterpriseregistration.<внешнее доменное имя> и certauth.<имя ADFS>.<внешнее доменное имя> Например, enterpriseregistration.ithelpspb.blogspot.com и certauth.ithelpspb.blogspot.com:
enterpriseregistration используется для возможности клиентов регистрации посредству Workplace Join. Это даст необходимые механизмы для реализации задач условного доступа (Condition Access) в веб приложениях, аутентификация оных настроена через ADFS.
certauth предоставит возможность использовать аутентификацию посредству смарт-карт, в том числе виртуальных.
Установка ADFS может быть продолжена и на следующем шаге производим выбор сертификата SSL
На следующем шаге, необходимо выбрать учетную запись из-под которой будет работать сервис служб федерации. В качестве типа аккаунта, я рекомендую использовать Group Managed Service Accounts, далее gMSA. Подробно об этом типе можно прочитать тут. Ключевая особенность аккаунтов данного типа состоит в автоматическом обновлении пароля сервисного аккаунта на всех серверах фермы.
В случае, если в лесу Active Directory еще не разу не использовались gMSA, необходимо создать KDS Root Key для генерирования паролей gMSA. Если этого не сделать, в процессе создания будет получена следующая ошибка:
Сам же KDS Root Key создается с помощью следующего PowerShell командлета:
Права должны быть администратора предприятия. Успешным результатом его создания будет вывод его GUID:
Перейдем к следующем шагу и зададим сервисную учетную запись. В случае отсутствия gMSA в домене Active Directory, мастер установки выполнит его автоматическое создание при условии его запуска с правами администратора предприятия:
Указываем место размещение хранилище конфигурации новой фермы:
На завершающем этапе, мастер проверит введенную ранее конфигурацию перед установкой:
После чего, установка первого сервера фермы федерации ADFS завершена:
Добавление второго сервера в ферму ADFS
Добавление второго и более сервера в ферму ADFS осуществляется проще. Для успешного добавления потребуется предварительный импорт SSL сертификата, который использовался при создании новой фермы, и сетевая связность по tcp/443 с первым сервером ADFS.
Выполняем установку бинарых файлов и доходим до мастера установки ADFS. На первом шаге выбираем добавление сервера в существующею ферму ADFS:
Указываем FQDN первого сервера в фермы ADFS:
Сертификат и сервисный аккаунт указываем такие же, как и при создании первого сервера фермы:
После проверки конфигурации мастером выполняем установку:
После завершения процесса установки и конфигурирования обеих нод фермы, необходимо настроить балансировщик сетевой нагрузки. DNS записи фермы федерации, enterpriseregistration и certauth должны указывать на VIP адрес NLB балансировщика.
Установка и настройка Web Application Proxy
Установка первой и второй нод Web Application Proxy является однотипной операцией, для которой необходимо выполнить ряд условий:
- Добавление в доверенные ЦС внутреннего корневого центра сертификатов, которым подписан SSL сертификат фермы ADFS. PKI инфраструктура должна быть настроена соответствующим образом для возможности проверки CRL листов отзыва. Публикации в LDAP недостаточно, так как сервера WAP не будут являться членом домена Active Directory;
- Наличие SSL сертификата, подписанного внешним коммерческим ЦС. Рекомендую использовать SAN тип сертификатов, так как wildcard не будет покрывать домен certauth.sts.ithelpspb.blogspot.com. Напомню, он будет использоваться для аутентификации по средству смарт-карт. Минимальный набор доменов в сертификате то же что использовалось при создании сертификата для фермы ADFS + те домены, веб приложения которых планируется к публикации. Например, если речь идет об Exchnage, это может быть mail и autodiscover.
Используя PowerShell, устанавливаем бинарники служб Web Application Proxy:
После чего, открываем мастер конфигурирования Web Application Proxy из Server Manager:
Был случайно пропущен шаг по указанию расположения фермы ADFS и учетной записи. В необходимо задать FQDN фермы и учетную запись, которая обладает административными полномочиями на серверах ADFS.
На следующем шаге выбираем коммерческий SSL сертификат, который будет предоставляться внешним клиентам:
Работа мастера завершена успешно:
Аналогичным образом необходимо настроить второй сервер Web Application Proxy. Как и в случае с фермой ADFS, далее следует конфигурирование балансировщика сетевой нагрузки. DNAT c публичного IP адреса необходимо будет выполнить именно на VIP балансировщика, за которым находятся сервера WAP.
Касаемо портов, это tcp/80 и tcp/443. Интересной особенностью будет необходимость ручного создания правила для 80-го порта в локальной брандмауэре. Во время работы мастера, нужно исключение не создается.
Выводы
Хотя и правильный дизайн предполагает высокую доступность и резервирование компонентов, не всегда получается удовлетворить эти требования с материально-технической стороны. В этом случае, для развертывания не отказоустойчивой конфигурации, данный материал так же актуален. Единственная поправка будет состоять в отсутствии резервных серверов и NLB.
В статье » Установка служб федерации Active Directory (ADFS)» детально был рассмотрен процесс установки и конфигурации ADFS в отказоустойчивом режиме. Работа над материалом заняла пять недель и как результат он получился довольно объемным и детализированным. Надеюсь, он поможет в развертывании и последующему освоению данного сервиса.
