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

С ростом облака многие компании перешли на использование идентификатора Microsoft Entra для различных приложений и служб. Использование Microsoft Entra ID теперь стало стандартом во многих организациях. В этой статье рассматриваются некоторые аспекты устранения неполадок, возникающих с этой федерацией. Некоторые из разделов в общей статье по устранению неполадок все еще относятся к вопросам федерации с Azure, поэтому в этой статье описываются особенности взаимодействия с Microsoft Entra ID и службами федерации Active Directory (AD FS).

Перенаправление в AD FS

Перенаправление происходит при входе в приложение, например Office 365, и вы перенаправляетесь на серверы AD FS вашей организации для входа.

Снимок экрана: область перенаправления.

Первое, что необходимо проверить

Если перенаправление не происходит, есть несколько вещей, которые нужно проверить.

  1. Убедитесь, что клиент Microsoft Entra включен для федерации. Войдите на портал Azure и проверьте параметры Microsoft Entra Connect.

    Снимок экрана: панель входа пользователя в Microsoft Entra Connect.

  2. Убедитесь, что личный домен проверен. Выберите домен рядом с федерацией на портале Azure.

    снимок экрана, на котором показан домен рядом с федерацией на портале.

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

    Для получения этих сведений можно также использовать командлет PowerShell Get-MgDomain.

    Снимок экрана: окно PowerShell с результатами команды Get-MgDomain.

Вы получаете ошибку "Неизвестный метод проверки подлинности"

При перенаправлении из Azure может возникнуть ошибка "Неизвестный метод проверки подлинности" с сообщением о том, что AuthnContext не поддерживается на уровне AD FS или службы маркеров безопасности (STS).

Этот сценарий наиболее распространен, когда идентификатор Microsoft Entra перенаправляется в AD FS или STS с помощью параметра, который применяет метод проверки подлинности.

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

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

  • Для SAML 2.0 используйте следующий код:

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

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

Метод проверки подлинности, который требуется Универсальный код ресурса (URI) WAUTH
Проверка подлинности на основе имени пользователя и пароля urn:oasis:names:tc:SAML:1.0:am:password
Проверка подлинности клиента SECURE Sockets Layer (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:names:tc:SAML:2.0:ac:classes:TLSClient
X.509 certificate urn:oasis:names:tc:SAML:2.0:ac:classes:X509
Встроенная проверка подлинности Windows urn:federation:authentication:windows
Kerberos urn:oasis:names: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 2012 R2

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

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

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

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

AD FS 2016

  1. Под Управлением AD FS выберите Служба>Методы проверки подлинности в оснастке AD FS.

  2. В разделе "Первичная проверка подлинности" выберите "Изменить".

  3. На панели "Изменить методы проверки подлинности " на вкладке "Основной " можно настроить параметры в рамках политики проверки подлинности.

    Снимок экрана: панель

Токены, выданные AD FS

В этом разделе рассматриваются маркеры, выданные AD FS.

Идентификатор Microsoft Entra выдает ошибку после выдачи токена

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

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

  • Токен для идентификации Microsoft Entra должен содержать следующие обязательные утверждения:

    • WSFED:

      • Имя участника-пользователя. Значение этого утверждения должно соответствовать имени участника-пользователя (UPN) пользователей в идентификаторе Microsoft Entra.
      • ImmutableID: значение этого утверждения должно соответствовать sourceAnchor или ImmutableID атрибутам пользователя в идентификаторе Microsoft Entra.

      Чтобы получить значение атрибута User в идентификаторе Microsoft Entra ID, выполните следующую командную строку: Get-AzureADUser –UserPrincipalName <UPN>

      Снимок экрана: панель PowerShell с результатами команды Get-AzureADUser.

    • SAML 2.0:

      • IDPEmail: значение этого утверждения должно соответствовать имени участника-пользователя в идентификаторе Microsoft Entra.
      • NAMEID: значение этого утверждения должно соответствовать sourceAnchor или ImmutableID атрибутам пользователя в идентификаторе Microsoft Entra.

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

Несоответствие сертификата подписи токенов между AD FS и идентификатором Microsoft Entra

AD FS использует сертификат подписания токенов для подписи токена, который отправляется пользователю или приложению. Доверие между AD FS и Microsoft Entra ID — это федеративное доверие, основанное на сертификате для подписи токенов.

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

Чтобы исправить эту проблему, следуйте шагам, описанным в разделе Обновление сертификатов федерации для Office 365 и Microsoft Entra ID.

Другие распространенные вещи для проверки

Если у вас возникли проблемы с взаимодействием AD FS и Microsoft Entra, проверьте следующее:

  • Устаревшие или кэшированные учетные данные в Менеджере учетных данных Windows.
  • Безопасный хэш-алгоритм (SHA), настроенный для доверия проверяющей стороны для Office 365, имеет значение SHA1.

Связанный контент

  • Last updated on