Устранение неполадок единого входа с службы федерации 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 и параметры запроса проверки подлинности.

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

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

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

Если приложением являются Службы Microsoft Online Services, то взаимодействием можно управлять с помощью параметра PromptLoginBehavior из объекта доверенной области. Этот параметр определяет, Azure AD ли клиенты отправлять 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: Azure AD отправляет wauth и wfresh в AD FS вместо prompt=login. Это приводит к запросу проверки подлинности на использование проверки подлинности на основе форм.
    2. NativeSupport: параметр prompt=login отправляется в AD FS как есть.
    3. Отключено. В AD FS ничего не отправляется.

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

Сценарий Azure Active Directory (Azure AD)

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

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

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

Сценарий Azure AD без Azure AD

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

Проверка отключения единого входа

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

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

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

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

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

Проверка конфигурации на сервере 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. Найдите конечные точки и проверьте, включены ли состояния в столбце Enabled .

    Проверьте состояние всех включенных конечных точек AD FS.

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

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

Если Azure AD 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. Рекомендуется использовать Azure AD 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. Убедитесь, что сертификат, указанный в разделе Service communications , является ожидаемым сертификатом.

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

    Используйте команду Get-ADUser, чтобы проверить состояние включенного пользователя.

Проверка состояния пользователя в пользовательском интерфейсе
  1. Войдите на любой из контроллеров домена.

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

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

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

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

    Проверьте, установлен ли флажок &quot;Учетная запись отключена&quot;.

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

    Выходные данные команды repadmin showobjmeta.

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

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

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

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

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

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

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

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

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

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

      Проверьте входящее доверие в доменные службы Active Directory диалоговом окне.

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

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

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

Проверьте, синхронизирован ли пользователь с Azure AD

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

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

Если пользователя нет в списке, синхронизируются с Azure AD.

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

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

Примечание

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

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

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

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

  1. Получение sourceAnchor и имени участника-пользователя в Azure AD Connect.

    1. Откройте Azure AD Connect.

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

      Выберите &quot;Просмотреть текущую конфигурацию&quot; на странице дополнительных задач Azure AD Connect.

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

      Получение значений SOURCE ANCHOR и USER PRINCIPAL NAME на странице Azure AD Connect.

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

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

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

    3. Щелкните правой кнопкой мыши отношение доверия проверяющей Azure AD и выберите команду "Изменить политику выдачи утверждений".

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

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

      Проверьте значения immutableID и UPN в соответствующем правиле утверждения, настроенном на сервере A D F S.

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

    • Если AD FS управляется Azure AD Connect, сбросьте доверие проверяющей стороны с помощью Azure AD Connect.
    • Если AD FS не управляется Azure AD 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 или обновления существующего правила. Выберите идентификатор имени для типа входящего утверждения и укажите формат, необходимый приложению.

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

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

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

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

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

    Выберите алгоритм, соответствующий требуемой приложению, на вкладке &quot;Дополнительно&quot; в диалоговом окне &quot;Параметры&quot;.

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

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

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

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

    Get-ADFSCerticate -CertificateType "token-signing"
    

    Запустите Get-ADFSCerticate, подписывав маркер типа сертификата.

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

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

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

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

    Get-ADFSProperties | FL AutoCertificateRollover
    

    Выполните командлет Get-ADFSProperties, чтобы убедиться, что сертификаты продлеваются автоматически.

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

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

В этой статье описывается, как проверить компоненты и службы, связанные с ADFS. Эти действия могут помочь при устранении неполадок при входе в систему (SSO) службы федерации 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. Найдите конечную точку и проверьте, включено ли состояние в столбце "Включен прокси-сервер ".

    Проверьте состояние конечных точек AD FS, отображаемое в столбце &quot;Включен прокси-сервер&quot;.

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

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

Примечание

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

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

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

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

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

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

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

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

В списке возвращаемых привязок найдите привязки с идентификатором приложения 5d89a20c-beab-4389-9447-324788eb944a. Ниже приведен пример работоспособной привязки. Обратите внимание на строку "Ctl Store Name" (Имя магазина 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:port

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

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

Проблема 2. Привязка сертификата AD FS не имеет имени хранилища CTL, установленного в AdfsTrustedDevices

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

Set-AdfsSslCertificate -Thumbprint Thumbprint

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

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

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

Сертификаты для каждого веб-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://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Принудительная многофакторная проверка подлинности: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  3. Войдите на Sign-In страницы.

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

Проверка того, является ли отсутствие или непредвиденное утверждение причиной запрета доступа к ресурсу

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

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

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

    • WS-Fed: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Принудительная многофакторная проверка подлинности: https://FerderationInstance/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

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

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