sso is running что за ошибка на госуслугах

Устранение ошибок единого входа

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

API единого входа в настоящее время поддерживается для Word, Excel, Outlook и PowerPoint. Дополнительные сведения о текущей поддержке API единого входа см. в статье Наборы обязательных элементов API идентификации. Если вы работаете с надстройкой Outlook, обязательно включите современную проверку подлинности для клиента Microsoft 365. Сведения о том, как это сделать, см. в статье Exchange Online: как включить в клиенте современную проверку подлинности.

Средства отладки

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

Причины и обработка ошибок в методе getAccessToken

Примеры обработки ошибок, рассматриваемых в этом разделе:

13000

Надстройка или версия Office не поддерживает API getAccessToken.

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

13001

Другая возможность — реагирование на ошибку 13001, с переключением на альтернативную систему проверки подлинности пользователя. Это обеспечит вход пользователя в AAD, но не вход пользователя в Office.

Эта ошибка никогда не возникает в Office в Интернете. Если срок действия cookie-файла пользователя истек, Office в Интернете возвращает ошибку 13006.

13002

Пользователь прервал вход или отменил свое согласие (например, выбрав Отмена в диалоговом окне согласия).

13003

Тип пользователя не поддерживается. Пользователь не подписывался в Office с действительной учетной записью Майкрософт, Microsoft 365 для образования или учетной записью работы. Например, это может произойти, если Office работает с учетной записью локального домена. Ваш код должен инициировать возврат к альтернативной системе проверки подлинности пользователя. В Outlook эта ошибка также может возникнуть, если современная проверка подлинности отключена для клиента пользователя в Exchange Online. Дополнительные сведения см. в разделе Требования и рекомендации.

13004

Недопустимый ресурс. (Эта ошибка должна быть замечена только в разработке.) Манифест надстройки не был настроен правильно. Обновите манифест. Дополнительные сведения см. в статье Проверка манифеста надстройки Office. Самая распространенная проблема заключается в том, что в элементе Resource (который входит в элемент WebApplicationInfo) указан домен, не соответствующий домену надстройки. Хотя часть протокола значения ресурса должна быть «api», а не «https», все остальные части доменного имени (включая порт, если таковой имеется) должны быть такими же, как и для надстройки.

13005

Другая возможная причина при разработке заключается в том, что ваша надстройка использует Internet Explorer, и вы используете самозаверяющий сертификат. (Сведения об определении браузера, используемого надстройкой, см. в статье Браузеры, используемые надстройками Office.)

13006

Ошибка клиента. Эта ошибка возникает только в Office в Интернете. Код должен предлагать пользователю выйти и затем перезапустить сеанс браузера для Office.

13007

Приложение Office не удалось получить маркер доступа к веб-службе надстройки.

В рабочей среде эта ошибка может возникать по нескольким причинам. Вот некоторые из них:

Во всех этих случаях ваш код должен инициировать возврат к альтернативной системе проверки подлинности пользователя.

13008

13010

Пользователь запускает надстройки в Office на Microsoft Edge. Домен пользователя Microsoft 365 и домен находятся в различных зонах безопасности в login.microsoftonline.com параметрах браузера. Эта ошибка возникает только в Office в Интернете. Если возвращается эта ошибка, то пользователь уже видел сообщение с соответствующим пояснением и ссылкой на инструкции по изменению конфигурации зон. Если ваша надстройка предоставляет функции, не требующие входа пользователя, то в коде следует отслеживать эту ошибку и позволять надстройке продолжать работу.

13012

Существует несколько возможных причин.

Ваш код должен инициировать возврат к альтернативной системе проверки подлинности пользователя.

13013

Вызов был вызван слишком много раз за короткое время, поэтому Office последний getAccessToken вызов. Обычно это вызвано бесконечным циклом звонков к методу. При отзыве метода рекомендуется использовать сценарии. Однако в коде следует использовать переменную счетчика или флага, чтобы убедиться, что метод не отзывается повторно. Если один и тот же путь кода «повторная» снова запущен, код должен вернуться к альтернативной системе проверки подлинности пользователей. Пример кода см. в примере использования переменной вHomeES6.js retryGetAccessToken илиssoAuthES6.js.

50001

Эта ошибка (нехарактерная для getAccessToken ) может указывать, что браузер поместил в кэш старую копию файлов office.js. Во время разработки очистите кэш браузера. Другой возможный вариант — версия Office устарела и не поддерживает единый вход. В Windows минимальная версия — 16.0.12215.20006. На Mac — 16.32.19102902.

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

Ошибки на стороне сервера из Azure Active Directory

Примеры обработки ошибок, рассматриваемых в этом разделе:

Ошибки условного доступа и многофакторной проверки подлинности

Независимо от архитектуры, если значение утверждений было отправлено из AAD, код должен отозвать и передать getAccessToken authChallenge: CLAIMS-STRING-HERE options параметр. Когда служба AAD обнаруживает эту строку, она предлагает пользователю указать дополнительные факторы, а затем возвращает новый маркер доступа, который будет принят в потоке выполнения от имени другого субъекта.

Ошибки, вызванные отсутствием согласия

Если в службе AAD нет записи о том, что пользователь или администратор клиента согласился предоставить надстройке доступ к ресурсу Microsoft Graph, то AAD отправит вашей веб-службе сообщение об ошибке. Код должен сообщить клиенту (например, в тексте отклика 403 Forbidden ).

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

Ошибки, вызванные недействительными или отсутствующими областями (разрешениями)

Эта ошибка возникает только в процессе разработки.

Ошибка, вызванная недействительной аудиторией, в маркере доступа (не маркере начальной загрузки)

Код на стороне сервера должен отправить отклик 403 Forbidden клиенту, а тот должен показать пользователю понятное сообщение и, возможно, также записать ошибку в консоли или журнале.

Источник

Ошибка отправки заявления в ведомство на Госуслугах что это значит и что делать дальше

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

Что означает сообщение об ошибке отправки заявления на Госуслугах?

Как правило, проблемы возникают при формировании запроса в ведомство (например, если родители школьника хотят получить бесплатное питание для ребенка или оформить выплату). Чтобы заявка была рассмотрена, её обычно требуется дополнять сопроводительными документами, то есть их сканами. Ошибка может возникать из-за того, что был превышен размер прикрепленного файла или он сохранен в недопустимом формате. Проблемы могут быть и из-за работы браузера.

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

Например, на экране могут быть следующие сообщения:

Ошибки, вызванные сбоем работы самого сайта Госуслуги

Стоит учитывать, что первичная обработка заявлений в ведомства осуществляет роботом, а значит, в его настройках произошел сбой, который пока не исправили программисты сервиса. Проблема в том, что если ошибка допущена самим пользователем, то обычно на экран выводится пояснение. В случае сбоя в системе отображаются только очень размытые сообщения («Произошла ошибка при отправке данных», «Что-то пошло не так» и прочие). Гадать в такой ситуации нет никакого смысла.

Что делать, если из-за ошибки невозможно отправить заявление в ведомство через Госуслуги

Можно попробовать обновить страницу или перезагрузить ПК. Если это не помогло, то действуем следующим образом.

Подаем заявку в ведомство заново

После неудачной отправки запроса нужно подождать некоторое время, так как возможно «Ошибка отправки заявления в ведомство» произошла на самом сайте. После этого необходимо перейти в свой профиль и найти заявку, которая помечена ошибкой. Её нужно удалить, но не стоит использовать ее в качестве черновика или пытаться отправить её повторно.

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

Отправляем заявку через сайт Госуслуги через другой браузер или, очистив куки

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

Очистить куки очень просто. Для этого рассмотрим процедуру на примере браузера Chrome:

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

В браузере Яндекс процедура выполняется аналогичным способом. Обратите внимание также и на пункт «История браузера». В нашем примере мы видим, что приложение хранит информацию о более чем 11 000 сайтов. Это может привести к серьезной перегрузке браузера, поэтому выполнять очистку истории рекомендуется выполнять раз в 2-3 месяца.

Обращаемся в техническую поддержку сервиса

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

При обращении в техподдержку необходимо следовать нескольким правилам:

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

Чтобы задать вопрос в техподдержку:

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

Обращаемся в ведомство напрямую

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

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

Источник

👨⚕️️ Что такое единый вход ( Single Sign-on или SSO)👨⚕️ – решение для обеспечения безопасности данных вашей компании

Single Sign-on или Единая регистрация – это метод аутентификации, который помогает войти в несколько приложений с использованием единой учетной записи.

Безопасность повышается за счет единого входа (SSO) в свете того факта, что пользователи избавляются от различных проблем с секретными паролями.

Давайте будем честными, пользователи не любят сложные пароли;

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

Есть две основные проблемы, с которыми сталкиваются эти предприятия:

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

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

Расширение стороннего доступа

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

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

В исследовании, проведенном Aberdeen, было показано, что около 1/3 исследованных предприятий предоставили доступ по крайней мере 25 сторонним организациям, в то время как у 10% было свыше 200 внешних партнеров.

В этом случае единый вход (SSO) будет очень полезным решением для защиты активов вашей компании.

Балансировка между безопасностью и удобством использования

При работе с растущей пользовательской базой безопасность и стоимость имеют первостепенное значение.

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

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

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

Частота и стоимость кибератак

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

Одна утечка данных стоит в среднем около 450 тыс. долларов, но может стоить значительно дороже.

Немного подготовки может сэкономить много денег и доверия.

Традиционные системные расходы

Использование традиционной системы может быть дорогостоящим, около 3,5 миллионов долларов для производителей.

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

Многофакторная аутентификация и единый вход в систему (SSO), возможно, это решение, которое компания может внедрить, чтобы избежать атак на основе учетных данных.

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

Уменьшите головную боль помощи пользователям с восстановлением пароля с помощью единого входа (SSO)

Представьте себе организацию с десятью различными администрациями.

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

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

Единая регистрация (SSO) помогает уменьшить количество паролей, которые должны помнить пользователи.

Клиентам настоятельно рекомендуется использовать бесконечно уникальные пароли для разных систем.

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

Система единого входа (SSO) может необычайно уменьшить количество паролей, которые необходимо запомнить пользователям, что может побудить пользователя выбрать значительно более надежный пароль.

Источник

Устранение проблем SSO с службами федерации Active Directory (AD FS)

В этой статье вы можете разрешить проблемы с одним входом (SSO) с помощью служб Федерации Active Directory (AD FS).

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

Применяется к: Исходный номер KB служб Федерации Active Directory: 4034932

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

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

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

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

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

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

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

Проверка параметров AD FS

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

Откройте Windows PowerShell с параметром Run в качестве администратора.

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

Изучите значение атрибута WindowsIntegratedFallbackEnbaled.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если приложение Microsoft Online Services, то вы можете управлять параметром PromptLoginBehavior из доверенного объекта realm. Этот параметр контролирует, отправляют ли клиенты Azure AD запрос на вход в AD FS. Чтобы установить параметр PromptLoginBehavior, выполните следующие действия:

Откройте Windows PowerShell с помощью параметра «Выполнить как администратор».

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

Установите параметр PromptLoginBehavior, задав следующую команду:

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

Дополнительные данные о команде Set-MSOLDomainFederationSettings см. в журнале Active Directory Federation Services prompt=login parameter support.

Azure Active Directory (Azure AD)

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

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

Сценарий Non Azure AD

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

Проверьте отключение SSO

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

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

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

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

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

Проверка конфигурации на сервере AD FS и стороне, которая полагается

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

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

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

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

Соблюдайте настроенный набор правил утверждения.

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

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

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

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

Проверьте правила выдачи сторон, которые полагаются

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

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

Соблюдайте набор правил, определенный в атрибутах IssuanceAuthorizationRules или IssuanceAuthorizationRulesFile.

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

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

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

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

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

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

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

Если параметр SupportsMFA false, установите его true, выведя следующую команду:

Проверьте отключение SSO

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

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

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

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

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

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

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

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

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

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

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

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

Вход успешно

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

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

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

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

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

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

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

Вход неуспешен

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

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

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

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

Расширение > конечных точек службы.

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

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

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

Если служба Azure AD Подключение не установлена, проверьте, соответствует ли сертификат 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 Подключение, что упрощает управление сертификатами SSL. См. статью Обновление сертификата TLS/SSL для фермы служб Федерации active Directory (AD FS).

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

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

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

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

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

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

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

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

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

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

Установите правильный сертификат:

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

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

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

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

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

Список всех суффиксов upN, используемых в организации, с помощью следующей команды:

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

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

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

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

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

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

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

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

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

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

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

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

На основном сервере AD FS откройте Windows PowerShell с параметром Run as administrator.

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

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

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

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

На основном сервере AD FS откройте Windows PowerShell с параметром Run as administrator.

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

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

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

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

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

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

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

Запросы OAuth

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

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

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

WS-Fed запросы

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

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

Запросы SAML

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

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

Сделайте следующие проверки в расшифроваемом значении:

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

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

Два предыдущих метода не работают

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

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

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

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

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

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

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

Откройте Windows PowerShell.

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

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

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

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

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

Щелкните вкладку Учетная запись.

В параметрах Учетная запись убедитесь, что учетная запись отключена.

Если параметр проверяется, его ото всех.

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

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

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

Откройте Windows PowerShell.

Получите метаданные объекта пользователя, выразив следующую команду:
repadmin /showobjmeta «user DN»

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

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

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

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

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

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

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

Щелкните вкладку Trusts.

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

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

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

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

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

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

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

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

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

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

Проверка неизменяемого ИПД и правила утверждения о выдаче

Azure AD требует неоменяемого ID и upN пользователя для проверки подлинности пользователя.

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

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

Чтобы проверить, совпадают ли правила утверждения для неоменяемых ИБД и UPN в AD FS, которые использует Azure AD, выполните следующие действия:

Получите sourceAnchor и UPN в Azure AD Подключение.

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

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

Если эти проверки не помогли вам решить проблему, см. в приложении Dump Token для устранения неполадок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Найдите правило, которое выдает утверждение 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 в следующем синтаксисе:

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

Спросите владельца приложения о формате NameIdentifier, требуемом приложением.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка DNS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В списке возвращенных привязки и посмотрите на тех, у кого есть ID приложения 5d89a20c-beab-4389-9447-324788eb944a. Вот пример здоровой привязки. Обратите внимание на строку «Имя магазина Ctl».

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

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

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

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

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

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

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

Использование другого IP-адреса для связи SSL AD FS

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

Установите AdfsTrustedDevices в качестве CTL-магазина для привязки IP:port

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

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

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

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

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

Поэтому удалите любой сертификат ca, выданный из магазина сертификатов AdfsTrustedDevices.

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

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

Способ 1

Установите обновление, задокументированное в KB 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.

Использование приложения Dump Token

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

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

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

Получить сведения о клиенте группы и клиента OAuth

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

На сервере AD FS откройте Windows PowerShell с параметром Run as administrator.

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

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

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

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

На сервере AD FS откройте Windows PowerShell с параметром Run as administrator.

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

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

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

Настройка приложения Dump Token

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

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

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

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

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

Сведения о политике

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

С помощью приложения Dump Token можно диагностировать политику авторизации

Установите политику проверки подлинности маркеров сброса, которая будет такой же, как и неустойка.

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

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

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

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

Настройте правила утверждения в приложении Dump Token таким же, как и правила утверждений неудаваемой стороны.

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

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

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

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

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

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

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

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

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

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

Источник