Устранение неполадок единого входа в службы федерации Active Directory (AD FS) (AD FS)

Эта статья поможет устранить проблемы с единым входом (SSO) с службы федерации Active Directory (AD FS) (AD FS).

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

Область применения: службы федерации Active Directory (AD FS)
Исходный номер базы знаний: 4034932

Запрос проверки подлинности ntlm или на основе форм

Если при устранении неполадок с единым входом (SSO) с службы федерации Active Directory (AD FS) (AD FS) пользователи получили непредвиденное запрос на проверку подлинности NTLM или на основе форм, выполните действия, описанные в этой статье, чтобы устранить эту проблему.

Проверка параметров встроенной проверки подлинности Windows

Чтобы устранить эту проблему, проверка параметры встроенной проверки подлинности Windows в клиентском браузере, параметры AD FS и параметры запроса проверки подлинности.

Проверка клиентского браузера пользователя

Проверьте следующие параметры в свойствах браузера:

• На вкладке Дополнительно убедитесь, что включен параметр Включить встроенную проверку подлинности Windows .
• В разделе Безопасность>локальные сайты>интрасети>Дополнительно убедитесь, что URL-адрес AD FS находится в списке веб-сайтов.
• В разделе Безопасность > Локальный уровень интрасети > Настраиваемый уровень убедитесь, что выбран параметр Автоматический вход только в зоне интрасети .

Если вы используете Firefox, Chrome или Safari, убедитесь, что в этих браузерах включены аналогичные параметры.

Проверьте параметры AD FS

Проверьте параметр WindowsIntegratedFallback

1. Откройте Windows PowerShell с параметром Запуск от имени администратора.

2. Получите глобальную политику проверки подлинности, выполнив следующую команду:

   Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
   

3. Проверьте значение атрибута WindowsIntegratedFallbackEnabled .

Если значение равно True, ожидается проверка подлинности на основе форм. Это означает, что запрос на проверку подлинности поступает из браузера, который не поддерживает встроенную проверку подлинности Windows. См. следующий раздел о том, как обеспечить поддержку браузера.

Если значение равно False, следует ожидать встроенную проверку подлинности Windows.

Проверьте параметр WIASupportedUsersAgents

1. Получите список поддерживаемых агентов пользователей, выполнив следующую команду:

   Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
   

2. Изучите список строк агента пользователя, возвращаемых командой.

Убедитесь, что строка агента пользователя в браузере находится в списке. Если нет, добавьте строку агента пользователя, выполнив следующие действия:

1. Перейдите на страницу http://useragentstring.com/ , где будет обнаружена строка агента пользователя в браузере.

2. Получите список поддерживаемых агентов пользователей, выполнив следующую команду:

   $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
   

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

   $wiaStrings = $wiaStrings+"NewUAString"
   

   Пример:

   $wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"
   

4. Обновите параметр WIASupportedUserAgents, выполнив следующую команду:

   Set-ADFSProperties -WIASupportedUserAgents $wiaStrings
   

Проверка параметров запроса на проверку подлинности

Проверьте, указывает ли запрос на проверку подлинности на основе форм в качестве метода проверки подлинности.

1. Если запрос проверки подлинности является WS-Federation запросом, проверка, если запрос содержит wauth= urn:oasis:names:tc:SAML:1.0:am:password.
2. Если запрос проверки подлинности является запросом SAML, проверка, если запрос содержит элемент samlp:AuthnContextClassRef со значением urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

Дополнительные сведения см. в статье Общие сведения о обработчиках проверки подлинности на страницах входа AD FS.

Проверьте, является ли приложение Microsoft Online Services для Office 365

Если приложение, к которому вы хотите получить доступ, не является Microsoft Online Services, то, что вы ожидаете и контролируется входящим запросом проверки подлинности. Обратитесь к владельцу приложения, чтобы изменить поведение.

Примечание.

модули PowerShell Azure AD и MSOnline устарели с 30 марта 2024 г. Дополнительные сведения см. в статье Обновление для прекращения поддержки. После этой даты поддержка этих модулей ограничивается поддержкой миграции пакета SDK Для Microsoft Graph PowerShell и исправлениями безопасности. Устаревшие модули будут работать до 30 марта 2025 г.

Мы рекомендуем выполнить миграцию в Microsoft Graph PowerShell для взаимодействия с Microsoft Entra ID (ранее Azure AD). Распространенные вопросы о миграции см. в разделе Вопросы и ответы о миграции. Примечание: В версиях 1.0.x MSOnline может возникнуть сбой после 30 июня 2024 г.

Если приложение является Microsoft Online Services, то все, что вы испытываете, может управляться параметром PromptLoginBehavior из объекта доверенной области. Этот параметр определяет, отправляют ли клиенты Microsoft Entra командлету prompt=login в AD FS. Чтобы задать параметр PromptLoginBehavior , выполните следующие действия.

1. Откройте Windows PowerShell с параметром "Запуск от имени администратора".

2. Получите существующий параметр федерации домена, выполнив следующую команду:

   Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
   

3. Задайте параметр PromptLoginBehavior, выполнив следующую команду:

   Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>
   

   Значения параметра PromptLoginBehavior:

   1. TranslateToFreshPasswordAuth: Microsoft Entra ID отправляет wauth и wfresh в AD FS вместо prompt=login. Это приводит к запросу проверки подлинности для использования проверки подлинности на основе форм.
   2. NativeSupport: параметр prompt=login отправляется в AD FS как есть.
   3. Отключено: в AD FS ничего не отправляется.

Дополнительные сведения о команде Set-MSOLDomainFederationSettings см. в разделе поддержка параметра службы федерации Active Directory (AD FS) prompt=login.

сценарий Microsoft Entra

Если запрос на проверку подлинности, отправленный Microsoft Entra ID включает параметр prompt=login, отключите возможность prompt=login, выполнив следующую команду:

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

После выполнения этой команды Office 365 приложения не будут включать параметр prompt=login в каждом запросе проверки подлинности.

Сценарий без Microsoft Entra

Параметры запроса, такие как WAUTH и RequestedAuthNContext , в запросах на проверку подлинности могут иметь указанные методы проверки подлинности. Проверьте, нет ли других параметров запроса, принудительно применяющих непредвиденное запрос на проверку подлинности. Если это так, измените параметр запроса, чтобы использовать ожидаемый метод проверки подлинности.

Проверьте, отключен ли единый вход.

Если единый вход отключен, включите его и проверьте, устранена ли проблема.

Запрос многофакторной проверки подлинности

Чтобы устранить эту проблему, проверка, правильно ли заданы правила утверждений в проверяющей стороне для многофакторной проверки подлинности.

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

Дополнительные сведения о многофакторной проверке подлинности в AD FS см. в следующих статьях:

• Под капотом обзор многофакторной идентификации в ADFS — часть 1: политика
• Под капотом обзор многофакторной идентификации в ADFS — часть 2: MFA с учетом проверяющих сторон

Проверьте конфигурацию на сервере AD FS и проверяющей стороне

Чтобы проверка конфигурацию на сервере AD FS, проверьте глобальные дополнительные правила проверки подлинности. Чтобы проверка конфигурацию проверяющей стороны, проверьте дополнительные правила проверки подлинности для доверия проверяющей стороны.

1. Чтобы проверка конфигурацию на сервере AD FS, выполните следующую команду в окне Windows PowerShell.

   Get-ADFSAdditionalAuthenticationRule
   

   Чтобы проверка конфигурацию на проверяющей стороне, выполните следующую команду:

   Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
   

   Примечание.

   Если команды ничего не возвращают, дополнительные правила проверки подлинности не настроены. Пропустите этот раздел.

2. Просмотрите настроенный набор правил утверждений.

Проверьте, включена ли многофакторная проверка подлинности в наборе правил утверждений.

Набор правил утверждений состоит из следующих разделов:

• Оператор условия: C:[Type=``…,Value=…]
• Оператор проблемы: => issue (Type=``…,Value=…)

Если инструкция проблемы содержит следующее утверждение, указывается многофакторная проверка подлинности.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Ниже приведены примеры, в которых требуется использовать многофакторную проверку подлинности для устройств, присоединенных к рабочему месту, и для доступа к экстрасети соответственно:

• c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")
• c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

Проверка правил выдачи проверяющей стороны

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

1. Выполните в Windows PowerShell следующую команду:

   Get-ADFSRelyingPartyTrust -TargetName ClaimApp
   

2. Просмотрите набор правил, определенный в атрибутах IssuanceAuthorizationRules или IssuanceAuthorizationRulesFile.

Набор правил должен включать следующее правило выдачи для прохождения утверждений многофакторной проверки подлинности:
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==" http://schemas.microsoft.com/claims/multipleauthn"]=>issue(claim = c)

Проверка параметра запроса проверки подлинности

Проверьте, указывает ли запрос на проверку подлинности многофакторную проверку подлинности в качестве метода проверки подлинности.

• Если запрос на проверку подлинности является запросом WS-Federation, проверка, если запрос содержит wauth= http://schemas.microsoft.com/claims/multipleauthn.
• Если запрос проверки подлинности является запросом SAML, проверка, если запрос содержит элемент samlp:AuthnContextClassRef со значением http://schemas.microsoft.com/claims/multipleauthn.

Дополнительные сведения см. в статье Общие сведения о обработчиках проверки подлинности на страницах входа AD FS.

Проверьте, является ли приложение Microsoft Online Services для Office 365

Если вы хотите получить доступ к приложению Microsoft Online Services для Office 365, проверка параметр федерации домена SupportsMFA.

1. Получите текущий параметр федерации домена SupportsMFA, выполнив следующую команду:

   Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
   

2. Если параметр SupportsMFA имеет значение FALSE, задайте для него значение TRUE, выполнив следующую команду:

   Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
   

Проверьте, отключен ли единый вход.

Если единый вход отключен, включите его и проверьте, устранена ли проблема.

Пользователи не могут войти на целевой сайт или в службу

Эта проблема может возникнуть на странице входа AD FS или на стороне приложения.

Если проблема возникает на странице входа AD FS, вы получите сообщение "Произошла ошибка", "Служба HTTP 503 недоступна" или другое сообщение об ошибке. В URL-адресе страницы ошибки отображается имя службы AD FS, например fs.contoso.com.

Если проблема возникает на стороне приложения, в URL-адресе страницы ошибки отображается IP-адрес или имя сайта целевой службы.

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

Эта проблема возникает на странице входа AD FS

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

Проблема затрагивает всех пользователей, и пользователь не может получить доступ ни к одной из проверяющих сторон

Давайте проверка функции внутреннего входа с помощью IdpInitiatedSignOn. Для этого используйте страницу IdpInititatedSignOn, чтобы проверить, работает ли служба AD FS и правильно ли работает функция проверки подлинности. Чтобы открыть страницу IdpInitiatedSignOn, выполните следующие действия:

1. Включите страницу IdpInitiatedSignOn, выполнив следующую команду на сервере AD FS:

   Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
   

2. На компьютере, который находится в вашей сети, перейдите на следующую страницу:
   https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

3. Введите правильные учетные данные допустимого пользователя на странице входа.

Вход выполнен успешно

Если вход выполнен успешно, проверка, если служба AD FS запущена.

1. На сервере AD FS откройте диспетчер сервера.
2. В диспетчер сервера щелкните Сервис>Службы.
3. Проверьте, имеет ли значение Состояниеслужбы федерации Active Directory (AD FS)выполняется.

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

1. Включите страницу IdpInitiatedSignOn, выполнив следующую команду на сервере AD FS:

   Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
   

2. На компьютере, который находится за пределами вашей сети, перейдите на следующую страницу:
   https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

3. Введите правильные учетные данные допустимого пользователя на странице входа.

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

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

Вход завершился неудачно

Если вход завершился неудачно, проверка связанные с AD FS компоненты и службы.

Проверьте, запущено ли состояние службы AD FS.

1. На сервере AD FS откройте диспетчер сервера.
2. В диспетчер сервера щелкните Сервис>Службы.
3. Проверьте, имеет ли значение Состояниеслужбы федерации Active Directory (AD FS)выполняется.

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

1. На сервере AD FS откройте консоль управления AD FS.

2. Разверните узелКонечные точкислужбы>.

3. Найдите конечные точки и проверьте, включены ли состояния в столбце Включено .

   

Затем проверка, установлен ли Microsoft Entra Connect. Рекомендуется использовать Microsoft Entra Connect, что упрощает управление SSL-сертификатами.

Если установлено Microsoft Entra Connect, убедитесь, что он используется для управления SSL-сертификатами и их обновления.

Если Microsoft Entra Connect не установлен, проверка, соответствует ли SSL-сертификат следующим требованиям AD FS:

• Сертификат получен из доверенного корневого центра сертификации.

  Ad FS требует, чтобы SSL-сертификаты были из доверенного корневого центра сертификации. Если доступ к AD FS осуществляется с компьютеров, не присоединенных к домену, рекомендуется использовать SSL-сертификат из доверенного стороннего корневого центра сертификации, например DigiCert, VeriSign и т. д. Если SSL-сертификат не является доверенным корневым центром сертификации, обмен данными ПО SSL может нарушиться.

• Допустимое имя субъекта сертификата.

  Имя субъекта должно соответствовать имени службы федерации, а не имени сервера AD FS или другому имени. Чтобы получить имя службы федерации, выполните следующую команду на основном сервере AD FS:
  Get-AdfsProperties | select hostname

• Сертификат не отозван.

  Проверьте отзыв сертификата. Если сертификат отозван, SSL-подключение не может быть доверенным и будет заблокировано клиентами.

Если SSL-сертификат не соответствует этим требованиям, попробуйте получить квалифицированный сертификат для связи ПО SSL. Рекомендуется использовать Microsoft Entra Connect, что упрощает управление SSL-сертификатами. См. раздел Обновление TLS/SSL-сертификата для фермы службы федерации Active Directory (AD FS) (AD FS).

Если SSL-сертификат соответствует этим требованиям, проверка следующие конфигурации SSL-сертификата.

Проверка правильности установки SSL-сертификата

SSL-сертификат должен быть установлен в личное хранилище для локального компьютера на каждом сервере федерации в ферме. Чтобы установить сертификат, дважды щелкните . PFX-файл сертификата и следуйте указаниям мастера.

Чтобы проверить, установлен ли сертификат в правильном месте, выполните следующие действия:

1. Выведите список сертификатов, которые находятся в личном хранилище для локального компьютера, выполнив следующую команду:
   dir Cert:\LocalMachine\My
2. Проверьте, есть ли сертификат в списке.

Проверьте, используется ли правильный SSL-сертификат.

Получите отпечаток сертификата, который используется для ssl-связи, и проверьте, соответствует ли отпечаток ожидаемому отпечатку сертификата.

Чтобы получить отпечаток используемого сертификата, выполните следующую команду в Windows PowerShell:

Get-AdfsSslCertificate

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

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

Проверьте, задан ли SSL-сертификат в качестве сертификата связи службы.

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

1. В консоли управления AD FS разверните узел Сертификаты службы>.
2. Проверьте, является ли сертификат, указанный в разделе Обмен данными службы , ожидаемым сертификатом.

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

1. Задайте правильный сертификат:

   1. Щелкните правой кнопкой мыши Пункт Сертификаты и выберите команду Задать сертификат связи службы.
   2. Выберите правильный сертификат.

2. Проверьте, имеет ли служба AD FS разрешение на чтение сертификата:

   1. Добавьте оснастку Сертификаты для учетной записи локального компьютера в консоль управления Майкрософт (MMC).
   2. Разверните Certificates (Local Computer) (Сертификаты на локальном компьютере) >Личные>Сертификаты.
   3. Щелкните правой кнопкой мыши SSL-сертификат и выберите Все задачи>Управление закрытыми ключами.
   4. Проверьте, указан ли adfssrv в разделе Имена групп и пользователей с разрешением на чтение .

3. Если adfssrv отсутствует в списке, предоставьте службе AD FS разрешение на чтение сертификата:

   1. Нажмите кнопку Добавить, выберите Пункты расположения, щелкните сервер и нажмите кнопку ОК.
   2. В разделе Введите имена объектов для выбора введите nt service\adfssrv, щелкните Проверить имена и нажмите кнопку ОК.
      Если вы используете AD FS со службой регистрации устройств (DRS), введите nt service\drs .
   3. Предоставьте разрешение на чтение и нажмите кнопку ОК.

Проверьте, настроена ли служба регистрации устройств (DRS) в AD FS

Если вы настроили AD FS с DRS, убедитесь, что SSL-сертификат также правильно настроен для RDS. Например, если есть два суффикса contoso.com имени участника-пользователя и fabrikam.com, сертификат должен иметь enterpriseregistration.contoso.com и enterpriseregistration.fabrikma.com в качестве альтернативных имен субъектов (SAN).

Чтобы проверка, имеет ли SSL-сертификат правильные имена SAN, выполните следующие действия.

1. Выведите список всех суффиксов имени участника-пользователя, используемых в организации, выполнив следующую команду:

   Get-AdfsDeviceRegistratrionUpnSuffix
   

2. Убедитесь, что SSL-сертификат имеет настроенные необходимые сети SAN.

3. Если SSL-сертификат не имеет правильных имен DRS в качестве san, получите новый SSL-сертификат с правильными именами SAN для DRS, а затем используйте его в качестве SSL-сертификата для AD FS.

Затем проверка конфигурацию сертификата на wap-серверах и резервные привязки:

• Проверьте, настроен ли правильный SSL-сертификат на всех WAP-серверах.

  1. Убедитесь, что SSL-сертификат установлен в личном хранилище для локального компьютера на каждом WAP-сервере.

  2. Получите SSL-сертификат, используемый WAP, выполнив следующую команду:

     Get-WebApplicationProxySslCertificate
     

  3. Если SSL-сертификат указан неправильно, задайте правильный SSL-сертификат, выполнив следующую команду:

     Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
     

• Проверьте привязки сертификатов и при необходимости обновите их.

  Для поддержки случаев, отличных от SNI, администраторы могут указывать резервные привязки. Кроме стандартной привязки federationservicename:443, найдите резервные привязки по следующим идентификаторам приложений:

  • {5d89a20c-beab-4389-9447-324788eb944a}: это идентификатор приложения для AD FS.
  • {f955c070-e044-456c-ac00-e9e4275b3f04}: это идентификатор приложения для веб-Application Proxy.

  Например, если SSL-сертификат указан для резервной привязки, например 0.0.0.0:443, убедитесь, что привязка обновляется соответствующим образом при обновлении SSL-сертификата.

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

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

1. На основном сервере AD FS откройте Windows PowerShell с параметром Запуск от имени администратора.

2. Добавьте компонент AD FS 2.0 в Windows PowerShell, выполнив следующую команду:

   Add-PSSnapin Microsoft.Adfs.PowerShell
   

3. Получите сведения о проверяющей стороне, выполнив следующую команду:

   $rp = Get-AdfsRelyingPartyTrust RPName
   

4. Получите сведения о клиенте OAuth, выполнив следующую команду:

   $client = Get-AdfsClient ClientName
   

Если вы используете функцию группы приложений в Windows Server 2016, выполните следующие действия.

1. На основном сервере AD FS откройте Windows PowerShell с параметром Запуск от имени администратора.

2. Получите сведения о проверяющей стороне, выполнив следующую команду:
   $rp = Get-AdfsWebApiApplication ResourceID

3. Если клиент OAuth является общедоступным, получите сведения о клиенте, выполнив следующую команду:

   $client = Get-AdfsNativeClientApplication ClientName
   

   Если клиент является конфиденциальным, получите сведения о клиенте, выполнив следующую команду:

   $client = Get-AdfsServerApplication ClientName
   

Теперь перейдите к следующим методам устранения неполадок.

Проверьте параметры проверяющей стороны и клиента

Идентификатор проверяющей стороны, идентификатор клиента и URI перенаправления должны быть предоставлены владельцем приложения и клиентом. Однако по-прежнему может быть несоответствие между тем, что предоставляет владелец, и тем, что настроено в AD FS. Например, несоответствие может быть вызвано опечаткой. Убедитесь, что параметры, предоставляемые владельцем, соответствуют параметрам, настроенным в AD FS. Действия, описанные на предыдущей странице, позволяют получить параметры, настроенные в AD FS с помощью PowerShell.

Параметры, предоставленные владельцем	Параметры, настроенные в AD FS
Идентификатор проверяющей стороны	$rp. Идентификатор
URI перенаправления проверяющей стороны	Соответствие префикса или подстановочного знака $rp. WSFedEndpoint для WS-Fed проверяющей стороны $rp. SamlEndpoints для проверяющей стороны SAML
Идентификатор клиента	$client. Clientid
URI перенаправления клиента	Соответствие префикса $client. RedirectUri

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

Запросы OAuth

Запрос OAuth выглядит следующим образом:

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

Проверьте, соответствуют ли параметры запроса параметрам, настроенным в AD FS.

Параметры запроса	Параметры, настроенные в AD FS
client_id	$client. Clientid
redirect_uri	Соответствие префикса @client_RedirectUri

Параметр resource должен представлять действительную проверяющую сторону в AD FS. Получите сведения о проверяющей стороне, выполнив одну из следующих команд.

• Если вы используете обычную проверяющую сторону, выполните следующую команду:
  Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
• Если вы используете функцию группы приложений в Windows Server 2016, выполните следующую команду:
  Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

запросы WS-Fed

Запрос WS-Fed выглядит следующим образом:

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

Проверьте, соответствуют ли параметры запроса параметрам, настроенным в AD FS:

Параметры запроса	Параметры, настроенные в AD FS
wtrealm	$rp. Идентификатор
Wreply	Соответствие префикса или подстановочного знака $rp. WSFedEndpoint

Запросы SAML

Запрос SAML выглядит следующим образом:

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

Декодирование значения параметра SAMLRequest с помощью параметра "From DeflatedSAML" в мастере текста Fiddler. Декодированные значения выглядят следующим образом:

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

Выполните следующие проверки в декодированных значениях:

• Проверьте, соответствует ли имя узла в значении Destination имени узла AD FS.
• Проверьте, соответствует $rp.Identifierли значение издателя .

Дополнительные примечания для SAML:

• $rp. SamlEndpoints: показывает все типы конечных точек SAML. Ответ от AD FS отправляется на соответствующие URL-адреса, настроенные в конечных точках. Конечная точка SAML может использовать привязки перенаправления, публикации или артефакта для передачи сообщений. Все эти URL-адреса можно настроить в AD FS.
• $rp. SignedSamlRequestsRequired: если задано значение, запрос SAML, отправленный проверяющей стороной, должен быть подписан. В запросе должны присутствовать параметры SigAlg и Signature.
• $rp. RequestSigningCertificate. Это сертификат подписи, используемый для создания подписи в запросе SAML. Убедитесь, что сертификат действителен, и попросите владельца приложения сопоставить сертификат.

Проверка сертификата шифрования

Если $rp.EncryptClaims возвращает значение Включено, шифрование проверяющей стороны включено. AD FS использует сертификат шифрования для шифрования утверждений. Выполните следующие проверки:

• $rp. EncryptionCertificate. Используйте эту команду, чтобы получить сертификат и проверка, если он действителен.
• $rp. EncryptionCertificateRevocationCheck. Используйте эту команду, чтобы проверка, соответствует ли сертификат требованиям проверка отзыва.

Предыдущие два метода не работают

Чтобы продолжить устранение неполадок, см . раздел Использование приложения маркера дампа.

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

В этом сценарии выполните следующие проверки.

Проверьте, отключен ли пользователь

Проверьте состояние пользователя в Windows PowerShell или пользовательском интерфейсе. Если пользователь отключен, включите его.

Проверьте состояние пользователя с помощью Windows PowerShell

1. Войдите в любой из контроллеров домена.

2. Откройте Windows PowerShell.

3. Проверьте состояние пользователя, выполнив следующую команду:

   Get-ADUser -Identity <samaccountname of the user> | Select Enabled
   

   

Проверка состояния пользователя в пользовательском интерфейсе

1. Войдите в любой из контроллеров домена.

2. Откройте консоль управления Пользователи и компьютеры Active Directory.

3. Щелкните узел Пользователи , щелкните правой кнопкой мыши пользователя в правой области и выберите пункт Свойства.

4. Перейдите на вкладку Учетная запись .

5. В разделе Параметры учетной записи проверьте, установлен ли флажок Учетная запись отключена .

   

6. Если флажок установлен, снимите его флажок.

Проверьте, были ли недавно обновлены свойства пользователя.

Если какое-либо свойство пользователя обновляется в Active Directory, это приводит к изменению метаданных объекта пользователя. Проверьте объект метаданных пользователя, чтобы узнать, какие свойства были обновлены недавно. При обнаружении изменений убедитесь, что они были приняты связанными службами. Чтобы проверка, были ли изменены свойства пользователя, выполните следующие действия.

1. Войдите в контроллер домена.

2. Откройте Windows PowerShell.

3. Получите метаданные объекта пользователя, выполнив следующую команду:
   repadmin /showobjmeta <destination DC> "user DN"

   Пример команды:
   repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

4. В метаданных проверьте столбец Time/Date для каждого атрибута, чтобы найти ключ к изменению. В следующем примере атрибут userPrincipleName принимает более новую дату, чем другие атрибуты, которые представляют собой изменение метаданных объекта пользователя.

   

Проверьте доверие леса, если пользователь принадлежит к другому лесу

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

1. Войдите в контроллер домена в лесу, где развернута служба AD FS.

2. Откройте консоль управления Домены и отношения доверия Active Directory.

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

4. Перейдите на вкладку Доверие .

5. В разделе Домены, доверенные этим доменом (исходящие отношения доверия) или Домены, которые доверяют этому домену (входящие отношения доверия), щелкните проверяемое доверие, а затем щелкните Свойства.

6. Нажмите кнопку Проверить.
   В диалоговом окне доменные службы Active Directory выберите один из параметров.

   • Если выбрано значение Нет, рекомендуется повторить ту же процедуру для взаимной области.

   • Если выбрано значение Да, укажите учетные данные администратора для взаимного домена. Нет необходимости выполнять одну и ту же процедуру для взаимной области.

     

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

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

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

Проверьте, синхронизирован ли пользователь с Microsoft Entra ID

Если пользователь пытается войти в Microsoft Entra ID, он будет перенаправлен в AD FS для проверки подлинности федеративного домена. Одной из возможных причин неудачного входа является то, что пользователь еще не синхронизирован с Microsoft Entra ID. После первой попытки проверки подлинности в AD FS может появиться цикл из Microsoft Entra ID в Active Directory FS. Чтобы определить, синхронизирован ли пользователь с Microsoft Entra ID, выполните следующие действия.

1. Скачайте и установите модуль PowerShell Azure AD для Windows PowerShell.
2. Откройте Windows PowerShell с параметром "Запуск от имени администратора".
3. Инициируйте подключение к Microsoft Entra ID, выполнив следующую команду:
   Connect-MsolService
4. Укажите учетные данные глобального администратора для подключения.
5. Получите список пользователей в Microsoft Entra ID, выполнив следующую команду:
   Get-MsolUser
6. Проверьте, есть ли пользователь в списке.

Если пользователя нет в списке, синхронизируйте его с Microsoft Entra ID.

Проверка immutableID и имени участника-пользователя в правиле утверждения выдачи

Microsoft Entra ID требуется immutableID и имя участника-пользователя для проверки подлинности пользователя.

Примечание.

immutableID также называется sourceAnchor в следующих средствах:

• Azure AD Sync
• Синхронизация Azure Active Directory (DirSync)

Администраторы могут использовать Microsoft Entra Connect для автоматического управления доверием AD FS с помощью Microsoft Entra ID. Если вы не управляете доверием через Microsoft Entra Connect, рекомендуется сделать это, скачав Microsoft Entra Подключение Microsoft Entra Connect включает автоматическое управление правилами утверждений на основе параметров синхронизации.

Чтобы проверка, соответствуют ли правила утверждений для immutableID и имени участника-пользователя в AD FS, которые использует Microsoft Entra ID, выполните следующие действия.

1. Получите sourceAnchor и upN в Microsoft Entra Connect.

   1. Откройте Microsoft Entra Connect.

   2. Щелкните Просмотреть текущую конфигурацию.

      

   3. На странице Проверка решения запишите значения SOURCE ANCHOR и USER PRINCIPAL NAME.

2. Проверьте значения immutableID (sourceAnchor) и UPN в соответствующем правиле утверждений, настроенном на сервере AD FS.

   1. На сервере AD FS откройте консоль управления AD FS.

   2. Щелкните Отношения доверия с проверяющей стороной.

   3. Щелкните правой кнопкой мыши проверяющую сторону доверия с Microsoft Entra ID и выберите изменить политику выдачи утверждений.

   4. Откройте правило утверждений для неизменяемого идентификатора и имени участника-пользователя.

   5. Убедитесь, что переменные, запрашиваемые для значений immutableID и UPN, совпадают с теми, которые отображаются в Microsoft Entra Connect.

      

3. Если есть разница, используйте один из приведенных ниже методов.

   • Если AD FS управляется Microsoft Entra Connect, сбросьте доверие проверяющей стороны с помощью Microsoft Entra Connect.
   • Если служба AD FS не управляется Microsoft Entra Connect, исправьте утверждения правильными атрибутами.

Если эти проверки не помогли решить проблему, см . статью Использование приложения маркера дампа для устранения этой проблемы.

Эта проблема возникает на стороне приложения

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

1. Получите текущий сертификат подписи маркера в AD FS, выполнив следующую команду:

   Get-ADFSCertificate -CertificateType token-signing
   

2. В списке возвращенных сертификатов найдите тот, который имеет значение IsPrimary = TRUE, и запишите отпечаток.

3. Получите отпечаток текущего сертификата подписи маркера на партнере федерации. Владелец приложения должен предоставить вам это.

4. Сравните отпечатки двух сертификатов.

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

Get-ADFSCertificate -CertificateType token-decrypting

Отпечатки двух сертификатов совпадают

Если отпечатки совпадают, убедитесь, что партнеры используют новые сертификаты AD FS.

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

Примечание.

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

• Партнеры могут получить доступ к метаданным федерации.

  Если партнеры могут получить доступ к метаданным федерации, попросите партнеров использовать новые сертификаты.

• Партнеры не могут получить доступ к метаданным федерации

  В этом случае необходимо вручную отправить партнерам открытые ключи новых сертификатов. Для этого выполните следующие действия:

  1. Экспортируйте открытые ключи в виде файлов CERT или P7B-файлов, чтобы включить все цепочки сертификатов.
  2. Отправка открытых ключей партнерам.
  3. Попросите партнеров использовать новые сертификаты.

Отпечатки двух сертификатов не совпадают

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

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

   Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm
   

   Возможные значения: SHA1 или SHA256.

2. Обратитесь к владельцу приложения за алгоритмом, используемым на стороне приложения.

3. Проверьте, совпадают ли два алгоритма.

Если два алгоритма совпадают, проверка, если формат идентификатора имени соответствует тому, что требуется приложению.

1. На сервере AD FS дамп правил преобразования выдачи, выполнив следующую команду:

   (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
   

2. Найдите правило, которое выдает утверждение NameIdentifier. Если такое правило не существует, пропустите этот шаг.

   Ниже приведен пример правила:

   c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

   Обратите внимание на формат NameIdentifier в следующем синтаксисе:

   Properties["Property-type-URI"] = "ValueURI"

   Возможные форматы перечислены ниже. Первый формат используется по умолчанию.

   • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.
   • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
   • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
   • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

3. Запросите у владельца приложения формат NameIdentifier, необходимый приложению.

4. Проверьте, совпадают ли два формата NameIdentifier.

5. Если форматы не совпадают, настройте утверждение NameIdentifier, чтобы использовать формат, необходимый приложению. Для этого выполните следующие действия:

   1. Откройте консоль управления AD FS.
   2. Щелкните Отношения доверия с проверяющей стороной, выберите соответствующего партнера по федерации, а затем в области Действия щелкните Изменить политику выдачи утверждений.
   3. Добавьте новое правило, если нет правила для выдачи утверждения NameIdentifier или обновите существующее правило. Выберите Идентификатор имени в поле Тип входящего утверждения, а затем укажите формат, необходимый приложению.

   

Если два алгоритма не совпадают, обновите алгоритм подписывания, используемый доверием проверяющей стороны.

1. Откройте консоль управления AD FS.

2. Щелкните правой кнопкой мыши проверяющую сторону доверия и выберите пункт Свойства.

3. На вкладке Дополнительно выберите алгоритм, соответствующий тому, что требуется приложению.

   

Об автоматическом продлении сертификата

Если сертификат подписи маркера или сертификат расшифровки маркера самозаверяется, функция AutoCertificateRollover включена по умолчанию для этих сертификатов, а AD FS управляет автоматическим продлением сертификатов, когда срок их действия истек.

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

1. Выполните следующую команду:

   Get-ADFSCerticate -CertificateType "token-signing"
   

   

2. Изучите атрибуты сертификата.

   Если атрибуты Subject и Issuer начинаются с "CN=ADFS Signing...", сертификат самозаверяется и управляется автосертификатором.

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

1. Выполните следующую команду:

   Get-ADFSProperties | FL AutoCertificateRollover
   

   

2. Изучите атрибут AutoCertificateRollover.

   • Если AutoCertificateRollover = TRUE, AD FS автоматически создает новые сертификаты (за 30 дней до истечения срока действия по умолчанию) и задает их в качестве основных сертификатов (за 25 дней до истечения срока действия).
   • Если AutoCertificateRollover = FALSE, необходимо вручную заменить сертификаты.

Проверка компонентов и служб, связанных с ADFS

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

Проверка DNS

Доступ к ADFS должен указывать непосредственно на один из серверов WAP (веб-Application Proxy) или подсистему балансировки нагрузки перед wap-серверами. Выполните следующие проверки:

• Связь с именем службы федерации (например, fs.contoso.com). Убедитесь, что IP-адрес, на который разрешается связь, относится к одному из WAP-серверов или подсистеме балансировки нагрузки wap-серверов.
• Проверьте, есть ли запись A для службы федерации на DNS-сервере. Запись A должна указывать на один из WAP-серверов или на подсистему балансировки нагрузки серверов WAP.

Если WAP не реализован в вашем сценарии внешнего доступа, проверка, если доступ к ADFS указывает непосредственно на один из серверов ADFS или подсистему балансировки нагрузки перед серверами ADFS:

• Связь с именем службы федерации (например, fs.contoso.com). Убедитесь, что IP-адрес, который вы получаете, разрешается на один из серверов ADFS или подсистему балансировки нагрузки серверов ADFS.
• Проверьте, есть ли запись A для службы федерации на DNS-сервере. Запись A должна указывать на один из серверов ADFS или на подсистему балансировки нагрузки серверов ADFS.

Проверьте, используется ли подсистема балансировки нагрузки.

Проверьте, блокирует ли брандмауэр трафик между:

• Сервер ADFS и подсистема балансировки нагрузки.
• Сервер WAP (веб-Application Proxy) и подсистема балансировки нагрузки, если используется WAP.

Если в подсистеме балансировки нагрузки включена проба, проверка следующее:

• Если вы используете Windows Server 2012 R2, убедитесь, что установлен накопительный пакет обновления за август 2014 г.
• Проверьте, включен ли порт 80 в брандмауэре на серверах WAP и серверах ADFS.
• Убедитесь, что проверка настроена для порта 80 и для конечной точки /adfs/probe.

Проверка параметров брандмауэра

Проверьте, включен ли входящий трафик через TCP-порт 443:

• брандмауэр между сервером веб-Application Proxy и фермой серверов федерации.
• брандмауэр между клиентами и сервером веб-Application Proxy.

Проверьте, включен ли входящий трафик через TCP-порт 49443 на брандмауэре между клиентами и веб-сервером Application Proxy при выполнении следующих условий:

• Проверка подлинности клиента TLS с помощью сертификата X.509 включена.
• Вы используете ADFS на Windows Server 2012 R2.

Примечание.

Конфигурация не требуется на брандмауэре между сервером веб-Application Proxy и серверами федерации.

Проверьте, включена ли конечная точка на прокси-сервере.

ADFS предоставляет различные конечные точки для различных функций и сценариев. Не все конечные точки включены по умолчанию. Чтобы проверка, включена ли конечная точка на прокси-сервере, выполните следующие действия.

1. На сервере ADFS откройте консоль управления ADFS.

2. Разверните узелКонечные точкислужбы>.

3. Найдите конечную точку и проверьте, включено ли состояние в столбце Включено прокси-сервер .

   

Проверка отношения доверия прокси-сервера

При развертывании веб-Application Proxy (WAP) необходимо установить отношение доверия прокси-сервера между WAP-сервером и сервером AD FS. Проверьте, установлено ли отношение доверия прокси-сервера или в какой-то момент времени начинается сбой.

Примечание.

Сведения на этой странице относятся к AD FS 2012 R2 и более поздних версий.

Базовые сведения

Отношение доверия прокси-сервера основано на сертификате клиента. При запуске мастера веб-Application Proxy после установки мастер создает самозаверяющий сертификат клиента, используя учетные данные, указанные в мастере. Затем мастер вставляет сертификат в базу данных конфигурации AD FS и добавляет его в хранилище сертификатов AdfsTrustedDevices на сервере AD FS.

Для любого соединения SSL http.sys использует следующий порядок приоритета для привязок SSL-сертификатов, чтобы соответствовать сертификату:

Priority	Имя	Параметры	Описание
1	IP	IP:порт	Точное совпадение IP-адресов и портов
2	SNI	Имя узла:порт	Точное совпадение имени узла (подключение должно указывать SNI)
3	CCS	Порт	Вызов центрального хранилища сертификатов
4	Подстановочный знак IPv6	Порт	Совпадение с подстановочными знаками IPv6 (подключение должно быть IPv6)
5	Подстановочный знак IP-адреса	Порт	Совпадение с подстановочными знаками IP-адресов (подключение может быть IPv4 или IPv6)

AD FS 2012 R2 и более поздних версий не зависят от служб IIS и работают как служба поверх http.sys. имя_узла:привязки SSL-сертификата порта используются AD FS. Во время проверки подлинности сертификата клиента AD FS отправляет список доверия сертификатов (CTL) на основе сертификатов в хранилище AdfsTrustedDevices. Если привязка SSL-сертификата для сервера AD FS использует IP:порт или хранилище CTL не является AdfsTrustedDevices, отношение доверия прокси-сервера может не быть установлено.

Получение привязок SSL-сертификатов для AD FS

На сервере AD FS выполните следующую команду в Windows PowerShell:
netsh http show sslcert

В списке возвращенных привязок найдите объекты с идентификатором приложения 5d89a20c-beab-4389-9447-324788eb944a. Ниже приведен пример работоспособной привязки. Обратите внимание на строку "Имя хранилища Ctl".

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)  
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

Запуск скрипта для автоматического обнаружения проблем

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

param
(
  [switch]$syncproxytrustcerts
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1
$certbindingissuedetected = $false
While($i -lt $httpsslcertoutput.count)
{
        $ipport = $false
        $hostnameport = $false
        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }
        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }
        ## Check for IP specific certificate bindings
        if ( ( $ipport -eq $true ) )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )
            {
                $warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning
                $certbindingissuedetected = $true
            }
            $i = $i + 14
            continue
        }
        ## check that CTL Store is set for ADFS service binding
        elseif ( $hostnameport -eq $true )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )
            {
                Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"
                $certbindingissuedetected = $true
            }
        $i = $i + 14
        continue
        }
    $i++
}
If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues detected" }
}
function checkadfstrusteddevicesstore()
{
## check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store
Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"
$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}
If ( $certlist.count -gt 0 )
{
    Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"
    $certlist | Format-List Subject
}
Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }
}
function checkproxytrustcerts
{
    Param ([bool]$repair=$false)
    Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")
    $doc = new-object Xml
    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")
    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"
    $cli = new-object System.Data.SqlClient.SqlConnection
    $cli.ConnectionString = $connString
    $cmd = new-object System.Data.SqlClient.SqlCommand
    $cmd.CommandText = $command
    $cmd.Connection = $cli
    $cli.Open()
    $configString = $cmd.ExecuteScalar()
    $configXml = new-object XML
    $configXml.LoadXml($configString)
    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2
    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices
    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")
    $store.open("MaxAllowed")
    $atLeastOneMismatch = $false
    $badCerts = @()
    foreach($rawCert in $rawCerts)
    {   
        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
        $now = Get-Date
        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))
        {
            $certThumbprint = $cert.Thumbprint
         $certSubject = $cert.Subject
         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue
         if ($ctlMatch -eq $null)
         {
       $atLeastOneMismatch = $true
          Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"
       if ($repair -eq $true)
       {
        write-Warning "Attempting to repair"
        $store.Add($cert)
        Write-Warning "Repair successful"
       }
                else
                {
                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")
                }
         }
        }
    }
    $store.Close()
    if ($atLeastOneMismatch -eq $false)
    {
     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")
    }
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")

Проблема 1. Существует привязка для конкретного IP-адреса

Привязка может конфликтовать с привязкой сертификата AD FS через порт 443.

Привязка IP:port имеет наивысший приоритет. Если привязка IP:port находится в привязках SSL-сертификатов AD FS, http.sys всегда использует сертификат для привязки ssl-связи. Чтобы решить эту проблему, используйте следующие методы.

1. Удаление привязки IP:port

   Имейте в виду, что привязка IP:port может вернуться после ее удаления. Например, приложение, настроенное с этой привязкой IP:port, может автоматически воссоздать его при следующем запуске службы.

2. Использование другого IP-адреса для подключения ПО SSL AD FS

   Если требуется привязка IP:port, разрешите полное доменное имя службы ADFS на другой IP-адрес, который не используется ни в каких привязках. Таким образом, http.sys будет использовать привязку Hostname:port для связи SSL.

3. Задайте AdfsTrustedDevices в качестве хранилища CTL для привязки IP:порт

   Это последнее средство, если вы не можете использовать описанные выше методы. Но лучше понять следующие условия, прежде чем изменять хранилище CTL по умолчанию на AdfsTrustedDevices:

   • Почему существует привязка IP:port.
   • Если привязка использует хранилище CTL по умолчанию для проверки подлинности сертификата клиента.

Проблема 2. Для привязки сертификата AD FS не задано значение AdfsTrustedDevices.

Если установлено Microsoft Entra Connect, используйте Microsoft Entra Connect, чтобы задать имя хранилища CTL в значение AdfsTrustedDevices для привязок SSL-сертификатов на всех серверах AD FS. Если Microsoft Entra Connect не установлен, повторно создайте привязки сертификатов AD FS, выполнив следующую команду на всех серверах AD FS.

Set-AdfsSslCertificate -Thumbprint Thumbprint

Проблема 3. Сертификат, который не является самозаверяющим, существует в хранилище сертификатов AdfsTrustedDevices

Если сертификат, выданный ЦС, находится в хранилище сертификатов, где обычно существуют только самозаверяемые сертификаты, созданный из хранилища CTL будет содержать только выданный ЦС сертификат. Хранилище сертификатов AdfsTrustedDevices — это хранилище, которое должно содержать только самозаверяющие сертификаты. К этим сертификатам относятся:

• MS-Organization-Access: самозаверяющий сертификат, используемый для выдачи сертификатов присоединения к рабочему месту.
• Доверие прокси-сервера ADFS. Сертификаты для каждого сервера веб-Application Proxy.

Поэтому удалите сертификат, выданный ЦС, из хранилища сертификатов AdfsTrustedDevices.

Проблема 4. Установка KB2964735 или повторное выполнение скрипта с помощью -syncproxytrustcerts

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

Чтобы решить эту проблему, используйте один из следующих методов.

Способ 1

Установите обновление, описанное в 2964735 базы знаний , на всех серверах AD FS. После установки обновления ожидается автоматическая синхронизация сертификата клиента.

Способ 2

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

Примечание.

Это не является постоянным решением, так как сертификаты клиента будут обновляться на регулярной основе.

Проблема 5. Все проверки пройдены. Но проблема сохраняется

Проверьте, есть ли несоответствие часового пояса или часового пояса. Если время совпадает, а часовой пояс — нет, отношения доверия прокси-сервера также не удастся установить.

Проверьте, есть ли ssl-завершение между сервером AD FS и WAP-сервером.

Если завершение SSL происходит на сетевом устройстве между серверами AD FS и WAP-сервером, обмен данными между AD FS и WAP прерывается, так как обмен данными основан на сертификате клиента.

Отключите завершение SSL на сетевом устройстве между AD FS и WAP-серверами.

Использование приложения маркера дампа

Приложение маркера дампа полезно при отладке проблем со службой федерации, а также при проверке настраиваемых правил утверждений. Это не официальное решение, но хорошее независимое решение для отладки, которое рекомендуется для устранения неполадок.

Перед использованием приложения маркера дампа

Перед использованием приложения маркера дампа необходимо:

1. Получите сведения о проверяющей стороне для приложения, к которому вы хотите получить доступ. Если проверка подлинности OAuth реализована, получите сведения о клиенте OAuth.
2. Настройте приложение маркера дампа.

Получение сведений о проверяющей стороне и клиенте OAuth

Если вы используете обычную проверяющую сторону, выполните следующие действия.

1. На сервере AD FS откройте Windows PowerShell с параметром Запуск от имени администратора.

2. Добавьте компонент AD FS 2.0 в Windows PowerShell, выполнив следующую команду:

   Add-PSSnapin Microsoft.Adfs.PowerShell
   

3. Получите сведения о проверяющей стороне, выполнив следующую команду:

   $rp = Get-AdfsRelyingPartyTrust RPName
   

4. Получите сведения о клиенте OAuth, выполнив следующую команду:

   $client = Get-AdfsClient ClientName
   

Если вы используете функцию группы приложений в Windows Server 2016, выполните следующие действия.

1. На сервере AD FS откройте Windows PowerShell с параметром Запуск от имени администратора.

2. Получите сведения о проверяющей стороне, выполнив следующую команду:

   $rp = Get-AdfsWebApiApplication ResourceID
   

3. Если клиент OAuth является общедоступным, получите сведения о клиенте, выполнив следующую команду:

   $client = Get-AdfsNativeClientApplication ClientName
   

   Если клиент OAuth является конфиденциальным, получите сведения о клиенте, выполнив следующую команду:

   $client = Get-AdfsServerApplication ClientName
   

Настройка приложения маркера дампа

Чтобы настроить приложение маркера дампа, выполните следующие команды в окне Windows PowerShell:

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

Теперь перейдите к следующим методам устранения неполадок. В конце каждого метода посмотрите, решена ли проблема. Если нет, используйте другой метод.

Методы устранения неполадок

Проверьте политику авторизации, чтобы узнать, влияет ли пользователь.

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

Получение сведений о политике

$rp. IssuanceAuthorizationRules показывает правила авторизации проверяющей стороны.

В Windows Server 2016 и более поздних версиях можно использовать $rp. AccessControlPolicyName для настройки политики проверки подлинности и авторизации. Если $rp. AccessControlPolicyName имеет значение. Существует политика управления доступом, которая управляет политикой авторизации. В этом случае $rp. Параметр IssuanceAuthorizationRules пуст. Используйте $rp. ResultantPolicy— сведения о политике управления доступом.

Если $rp. ResultantPolicy не содержит подробных сведений о политике, изучите фактические правила утверждений. Чтобы получить правила утверждений, выполните следующие действия.

1. Задайте для политики управления доступом значение $null, выполнив следующую команду:
   Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
2. Получите сведения о проверяющей стороне, выполнив следующую команду:
   $rp = Get-AdfsRelyingPartyTrust RPName
3. Проверьте $rp.IssuanceAuthorizationRules и $rp. AdditionalAuthenticationRules.

Использование приложения маркера дампа для диагностики политики авторизации

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

2. В зависимости от установленной политики проверки подлинности пользователь должен открыть одну из следующих ссылок.

   • WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
   • SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
   • Принудительная многофакторная проверка подлинности: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

3. Войдите на страницу Sign-In.

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

Проверьте, вызывает ли какое-либо отсутствие или непредвиденное утверждение причиной отказа в доступе к ресурсу

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

2. Настройте политику проверки подлинности маркера дампа так, чтобы она совпадала с неудачной проверяющей стороной.

3. В зависимости от установленной политики проверки подлинности пользователь должен открыть одну из следующих ссылок.

   • WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
   • SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
   • Принудительная многофакторная проверка подлинности: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

4. Войдите на страницу Sign-In.

Это набор утверждений, которые проверяющая сторона будет получать для пользователя. Если какие-либо утверждения отсутствуют или непредвиденные, изучите политику выдачи, чтобы узнать причину.

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

Проверьте, требуется ли состояние устройства

Если правила авторизации проверка для утверждений устройств, проверьте, отсутствуют ли какие-либо из этих утверждений устройства в списке утверждений, которые вы получаете из приложения "Маркер дампа". Отсутствующие утверждения могут блокировать проверку подлинности устройства. Чтобы получить утверждения из приложения маркера дампа, выполните действия, описанные в разделе Использование приложения маркера дампа для диагностики политики авторизации в разделе Проверка политики авторизации, если пользователь был затронут методом .

Ниже приведены утверждения устройств. Некоторые из них могут использоваться в правилах авторизации.

• http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
• http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
• http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
• http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
• http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
• http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
• http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
• http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
• http://schemas.microsoft.com/2014/02/deviceusagetime
• http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
• http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

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

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