Установка служб федерации Active Directory (ADFS)

В обзоре служб федерации Active Directory (ADFS) было дано развернутое объяснение назначения  и принципов работы данного сервиса. Сейчас же, пришло время познакомится с практической стороной вопроса, а именно с установкой служб ADFS. Ранее, мной уже рассматривался этот процесс, но тогда фокус статьи был смещен в сторону Exchange Server и, по прошествии времени,  у меня появились замечания к качеству проработки материала.

Архитектура развертывания служб федерации Active Directory (ADFS)

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

  • Высокая доступность
  • Планирование пространства имен DNS
  • Использование сертификатов безопасности
  • Размещение хранилище конфигурации

Высокая доступность

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

Архитектура высокой доступности служб федерации Active Directory (ADFS)
Архитектура высокой доступности служб федерации Active Directory (ADFS)

Он обусловлен дублированием компонентов, как серверов федерации, так и пограничных северов (Web Application Proxy). Внешние и внутренние запросы от клиентов будут терминироваться на балансировщиках сетевой нагрузки NLB. Это важный момент, так как игнорирование подобного дизайна может привести к серьезным последствиям. Например, если аутентификация в Office 365 или G Suite связана с ADFS и архитектура не предполагает высокую доступность, во время отказа все новые аутентификации будут провальными. Те, кто успел аутентифицироваться до отказа продолжат работу пока не истечет время жизни токена.

Планирование пространства имен DNS

Еще одним важным вопросом будет планирование DNS имен. Лучшим решение будет использование DNS Split зоны. Будет происходить дублирование внешней доменной зоны на DNS серверах контроллеров домена. Это позволит разрешать один и тот же FQDN фермы серверов федерации в разные IP (публичный и приватный). Публичный для внешних клиентов, приватный для внутренних. Схематически, это будет выглядеть следующим образом:

Архитектура пространства имен в службах федерации Active Directory (ADFS)
Архитектура пространства имен в службах федерации Active Directory (ADFS)

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-е сервера:

Cервера ADFS

В качестве серверной ОС, я буду использовать Windows Server 2019 на борту которого службы федерации версии 5.0. Сразу же стоит сделать ремарку — более удобное администрирование сервиса предоставит редакция с GUI. Это обусловлено тем, что в пакете RSAT отсутствует GUI консоль управления сервисом. Службы ADFS можно поставить в Core редакции, но тогда все последующее управление необходимо выполнять сугубо через PowerShell.

Установка первого сервера и создание фермы ADFS

На первом сервере служб федерации выполняем установку бинарный файлов. Для этого воспользуемся следующим PowerShell командлетом:

После установки, из Server Manager запускаем мастер установки служб федерации Active Directory (ADFS)

запуск мастера установки служб федерации Active Directory (ADFS)
Запуск мастера установки служб федерации Active Directory

На следующем шаге необходимо задать учетные данные администратора домена Active Directory:

Указание учетных данных администратора домена Active Directory
Указание учетных данных администратора домена Active Directory

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

  • Сертификат должен обладать EKU «Server Authentication» и возможностью экспорта закрытого ключа. Это важно, так как на всех серверах фермы должен использоваться единый сертификат. Другими словами, после установки первого сервера фермы, сертификат подлежит экспорту и импорту на последующий сервер. Использовать разные сертификаты с не совпадающими thumbprint не представляется возможным.
  • Для создания сертификата может служить шаблон веб сервера или другой на его основе. Главное, чтобы EKU был верным. Я предпочитаю использовать его более стойкую модифицированную версию с новой криптографией. Еще одним важным моментом будет правильные subject name и subject alternative name:
  1. В subject name и subject alternative name должно присутствовать полное доменное имя фермы ADFS, например, sts.ait.in.ua;
  2. В subject alternative name должны присутствовать записи enterpriseregistration и certauth в таком виде: enterpriseregistration.<внешнее доменное имя> и certauth.<имя ADFS>.<внешнее доменное имя>  Например, enterpriseregistration.ait.in.ua и certauth.sts.ait.in.ua:
Правильные subject name и subject alternative name в SSL сертификате ADFS
Правильные subject name и subject alternative name в SSL сертификате ADFS
Возможность экспорта сертификата служб федерации Active Directory (ADFS)
Возможность экспорта сертификата служб федерации Active Directory

enterpriseregistration используется для возможности клиентов регистрации посредству Workplace Join. Это даст необходимые механизмы для реализации задач условного доступа (Condition Access) в веб приложениях, аутентификация оных настроена через ADFS.

certauth предоставит возможность использовать аутентификацию посредству смарт-карт, в том числе виртуальных. Более подробно о виртуальных смарт-картах можно прочитать в заметке — Виртуальная смарт-карта. Используем?

Установка ADFS может быть продолжена и на следующем шаге производим выбор сертификата SSL

Выбор сертификата SSL в мастере установки служб федерации Active Directory (ADFS)
Выбор сертификата SSL в мастере установки служб федерации Active Directory

На следующем шаге, необходимо выбрать учетную запись из-под которой будет работать сервис служб федерации. В качестве типа аккаунта, я рекомендую использовать Group Managed Service Accounts, далее gMSA. Подробно об этом типе можно прочитать тут. Ключевая особенность аккаунтов данного типа состоит в автоматическом обновлении пароля сервисного аккаунта на всех серверах фермы.

В случае, если в лесу Active Directory еще не разу не использовались gMSA, необходимо создать KDS Root Key для генерирования паролей gMSA. Если этого не сделать, в процессе создания будет получена следующая ошибка:

Group Managed Service Accounts are not available because the KDS Root Key has not been set
Group Managed Service Accounts are not available because the KDS Root Key has not been set

Сам же KDS Root Key создается с помощью следующего PowerShell командлета:

Права должны быть администратора предприятия. Успешным результатом его создания будет вывод его GUID:

Перейдем к следующем шагу и зададим сервисную учетную запись. В случае отсутствия gMSA в домене Active Directory, мастер установки выполнит его автоматическое создание при условии его запуска с правами администратора предприятия:

Задание сервисного аккаунта в мастере установки служб федерации Active Directory (ADFS)
Задание сервисного аккаунта в мастере установки служб федерации Active Directory

Указываем место размещение хранилище конфигурации новой фермы:

Указание расположения SQL базы данных в мастере установки служб федерации Active Directory (ADFS)
Указание расположения SQL базы данных в мастере установки служб федерации Active Directory

На завершающем этапе, мастер проверит введенную ранее конфигурацию перед установкой:

Установка служб федерации Active Directory (ADFS)
Установка служб федерации Active Directory

После чего, установка первого сервера фермы федерации ADFS завершена:

Завершение работы мастера установки служб федерации Active Directory (ADFS)
Завершение работы мастера установки служб федерации Active Directory

Добавление второго сервера в ферму ADFS

Добавление второго и более сервера в ферму ADFS осуществляется проще. Для успешного добавления потребуется предварительный импорт SSL сертификата, который использовался при создании новой фермы, и сетевая связность по tcp/443 с первым сервером ADFS.

Выполняем установку бинарых файлов и доходим до мастера установки ADFS. На первом шаге выбираем добавление сервера в существующею ферму ADFS:

Добавление второго сервера в ферму ADFS
Добавление второго сервера в ферму ADFS

Указываем FQDN первого сервера в фермы ADFS:

Указание FQDN первого сервера в ферме ADFS
Указание FQDN первого сервера в ферме ADFS

Сертификат и сервисный аккаунт указываем такие же, как и при создании первого сервера фермы:

Задание сервисного аккаунта на втором сервере фермы ADFS
Задание сервисного аккаунта на втором сервере фермы ADFS

После проверки конфигурации мастером выполняем установку:

Успешное добавление второго сервера в ферму ADFS
Успешное добавление второго сервера в ферму 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.ait.in.ua. Напомню, он будет использоваться для аутентификации по средству смарт-карт. Минимальный набор доменов в сертификате то же что использовалось при создании сертификата для фермы ADFS + те домены, веб приложения которых планируется к публикации. Например, если речь идет об Exchnage, это может быть mail и autodiscover.
Задание имени и доменного суффикса на WAP сервере
Задание имени и доменного суффикса на WAP сервере

Используя PowerShell, устанавливаем бинарники служб Web Application Proxy:

После чего, открываем мастер конфигурирования Web Application Proxy из Server Manager:

Мастер настройки Web Application Proxy
Мастер настройки Web Application Proxy

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

На следующем шаге выбираем коммерческий SSL сертификат, который будет предоставляться внешним клиентам:

Выбор коммерческого сертификата на сервере Web Application Proxy
Выбор коммерческого сертификата на сервере Web Application Proxy

Работа мастера завершена успешно:

Успешное завершение работы мастера настройки Web Application Proxy
Успешное завершение работы мастера настройки Web Application Proxy

Аналогичным образом необходимо настроить второй сервер Web Application Proxy. Как и в случае с фермой ADFS, далее следует конфигурирование балансировщика сетевой нагрузки. DNAT c публичного IP адреса необходимо будет выполнить именно на VIP балансировщика, за которым находятся сервера WAP.

Касаемо портов, это tcp/80 и tcp/443. Интересной особенностью будет необходимость ручного создания правила для 80-го порта в локальной брандмауэре. В время работы мастера, нужно исключение не создается.

Выводы

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

В статье » Установка служб федерации Active Directory (ADFS)» детально был рассмотрен процесс установки и конфигурации ADFS в отказоустойчивом режиме.  Работа над материалом заняла две недели и как результат он получился довольно объемным и детализированным. Надеюсь, он поможет в развертывании и последующему освоению данного сервиса.

Оставить комментарий

avatar
  Подписаться  
Уведомление о