Поделиться через

Устранение неполадок AD FS в идентификаторе Microsoft Entra и Office 365

В этой статье описывается устранение неполадок с проверкой подлинности федеративных пользователей в идентификаторе Microsoft Entra или Office 365.

Исходный номер базы знаний: 3079872

Симптомы

  • Федеративные пользователи не могут войти в Office 365 или Microsoft Azure, несмотря на то, что управляемые пользователи облака, имеющие UPN суффикс domainxx.onmicrosoft.com, могут войти без проблем.
  • Перенаправление на службы федерации Active Directory (AD FS) или STS не происходит для федеративного пользователя. Или возникает ошибка "Страница не может отображаться".
  • При попытке проверки подлинности с помощью AD FS в браузере вы получаете предупреждение, связанное с сертификатом. Что указывает на ошибку проверки сертификата или то, что сертификат не доверен.
  • Ошибка или ошибки неизвестного метода проверки подлинности, указывающие, что AuthnContext не поддерживается. Кроме того, ошибки на уровне AD FS или STS при перенаправлении из Office 365.
  • AD FS выдает ошибку "Доступ запрещен".
  • AD FS выдает ошибку, указывающую, что возникла проблема с доступом к сайту; который включает в себя номер ссылочного идентификатора.
  • Пользователь неоднократно запрашивает учетные данные на уровне AD FS.
  • Федеративные пользователи не могут пройти проверку подлинности из внешней сети или при использовании приложения, принимающего маршрут внешней сети (например, Outlook).
  • Федеративные пользователи не могут войти в систему после изменения сертификата подписи токенов в AD FS.
  • Ошибка "К сожалению, у нас возникают проблемы при входе федеративного пользователя в Office 365 в Microsoft Azure". Эта ошибка включает коды ошибок, такие как 8004786C, 80041034, 80041317, 80043431, 80048163, 80045C06, 8004789A или BAD-запрос.

Процесс устранения неполадок

  1. Перейдите к Microsoft Office Home, а затем введите имя входа федеративного пользователя (например, кто-то@.com). После нажатия клавиши TAB, чтобы снять фокус с поля ввода логина, проверьте, изменяется ли состояние страницы на Перенаправление, а затем вас перенаправляют в службу федерации Active Directory (AD FS) для входа.

    Примечание.

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

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

    При перенаправлении отображается следующая страница:

    Страница, отображаемая при перенаправлении D F S.

    1. Если перенаправление не происходит и вам предлагается ввести пароль на той же странице, это означает, что Microsoft Entra ID или Office 365 не распознает пользователя или домен пользователя для федерации. Чтобы проверить, существует ли доверие федерации между Microsoft Entra ID или Office 365 и вашим сервером AD FS, запустите Get-MgDomain командлет и проверьте AuthenticationType.

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

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

      Get-MgDomainFederationConfiguration -DomainId <domain_id>

      Примечание.

      < > domain_id — это заполнитель имени вашего домена. Например, contoso.com.

      Проверьте URI, URL-адрес и сертификат партнера федерации, настроенного с помощью Office 365 или Microsoft Entra ID.

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

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

      Убедитесь, что сертификат связи службы D F S совпадает с сертификатом, настроенным на A F F S.

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

      В AD FS 2.0:

      • Привязите сертификат к первому сайту IIS по> умолчанию.
      • Используйте оснастку AD FS, чтобы добавить тот же сертификат в качестве служебного сертификата связи.

      В AD FS 2012 R2:

      • Используйте оснастку AD FS или команду Add-adfscertificate, чтобы добавить сертификат для связи службы.
      • Set-adfssslcertificate Используйте команду, чтобы задать тот же сертификат для привязки SSL.

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

    3. Если клиенты, не поддерживающие SNI, пытаются установить сеанс SSL с AD FS или WAP 2-12 R2, попытка может завершиться ошибкой. В этом случае рекомендуется добавить резервную запись на серверах AD FS или WAP для поддержки клиентов, отличных от SNI. Дополнительные сведения см. в статье о поддержке клиентов, не поддерживающих SNI, с прокси-сервером веб-приложения и AD FS 2012 R2.

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

    • Для WS-Federation используйте строку запроса WAUTH, чтобы принудительно применить предпочтительный метод проверки подлинности.

    • Для SAML2.0 используйте следующее:

      <saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>

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

    В следующей таблице показаны URI типа проверки подлинности, распознаваемые AD FS для пассивной проверки подлинности WS-Federation.

    Метод проверки подлинности, который требуется wauth URI
    Проверка подлинности с помощью имени пользователя и пароля urn:oasis:names:tc:SAML:1.0:am:password
    Проверка подлинности SSL-клиента urn:ietf:rfc:2246
    Встроенная проверка подлинности Windows urn:federation:authentication:windows

    Поддерживаемые классы контекста проверки подлинности SAML

    Метод аутентификации URI класса контекста проверки подлинности
    Имя пользователя и пароль urn:oasis:names:tc:SAML:2.0:ac:classes:Password
    Защищенный паролем транспорт urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
    Клиент TLS urn:oasis:name:tc:SAML:2.0:ac:classes:TLSClient
    Сертификат X.509 urn:oasis:name:tc:SAML:2.0:ac:classes:X509
    Встроенная проверка подлинности Windows urn:federation:authentication:windows
    Kerberos urn:oasis:name:tc:SAML:2.0:ac:classes:Kerberos

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

    AD FS 2.0

    В разделе /adfs/ls/web.config убедитесь, что запись для типа проверки подлинности присутствует.

    <microsoft.identityServer.web>
<localAuthenticationTypes>
 < add name="Forms" page="FormsSignIn.aspx" />  
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>

    AD FS 2.0. Изменение типа локальной проверки подлинности

    AD FS 2012 R2

    1. В разделе "Управление AD FS" выберите Политики проверки подлинности в оснастке AD FS.

    2. В разделе "Первичная проверка подлинности" выберите "Изменить " рядом с глобальными параметрами. Вы также можете щелкнуть правой кнопкой мыши политики проверки подлинности и выбрать пункт "Изменить глобальную первичную проверку подлинности". В области "Действия" выберите "Изменить глобальную первичную проверку подлинности".

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

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

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

    1. Проблема репликации Active Directory

      Если репликация AD нарушена, изменения, внесенные пользователю или группе, могут не синхронизироваться между контроллерами домена. Между контроллерами домена может быть несоответствие пароля, UPN, GroupMembership или Proxyaddress, которое влияет на ответ AD FS (аутентификация и выдача утверждений). Вы должны начать смотреть на контроллеры домена на том же сайте, что и AD FS. Выполнение команды repadmin /showreps или DCdiag /v должно показать, есть ли проблема на контроллерах домена, к которым, скорее всего, обращается AD FS.

      Вы также можете собрать сводку репликации AD, чтобы убедиться, что изменения AD реплицируются правильно во всех контроллерах домена. Выходные repadmin /showrepl * /csv > showrepl.csv данные полезны для проверки состояния репликации. Дополнительные сведения см. в разделе "Устранение неполадок с репликацией Active Directory".

    2. Учетная запись заблокирована или отключена в Active Directory

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

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

      1. Используйте локальную или доменную политику, чтобы обеспечить успешность и сбой для следующих политик:

        • Событие аудита входа в систему, расположенное в Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy

        • Аудит доступа к объектам, расположенным в Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy

          Используйте локальную или доменную политику, чтобы включить успешность и сбой.

      2. Отключите следующую политику:

        Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)

        Эта политика находится в Computer configuration\Windows Settings\Security setting\Local Policy\Security Option.

        Отключите политику подкатегории политики принудительного аудита.

        Если вы хотите настроить его с помощью расширенного аудита, см. статью "Настройка компьютеров для устранения неполадок AD FS 2.0".

      3. Настройка AD FS для аудита:

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

        2. На панели Действия выберите действие Изменить свойства службы федерации.

        3. В диалоговом окне Свойства службы федерации выберите вкладку События.

        4. Установите флажки Success audits (Успешные события аудита) и Failure audits (Неудачные события аудита).

          Включите аудит A D F S, установив флажки аудита успешных событий и аудита неудачных событий на вкладке

        5. Запустите GPupdate /force на сервере.

    3. Имя учетной записи службы (SPN) зарегистрировано неправильно

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

      Введите имя службы A D F S на вкладке

      Убедитесь, что для службы AD FS нет повторяющихся SPN, так как это может привести к периодическим сбоям проверки подлинности с AD FS. Чтобы вывести список субъектов-служб, выполните команду SETSPN -L <ServiceAccount>.

      Выполните команду SETSPN -L, чтобы получить список имен субъектов-служб для службы A D F S.

      Запустите SETSPN -A HOST/AD FSservicename ServiceAccount, чтобы добавить SPN.

      Запустите SETSPN -X -F, чтобы проверить наличие повторяющихся SPN.

    4. Повторяющиеся UPN в Active Directory

      Пользователь может пройти проверку подлинности через AD FS при использовании SAMAccountName, но не может пройти проверку подлинности при использовании UPN. В этом сценарии Active Directory может содержать двух пользователей с одинаковым UPN (универсальное имя пользователя). Может получиться, что два пользователя будут иметь одинаковое учетное имя пользователя, когда пользователи добавляются и изменяются с помощью скриптов (например, ADSIedit).

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

      Для проверки наличия нескольких объектов в AD с одинаковыми значениями атрибута можно использовать следующие запросы:

      Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

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

    5. В сценарии, где вы используете свой адрес электронной почты в качестве идентификатора входа в Office 365, и вводите тот же адрес электронной почты при перенаправлении в AD FS для проверки подлинности, процесс может завершиться ошибкой "NO_SUCH_USER" в журнале аудита. Чтобы разрешить AD FS найти пользователя для проверки подлинности с помощью атрибута, отличного от имени участника-пользователя или SAMaccountname, необходимо настроить AD FS для поддержки альтернативного идентификатора входа. Дополнительные сведения см. в статье Configuring Alternate Login ID (Настройка альтернативного идентификатора входа).

      В AD FS 2012 R2

      1. Установите обновление 2919355.

      2. Обновите конфигурацию AD FS, выполнив следующий командлет PowerShell на любом из серверов федерации в ферме (если у вас есть ферма WID, необходимо выполнить эту команду на основном сервере AD FS в ферме):

        Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID <attribute> -LookupForests <forest domain>

        Примечание.

        AlternateLoginID — это имя LDAP атрибута, который вы хотите использовать для входа. И LookupForests — это список записей DNS лесов, к которым принадлежат ваши пользователи.

        Чтобы включить функцию альтернативного идентификатора входа, необходимо настроить параметры AlternateLoginID и LookupForests с ненулевым и допустимым значением.

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

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

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

      2. Нажмите Пуск, Запуск, введите mmc.exe и нажмите ВВОД.

      3. Выберите Файл, затем выберите Добавить/Удалить оснастку.

      4. Дважды щелкните сертификаты.

      5. Выберите учетную запись компьютера, а затем нажмите кнопку Далее.

      6. Выберите локальный компьютер и нажмите кнопку "Готово".

      7. Разверните Сертификаты (локальный компьютер), разверните Личные, а затем выберите Сертификаты.

      8. Щелкните правой кнопкой мыши новый сертификат подписывания токенов, выберите «Все задачи» и выберите «Управление закрытыми ключами».

        Действия по добавлению разрешения на доступ для чтения для учетной записи службы A D F S.

      9. Добавьте доступ на чтение для учетной записи службы AD FS 2.0 и нажмите кнопку "ОК".

      10. Закройте консоль сертификатов.

    7. Параметр расширенной защиты для проверки подлинности Windows включен для виртуального каталога AD FS или LS. Это может привести к проблемам с определенными браузерами. Иногда AD FS может неоднократно запрашивать учетные данные, и это может быть связано с включенной настройкой расширенной защиты для проверки подлинности Windows в приложении AD FS или LS на IIS.

      Включите параметр расширенной защиты для проверки подлинности Windows.

      Если включена расширенная защита для проверки подлинности, запросы проверки подлинности привязаны как к именам субъектов-служб (SPN) сервера, к которому клиент пытается подключиться, так и к внешнему каналу TLS, по которому происходит встроенная проверка подлинности Windows. Углублённая защита повышает функциональность аутентификации Windows для снижения рисков ретрансляции аутентификации или атак типа "человек посередине". Однако некоторые браузеры не работают с параметром расширенной защиты; вместо этого они неоднократно запрашивают учетные данные, а затем запрещают доступ. Отключение расширенной защиты помогает в этом сценарии.

      Для получения дополнительной информации см. статью AD FS 2.0: постоянные запросы учетных данных при использовании веб-отладчика Fiddler.

      Для AD FS 2012 R2

      Выполните следующий командлет, чтобы отключить расширенную защиту:

      Set-ADFSProperties -ExtendedProtectionTokenCheck None

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

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

      Настройте правило

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

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

      • Проблема синхронизации времени на сервере AD FS и прокси-сервере AD FS

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

      • Проверьте, правильно ли работает доверие прокси-сервера AD FS со службой AD FS. Повторно запустите конфигурацию прокси-сервера, если подозреваете, что доверие прокси-сервера нарушено.

  5. После того как AD FS выдает токен, Microsoft Entra ID или Office 365 выдает сообщение об ошибке. В этой ситуации проверьте следующие проблемы:

    • Утверждения, выданные AD FS в токене, должны соответствовать соответствующим атрибутам пользователя в идентификаторе Microsoft Entra. В маркере для идентификатора Microsoft Entra или Office 365 требуются следующие утверждения.

      WSFED:
      Имя участника-пользователя. Значение этого утверждения должно соответствовать имени участника-пользователя в идентификаторе Microsoft Entra.
      ImmutableID: значение этого утверждения должно соответствовать источникуAnchor или ImmutableID пользователя в идентификаторе Microsoft Entra.

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

      Get-MgUser -UserId <user_id_string>

      SAML 2.0:
      IDPEmail: значение этого утверждения должно соответствовать имени участника-пользователя пользователей в идентификаторе Microsoft Entra.
      NAMEID: значение этого утверждения должно соответствовать исходному или неизменяемому идентификатору пользователя в идентификаторе Microsoft Entra.

      Дополнительные сведения см. в разделе "Использование поставщика удостоверений SAML 2.0 (IdP) для единого входа".

      Примеры:
      Эта проблема может возникнуть, если UPN синхронизированного пользователя изменяется в AD, но онлайн каталог не обновляется. В этом сценарии можно исправить UPN пользователя в AD (чтобы он соответствовал имени входа связанного пользователя) или выполнить следующий командлет, чтобы изменить имя входа связанного пользователя в online-каталоге:

      Update-MgUser -UserId <user_id_string> -UserPrincipalName <DomainUPN-AD>

      Возможно, вы используете AADsync для синхронизации MAIL в качестве UPN и EMPID в качестве SourceAnchor, но правила утверждений доверяющей стороны на уровне AD FS не обновлены так, чтобы отправлять MAIL как UPN, а EMPID как ImmutableID.

    • Существует расхождение сертификата подписания токенов между AD FS и Office 365.

      Это одна из наиболее распространенных проблем. AD FS использует сертификат подписывания маркеров для подписи маркера, который отправляется пользователю или приложению. Доверие между AD FS и Office 365 — это федеративное доверие, основанное на этом сертификате подписи маркера (например, Office 365 проверяет, что полученный маркер подписан с помощью сертификата подписи маркера поставщика утверждений [служба AD FS], которому он доверяет).

      Однако если сертификат подписи маркера в AD FS изменяется из-за автоматического переключения сертификатов или вмешательства администратора (после или до истечения срока действия сертификата), сведения о новом сертификате необходимо обновить в клиенте Office 365 для федеративного домена. Это может не произойти автоматически; может потребоваться вмешательство администратора. Если основной сертификат подписи маркеров в AD FS отличается от того, о чем знает Office 365, маркер, выданный AD FS, не является доверенным в Office 365. Таким образом, федеративный пользователь не может войти в систему.

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

      Вы можете использовать Get-MgDomainFederationConfiguration -DomainId <domain_id> для дампа свойства федерации в AD FS и Office 365. Здесь можно сравнить отпечаток TokenSigningCertificate, чтобы проверить, синхронизирована ли конфигурация клиента Office 365 для федеративного домена. Если в конфигурации сертификата подписи токена вы найдете несоответствие, выполните следующую команду, чтобы обновить ее:

      Connect-MgGraph -scopes Domain.ReadWrite.All, Directory.ReadWrite.All
$tdo= Get-MgDomainFederationConfiguration -DomainID <domain_id>
Update-MgDomainFederationConfiguration -DomainId <domain_id> -InternalDomainFederationId $tdo.Id -SigningCertificate <certificate_token>
Disconnect-MgGraph

      Примечание.

      < > domain_id — это заполнитель имени вашего домена. Например, contoso.com.

      Дополнительные сведения см. в разделе "Продление сертификатов федерации" для Идентификатора Microsoft 365 и Microsoft Entra.

    • Правила утверждения преобразования выдачи для Office 365 RP не настроены правильно.

      В сценарии, когда у вас несколько доменов TLD (домены верхнего уровня), могут возникнуть проблемы при входе в систему, если параметр supportmultipledomain не использовался при создании и обновлении доверия RP.

      Мы рекомендуем использовать Entra Connect для управления федерациями и правилами утверждений. Обычно это автоматически настраивает ADFS и Entra соответствующим образом. Дополнительные сведения см. в разделе "Поддержка нескольких доменов для федерации с идентификатором Microsoft Entra".

    • Убедитесь, что шифрование маркеров не используется AD FS или STS, если маркер выдан идентификатору Microsoft Entra или Office 365.

  6. В Диспетчере учетных данных Windows существуют устаревшие кэшированные учетные данные.

    Иногда во время входа с рабочей станции на портал (или при использовании Outlook), когда пользователю предлагается предоставить учетные данные, учетные данные могут быть сохранены для целевого объекта (служба Office 365 или AD FS) в диспетчере учетных данных Windows ().Control Panel\User Accounts\Credential Manager Это помогает предотвратить запрос учетных данных в течение некоторого времени, но может вызвать проблему после изменения пароля пользователя и диспетчер учетных данных не обновляется. В этом сценарии устаревшие учетные данные отправляются в службу AD FS, поэтому проверка подлинности завершается ошибкой. Удаление или обновление кэшированных учетных данных в Диспетчере учетных данных Windows может помочь.

  7. Убедитесь, что безопасный хэш-алгоритм, настроенный для доверия проверяющей стороны для Office 365, имеет значение SHA1.

    Если доверие между STS/ AD FS и Microsoft Entra ID / Office 365 использует протокол SAML 2.0, алгоритм безопасного хэша, настроенный для цифровой подписи, должен быть SHA1.

  8. Если ни одна из предыдущих причин не применяется к вашей ситуации, создайте вариант поддержки с корпорацией Майкрософт и попросите их проверить, отображается ли учетная запись пользователя последовательно в клиенте Office 365. Дополнительные сведения см. в статье "Федеративный пользователь" многократно запрашивает учетные данные во время входа в Office 365, Azure или Intune.

  9. В зависимости от того, к какой облачной службе (интегрированная с идентификатором Microsoft Entra ID) вы обращаетесь, запрос проверки подлинности, отправленный в AD FS, может отличаться. Например, некоторые запросы могут включать дополнительные параметры, такие как Wauth или Wfresh, и эти параметры могут привести к разному поведению на уровне AD FS.

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

    AD FS 2.0 AD FS 2012 R2
    Накопительный пакет обновления за декабрь 2014 г. для Windows RT 8.1, Windows 8.1 и Windows Server 2012 R2

Справка

Дополнительную информацию о командлетах Microsoft Graph вы можете найти в следующих статьях: