Часто задаваемые вопросы об AD FS

Инструкции по переходу на AD FS можно найти в следующих статьях:

• Переход с AD FS для Windows Server 2012 R2 на AD FS для Windows Server 2016 или более поздней версии. (Процесс совпадает с обновлением с Windows Server 2016 AD FS до Windows Server 2019 AD FS.)
  • Обновление версии AD FS в Windows Server 2016 с помощью базы данных WID
  • Обновление версии AD FS в Windows Server 2016 с помощью базы данных SQL
• Windows Server 2012 AD FS в Windows Server 2012 R2 AD FS:
  • Migrating Active Directory Federation Services Role Service to Windows Server 2012 R2 (Переход службы ролей для служб федерации Active Directory на Windows Server 2012 R2)
• AD FS 2.0 до Windows Server 2012 AD FS:
  • Migrate Active Directory Federation Services Role Services to Windows Server 2012 (Переход служб ролей для служб федерации Active Directory в Windows Server 2012)
• AD FS 1.x to AD FS 2.0:
  • Переход с AD FS 1.x на AD FS 2.0

Для перехода с AD FS 2.0 или 2.1 (для Windows Server 2008 R2 или Windows Server 2012) используйте встроенные скрипты (расположенные в папке C:\Windows\ADFS).

В Windows Server 2016 добавлена поддержка HTTP/2, однако HTTP/2 нельзя использовать для проверки подлинности сертификата клиента. Во многих сценариях AD FS выполняется проверка подлинности с помощью сертификата клиента. Кроме того, многие клиенты не поддерживают повторные запросы по протоколу HTTP/1.1. Для этого конфигурация фермы AD FS перенастраивает параметры HTTP локального сервера на HTTP/1.1. При изменении конфигурации требуется перезагрузка сервера.

Эта конфигурация поддерживается, но в ней не будут доступны новые функции AD FS 2016. Такая конфигурация может использоваться временно для перехода с AD FS 2012 R2 на AD FS 2016. Постоянно ее использовать не рекомендуется.

Да, но это связано со следующими недостатками:

• Вам потребуется вручную управлять обновлением сертификатов для подписи маркера, так как Azure AD не сможет получить доступ к метаданным федерации. Дополнительные сведения об обновлении сертификата для подписи маркера вручную см. в статье Обновление сертификатов федерации для Office 365 и Azure Active Directory.
• Вы не сможете использовать прежние потоки проверки подлинности (например, поток проверки подлинности прокси-сервера ExO).

AD FS — это система без отслеживания состояния, поэтому балансировка нагрузки для входа в систему довольно проста. Ниже приведены некоторые основные рекомендации для систем балансировки нагрузки.

• Подсистемы балансировки нагрузки не нужно настраивать с учетом соответствия IP-адресов, так как это может привести к чрезмерной нагрузке на подмножество ваших серверов в определенных сценариях Exchange Online.
• Подсистемы балансировки нагрузки не должны завершать подключения HTTPS и устанавливать новое подключение к серверу AD FS.
• Подсистемы балансировки нагрузки должны гарантировать, что подключающийся IP-адрес будет преобразован в качестве исходного IP-адреса в пакете HTTP при отправке в AD FS. Если подсистема балансировки нагрузки не может отправить исходный IP-адрес в HTTP-пакет, она должна добавить IP-адрес к заголовку X-Forwarded-For. Это нужно для того, чтобы обеспечить правильную работу с определенными функциями, которые связаны с IP-адресами (такими, как запрещенный IP-адрес и интеллектуальная блокировка экстрасети). При этом из-за неправильной настройки может снизиться уровень безопасности.
• Подсистемы балансировки нагрузки должны поддерживать SNI. В противном случае убедитесь, что в службах федерации Active Directory настроено создание привязок HTTPS для возможности работы клиентов, которые не поддерживают SNI.
• Подсистемы балансировки нагрузки должны использовать конечную точку HTTP проверки работоспособности AD FS, чтобы определить, работают ли серверы AD FS или WAP. Они должны исключаться, если не получен ответ "200 ОК".

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

Кроме того:

• При использовании одностороннего доверия лесов, например леса сети периметра (также известного как DMZ), который содержит удостоверения партнеров, рекомендуется развертывать AD FS в корпоративном лесу. Лес сети периметра можно рассматривать как отношение доверия с локальным поставщиком утверждений, подключенным через LDAP. В этом случае встроенная проверка подлинности Windows не будет работать для пользователей леса сети периметра. Им придется проходить проверку подлинности с помощью пароля, так как это единственный поддерживаемый механизм для LDAP.

  Если такой вариант вам не подходит, необходимо настроить другой сервер AD FS в лесу сети периметра. Добавьте его как отношение доверия с поставщиком утверждений на сервере AD FS в корпоративном лесу. Пользователям придется выполнять обнаружение домашней области, но встроенная проверка подлинности Windows и проверка подлинности с помощью пароля будут работать. Внесите необходимые изменения в правила выдачи AD FS в лесу сети периметра, так как AD FS в корпоративном лесу не смогут получать дополнительные сведения о пользователях из леса сети периметра.

• Отношения доверия на уровне домена поддерживаются и могут работать. Но мы настоятельно рекомендуем перейти на модель доверия на уровне леса. Кроме того, необходимо обеспечить правильную маршрутизацию по имени участника-пользователя и разрешение имен NetBIOS.

Да. Адреса IPv6 используются для знакомых и неизвестных расположений.

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

Список поставщиков, сообщивших Майкрософт о себе, приводится в этой статье. Вы можете встретить решения от поставщиков, о которых нам неизвестно, поэтому список будет дополняться.

Да, сторонние прокси-серверы могут быть размещены перед AD FS, но любой такой прокси-сервер должен поддерживать протокол MS-ADFSPIP, который будет использоваться вместо прокси-службы веб-приложения.

Ниже приведен список известных нам сторонних поставщиков. Вы можете встретить решения от поставщиков, о которых нам неизвестно, поэтому список будет дополняться.

• F5 — доступ к диспетчеру политики
• Контроллер доставки приложений Citrix (ADC)

Версию электронной таблицы для AD FS 2016 можно скачать здесь. Эту электронную таблицу можно также использовать для AD FS для Windows Server 2012 R2.

Компания Apple выпустила набор требований под названием ATS, которые могут влиять на вызовы из приложений iOS, выполняющих аутентификацию в AD FS. Вы можете проверить, соответствуют ли ваши серверы AD FS и WAP требованиям к подключению с использованием ATS. В частности, следует убедиться в том, что:

• ваши серверы AD FS и WAP поддерживают TLS 1.2;
• согласованный комплект шифров для соединения по протоколу TLS будет поддерживать совершенную прямую секретность.

Сведения о том, как включить или отключить протоколы SSL 2.0 и 3.0, а также TLS 1.0, 1.1 и 1.2, см. в статье Управление протоколами SSL/TLS и комплектами шифров для AD FS.

Чтобы серверы AD FS и WAP выполняли согласование только с теми комплектами шифров TLS, которые поддерживают ATP, вы можете отключить все другие комплекты, не указанные в списке комплектов шифров, совместимых с ATP. Чтобы отключить такие комплекты, используйте командлеты TLS для PowerShell.

Значение утверждения sub — это хэш идентификатора клиента и значение утверждения привязки.

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

Вы можете использовать настроенный маркер id_token для добавления нужной информации в сам id_token. Дополнительную информацию см. в статье Настройка утверждений, которые будут генерироваться в id_token при использовании OpenID Connect или OAuth с AD FS 2016 или более поздней версией.

Для этого сценария в AD FS 2016 добавлен специальный символ ValueType (http://www.w3.org/2001/XMLSchema#json) и escape-символ (\x22). Ниже приведен пример для правила выдачи, а также окончательные выходные данные маркера доступа.

Пример правила выдачи:

=> issue(Type = "array_in_json", ValueType = "http://www.w3.org/2001/XMLSchema#json", Value = "{\x22Items\x22:[{\x22Name\x22:\x22Apple\x22,\x22Price\x22:12.3},{\x22Name\x22:\x22Grape\x22,\x22Price\x22:3.21}],\x22Date\x22:\x2221/11/2010\x22}");

Утверждение, выданное в маркере доступа:

"array_in_json":{"Items":[{"Name":"Apple","Price":12.3},{"Name":"Grape","Price":3.21}],"Date":"21/11/2010"}

В AD FS для Windows Server 2019 можно передать значение ресурса, внедренное в параметр области. Параметр области можно упорядочить в виде списка с разделителями-пробелами, где каждая запись представляет собой структуру из ресурса и области.

AD FS для Windows Server 2019 поддерживают PKCE (ключ подтверждения для обмена кодами) для потока предоставления кода авторизации OAuth.

Поддерживается:

• aza. Если вы используете расширения протокола OAuth 2.0 для клиентов брокера и параметр области содержит область aza, сервер выдает новый основной маркер обновления и устанавливает его в поле ответа refresh_token. Он также задает для поля refresh_token_expires_in время существования нового основного маркера обновления, если он применяется.
• openid. Эта область позволяет приложению запрашивать использование протокола авторизации OpenID Connect.
• logon_cert. Эта область позволяет приложению запрашивать сертификаты входа в систему, которые можно использовать для интерактивного входа пользователей, прошедших проверку подлинности. Сервер AD FS игнорирует указанный в ответе параметр access_token и вместо него предоставляет цепочку сертификатов CMS в кодировке Base64 или полный ответ PKI. Дополнительные сведения см. в разделе об обработке запроса.
• user_impersonation. Эта область необходима для запроса маркера доступа от имени AD FS. Дополнительные сведения об использовании этой области см. в статье Создание многоуровневого приложения с использованием OBO, OAuth и AD FS 2016 или более поздней версии.

Не поддерживается:

• vpn_cert. Область позволяет приложению запрашивать сертификаты VPN, которые можно использовать для установки VPN-подключений с использованием проверки подлинности по EAP-TLS. Эта область больше не поддерживается.
• адресом электронной почты. Эта область позволяет приложению запрашивать утверждение по электронной почте для пользователя, выполнившего вход. Эта область больше не поддерживается.
• profile. Область позволяет приложению запрашивать утверждения, связанные с профилем пользователя, который выполнил вход. Эта область больше не поддерживается.

Сертификат AD FS SSL — это не сертификат связи со службой AD FS из оснастки управления AD FS. Чтобы заменить сертификат AD FS SSL, необходимо использовать PowerShell. Выполните инструкции из статьи Управление SSL-сертификатами в AD FS и WAP 2016.

Сведения о том, как включить или отключить протоколы SSL и комплекты шифров, см. в статье Управление протоколами SSL/TLS и комплектами шифров для AD FS.

• Если прокси-служба используется для передачи в AD FS запросов, использующих встроенную проверку подлинности Windows, SSL-сертификат прокси-сервера должен использовать тот же ключ, что и SSL-сертификат сервера федерации.
• Если в AD FS включено свойство ExtendedProtectionTokenCheck (оно включено по умолчанию), SSL-сертификат прокси-сервера должен использовать тот же ключ, что и SSL-сертификат сервера федерации.
• В противном случае SSL-сертификат прокси-сервера может иметь не такой ключ, как сертификат AD FS SSL, но должен соответствовать тем же требованиям.

В AD FS на экране входа в систему отображается только один метод проверки подлинности, когда приложение должно предоставить определенный URI проверки подлинности, сопоставляемый с настроенным и включенным методом проверки. Метод передается в параметре wauth в запросах WS-Federation. В запросах SAML он передается в параметре RequestedAuthnCtxRef. При этом отображается только запрошенный метод проверки подлинности (например, вход с помощью пароля).

Когда службы AD FS используются с Azure AD, приложения часто отправляют в Azure AD параметр prompt=login. В Azure AD он по умолчанию используется для запроса нового входа в AD FS с помощью пароля. Это наиболее распространенная причина, по которой вам предлагается выполнить вход в AD FS только с помощью пароля и нет варианта входа с сертификатом. Эту проблему можно легко устранить, внеся изменения в параметры федеративного домена в Azure AD.

Дополнительные сведения см. в статье Поддержка параметра prompt=login в службах федерации Active Directory.

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

См. статью Настройка браузеров для использования встроенной проверки подлинности Windows (WIA) с AD FS.

Если у вас нет политик управления доступом на основе устройства в AD FS или сертификата Windows Hello для бизнеса, зарегистрированного с помощью AD FS, вы можете отключить BrowserSsoEnabled. Параметр BrowserSsoEnabled разрешает AD FS получать от клиента основной маркер обновления, который содержит сведения об устройстве. Без этого маркера аутентификация устройств AD FS не будет работать на устройствах Windows 10.

Администраторов часто интересует, как долго действует единый вход для пользователей, прежде чем им потребуется повторно ввести учетные данные, и как регулировать этот срок. Настройки времени действия единого входа описаны в статье Параметры единого входа AD FS.

Ниже указано заданное по умолчанию время существования различных cookie-файлов и маркеров (а также параметры, которые его регулируют).

Зарегистрированные устройства

• Cookie-файлы PRT и SSO. Действуют максимум 90 дней. За время существования отвечает параметр PSSOLifeTimeMins. (Если устройство используется по крайней мере каждые 14 дней. Это окно времени контролируется DeviceUsageWindow.)

• Маркер обновления. Срок действия зависит от приведенных выше параметров.

• access_token. По умолчанию действует 1 час. Срок определяет проверяющая сторона.

• id_token. Действует столько же, сколько маркер доступа.

Незарегистрированные устройства

• Файлы cookie единого входа. По умолчанию действуют 8 часов. Срок задается параметром SSOLifetimeMins. Если включена функция "Оставаться в системе" (KMSI), значение по умолчанию составляет 24 часа. Оно регулируется параметром KMSILifetimeMins.

• Токен обновления. По умолчанию действует 8 часов или 24 часа, если включена функция "Оставаться в системе".

• access_token. По умолчанию действует 1 час. Срок определяет проверяющая сторона.

• id_token. Действует столько же, сколько маркер доступа.

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

HSTS является механизмом политики веб-безопасности. Он помогает минимизировать атаки понижения версии протокола и захват файлов cookie для служб с конечными точками HTTP и HTTPS. Этот протокол позволяет веб-серверам объявлять, что веб-браузер (или другие агенты пользователя) должны взаимодействовать с ним только по протоколу HTTPS и никогда не использовать HTTP.

Все конечные точки AD FS для трафика веб-проверки подлинности открываются исключительно по протоколу HTTPS. Таким образом службы AD FS устраняют угрозы, создаваемые механизмом политики HSTS (они не допускают понижение версии протокола до HTTP, так как в них не предусмотрены прослушиватели для HTTP). Службы AD FS также не позволяют отправлять cookie-файлы на другой сервер с конечными точками HTTP, помечая все cookie-файлы флагом Secure.

Поэтому вам не нужно использовать HSTS на сервере AD FS, так как этот протокол не позволяет понижать версию. Серверы AD FS отвечают требованиям безопасности, так как они не используют протокол HTTP и помечают файлы cookie как безопасные.

Наконец, версии AD FS 2016 (с актуальными исправлениями) и AD FS 2019 поддерживают выпуск заголовка HSTS. Чтобы настроить эту возможность, см. статью Настройка заголовков ответа безопасности HTTP с помощью AD FS.

Мы не рекомендуем завершать запросы SSL до WAP-сервера, так как в этом случае заголовок XX-MS-Forwarded-Client-IP будет содержать IP-адрес сетевого устройства, расположенного перед WAP-сервером. Ниже приведено краткое описание различных утверждений, связанных с IP-адресами, которые поддерживаются AD FS.

• X-MS-Client-IP. Сетевой IP-адрес устройства, подключенного к службе маркеров безопасности. В случае запросов экстрасети это утверждение содержит IP-адрес WAP-сервера.
• X-MS-Forwarded-Client-IP. Многозначное утверждение, которое содержит значения, передаваемые Exchange Online в AD FS. В нем также указан IP-адрес устройства, подключенного к WAP-серверу.
• Userip. Для запросов экстрасети это утверждение будет содержать значение X-MS-Forwarded-Client-IP. Для запросов интрасети это утверждение будет содержать то же значение, что и заголовок X-MS-Client-IP.

В AD FS 2016 (с актуальными исправлениями) и более поздних версиях также поддерживается чтение заголовка X-Forwarded-For. Подсистемы балансировки нагрузки или сетевые устройства, не взаимодействующие на уровне 3 (и сохраняющие IP-адрес), должны добавлять входящий IP-адрес клиента в стандартный заголовок X-Forwarded-For.

Конечная точка UserInfo AD FS всегда возвращает утверждение субъекта, как указано в стандартах OpenID Connect. Службы AD FS не поддерживают дополнительные утверждения, запрошенные через конечную точку UserInfo. Сведения о том, как получить дополнительные утверждения в токене идентификации, см. в этой статье.

Эта группа создается только в том случае, если в домене есть контроллер домена Windows Server 2016 с ролью FSMO PDC. Чтобы устранить эту ошибку, можно создать группу вручную. Выполните следующие действия, чтобы предоставить необходимые разрешения после добавления учетной записи службы в качестве члена группы:

1. Откройте оснастку Пользователи и компьютеры Active Directory.
2. В области слева щелкните правой кнопкой мыши имя домена и выберите пункт Свойства.
3. Выберите Безопасность. Если вкладка Безопасность отсутствует, выберите Дополнительные параметры в меню Вид.
4. Нажмите Дополнительно, Добавить, Выберите субъект.
5. Откроется диалоговое окно Выбор пользователей, компьютеров, учетных записей служб или групп. В поле Введите имена выбираемых объектов введите Группа администраторов предприятия. Нажмите ОК.
6. В поле со списком Применяется к выберите Дочерние объекты пользователя.
7. Внизу страницы нажмите Очистить все.
8. В разделе Свойства выберите пункты Чтение msDS-KeyCredentialLink и Запись msDS-KeyCrendentialLink.

Федеративные пользователи могут не пройти проверку подлинности в Azure AD, если они работают с приложениями, использующими библиотеку ADAL для Android. При попытке отобразить страницу входа в таком приложении произойдет исключение AuthenticationException. В браузере Chrome страница входа AD FS может быть обозначена как незащищенная.

Все версии и устройства Android не поддерживают загрузку дополнительных сертификатов из поля сертификата authorityInformationAccess. Это ограничение относится и к браузеру Chrome. Любой сертификат проверки подлинности сервера, в котором отсутствуют промежуточные сертификаты, приведет к этой ошибке, если вся цепочка сертификатов не будет передана из AD FS.

Вы можете решить эту проблему, настроив серверы AD FS и WAP для отправки необходимых промежуточных сертификатов вместе с сертификатом SSL.

При экспорте SSL-сертификата с одного компьютера, который будет импортирован в личное хранилище компьютера на серверах AD FS и WAP, убедитесь, что экспортировали закрытый ключ, и выберите файл обмена личной информацией — PKCS #12.

Также установите флажки Включить все сертификаты в путь сертификата, если это возможно и Экспортировать все расширенные свойства.

Запустите certlm.msc на серверах Windows и импортируйте PFX-файл в личное хранилище сертификатов компьютера. Это приведет к тому, что сервер передаст всю цепочку сертификатов в библиотеку ADAL.

Службы AD FS не поддерживают запросы HEAD. Приложения не должны использовать запросы HEAD к конечным точкам AD FS. Использование этих запросов может привести к непредвиденным ответам на ошибки HTTP или их задержке. Кроме того, в журнале событий AD FS могут регистрироваться непредвиденные события ошибок.

Маркер обновления выдается в том случае, если срок действия маркера, выданного поставщиком удостоверений, составляет менее часа. Чтобы получать маркер обновления, задайте значение для срока действия маркера, выдаваемого поставщиком удостоверений, превышающее 1 час.

Для шифрования маркеров проверяющей стороны используется алгоритм AES256. Изменить его нельзя.

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

На серверах WAP можно по-прежнему использовать Set-WebApplicationProxySslCertificate. На серверах AD FS необходимо использовать netsh. Выполните следующие действия:

1. Выберите нужную группу серверов AD FS 2016.

2. На выбранных серверах импортируйте новый сертификат с помощью MMC.

3. Удалите существующие сертификаты:

   А. netsh http delete sslcert hostnameport=fs.contoso.com:443

   b. netsh http delete sslcert hostnameport=localhost:443

   c. netsh http delete sslcert hostnameport=fs.contoso.com:49443

4. Добавьте новые сертификаты:

   А. netsh http add sslcert hostnameport=fs.contoso.com:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable sslctlstorename=AdfsTrustedDevices

   b. netsh http add sslcert hostnameport=localhost:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable

   c. netsh http add sslcert hostnameport=fs.contoso.com:49443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable clientcertnegotiation=Enable

5. Перезапустите службу AD FS на выбранном сервере.

6. Отключите группу серверов WAP на время обслуживания.

7. На выбранных серверах WAP импортируйте новый сертификат с помощью MMC.

8. Установите сертификат на сервере, используя следующий командлет:

   • Set-WebApplicationProxySslCertificate -Thumbprint " CERTTHUMBPRINT"

9. Перезапустите службу на выбранных прокси-серверах WAP.

10. Верните выбранные серверы WAP и AD FS в рабочую среду.

Аналогичным образом обновите остальные серверы WAP и AD FS.

Серверы AD FS и WAP поддерживают брандмауэры любого типа, которые не завершают SSL в конечной точке. Кроме того, эти серверы имеют встроенные механизмы, которые:

• помогают предотвратить распространенные веб-атаки, такие как межсайтовые сценарии;
• выполняют функции прокси-сервера для AD FS;
• соответствуют требованиям протокола MS-ADFSPIP.

В AD FS 2016 привязка маркеров включается автоматически и вызывает несколько известных проблем в сценариях с прокси-сервером и федерацией. В результате этих проблем возникает ошибка. Чтобы устранить ее, выполните следующую команду PowerShell для отключения привязки маркеров:

Set-AdfsProperties -IgnoreTokenBinding $true

После обновления до Windows Server 2019 версия конфигурации прокси веб-приложения продолжит отображаться как Windows Server 2016. В версии для Windows Server 2019 нет обновленных функций для сервера WAP. При переходе на новую версию уровень поведения фермы AD FS повышается, а для WAP-сервера она по-прежнему указывается как Windows Server 2016. В этом весь замысел.

При включении ESL AD FS отслеживают действия в учетной записи и известные расположения для пользователей в базе данных ADFSArtifactStore. Размер этой базы данных масштабируется в зависимости от числа отслеживаемых пользователей и известных расположений. Планируя включить ESL, вы можете рассчитывать на то, что размер базы данных ADFSArtifactStore будет увеличиваться на 1 ГБ для каждых 100 000 пользователей.

Если ферма AD FS использует внутреннюю базу данных Windows, файлы базы данных по умолчанию расположены в папке C:\Windows\WID\Data. Чтобы предотвратить заполнение диска, перед включением убедитесь, что на нем свободно не менее 5 ГБ. Помимо свободного места на диске, учитывайте необходимость в дополнительной оперативной памяти после включения ESL из расчета 1 ГБ на каждые 500 000 пользователей.

Текст сообщения об ошибке:

Active Directory trust enumeration was unable to enumerate one of more domains due to the following error. Enumeration will continue but the Active Directory identifier list may not be correct. Validate that all expected Active Directory identifiers are present by running Get-ADFSDirectoryProperties.

Это событие возникает, когда леса не являются доверенными, а AD FS пытаются перечислить все леса в цепочке доверенных лесов и подключиться к ним. Например, если лес A и лес B в AD FS являются доверенными, как и лес B и лес C, AD FS перечислят все три леса и попытаются найти доверие между лесами A и C. Если пользователи из леса, который вызывает ошибку, должны пройти проверку подлинности AD FS, настройте доверие между лесом AD FS и лесом, который вызывает ошибку. Если пользователям из вызывающего ошибку леса не нужно проходить проверку подлинности с помощью AD FS, эту ошибку следует игнорировать.

Текст сообщения об ошибке:

Microsoft.IdentityServer.AuthenticationFailedException: MSIS5015: Authentication of the presented token failed. Token Binding claim in token must match the binding provided by the channel.

В AD FS 2016 привязка маркеров включается автоматически и вызывает несколько известных проблем в сценариях с прокси-сервером и федерацией. В результате этих проблем возникает ошибка. Чтобы устранить ее, выполните следующую команду PowerShell для отключения привязки маркеров:

Set-AdfsProperties -IgnoreTokenBinding $true

Текст сообщения об ошибке:

System.ServiceModel.FaultException: The formatter threw an error while trying to deserialize the message: There was an error while trying to deserialize parameter schemas.microsoft.com/ws/2009/12/identityserver/protocols/policystore:maxBehaviorLevel". The InnerException message was "Invalid enum value 'Win2019' cannot be deserialized into type 'Microsoft.IdentityServer.FarmBehavior'. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

Это событие происходит при выполнении следующих двух условий:

• Ферма работает в смешанном режиме.
• AD FS 2019 предоставляют сведения о максимальном уровне поведения фермы основному серверу федерации и не распознаются сервером федерации версии 2016.

AD FS 2019 повторяют попытки указать в ферме значение Win2019 для параметра MaxBehaviorLevel, пока через 2 месяца эта информация не становится просроченной и не удаляется из фермы автоматически. Чтобы не получать это сообщение, перенесите основную роль федерации на сервер федерации последней версии. Для этого выполните инструкции из раздела Обновление фермы AD FS до уровня поведения Windows Server 2019.