Рекомендации по защите служб федерации Active Directory

В этом документе приведены рекомендации по безопасному планированию и развертыванию службы федерации Active Directory (AD FS) и прокси-сервера веб-приложений (WAP). Он содержит рекомендации по дополнительным конфигурациям безопасности, конкретным вариантам использования и требованиям к безопасности.

Этот документ относится к AD FS и WAP в Windows Server 2012 R2, 2016 и 2019. Эти рекомендации можно использовать для локальной сети или в облачной размещенной среде, например Microsoft Azure.

Топология стандартного развертывания

Для развертывания в локальных средах рекомендуется стандартная топология развертывания, состоящая из следующих:

• Один или несколько серверов AD FS во внутренней корпоративной сети.
• Один или несколько серверов прокси веб-приложения (WAP) в DMZ-сети или экстрасети.

На каждом уровне AD FS и WAP оборудование или программная подсистема балансировки нагрузки помещается перед фермой серверов и обрабатывает маршрутизацию трафика. Брандмауэры помещаются перед внешним IP-адресом подсистемы балансировки нагрузки по мере необходимости.

Усиление защиты серверов AD FS

Ниже приведен список лучших практик и рекомендаций по укреплению и защите развертывания AD FS.

• Убедитесь, что только администраторы Active Directory и администраторы AD FS имеют права администратора в системе AD FS.
• Уменьшите членство в группах локальных администраторов на всех серверах AD FS.
• Требовать, чтобы все облачные администраторы использовали многофакторную проверку подлинности (MFA).
• Минимальная возможность администрирования с помощью агентов.
• Ограничение доступа к сети через брандмауэр узла.
• Убедитесь, что администраторы AD FS используют рабочие станции администрирования для защиты учетных данных.
• Поместите объекты сервера AD FS в организационную единицу верхнего уровня, которая не размещает другие серверы.
• Все объекты групповой политики, применяемые к серверам AD FS, должны применяться только к ним, а не к другим серверам. Это ограничивает потенциальное повышение привилегий путем изменения групповой политики.
• Убедитесь, что установленные сертификаты защищены от кражи (не сохраняйте их в общей папке в сети) и задайте напоминание о календаре, чтобы обеспечить их продление до истечения срока действия (истекший срок действия сертификата прерывает проверку подлинности федерации). Кроме того, мы рекомендуем защитить ключи и сертификаты подписывания в аппаратном модуле безопасности (HSM), подключенном к AD FS.
• Установите для ведения журналов наивысший уровень детализации и отправьте журналы AD FS (& security) в SIEM, чтобы сопоставить с аутентификацией AD, а также с AzureAD (или аналогичными системами).
• Удалите ненужные протоколы и функции Windows.
• Используйте длинный (>25 символов), сложный пароль для учетной записи службы AD FS. Мы рекомендуем использовать групповую управляемую учетную запись службы (gMSA) в качестве учетной записи службы, так как она удаляет необходимость управления паролем учетной записи службы с течением времени, управляя ею автоматически.
• Обновите последнюю версию AD FS для улучшения безопасности и ведения журнала (как всегда, сначала протестируйте).

Необходимые порты

На приведенной ниже схеме показаны порты брандмауэра, которые должны быть включены между компонентами развертывания AD FS и WAP. Если развертывание не включает идентификатор Microsoft Entra или Office 365, требования к синхронизации можно игнорировать.

Обмен данными между серверами федерации

Серверы федерации на ферме AD FS взаимодействуют с другими серверами фермы и серверами прокси-сервера веб-приложения (WAP) через ПОРТ HTTP 80 для синхронизации конфигурации. Убедитесь, что только эти серверы могут взаимодействовать друг с другом, и ни один другой не является мерой защиты в глубине.

Организации могут достичь этого состояния, настроив правила брандмауэра на каждом сервере. Правила должны разрешать входящий обмен данными только с IP-адресов серверов фермы и WAP-серверов. Некоторые сетевые балансировщики нагрузки (NLB) используют HTTP-порт 80 для проверки состояния отдельных серверов федерации. Убедитесь, что ip-адреса NLB включены в настроенные правила брандмауэра.

Microsoft Entra Connect и федеративные серверы/WAP

В этой таблице описываются порты и протоколы, необходимые для обмена данными между сервером Microsoft Entra Connect и серверами федерации и WAP.

WAP и серверы федерации

В этой таблице описываются порты и протоколы, необходимые для взаимодействия между серверами федерации и серверами WAP.

WAP и пользователи

В этой таблице описываются порты и протоколы, необходимые для взаимодействия между пользователями и серверами WAP.

Сведения о необходимых портах и протоколах, необходимых для гибридных развертываний, см. в разделе "Гибридные ссылочные порты подключения".

Сведения о портах и протоколах, необходимых для развертывания Microsoft Entra ID и Office 365, см. в документации по URL-адресу и диапазонам IP-адресов Office 365.

Включенные конечные точки

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

Минимальный набор конечных точек с включенным прокси-сервером для Microsoft Entra ID / Office 365 (необязательно)

Организации, развертывающие AD FS и WAP только для сценариев Идентификатора Microsoft Entra и Office 365, могут еще больше ограничить количество конечных точек AD FS, включенных на прокси-сервере, чтобы достичь более минимальной области атаки. Ниже приведен список конечных точек, которые должны быть включены на прокси-сервере в следующих сценариях:

Конечные точки AD FS можно отключить на прокси-сервере с помощью следующего командлета PowerShell:

Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/certificatemixed -Proxy $false

расширенная защита для проверки подлинности

Расширенная защита для аутентификации — это функция, которая смягчает последствия атак человека в середине (MITM) и включена по умолчанию в AD FS. Этот параметр можно проверить с помощью следующего командлета PowerShell:

Get-ADFSProperties

Свойство имеет значение ExtendedProtectionTokenCheck. Параметр по умолчанию — Allow, чтобы преимущества безопасности можно было достичь без проблем совместимости с браузерами, которые не поддерживают возможность.

Управление перегрузкой для защиты федеративной службы

Прокси-сервер службы федерации (часть WAP) обеспечивает управление перегрузкой для защиты службы AD FS от наводнения запросов. Прокси-сервер веб-приложения отклонит запросы на проверку подлинности внешнего клиента, если сервер федерации перегружен, как обнаружено задержкой между прокси-сервером веб-приложения и сервером федерации. Эта функция настроена по умолчанию с рекомендуемой пороговой задержкой. Чтобы проверить параметры, выполните следующие действия.

1. На компьютере прокси веб-приложения запустите командное окно с повышенными привилегиями.
2. Перейдите в каталог AD FS по адресу %WINDIR%\adfs\config.
3. Измените параметры управления перегрузкой с их значений по умолчанию на <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />.
4. Сохранить и закрыть файл.
5. Перезапустите службу AD FS, выполнив сначала net stop adfssrv, а затем net start adfssrv.

Инструкции по этой возможности см. в разделе "Настройка доступа экстрасети для AD FS" в Windows Server 2012 R2.

Стандартный HTTP-запрос проверяется на прокси-сервере

Прокси-сервер также выполняет следующие стандартные проверки для всего трафика:

• Сам FS-P проходит проверку подлинности в AD FS с помощью краткосрочного сертификата. В сценарии предполагаемого компрометации серверов dmz AD FS может "отозвать доверие прокси-сервера", чтобы он больше не доверял входящим запросам из потенциально скомпрометированных прокси-серверов. Отзыв доверия прокси-сервера аннулирует сертификат каждого прокси-сервера, так что он не может выполнить проверку подлинности для какой-либо цели на сервере AD FS.
• FS-P завершает все подключения и создает новое HTTP-подключение к службе AD FS во внутренней сети. Это обеспечивает буфер уровня сеанса между внешними устройствами и службой AD FS. Внешнее устройство никогда не подключается непосредственно к службе AD FS.
• FS-P выполняет проверку HTTP-запроса, которая специально фильтрует заголовки HTTP, которые не требуются службой AD FS.

Рекомендуемые конфигурации безопасности

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

Рекомендуемый способ для клиентов Microsoft Entra следить за своей инфраструктурой и поддерживать её в актуальном состоянии — это использовать Microsoft Entra Connect Health для AD FS, который является компонентом Microsoft Entra ID P1 или P2. Microsoft Entra Connect Health включает мониторы и оповещения, которые срабатывают, если компьютеру AD FS или WAP не хватает одного из важных обновлений, предназначенных специально для AD FS и WAP.

Дополнительные сведения о мониторинге работоспособности для AD FS см. в статье об установке агента Microsoft Entra Connect Health.

Рекомендации по защите и мониторингу доверия AD FS с помощью идентификатора Microsoft Entra

При федеративном подключении AD FS с идентификатором Microsoft Entra важно, чтобы конфигурация федерации (отношение доверия, настроенное между AD FS и идентификатором Microsoft Entra ID), отслеживалось внимательно, а любые необычные или подозрительные действия фиксируются. Для этого рекомендуется настроить оповещения и получать уведомления при каждом внесении изменений в конфигурацию федерации. Чтобы узнать, как настроить оповещения, см. статью "Мониторинг изменений в конфигурации федерации".

Дополнительные конфигурации безопасности

Следующие дополнительные возможности можно настроить для обеспечения большей защиты.

Защита учетных записей от «мягкой» блокировки в экстрасети

С помощью функции блокировки экстрасети в Windows Server 2012 R2 администратор AD FS может задать максимально допустимое количество неудачных запросов проверки подлинности (ExtranetLockoutThreshold) и observation window период времени (ExtranetObservationWindow). Когда достигнуто максимальное число (ExtranetLockoutThreshold) запросов проверки подлинности, AD FS перестает проверять подлинность предоставленных учетных данных учетной записи в AD FS за заданный период времени (ExtranetObservationWindow). Это действие защищает эту учетную запись от блокировки учетной записи AD, другими словами, она защищает эту учетную запись от потери доступа к корпоративным ресурсам, которые используют AD FS для проверки подлинности пользователя. Эти параметры применяются ко всем доменам, которые может аутентифицировать служба AD FS.

Для задания блокировки экстрасети AD FS можно использовать следующую команду Windows PowerShell.

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )

Дополнительные сведения об этой функции см. в разделе "Настройка блокировки экстрасети AD FS".

Отключение конечных точек Windows WS-Trust на прокси-сервере из экстрасети

Конечные точки Windows WS-Trust (/adfs/services/trust/2005/windowstransport и /adfs/services/trust/13/windowstransport) предназначены только для использования в интрасети и используют привязку WIA через HTTPS. Предоставление их экстрасети может позволить запросам к этим конечным точкам обойти защиту блокировки. Эти конечные точки должны быть отключены на прокси-сервере (т. е. отключены из экстрасети), чтобы защитить блокировку учетной записи AD с помощью следующих команд PowerShell. Нет известного влияния на конечных пользователей при отключении этих конечных точек на прокси-сервере.

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false

Дифференцировать политики доступа для доступа к интрасети и экстрасети

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

Включить требование многофакторной проверки подлинности (MFA)

AD FS можно настроить для принудительной проверки подлинности (например, многофакторной проверки подлинности) специально для запросов, поступающих через прокси-сервер, для отдельных приложений, а также для условного доступа к идентификатору Microsoft Entra ID / Office 365 и локальным ресурсам. Поддерживаемые методы MFA включают как поставщиков Microsoft Azure MF, так и сторонних поставщиков. Пользователю предлагается предоставить дополнительные сведения (например, SMS-текст, содержащий однократный код), а AD FS работает с подключаемым модулем от конкретного поставщика, чтобы разрешить доступ.

Поддерживаемые внешние поставщики MFA включают те, которые перечислены на странице "Настройка дополнительных методов проверки подлинности для AD FS ".

Включите защиту для предотвращения обхода облачной многофакторной аутентификации Microsoft Entra при федерации с Microsoft Entra ID.

Включите защиту для предотвращения обхода облачной многофакторной аутентификации Microsoft Entra при федерации с идентификатором Microsoft Entra и использовании многофакторной аутентификации Microsoft Entra для ваших федеративных пользователей.

Включение защиты федеративного домена в клиенте Microsoft Entra гарантирует, что многофакторная проверка подлинности Microsoft Entra всегда выполняется, когда федеративный пользователь обращается к приложению, управляемому политикой условного доступа, требующей многофакторной проверки подлинности. Это включает выполнение многофакторной проверки подлинности Microsoft Entra, даже если федеративный поставщик удостоверений указал (через утверждения федеративного токена), что MFA была выполнена локально. Принудительное применение многофакторной проверки подлинности Microsoft Entra каждый раз гарантирует, что скомпрометированная локальная учетная запись не может обойти многофакторную проверку подлинности Microsoft Entra, имитируя, что многофакторная проверка подлинности уже выполнена поставщиком удостоверений, и настоятельно рекомендуется, если не выполнять MFA для федеративных пользователей с помощью стороннего поставщика MFA.

Защиту можно включить, используя новый параметр безопасности federatedIdpMfaBehavior, который предоставляется как часть API MS Graph внутренней федерации или командлетов MS Graph PowerShell. Параметр federatedIdpMfaBehavior определяет, принимает ли Microsoft Entra ID многофакторную аутентификацию, выполненную федеративным поставщиком удостоверений, когда федеративный пользователь обращается к приложению, управляемому политикой условного доступа, требующей многофакторной аутентификации.

Администраторы могут выбрать одно из следующих значений:

Вы можете включить защиту, задав federatedIdpMfaBehavior как rejectMfaByFederatedIdp с помощью следующей команды.

MS GRAPH API

 PATCH /domains/{domainsId}/federationConfiguration/{internalDomainFederationId} 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

} 

Пример:

PATCH /domains/contoso.com/federationConfiguration/2a8ce608-bb34-473f-9e0f-f373ee4cbc5a 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

Пример:

Update-MgDomainFederationConfiguration -DomainId <domainsId> -InternalDomainFederationId <internalDomainFederationId> federatedIdpMfaBehavior "rejectMfaByFederatedIdp" 

Пример:

Update-MgDomainFederationConfiguration -DomainId “contoso.com” -InternalDomainFederationId “2a8ce608-bb34-473f-9e0f-f373ee4cbc5a” federatedIdpMfaBehavior "rejectMfaByFederatedIdp" 

Аппаратный модуль безопасности (HSM)

В конфигурации по умолчанию ключи AD FS, которые используются для подписывания маркеров, никогда не покидают серверы федерации в интрасети. Они никогда не присутствуют в dmZ или на прокси-компьютерах. При необходимости рекомендуется защитить эти ключи в аппаратном модуле безопасности (HSM), подключенном к AD FS. Корпорация Майкрософт не производит продукт HSM, однако есть несколько на рынке, поддерживающих AD FS. Чтобы реализовать эту рекомендацию, следуйте инструкциям поставщика по созданию сертификатов X509 для подписывания и шифрования, а затем используйте командлеты PowerShell установки AD FS, указав пользовательские сертификаты следующим образом:

Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>

где:

• CertificateThumbprint — ваш SSL-сертификат
• SigningCertificateThumbprint это ваш сертификат подписи (с защищенным ключом HSM)
• DecryptionCertificateThumbprint — сертификат шифрования (с защищенным ключом HSM)