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

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

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

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

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

A diagram depicting a standard A D F S topology.

Примечание

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

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

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

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

Требуемые порты

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

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

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

Примечание

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

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

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

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

Azure AD Connect и серверы федерации/WAP

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

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

Серверы WAP и Федерации

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

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

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

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

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

Дополнительные сведения о необходимых портах и протоколах, необходимых для гибридных развертываний, см. в этом документе.

подробные сведения о портах и протоколах, необходимых для развертывания Azure AD и Office 365, см. в документе здесь.

Конечные точки включены

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

Используемых Минимальный набор конечных точек прокси-сервера для Azure AD/Office 365

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

Конечная точка Назначение
/адфс/лс потоки проверки подлинности на основе браузера и текущие версии Microsoft Office использовать эту конечную точку для проверки подлинности Azure AD и Office 365
/adfs/services/trust/2005/usernamemixed используется для Exchange Online с Office клиентами старше, чем Office 2013 2015 мая update. Последующие клиенты используют пассивную конечную точку \адфс\лс.
/adfs/services/trust/13/usernamemixed используется для Exchange Online с Office клиентами старше, чем Office 2013 2015 мая update. Последующие клиенты используют пассивную конечную точку \адфс\лс.
/adfs/oauth2 Он используется для любых современных приложений (локально или в облаке), настроенных для проверки подлинности непосредственно в AD FS (т. е. не через AAD).
/адфс/сервицес/труст/мекс используется для Exchange Online с Office клиентами старше, чем Office 2013 2015 мая update. Последующие клиенты используют пассивную конечную точку \адфс\лс.
/ADFS/Ls/FederationMetadata/2007-06/federationmetadata.xml Требование для всех пассивных потоков; и используется Office 365 или Azure AD для проверки сертификатов 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 по адресу%Виндир%\адфс\конфиг.
  3. Измените параметры управления перегрузкой со значений по умолчанию на <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" /> .
  4. Сохраните и закройте файл.
  5. Перезапустите службу AD FS путем запуска net stop adfssrv, а затем net start adfssrv. Руководство по этой возможности можно найти здесь.

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

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

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

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

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

сведения об установке Azure AD Connect Health для AD FS можно найти здесь.

Рекомендации по защите и мониторингу отношения доверия AD FS с Azure AD

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

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

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

Мягкая защита блокировки экстрасети для учетных записей

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

чтобы задать AD FS блокировку экстрасети (пример), можно использовать следующую команду Windows PowerShell:

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

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

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

WS-Trust конечные точки Windows (/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-адфссинкпропертиес на дополнительном узле для мониторинга процесса последней синхронизации.

Различение политик доступа для интрасети и доступа к экстрасети

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

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

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

Поддерживаемые внешние поставщики MFA включают перечисленные на этой странице, а также HDi глобальные.

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

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

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

где:

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