18 подписчиков

Полное руководство по Active Directory Federation Services (ADFS)

21 января21 янв

314

11 мин

Оглавление

Введение
Зачем нужен ADFS?
Компоненты системы

Введение

ADFS (Active Directory Federation Services) — это компонент Windows Server, обеспечивающий функционал провайдера аутентификации для веб-приложений. Службы федерации AD используются для аутентификации внутренних пользователей домена в облачных и внешних сервисах.

Зачем нужен ADFS?

Несмотря на наличие Active Directory, его протоколы аутентификации (Kerberos, NTLM, LM) не предназначены для работы через интернет:

Kerberos требует членства веб-сервера в домене AD
NTLM и LM считаются недостаточно защищенными протоколами
Стандартные протоколы AD не подходят для современных веб-приложений

ADFS решает эти проблемы, выступая в роли центра выдачи маркеров доступа (claims). На основании успешной аутентификации в Active Directory, ADFS выдает цифровые удостоверения, которые затем используются для аутентификации и авторизации в веб-приложениях.

Компоненты системы

ADFS состоит из двух основных компонентов:

Active Directory Federation Services (ADFS) - основной сервер федерации
Web Application Proxy (WAP) - компонент для безопасной публикации в интернет, который:

Принимает входящие запросы из интернета
Перенаправляет их на ADFS сервер
Возвращает ответы клиенту
Может работать как реверс-прокси для публикации внутренних веб-приложений
Обеспечивает шифрование данных через TLS

Федеративное доверие в ADFS

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

Основные компоненты:

Identity Provider (IdP) - поставщик удостоверений, отвечающий за аутентификацию пользователей
Resource Provider (RP) - поставщик ресурсов, предоставляющий доступ к приложениям
Security Token Service (STS) - служба выдачи токенов безопасности
Claims Provider - служба, выдающая утверждения во время процесса входа (например, Active Directory)
Relying Party - приложение, использующее токены, выданные ADFS
Security Token - токен безопасности, содержащий утверждения о пользователе
Claims - формализованные утверждения в формате "тип-значение" о субъекте (например, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress: user@domain.com), которые имеют определенный тип из стандартной схемы URI, выдаются доверенным источником, используются для принятия решений о доступе и передаются в токене безопасности в стандартизированном формате

Процесс федеративной аутентификации:

Пользователь запрашивает доступ к приложению
Приложение перенаправляет пользователя на IdP
IdP аутентифицирует пользователя
IdP создает и подписывает токен безопасности
Токен передается приложению
Приложение проверяет токен и предоставляет доступ

Сертификаты в ADFS

SSL/TLS сертификат службы

Используется для защиты HTTPS соединений с ADFS
Требования:Для production среды должен быть от доверенного центра сертификации
Имя субъекта должно соответствовать FQDN сервера ADFS (например, sts.company.com)
Поддерживаются wildcard-сертификаты
Можно использовать один сертификат на ADFS и WAP серверах
Должен содержать закрытый ключ
Должен быть установлен в Personal store компьютера

Service Communications Certificate

Используется для защиты WCF-endpoint'ов и коммуникаций между ADFS серверами в ферме
Может быть тем же SSL сертификатом, что используется для HTTPS
В тестовой среде может быть самоподписанным
В production должен быть от доверенного центра сертификации

Token-Signing Certificate

Используется для подписи SAML токенов
Является self-signed сертификатом
Генерируется автоматически при установке ADFS
Срок действия по умолчанию 1 год
Публичная часть должна быть доступна Relying Party через федеративные метаданные

Token-Decrypting Certificate

Используется для расшифровки зашифрованных SAML токенов, полученных от Relying Party
Является self-signed сертификатом
Генерируется автоматически при установке ADFS
Срок действия по умолчанию 1 год
Публичная часть должна быть доступна Relying Party через федеративные метаданные

Примечание: Token-Signing и Token-Decrypting сертификаты являются внутренними сертификатами ADFS и не требуют установки сертификатов от доверенных центров сертификации. Их самоподписанность не влияет на безопасность, так как они используются только для криптографических операций с токенами.

Типы развертывания ADFS

Ферма ADFS с внутренней базой данных Windows Internal Database (WID)

Поддерживается во всех версиях Windows Server

Особенности:

Первый сервер является основным с базой данных для чтения/записи
Вторичные серверы содержат копию базы только для чтения
Изменения вносятся только на основном сервере
Синхронизация каждые 5 минут

Ограничения:

Максимум 5 серверов в ферме
До 100 доверительных отношений

Ферма ADFS с использованием SQL Server

Поддерживается во всех версиях Windows Server

Преимущества:

Все серверы равнозначны
Изменения можно вносить на любом сервере
Неограниченное количество серверов

Недостатки:

Сложнее в обслуживании
Зависимость от SQL Server

Установка и настройка ADFS

Предварительные требования

Выделенный сервер

ADFS должен быть установлен на отдельном сервере
Не допускается установка на контроллер домена
Не рекомендуется совмещать с другими ролями (RDS, RADIUS и т.д.)
Сервер должен быть членом домена, но не контроллером домена
Поддерживаются Windows Server 2012 R2 и новее

2. Сервисная учетная запись

Рекомендуется использовать Group Managed Service Account (gMSA)
Это лучше, чем использовать обычную доменную учетную запись для служб ADFS, потому что:

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

Поэтому Microsoft рекомендует использовать именно gMSA для служб ADFS.

# Получаем объект компьютера ADFS из AD

$server = Get-ADComputer adfs1

# Создаем gMSA аккаунт со следующими параметрами:

New-ADServiceAccount -Name gMSAADFS ` # Имя учетной записи

-DNSHostName adfs.contoso.com ` # DNS имя сервиса

-Enabled $True ` # Учетная запись активна

-ManagedPasswordIntervalInDays 30 ` # Пароль меняется каждые 30 дней

-PrincipalsAllowedToRetrieveManagedPassword $server # Только этот ADFS сервер может использовать учетку

По умолчанию gMSA учетки создаются в отдельном OU Managed Service Accounts.

Сертификат службы

Требуется SSL сертификат с:
EKU (Extended Key Usage): Server Authentication
Subject Name и SAN: FQDN ADFS сервера
Возможностью экспорта закрытого ключа
Формат: PFX
Может быть получен от внутреннего CA или внешнего центра сертификации

Процесс установки

Установка роли ADFS

# Через PowerShell

Add-WindowsFeature ADFS-Federation

# Или через Server Manager -> Add Roles and Features -> Active Directory Federation Services

2. Начальная настройка

Запустите конфигуратор ADFS (AD FS Configuration Wizard)

Выберите "Create the first federation server in a federation farm"

Укажите SSL сертификат (PFX)

Укажите сервисную учетную запись (gMSA)

Выберите тип базы данных:Windows Internal Database (WID) для небольших развертываний

Затем щелкаете, Next -> Next -> Configure. Ваш ADFS сервер развернут.

Тестирование и диагностика ADFS

Встроенная страница тестирования IdP

ADFS предоставляет встроенную страницу для тестирования аутентификации:

# Включение страницы тестирования

Set-AdfsProperties -EnableIdpInitiatedSignonPage $true

# URL для доступа

https://adfs.contoso.com/adfs/ls/IdpInitiatedSignon.aspx

Важно: Включайте эту страницу только для тестирования, в production она должна быть отключена.

Set-AdfsProperties -EnableIdpInitiatedSignonPage $false

Конечные точки (Endpoints)

ADFS использует различные конечные точки для обработки запросов:

Основные типы:

/adfs/ls - обработка запросов от веб-приложений (пассивная аутентификация)
/adfs/services/trust - обработка запросов от клиентских приложений (активная аутентификация)

# Получение списка конечных точек

Get-AdfsEndpoint

# Включение конечной точки

Enable-AdfsEndpoint -TargetAddressPath "/adfs/ls"

# Отключение конечной точки

Disable-AdfsEndpoint -TargetAddressPath "/adfs/ls"

ADFS Proxy Server

Прокси-сервер ADFS (также известный как Web Application Proxy) используется для обработки запросов из внешней сети.

Особенности:

Устанавливается в DMZ
Не выполняет аутентификацию
Только перенаправляет запросы на ADFS сервер
Защищает ADFS сервер от прямого доступа из интернета

Требования для установки:

Windows Server 2012 R2 или новее
Открытый порт 443 между прокси и ADFS
Сертификат (можно использовать тот же, что и на ADFS)
Доступ к ADFS серверу

Установка прокси-сервера:

Установить роль Web Application Proxy:

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

2. Настроить прокси с помощью Install-WebApplicationProxy:

# Публикация ADFS через WAP

Add-WebApplicationProxyApplication -ExternalPreauthentication PassThrough `

-ExternalUrl "https://external.company.com/adfs" `

-BackendServerUrl "https://internal-adfs.company.local" `

-ExternalCertificateThumbprint "CERT_THUMBPRINT" `

-Name "ADFS Proxy" `

-EnableHTTPRedirect

Процесс аутентификации

Пользователь пытается получить доступ к приложению
Приложение перенаправляет на ADFS
ADFS аутентифицирует пользователя через Active Directory
ADFS создает токен безопасности с утверждениями
Токен передается приложению
Приложение проверяет токен и предоставляет доступ

Файлы cookie при аутентификации:

MSISAuth - статус аутентификации
MSISAuthenticated - время аутентификации
MSISLoopDetectionCookie - отслеживание попыток входа
MSISSignout - очистка данных при выходе

Claims X-Ray для ADFS

Microsoft предоставляет специальный инструмент для тестирования claims:

Установка через PowerShell скрипт:

.\Install-ClaimsXray.ps1

Или настройка через консоль ADFS:Добавьте доверие для https://adfshelp.microsoft.com/ClaimsXray
Настройте необходимые claim rules
Возможности Claims X-Ray:Просмотр всех доступных claims
Тестирование правил преобразования
Проверка работы атрибутов
Анализ токенов безопасности

Анализ трафика с помощью Telerik Fiddler

Fiddler - незаменимый инструмент для анализа HTTPS трафика между клиентом и ADFS:

Настройка:Установите Fiddler
Включите HTTPS декодирование (Tools → Options → HTTPS)
Установите SSL сертификат Fiddler
Что можно анализировать:Процесс аутентификации в ADFS
Передаваемые claims и токены

Cookies аутентификации:MSISAuth
MSISAuthenticated
MSISLoopDetectionCookie
MSISSignout
Редиректы и цепочки аутентификации
Ошибки авторизации
Полезные советы:Используйте фильтры по хосту ADFS
Проверяйте заголовки безопасности
Анализируйте содержимое токенов
Отслеживайте цепочки редиректов
Типичные сценарии анализа:Отладка проблем с федерацией
Проверка корректности claims
Анализ ошибок аутентификации
Проверка безопасности соединения

Примечание: При использовании Fiddler в production среде убедитесь, что не нарушаете политики безопасности организации и не логируете чувствительные данные пользователей.