Microsoft Active Directory Federation Services

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

История

Разработка AD FS началась компанией Microsoft в начале 2000-х годов как ответ на потребность в безопасном доступе к ресурсам, расположенным за пределами контролируемой организации сети. Первая версия, AD FS 1.0, была выпущена в 2003 году для Windows Server 2003. Она была ориентирована на использование протокола WS-Federation и поддерживала только базовые сценарии федерации между двумя организациями.

В 2008 году с выходом Windows Server 2008 была представлена версия AD FS 2.0, которая стала значительно более функциональной. Она добавила поддержку протокола SAML 2.0, что позволило интегрироваться с широким кругом сторонних приложений и облачных сервисов, включая Microsoft Office 365. AD FS 2.0 также включала веб-интерфейс управления и возможность настройки правил выдачи утверждений (claims rules).

В Windows Server 2012 была выпущена версия AD FS 2.1, которая была встроена непосредственно в операционную систему и получила улучшенную интеграцию с PowerShell. Следующая версия, AD FS 3.0, появилась в Windows Server 2012 R2. Она принесла поддержку OAuth 2.0 и OpenID Connect, что сделало её пригодной для современных веб-приложений и мобильных клиентов. Также была добавлена функция многофакторной аутентификации (MFA).

В Windows Server 2016 была представлена версия AD FS 4.0, которая включала поддержку протокола Device Registration Service (DRS) для управления корпоративными устройствами, а также улучшенную интеграцию с Azure Active Directory. В Windows Server 2019 и 2022 развитие AD FS было сосредоточено на повышении безопасности, производительности и поддержке новых стандартов, таких как FIDO2.

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

AD FS работает по модели «утверждений» (claims). Утверждение — это заявление о субъекте (например, пользователе), которое содержит информацию о нём (например, адрес электронной почты, роль, идентификатор группы). Архитектура AD FS включает несколько ключевых компонентов:

Сервер федерации

Сервер федерации (Federation Server) является центральным компонентом. Он отвечает за обработку запросов аутентификации, проверку учётных данных, формирование и выдачу токенов безопасности, а также за маршрутизацию запросов между разными зонами федерации. Сервер федерации может быть развёрнут как в корпоративной сети, так и в периметре (DMZ) для обеспечения доступа из интернета.

Прокси-сервер федерации

Прокси-сервер федерации (Federation Server Proxy) — это дополнительный компонент, размещаемый в демилитаризованной зоне. Он действует как посредник между внешними клиентами и внутренним сервером федерации. Прокси-сервер не хранит учётные данные и не выполняет аутентификацию, а лишь перенаправляет запросы, обеспечивая дополнительный уровень безопасности.

База данных конфигурации

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

Модуль веб-аутентификации

Компонент, который обрабатывает HTTP-запросы, связанные с аутентификацией. Он взаимодействует с веб-сервером IIS (Internet Information Services) и обеспечивает работу протоколов WS-Federation, SAML, OAuth и OpenID Connect.

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

Процесс аутентификации через AD FS в типичном сценарии федерации выглядит следующим образом:

1. Пользователь запрашивает доступ к приложению. Пользователь открывает веб-браузер и переходит по URL-адресу приложения, которое является проверяющей стороной (Relying Party, RP).
2. Перенаправление на сервер AD FS. Приложение не имеет собственного механизма аутентификации. Оно перенаправляет пользователя на сервер федерации AD FS, передавая ему информацию о том, какой ресурс запрашивается.
3. Аутентификация на сервере AD FS. Сервер AD FS запрашивает у пользователя учётные данные (например, логин и пароль от корпоративной сети). В зависимости от конфигурации может быть запрошена дополнительная проверка (MFA).
4. Формирование токена. После успешной аутентификации сервер AD FS формирует токен безопасности, содержащий набор утверждений о пользователе (например, его имя, email, членство в группах). Токен подписывается цифровой подписью сервера AD FS.
5. Передача токена приложению. Сервер AD FS отправляет токен обратно в браузер пользователя, который перенаправляет его в приложение (проверяющую сторону).
6. Верификация токена приложением. Приложение проверяет цифровую подпись токена, чтобы убедиться, что он был выдан доверенным сервером AD FS. Затем оно извлекает утверждения из токена и использует их для авторизации пользователя (предоставления доступа к ресурсам).
7. Предоставление доступа. Если проверка прошла успешно, приложение предоставляет пользователю доступ к запрашиваемому ресурсу.

Классификация и виды

AD FS можно классифицировать по нескольким признакам:

По роли в федерации

• Поставщик удостоверений (Identity Provider, IdP). Сервер AD FS, который аутентифицирует пользователей и выдает токены. Это роль, которую выполняет AD FS в своей организации.
• Проверяющая сторона (Relying Party, RP). Приложение или сервис, который доверяет токенам, выданным AD FS, и использует их для авторизации. В контексте AD FS, проверяющая сторона — это приложение, которое настроено на использование AD FS для аутентификации.

По типу развертывания

• Локальное развертывание (On-premises). AD FS устанавливается на серверы, находящиеся в физическом или виртуальном дата-центре организации.
• Гибридное развертывание (Hybrid). AD FS используется совместно с облачными сервисами, такими как Azure Active Directory, для обеспечения единого входа в локальные и облачные приложения.

Применение

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

• Единый вход в облачные сервисы. Наиболее распространённое применение — обеспечение единого входа для пользователей в Microsoft Office 365, Salesforce, Dropbox и другие SaaS-приложения. Пользователь вводит свои корпоративные учётные данные один раз, и AD FS автоматически аутентифицирует его во всех доверенных облачных сервисах.
• Федерация между организациями. AD FS позволяет создавать доверительные отношения между двумя или более организациями. Например, компания-партнёр может предоставить своим сотрудникам доступ к определённым ресурсам другой компании, используя свои собственные учётные данные.
• Доступ к веб-приложениям внутри организации. AD FS может использоваться для централизованной аутентификации пользователей при доступе к внутренним веб-приложениям, таким как корпоративные порталы, системы управления проектами или CRM.
• Многофакторная аутентификация. AD FS поддерживает интеграцию с различными решениями MFA, включая Azure MFA, RSA SecurID и другие. Это позволяет усилить безопасность доступа к критически важным ресурсам.
• Управление устройствами. С помощью Device Registration Service (DRS) AD FS может регистрировать корпоративные устройства, что позволяет применять политики условного доступа, например, требовать, чтобы устройство было зарегистрировано в домене.

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

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

• Сложность развертывания и настройки. Для корректной работы AD FS требуется тщательная настройка DNS, сертификатов, правил брандмауэра и конфигурации веб-сервера. Это требует высокой квалификации администратора.
• Зависимость от локальной инфраструктуры. AD FS является локальным решением, что требует наличия серверного оборудования, его обслуживания, резервного копирования и обеспечения отказоустойчивости. При отказе сервера AD FS пользователи теряют доступ ко всем приложениям, использующим его для аутентификации.
• Ограниченная поддержка современных протоколов. Хотя AD FS поддерживает OAuth 2.0 и OpenID Connect, его реализация может быть менее гибкой, чем у специализированных решений, таких как Azure Active Directory или Auth0.
• Сложность управления правилами утверждений. Настройка правил выдачи утверждений (claims rules) может быть нетривиальной задачей, особенно в сложных сценариях федерации с большим количеством проверяющих сторон.
• Тенденция к замене на облачные решения. Microsoft активно продвигает Azure Active Directory как более современное и масштабируемое решение для управления удостоверениями. Многие организации, использующие AD FS, постепенно мигрируют на Azure AD, особенно для доступа к облачным сервисам.

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

• AD FS является одним из ключевых компонентов для реализации гибридной идентификации в экосистеме Microsoft, позволяя связывать локальные Active Directory с облачной Azure Active Directory.
• Протокол WS-Federation, который является основой AD FS, был разработан Microsoft совместно с IBM, BEA Systems и VeriSign в начале 2000-х годов.
• AD FS может использоваться не только для аутентификации пользователей, но и для аутентификации приложений (сервис-сервис) с использованием OAuth 2.0 и гранта client credentials.

Источники

• Microsoft Docs: Active Directory Federation Services (AD FS) Overview
• Windows Server Documentation: AD FS Deployment Guide
• Техническая документация Microsoft по протоколам WS-Federation, SAML, OAuth 2.0 и OpenID Connect
• Книга: "Active Directory Federation Services" by Steve Pate, 2012