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

  • Статья

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

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

Топология развертывания уровня "Стандартный"

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

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

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

A diagram depicting a standard A D F S topology.

Примечание.

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

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

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

  • Убедитесь, что только Администратор Active Directory и Администратор AD FS имеют права администратора в системе AD FS.
  • Уменьшите членство в группах локальных Администратор istrator на всех серверах 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, требования к синхронизации можно игнорировать.

Примечание.

Порт 49443 требуется только в том случае, если используется проверка подлинности сертификата пользователя, которая является необязательной для идентификатора Microsoft Entra и Office 365.

A diagram showing the required ports and protocols for an A D F S deployment.

Примечание.

Порт 808 (Windows Server 2012R2) или порт 1501 (Windows Server 2016+) — это Net. TCP-порт AD FS используется для локальной конечной точки WCF для передачи данных конфигурации в процесс службы и PowerShell. Этот порт можно увидеть, выполнив команду Get-AdfsProperties | выберите NetTcpPort. Это локальный порт, который не должен быть открыт в брандмауэре, но будет отображаться в сканировании портов.

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

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

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

Microsoft Entra Подключение и серверы федерации/WAP

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

Протокол Порты Description
HTTP 80 (TCP или UDP) Используется для загрузки CRL (списки отзыва сертификатов) для проверки сертификатов SSL.
HTTPS 443 (TCP или UDP) Используется для синхронизации с идентификатором Microsoft Entra.
WinRM 5985 Прослушиватель WinRM.

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

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

Протокол Порты Description
HTTPS 443 (TCP или UDP) Используется для проверки подлинности.

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

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

Протокол Порты Description
HTTPS 443 (TCP или UDP) Используется для проверки подлинности устройств.
TCP 49443 (TCP) Используется для проверки подлинности с помощью сертификата.

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

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

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

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

Min set of endpoints proxy enabled for Microsoft Entra ID / Office 365 (необязательно)

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

Конечная точка Характер использования
/adfs/ls/ Потоки проверки подлинности на основе браузера и текущие версии Microsoft Office используют эту конечную точку для проверки подлинности Microsoft Entra ID и Office 365
/adfs/services/trust/2005/usernamemixed Используется для Exchange Online с клиентами Office старше обновления Office 2013 за май 2015 г. Позже клиенты используют пассивные конечные точки \adfs\ls.
/adfs/services/trust/13/usernamemixed Используется для Exchange Online с клиентами Office старше обновления Office 2013 за май 2015 г. Позже клиенты используют пассивные конечные точки \adfs\ls.
/adfs/oauth2/ Используется для любых современных приложений (локальных или в облаке), настроенных для проверки подлинности непосредственно в AD FS (т. е. не через идентификатор Microsoft Entra)
/adfs/services/trust/mex Используется для Exchange Online с клиентами Office старше обновления Office 2013 за май 2015 г. Позже клиенты используют пассивные конечные точки \adfs\ls.
/federationmetadata/2007-06/federationmetadata.xml Требование для любых пассивных потоков; и используется идентификатором Office 365 / Microsoft Entra для проверка сертификатов 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 Подключение Health for AD FS, функцию Microsoft Entra ID P1 или P2. Microsoft Entra Подключение Health включает мониторы и оповещения, которые активируются, если компьютер AD FS или WAP отсутствует одно из важных обновлений, специально для AD FS и WAP.

Дополнительные сведения о мониторинге работоспособности ad FS см. в статье Microsoft Entra Подключение установка агента работоспособности.

Рекомендации по защите и мониторингу доверия 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 выполняется на внутренняя база данных Windows (WID) и имеет дополнительный сервер AD FS после отключения конечных точек на основном сервере, дождитесь синхронизации на вторичных узлах перед перезапуском службы AD FS на них. Используйте команду PowerShell Get-AdfsSyncProperties на вторичном узле для отслеживания последнего процесса СИНХРОНИЗАЦИи.

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

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

Включение защиты для предотвращения обхода облачной многофакторной проверки подлинности 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 MFA, выполняемый федеративным поставщиком удостоверений, когда федеративный пользователь обращается к приложению, управляемому политикой условного доступа, требующей многофакторной идентификации.

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

Свойство Description
acceptIfMfaDoneByFederatedIdp Идентификатор Microsoft Entra принимает MFA при выполнении поставщиком удостоверений. В противном случае выполняет многофакторную проверку подлинности Microsoft Entra.
enforceMfaByFederatedIdp Идентификатор Microsoft Entra принимает MFA при выполнении поставщиком удостоверений. Если нет, он перенаправляет запрос к поставщику удостоверений для выполнения MFA.
rejectMfaByFederatedIdp Идентификатор Microsoft Entra всегда выполняет многофакторную проверку подлинности Microsoft Entra и отклоняет MFA при выполнении поставщиком удостоверений.

Вы можете включить защиту, установив 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)