Active Directory Federation Services

Active Directory Federation Services (AD FS) — это компонент операционных систем семейства Windows Server, разработанный корпорацией Microsoft, который предоставляет службы федерации удостоверений (Identity Federation Services). AD FS реализует механизм единого входа (Single Sign-On, SSO) для доступа к приложениям и сервисам, расположенным за пределами корпоративной сети, на основе стандартов открытой аутентификации и авторизации, таких как WS-Federation, SAML 2.0, OAuth 2.0 и OpenID Connect. Основная функция AD FS — обеспечить безопасный обмен цифровыми удостоверениями между доверяющими друг другу организациями (партнёрами по федерации) без необходимости синхронизации паролей или создания дублирующих учётных записей.

История и развитие

Первая версия AD FS была выпущена вместе с Windows Server 2003 R2 как компонент Active Directory, предназначенный для обеспечения доступа к веб-приложениям в рамках федеративных отношений. Основной протокол на тот момент был WS-Federation, разработанный Microsoft как часть более широкой спецификации Web Services (WS-*). В Windows Server 2008 и 2008 R2 AD FS был значительно переработан: появилась поддержка протокола SAML 2.0, что позволило интегрироваться с продуктами других вендоров, а также улучшена поддержка атрибутов и утверждений (claims).

Начиная с Windows Server 2012, AD FS стал полноценной платформой для федерации, поддерживающей не только веб-приложения, но и мобильные устройства, а также облачные сервисы, в первую очередь Office 365 и Azure. В версии для Windows Server 2016 была добавлена поддержка OAuth 2.0 и OpenID Connect, что сделало AD FS пригодным для современных сценариев с одностраничными приложениями (SPA) и REST API. В Windows Server 2019 и 2022 фокус сместился в сторону гибридных сценариев, интеграции с Azure AD и повышения безопасности (внедрение Proof Key for Code Exchange (PKCE), улучшенное управление сессиями).

Архитектура и компоненты

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

Сервер федерации (Federation Server)

Это центральный компонент, который обрабатывает запросы на аутентификацию и авторизацию. Сервер федерации принимает токены безопасности от поставщика удостоверений (IdP), валидирует их и выдаёт токены для ресурсов (relying party). Он также управляет политиками аутентификации и правилами преобразования утверждений (claims rules). В типовой конфигурации используется несколько серверов федерации, объединённых в ферму (farm) для обеспечения отказоустойчивости и масштабирования.

Прокси сервера федерации (Federation Server Proxy)

Прокси-сервер (WAP — Web Application Proxy в Windows Server 2012 R2 и новее) размещается в периметральной сети (DMZ) и выступает в роли реверс-прокси для внешних запросов. Он принимает входящие HTTPS-запросы от клиентов из интернета, проверяет их базовую валидность и перенаправляет на внутренний сервер федерации. Прокси не хранит ключи подписи и не выполняет полную аутентификацию, что снижает риски при компрометации периметра.

Служба токенов безопасности (Security Token Service, STS)

Это логический компонент AD FS, который отвечает за создание, подписание и выдачу токенов безопасности. STS получает запрос на аутентификацию, проверяет учётные данные пользователя (через Active Directory или другой поставщик удостоверений), формирует набор утверждений (claims) и подписывает токен. Токен может быть в формате SAML, JSON Web Token (JWT) или другого поддерживаемого протокола.

База данных конфигурации (Configuration Database)

AD FS использует базу данных для хранения конфигурации фермы, включая сертификаты, доверенные отношения (trusts), правила утверждений и политики. В Windows Server 2012 и новее используется внутренняя база данных Windows Internal Database (WID) для небольших ферм или SQL Server для крупных развёртываний с высокой доступностью.

Принцип работы

Процесс федерации в AD FS можно описать на примере доступа пользователя к облачному приложению (например, Office 365).

1. Запрос ресурса: Пользователь открывает браузер и переходит по URL облачного приложения (например, portal.office.com). Приложение (relying party) не может аутентифицировать пользователя самостоятельно и перенаправляет его на сервер AD FS (IdP) с помощью HTTP-редиректа.
2. Аутентификация: Браузер пользователя попадает на сервер AD FS (через прокси, если запрос из интернета). AD FS запрашивает у пользователя учётные данные (логин/пароль, смарт-карту, сертификат, биометрию). Аутентификация выполняется против Active Directory или другого настроенного поставщика (например, Azure AD в гибридном сценарии).
3. Формирование токена: После успешной аутентификации STS AD FS формирует токен безопасности. В токен включаются утверждения (claims) — атрибуты пользователя, необходимые приложению: имя, группа, адрес электронной почты, идентификатор. Токен подписывается сертификатом AD FS.
4. Передача токена: Браузер пользователя получает токен и перенаправляется обратно в облачное приложение. Токен передаётся через HTTP POST или редирект.
5. Валидация токена: Облачное приложение получает токен, проверяет его подпись с помощью открытого ключа сертификата AD FS (который оно заранее получило через метаданные федерации), проверяет срок действия и извлекает утверждения. Если всё корректно, приложение создаёт сессию для пользователя и предоставляет доступ.

Утверждения (Claims) и правила

Основой AD FS является модель утверждений (claims-based identity). Утверждение — это пара «ключ-значение», описывающая некоторое свойство пользователя или запроса. Примеры утверждений: email: user@example.com, role: Manager, group: Domain Admins.

AD FS использует правила преобразования утверждений (claims transformation rules) для управления тем, какие утверждения извлекаются из источника (Active Directory) и как они преобразуются перед передачей в приложение. Правила бывают двух типов:

• Правила принятия (Acceptance rules): Определяют, какие утверждения от поставщика удостоверений (например, другого AD FS) принимаются.
• Правила выдачи (Issuance rules): Определяют, какие утверждения будут включены в токен, выдаваемый приложению. Правила могут быть простыми (прямое копирование атрибута AD) или сложными (агрегация, фильтрация, условное преобразование).

Протоколы и стандарты

AD FS поддерживает несколько протоколов для обеспечения совместимости с различными приложениями и системами:

• WS-Federation: Устаревающий, но всё ещё используемый протокол от Microsoft, основанный на SOAP и HTTP. Используется в основном для интеграции с SharePoint, Dynamics CRM и старыми версиями Office.
• SAML 2.0 (Security Assertion Markup Language): Открытый стандарт на основе XML, широко применяемый в корпоративных приложениях (Salesforce, Workday, SAP) и облачных сервисах. AD FS поддерживает как роль IdP (выдача SAML-токенов), так и роль поставщика услуг (SP) при необходимости.
• OAuth 2.0: Протокол авторизации, ориентированный на делегирование доступа к ресурсам. AD FS поддерживает его для современных сценариев, где клиент (например, мобильное приложение) получает токен доступа (access token) для вызова API.
• OpenID Connect (OIDC): Слой аутентификации поверх OAuth 2.0. AD FS поддерживает OIDC для одностраничных приложений (SPA) и нативных приложений, позволяя получать ID-токен (JWT) с информацией о пользователе.

Применение

AD FS широко используется в корпоративной среде для решения следующих задач:

• Единый вход в облачные сервисы: Наиболее распространённый сценарий — интеграция с Microsoft 365 (Office 365). AD FS позволяет пользователям входить в облачные приложения (Exchange Online, SharePoint Online, Teams) с использованием корпоративных учётных данных и политик безопасности (например, блокировка доступа с устройств, не соответствующих политике).
• Федерация с партнёрскими организациями: Две компании могут настроить доверительные отношения между своими AD FS, чтобы сотрудники одной компании могли получать доступ к ресурсам другой (например, к порталу поставщика или заказчика) без создания отдельных учётных записей.
• Доступ к веб-приложениям внутри организации: AD FS может выступать в роли центральной точки входа для внутренних веб-приложений, реализуя SSO и централизованное управление доступом.
• Мобильный доступ: С помощью Web Application Proxy (WAP) AD FS обеспечивает безопасный доступ к корпоративным приложениям с мобильных устройств из интернета, поддерживая такие протоколы, как OAuth 2.0 и OIDC.

Критика и ограничения

Несмотря на широкое распространение, AD FS имеет ряд недостатков и ограничений:

• Сложность развёртывания и обслуживания: Настройка AD FS требует глубоких знаний Active Directory, сертификатов, DNS и протоколов федерации. Ошибки в конфигурации могут привести к полной недоступности аутентификации.
• Зависимость от локальной инфраструктуры: AD FS является локальным компонентом, что требует наличия серверов, их обслуживания, резервирования и защиты от сбоев. Это увеличивает совокупную стоимость владения (TCO) по сравнению с облачными решениями.
• Ограниченная поддержка современных протоколов: Хотя AD FS поддерживает OAuth 2.0 и OIDC, его реализация менее гибкая и функциональная, чем у специализированных решений, таких как Azure AD или Auth0. Например, отсутствует встроенная поддержка Proof Key for Code Exchange (PKCE) в старых версиях.
• Проблемы с масштабированием: При очень большом количестве пользователей (миллионы) и приложений производительность AD FS может снижаться, а управление правилами утверждений становится сложным.
• Уязвимости безопасности: В прошлом были обнаружены критические уязвимости в AD FS, связанные с подделкой токенов (например, CVE-2021-33779), что требовало немедленного обновления. Корректная настройка сертификатов и политик безопасности критична для предотвращения атак.

Сравнение с альтернативами

AD FS часто сравнивают с другими решениями для федерации удостоверений:

• Azure Active Directory (Azure AD): Облачный сервис Microsoft, который постепенно вытесняет AD FS для многих сценариев. Azure AD проще в настройке, не требует собственной инфраструктуры, поддерживает больше протоколов и интеграций, а также предоставляет расширенные возможности защиты (условный доступ, защита от атак). Однако Azure AD не может полностью заменить AD FS в сценариях, где требуется строгая изоляция данных или локальное управление.
• Active Directory Federation Services (AD FS) vs. ADFS (другие реализации): Существуют и другие реализации служб федерации, например, Shibboleth (открытое ПО) или Okta (коммерческое облачное решение). AD FS выигрывает за счёт тесной интеграции с экосистемой Microsoft, но проигрывает в гибкости и кроссплатформенности.

Интересные факты

• AD FS был одним из первых продуктов Microsoft, реализовавших модель утверждений (claims), которая впоследствии легла в основу Azure AD.
• В Windows Server 2012 R2 AD FS и Web Application Proxy (WAP) были объединены в единую роль, что упростило развёртывание.
• AD FS может выступать не только как поставщик удостоверений (IdP), но и как поставщик услуг (SP), что позволяет создавать сложные цепочки федерации.
• Для повышения безопасности рекомендуется использовать сертификаты, выданные корпоративным центром сертификации (CA), а не самоподписанные.

Источники

• Microsoft Docs: Active Directory Federation Services (AD FS) Overview
• Windows Server 2012 R2: Active Directory Federation Services (AD FS) Deployment Guide
• «Understanding Active Directory Federation Services» — Microsoft Press
• «Active Directory: Designing, Deploying, and Running Active Directory» — Brian Desmond
• CVE-2021-33779: Active Directory Federation Services Elevation of Privilege Vulnerability