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

Статья
02/13/2024

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

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

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

Redirection screen to AD FS

Первое, что нужно проверка

Если перенаправление не происходит, необходимо проверка

Убедитесь, что клиент Microsoft Entra включен для федерации, войдите в портал Azure и проверка в microsoft Entra Подключение.
Убедитесь, что личный домен проверен, щелкнув домен рядом с федерацией в портал Azure.
Наконец, вы хотите проверка DNS и убедиться, что серверы AD FS или WAP-серверы разрешаются из Интернета. Убедитесь, что это разрешено и вы можете перейти к нему.
Для получения этих сведений также можно использовать командлет Get-MgDomain PowerShell.

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

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

Чаще всего это происходит, когда идентификатор Microsoft Entra перенаправляется в 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) wauth
Проверка подлинности с помощью имени пользователя и пароля	urn:oasis:names:tc:SAML:1.0:am:password
Проверка подлинности SSL-клиента	urn:ietf:rfc:2246
Встроенная проверка подлинности Windows	urn:federation:authentication:windows

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

Authentication method	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 2012 R2

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

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

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

**Убедитесь, что выбран необходимый метод проверки подлинности проверка.

AD FS 2016

В разделе "Управление AD FS" щелкните "Методы службы и проверки подлинности" в оснастке AD FS.

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

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

Edit Authentication Methods window

Маркеры, выданные AD FS

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

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

Утверждения, выданные AD FS в токене, должны соответствовать соответствующим атрибутам пользователя в идентификаторе Microsoft Entra.
Маркер для идентификатора Microsoft Entra должен содержать следующие обязательные утверждения:
- WSFED:
  - Имя участника-пользователя. Значение этого утверждения должно соответствовать имени участника-пользователя в идентификаторе Microsoft Entra.
  - ImmutableID: значение этого утверждения должно соответствовать источникуAnchor или ImmutableID пользователя в идентификаторе Microsoft Entra.

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

Screenshot of the PowerShell window showing the results of the Get-AzureADUser command.

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

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

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

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

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

Чтобы устранить эту проблему, можно использовать инструкции, описанные в разделе "Продление сертификатов федерации" для Office 365 и идентификатора Microsoft Entra.

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

Ниже приведен краткий список вещей, которые необходимо проверка при возникновении проблем с AD FS и взаимодействием с Microsoft Entra.

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

Next Steps

Устранение неполадок в AD FS

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