Техническое подробное руководство по проверке подлинности на основе сертификатов Microsoft Entra

В этой статье объясняется, как работает проверка подлинности на основе сертификатов Microsoft Entra (CBA) и подробно описаны технические сведения о конфигурациях Microsoft Entra CBA.

Как работает проверка подлинности на основе сертификатов Microsoft Entra?

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

Теперь мы рассмотрим каждый шаг:

1. Пользователь пытается обратиться к приложению, например к порталу MyApps.

2. Если пользователь еще не вошел в систему, пользователь перенаправляется на страницу https://login.microsoftonline.com/входа пользователя в идентификатор Microsoft Entra ID.

3. Пользователь вводит свое имя пользователя на страницу входа в Microsoft Entra, а затем нажмите кнопку "Далее". Идентификатор Microsoft Entra выполняет обнаружение домашней области с помощью имени клиента, а имя пользователя используется для поиска пользователя в клиенте.

   

4. Идентификатор Microsoft Entra проверяет, включена ли CBA для клиента. Если CBA включен, пользователь видит ссылку на использование сертификата или смарт-карты на странице паролей. Если пользователь не видит ссылку на вход, убедитесь, что CBA включен в клиенте. Дополнительные сведения см. в разделе Разделы справки включение Microsoft Entra CBA?.

   Примечание.

   Если CBA включен в клиенте, все пользователи видят ссылку на использование сертификата или смарт-карты на странице пароля. Однако только пользователи в области CBA могут успешно пройти проверку подлинности в приложении, которое использует идентификатор Microsoft Entra в качестве поставщика удостоверений (IdP).

   

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

   

5. После выбора проверки подлинности на основе сертификатов клиент перенаправляется в конечную точку certauth, которая используется https://certauth.login.microsoftonline.com для общедоступного идентификатора Microsoft Entra. Для Azure для государственных организаций конечной точкой certauth является https://certauth.login.microsoftonline.us.

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

   Примечание.

   Администратор сети должен разрешить доступ к странице входа пользователя и конечной точке *.certauth.login.microsoftonline.com certauth для облачной среды клиента. Отключите проверку TLS в конечной точке certauth, чтобы обеспечить успешное выполнение запроса сертификата клиента в рамках подтверждения TLS.

   Убедитесь, что отключение проверки TLS также работает для нового URL-адреса с указаниями издателя. Не закодировать URL-адрес с помощью tenantId, так как он может измениться для пользователей B2B. Используйте регулярное выражение, чтобы разрешить как старому, так и новому URL-адресу работать для отключения проверки TLS. Например, в зависимости от прокси-сервера, использования *.certauth.login.microsoftonline.com или *certauth.login.microsoftonline.com. В Azure для государственных организаций используйте *.certauth.login.microsoftonline.us или *certauth.login.microsoftonline.us.

   Если доступ не разрешен, проверка подлинности на основе сертификатов завершается ошибкой при включении подсказок издателя.

6. Идентификатор Microsoft Entra запрашивает сертификат клиента. Пользователь выбирает сертификат клиента и нажимает кнопку "ОК".

   

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

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

9. Идентификатор Microsoft Entra завершает процесс входа, отправив основной маркер обновления обратно, чтобы указать успешный вход.

10. После успешного входа в систему пользователь может получить доступ к приложению.

Общие сведения о подсказках издателя (предварительная версия)

Указания издателя отправляют доверенный ЦС в рамках подтверждения TLS. Список доверенных ЦС устанавливается для субъекта центров сертификации (ЦС), отправленных клиентом в хранилище доверия Entra. Клиент браузера или клиент собственного приложения используют подсказки, отправляемые сервером, для фильтрации сертификатов, отображаемых в средство выбора сертификатов. Клиент отображает только сертификаты проверки подлинности, выданные центрами сертификации в хранилище доверия.

Включение подсказок издателя

Чтобы включить флажок "Подсказки издателя". Администраторы политики проверки подлинности должны нажать кнопку "Подтвердить ", убедившись, что прокси-сервер с включенной проверкой TLS обновлен правильно и сохраняется.

Примечание.

Если у вашей организации есть брандмауэры или прокси-серверы с проверкой TLS, убедитесь, что вы отключили проверку TLS конечной точки certauth, которая может соответствовать любому имени в [*.]certauth.login.microsoftonline.comсоответствии с конкретным прокси-сервером.

Примечание.

URL-адрес центра сертификации будет иметь формат t{tenantId}.certauth.login.microsoftonline.com после включения подсказок издателя.

Распространение обновлений хранилища доверия ЦС

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

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

Возможность многофакторной проверки подлинности на основе сертификатов

Microsoft Entra CBA поддерживает многофакторную проверку подлинности (MFA). Microsoft Entra CBA может быть однофакторной (SF) или многофакторной (MF) в зависимости от конфигурации клиента. Включение CBA делает пользователя потенциально способным завершить многофакторную проверку подлинности. Пользователю может потребоваться дополнительная конфигурация для завершения MFA и подтверждения регистрации других методов проверки подлинности, когда пользователь находится в области CBA.

Если у пользователя с поддержкой CBA есть только сертификат единого фактора (SF) и требуется выполнить MFA:

1. Используйте пароль и сертификат SF.
2. Выдача временного прохода доступа.
3. Администратор политики проверки подлинности добавляет номер телефона и разрешает проверку подлинности голосового и текстового сообщения для учетной записи пользователя.

Если пользователь с поддержкой CBA еще не выдан сертификат и должен завершить MFA:

1. Выдача временного прохода доступа.
2. Администратор политики проверки подлинности добавляет номер телефона и разрешает проверку подлинности голосового и текстового сообщения для учетной записи пользователя.

Если пользователь с поддержкой CBA не может использовать сертификат MF, например на мобильном устройстве без поддержки смарт-карт, и необходимо выполнить MFA:

1. Выдача временного прохода доступа.
2. Пользователь должен зарегистрировать другой метод MFA (если пользователь может использовать сертификат MF).
3. Используйте пароль и сертификат MF (если пользователь может использовать сертификат MF).
4. Администратор политики проверки подлинности добавляет номер телефона и разрешает проверку подлинности голосового и текстового сообщения для учетной записи пользователя.

MFA с однофакторной проверкой подлинности на основе сертификата

Microsoft Entra CBA можно использовать в качестве второго фактора для удовлетворения требований MFA с помощью однофакторных сертификатов. Ниже приведены некоторые поддерживаемые сочетания:

1. CBA (первый фактор) и секретные ключи (второй фактор)
2. CBA (первый фактор) и вход без пароля (второй фактор)
3. Ключи безопасности CBA (первый фактор) и FIDO2 (второй фактор)

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

Внимание

Пользователь считается способом MFA, если они включены в параметры метода CBA. Это означает, что пользователь не может использовать подтверждение в рамках проверки подлинности для регистрации других доступных методов. Убедитесь, что пользователи без допустимого сертификата не включены в параметры метода CBA. Дополнительные сведения о том, как работает проверка подлинности, см. в разделе Многофакторная проверка подлинности Microsoft Entra.

Действия по настройке входа без пароля телефона (PSI) с помощью CBA

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

1. Войдите в Центр администрирования Microsoft Entra как минимум администратор политики проверки подлинности.

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

   Внимание

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

3. Выберите параметры многофакторной проверки подлинности>на основе нескольких компонентов защиты.>

   

4. В разделе " Параметры проверки" снимите уведомление через мобильное приложение и нажмите кнопку "Сохранить".

   

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

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

1. Введите имя участника-пользователя (UPN) и нажмите кнопку "Далее".

   

2. Выберите Войти с помощью сертификата.

   

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

   

3. Выберите правильный сертификат пользователя в средство выбора сертификатов клиента и нажмите кнопку "ОК".

   

4. Так как сертификат настроен как сила однофакторной проверки подлинности, пользователю требуется второй фактор для удовлетворения требований MFA. Пользователь видит доступные второй фактор, который в данном случае является без пароля входа. Выберите " Утвердить запрос" для приложения Microsoft Authenticator.

   

5. Вы получите уведомление на телефоне. Выберите " Утвердить вход?".

6. Введите номер, который отображается на экране браузера или приложения, в Microsoft Authenticator.

   

7. Выберите "Да ", а пользователь может пройти проверку подлинности и войти в систему.

MFA с проверкой подлинности на основе сертификатов в качестве второго фактора (предварительная версия)

CBA можно использовать как второй фактор, например пароль (первый фактор) и CBA (второй фактор), чтобы получить MFA.

Примечание.

В iOS пользователи с проверкой подлинности на основе сертификатов увидят "двойной запрос", где они должны дважды щелкнуть параметр для использования проверки подлинности на основе сертификатов. В iOS пользователи с приложением Microsoft Authenticator также увидят почасовую строку входа, чтобы пройти проверку подлинности с помощью CBA, если есть политика обеспечения надежности проверки подлинности, применяющая CBA, или если они используют CBA в качестве второго фактора или поэтапной проверки подлинности.

Общие сведения о политике привязки проверки подлинности

Политика привязки проверки подлинности помогает определить силу проверки подлинности как однофакторную или многофакторную. Администраторы политики проверки подлинности могут изменить значение по умолчанию с однофакторной на многофакторную или настраиваемую конфигурацию политики с помощью субъектов-издателей или OID политики или полей OID политики в сертификате.

Сильные стороны сертификата

Администраторы политики проверки подлинности могут определить, являются ли сертификаты однофакторными или многофакторными. Дополнительные сведения см. в документации, которая сопоставляет уровни проверки подлинности NIST с методами проверки подлинности Microsoft Entra, которая основана на NIST 800-63B SP 800-63B, рекомендации по проверке подлинности и жизненному циклу Mgmt.

Многофакторная проверка подлинности сертификата

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

Как идентификатор Microsoft Entra ID разрешает несколько правил привязки политики проверки подлинности

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

1. Правила OID издателя + политики имеют приоритет над правилами OID политики. Правила OID политики имеют приоритет над правилами издателя сертификатов.
2. Сначала вычисляются правила OID издателя + политики. Если у вас есть пользовательское правило с поставщиком ЦС1 и политикой OID 1.2.3.4.5 с MFA, то только сертификат A удовлетворяет значению издателя и OID политики будет предоставленА MFA.
3. Затем вычисляются пользовательские правила с помощью OID политик. Если у вас есть сертификат A с политикой OID 1.2.3.4.5 и производными учетными данными B на основе этого сертификата с политикой OID 1.2.3.4.5.6, а настраиваемое правило определяется как идентификатор политики с значением 1.2.3.4.5 с MFA, только сертификат A удовлетворяет MFA, а учетные данные B удовлетворяют только однофакторной проверке подлинности. Если пользователь использовал производные учетные данные во время входа и был настроен на MFA, пользователь запрашивает второй фактор успешной проверки подлинности.
4. Если существует конфликт между несколькими идентификаторами политик (например, если сертификат имеет два OID политики, где один привязывается к однофакторной проверке подлинности и другим привязывается к MFA), то обработайте сертификат как однофакторную проверку подлинности.
5. Затем вычисляются пользовательские правила с помощью ЦС издателя.
6. Если сертификат имеет соответствие правил политики OID и издателя, идентификатор политики всегда проверяется первым, и если правило политики не найдено, то проверяются привязки издателя. Идентификатор объекта политики имеет более высокий приоритет привязки проверки подлинности, чем издатель.
7. Если один ЦС привязывается к MFA, все сертификаты пользователей, выдаваемые этим ЦС, квалифицируются как MFA. Такая же логика применяется для однофакторной проверки подлинности.
8. Если один OID политики привязывается к MFA, все сертификаты пользователей, включающие этот идентификатор OID политики в качестве одного из идентификаторов OID (сертификат пользователя может иметь несколько идентификаторов OID политики), квалифицируются как MFA.
9. У одного издателя сертификата может быть только одна допустимая строчная привязка проверки подлинности (т. е. сертификат не может привязаться как к одному фактору, так и к MFA).

Внимание

Существует известная проблема, из-за которой администратор политики проверки подлинности Microsoft Entra настраивает правило политики проверки подлинности CBA с помощью издателя и OID политики влияет на некоторые сценарии регистрации устройств, в том числе:

• Регистрация Windows Hello for Business
• Регистрация ключа безопасности Fido2
• Вход без пароля Windows Phone

Регистрация устройств с помощью присоединения к рабочему месту, идентификатор Microsoft Entra и гибридные сценарии присоединения устройств Microsoft Entra не влияют. Правила политики проверки подлинности CBA, использующие OID издателя ИЛИ политики, не влияют. Чтобы устранить проблему, администраторы политик проверки подлинности должны:

• Измените правила политики проверки подлинности на основе сертификатов в настоящее время с помощью параметров издателя и политики OID, а также удалите требование издателя или OID и сохраните его. ИЛИ
• Удалите правило политики проверки подлинности в настоящее время с помощью издателя и OID политики и создайте правила с помощью только издателя или OID политики

Мы работаем над устранением проблемы.

Общие сведения о политике привязки имени пользователя

Политика привязки имени пользователя помогает проверить сертификат пользователя. По умолчанию имя субъекта-субъекта субъекта (SAN) в сертификате сопоставляется с атрибутом UserPrincipalName объекта пользователя для определения пользователя.

Повышение безопасности с помощью привязок сертификатов

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

Типы сопоставления на основе имен пользователей и адресов электронной почты считаются низкими сходствами. Идентификатор Microsoft Entra реализует три сопоставления, которые считаются низким сходством на основе повторно используемых идентификаторов. Другие считаются привязками высокой сходства. Дополнительные сведения см. в разделе certificateUserIds.

Поле сопоставления сертификатов	Примеры значений в certificateUserIds	Атрибуты объекта пользователя	Тип
Основное имя	X509:<PN>bob@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	низкая сходство
RFC822Name	X509:<RFC822>user@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	низкая сходство
IssuerAndSubject (предварительная версия)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	низкая сходство
Тема (предварительная версия)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	низкая сходство
SKU	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	certificateUserIds	высокая сходство
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR	certificateUserIds	высокая сходство
IssuerAndSerialNumber (предварительная версия)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT Чтобы получить правильное значение для серийного номера, выполните следующую команду и сохраните значение, показанное в CertificateUserIds: Синтаксис Certutil –dump –v [~certificate path~] >> [~dumpFile path~] Пример: certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	высокая сходство

Определение привязки affinity на уровне клиента и переопределение с настраиваемыми правилами (предварительная версия)

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

Как идентификатор Microsoft Entra ID разрешает несколько правил привязки политик имени пользователя

Используется привязка с наивысшим приоритетом (наименьшим числом).

1. Поиск объекта пользователя с помощью имени пользователя или имени участника-пользователя.
2. Получите список всех привязок пользователей, которые настроены администратором политики проверки подлинности в конфигурации метода проверки подлинности CBA, упорядоченной атрибутом priority. Сегодня концепция приоритета не предоставляется в пользовательском интерфейсе портала. Graph возвращает атрибут приоритета для каждой привязки, и они используются в процессе оценки.
3. Если у клиента включена привязка с высоким сходством или если значение сертификата соответствует пользовательскому правилу, требующем привязки высокой сходства, удалите все привязки с низким сходством из списка.
4. Оцените каждую привязку в списке, пока не будет выполнена успешная проверка подлинности.
5. Если поле сертификата X.509 настроенной привязки находится в представленном сертификате, идентификатор Microsoft Entra соответствует значению в поле сертификата значению атрибута пользовательского объекта.
   1. Если совпадение найдено, проверка подлинности пользователя выполнена успешно.
   2. Если совпадение не найдено, перейдите к следующей привязке приоритета.
6. Если поле сертификата X.509 отсутствует в представленном сертификате, перейдите к следующей привязке приоритета.
7. Проверьте все настроенные привязки имени пользователя, пока один из них не приведет к успешной проверке подлинности пользователя.
8. Если совпадение не найдено ни в одной из настроенных привязок пользователей, проверка подлинности пользователя завершается ошибкой.

Защита конфигурации Microsoft Entra с помощью нескольких привязок имени пользователя

Каждый атрибут объекта пользователя Microsoft Entra (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds), доступный для привязки сертификатов к учетным записям пользователей Microsoft Entra, имеет уникальное ограничение, чтобы убедиться, что сертификат соответствует только одной учетной записи пользователя Microsoft Entra. Однако Microsoft Entra CBA поддерживает несколько методов привязки в политике привязки имени пользователя, которая позволяет администратору политики проверки подлинности разместить один сертификат в нескольких конфигурациях учетных записей пользователей Microsoft Entra.

Внимание

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

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

Например, предположим, что у вас есть две привязки имени пользователя для имени участника-пользователя, сопоставленного с upN и SubjectKeyIdentifier (SKI) с сертификатомUserIds. Если требуется, чтобы сертификат использовался только для одной учетной записи, администратор политики проверки подлинности должен убедиться, что у учетной записи есть имя участника-пользователя, который присутствует в сертификате, и реализовать сопоставление SKI в атрибуте certificateUserId той же учетной записи.

Поддержка нескольких сертификатов с одной учетной записью пользователя Microsoft Entra (M:1)

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

Облачные учетные записи только для облачных учетных записей можно сопоставить несколько сертификатов (до 5) для использования, заполняя поле certificateUserIds (сведения о авторизации на пользовательском портале) уникальными значениями, определяющими каждый сертификат. Если организация использует привязки с высоким сходством, например Issuer + SerialNumber, значения в CertificateUserIds могут выглядеть следующим образом:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

В этом примере первое значение представляет X509Certificate1, а второе значение представляет X509Certificate2. Пользователь может представить любой сертификат при входе, и если для привязки имени пользователя CBA задано указание на поле certificateUserIds, чтобы найти конкретный тип привязки (то есть Issuer+SerialNumber в этом примере), пользователь успешно войдет в систему.

Гибридные синхронизированные учетные записи для синхронизированных учетных записей можно сопоставить несколько сертификатов для использования, заполняя поле altSecurityIdentities в AD значения, определяющие каждый сертификат. Если организация использует привязки высокой сходства (т. е. строгой проверки подлинности) говорят issuer + SerialNumber, это может выглядеть следующим образом:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

В этом примере первое значение представляет X509Certificate1, а второе значение представляет X509Certificate2. Затем эти значения должны быть синхронизированы с полем certificateUserIds в идентификаторе Microsoft Entra.

Поддержка одного сертификата с несколькими учетными записями пользователей Microsoft Entra (1:M)

Существуют сценарии, в которых организация должна использовать один и тот же сертификат для проверки подлинности в нескольких удостоверениях. Чаще всего это касается учетных записей администрирования. Это также может быть для учетных записей разработчиков или временных учетных записей обязанностей. В традиционном поле AD altSecurityIdentities используется для заполнения значений сертификата, а подсказка используется во время входа для направления AD в нужную учетную запись для проверки входа. При использовании Microsoft Entra CBA это отличается и нет подсказки. Вместо этого обнаружение домашней области определяет нужную учетную запись для проверки значений сертификата. Другое ключевое отличие заключается в том, что Microsoft Entra CBA обеспечивает уникальность в поле certificateUserIds. Это означает, что две учетные записи не могут заполнять одинаковые значения сертификатов.

Внимание

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

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

Заполните поле certificateUserIds (сведения о авторизации на пользовательском портале) уникальным значением, определяющим нужный сертификат. Если в организации используются привязки высокой сходства (т. е. строгой проверки подлинности) говорят issuer + SerialNumber и SKI, это может выглядеть следующим образом:

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

• Издатель + серийный номер —> CertificateUserIds
• SKI —> CertificateUserIds

Значения CertificateUserIds учетной записи пользователя:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

Теперь, когда любой пользователь представляет тот же сертификат при входе, пользователь успешно войдет в систему, так как их учетная запись соответствует уникальному значению этого сертификата. Одна учетная запись будет проходить проверку подлинности с помощью issuer+SerialNumber и другой с помощью привязки SKI.

Примечание.

Количество учетных записей, которые можно использовать таким образом, ограничивается количеством привязок пользователей, настроенных для клиента. Если организация использует только привязки высокого сопоставления, количество поддерживаемых учетных записей будет ограничено 3. Если организация также использует привязки с низким сходством, это число увеличивается до 7 учетных записей (1 PrincipalName, 1 RFC82Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Тема).

Гибридные синхронизированные учетные записи для синхронизированных учетных записей подход будет отличаться. Хотя администраторы политики проверки подлинности могут сопоставлять уникальные значения с каждой учетной записью пользователя, которая будет использовать сертификат, распространенная практика заполнения всех значений для каждой учетной записи в идентификаторе Microsoft Entra будет сделать это трудно. Вместо этого Microsoft Entra Connect должен фильтровать требуемые значения для каждой учетной записи, чтобы уникальные значения, заполненные учетной записью в идентификаторе Microsoft Entra. Правило уникальности применяется в пределах границы одного каталога или клиента (то есть администраторы политики проверки подлинности могут сопоставить сертификат для использования в другом каталоге или клиенте, если значения остаются уникальными для каждой учетной записи). Кроме того, в организации может быть несколько лесов AD, которые вносят вклад пользователей в один клиент Microsoft Entra. В этом случае Microsoft Entra Connect будет применять фильтр к каждому из этих лесов AD с той же целью, чтобы заполнить только нужное уникальное значение для облачной учетной записи.

Заполните поле altSecurityIdentities в AD значениями, определяющими нужный сертификат, и включите требуемое значение сертификата для этого типа учетной записи пользователя (например, подробности, администратора, разработчика и т. д.). Выберите ключевой атрибут в AD, который сообщит синхронизации, какой тип учетной записи пользователя оценивает пользователь (например, msDS-cloudExtensionAttribute1). Заполните этот атрибут значением типа пользователя, например подробным, администратором или разработчиком. Если это основная учетная запись пользователя, значение можно оставить пустым или null.

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

Лес 1 — Account1 (bob@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Лес 1 — Account2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Лес 2 — ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Затем эти значения должны быть синхронизированы с полем certificateUserIds в идентификаторе Microsoft Entra.

Шаги по синхронизации с certificateUserIds

1. Настройка Microsoft Entra Connect для добавления поля alternativeSecurityIds в Метавселенную
2. Для каждого леса AD настройте новое пользовательское правило входящего трафика с высоким приоритетом (низкое число ниже 100). Добавьте преобразование выражения с полем altSecurityIdentities в качестве источника. Целевое выражение будет использовать выбранный и заполненный ключевой атрибут, а также сопоставление с определенными типами пользователей.
3. Например:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

В приведенном выше примере altSecurityIdentities и ключевого атрибута msDS-cloudExtensionAttribute1is сначала проверяются, если они заполнены. Если нет, проверка altSecurityIdentities проверяется, заполняется ли она. Если он пуст, то присвойте ему значение NULL. В противном случае учетная запись попадает в регистр по умолчанию, и в этом примере мы отфильтруем только сопоставление Issuer+SerialNumber. Если ключевой атрибут заполняется, то проверяется значение, чтобы узнать, равен ли он одному из определенных типов пользователей. В этом примере, если это значение является подробным, мы отфильтруем значение SHA1PublicKey из altSecurityIdentities. Если значение является разработчиком, мы отфильтруем значение SubjectKeyIssuer из altSecurityIdentities. Может быть несколько значений сертификатов определенного типа. Например, несколько значений PrincipalName или НЕСКОЛЬКО ЗНАЧЕНИй SKI или SHA1-PUKEY. Фильтр получит все значения и синхронизируется с идентификатором Microsoft Entra — а не только первым, который он находит.

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

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
) 

Если значение в altSecurityIdentities не соответствует ни одному из значений поиска в атрибуте элемента управления, передается авторитарнаяNull. Это гарантирует, что предыдущие или последующие правила, которые заполняют alternativeSecurityId, игнорируются, и результат пуст в идентификаторе Microsoft Entra.

1. Настройте новое пользовательское правило исходящего трафика с низким приоритетом (большое число выше 160 – внизу списка).
2. Добавьте прямое преобразование с полем alternativeSecurityIds в качестве источника и поля certificateUserIds в качестве целевого объекта.
3. Выполните цикл синхронизации, чтобы завершить заполнение данных в идентификаторе Microsoft Entra.

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

Общие сведения о процессе отзыва сертификата

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

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

Администраторы политики проверки подлинности могут настроить точку распространения CRL во время процесса установки доверенных издателей в клиенте Microsoft Entra. У каждого доверенного издателя должен быть список отзыва сертификатов, на которые можно ссылаться с помощью URL-адреса, доступного к Интернету.

Внимание

Максимальный размер списка отзыва сертификатов для идентификатора Microsoft Entra для успешного скачивания в интерактивном входе и кэше составляет 20 МБ в общедоступных идентификаторах Microsoft Entra ID и 45 МБ в облаках Azure для государственных организаций США, и время, необходимое для скачивания списка отзыва сертификатов, не должно превышать 10 секунд. Если идентификатор Microsoft Entra ID не может скачать список отзыва сертификатов, проверка подлинности на основе сертификатов с использованием сертификатов, выданных соответствующим ЦС, завершается сбоем. Рекомендуется хранить файлы CRL в пределах ограничений размера, сохранять сроки существования сертификатов в разумных ограничениях и очищать просроченные сертификаты. Дополнительные сведения см. в разделе Существует ли ограничение для размера списка отзыва сертификатов?.

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

"Список отзыва сертификатов (CRL), скачанный из {URI}, превысил максимальный допустимый размер ({size} байт) для списков отзыва сертификатов в идентификаторе Microsoft Entra. Повторите попытку через несколько минут. Если проблема сохранится, обратитесь к администраторам клиента".

После ошибки идентификатор Microsoft Entra пытается скачать список отзыва сертификатов, подлежащих ограничениям на стороне службы (45 МБ в общедоступных идентификаторах Microsoft Entra ID и 150 МБ в облаках Azure для государственных организаций США).

Внимание

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

На данный момент мы не поддерживаем Online Certificate Status Protocol (OCSP) из соображений производительности и надежности. Вместо скачивания списка отзыва сертификатов при каждом подключении клиентским браузером для OCSP идентификатор Microsoft Entra скачивается один раз при первом входе и кэширует его, тем самым повышая производительность и надежность проверки списка отзыва сертификатов. Мы также индексируем кэш, чтобы значительно повысить скорость работы при каждом поиске. Клиенты должны публиковать списки отзыва сертификатов для отзыва сертификата.

Ниже приведен типичный поток проверки списка отзыва сертификатов.

1. Идентификатор Microsoft Entra пытается скачать список отзыва сертификатов при первом входе любого пользователя с сертификатом соответствующего доверенного издателя или центра сертификации.
2. Идентификаторы Microsoft Entra кэшируются и повторно используют список отзыва сертификатов для последующего использования. Она учитывает дату следующего обновления и, если она доступна, в документе CRL дата публикации следующего списка отзыва сертификатов (используется центрами сертификации Windows Server).
3. Проверка подлинности на основе сертификата пользователя завершается ошибкой, если:

   • Список отзыва сертификатов настроен для доверенного издателя, и идентификатор Microsoft Entra ID не может скачать список отзыва сертификатов из-за ограничений доступности, размера или задержки.

   • Сертификат пользователя указан как отозванный в списке отзыва сертификатов.

     

   • Идентификатор Microsoft Entra пытается скачать новый список отзыва сертификатов из точки распространения, если истек срок действия кэшированного документа CRL.

Примечание.

Идентификатор Microsoft Entra проверяет список отзыва выдаваемых ЦС и других ЦС в цепочке доверия PKI до корневого ЦС. У нас есть ограничение до 10 ЦС из конечного сертификата клиента для проверки CRL в цепочке PKI. Ограничение заключается в том, чтобы убедиться, что плохой субъект не приводит службу, отправляя цепочку PKI с огромным количеством ЦС с большим размером CRL. Если в цепочке PKI клиента более 5 ЦС и в случае компрометации ЦС администраторы политики проверки подлинности должны удалить скомпрометированного доверенного издателя из конфигурации клиента Microsoft Entra.

Внимание

Из-за характера циклов кэширования и публикации CRL настоятельно рекомендуется в случае отзыва сертификата также отозвать все сеансы затронутого пользователя в идентификаторе Microsoft Entra ID.

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

Настройка отзыва сертификата

Чтобы отозвать сертификат клиента, идентификатор Microsoft Entra извлекает список отзыва сертификатов (CRL) из URL-адресов, отправленных в рамках сведений центра сертификации и кэширует его. Метка времени последней публикации (свойствоДата вступления в силу ) в списке отзыва сертификатов обеспечивает допустимость этого списка. Список отзыва сертификатов периодически опрашивается для отзыва доступа к сертификатам, которые числятся в этом списке.

Если требуется более быстрый отзыв (например, если пользователь потерял устройство), то маркер авторизации пользователя можно сделать недействительным. Чтобы сделать маркер авторизации недействительным, с помощью Windows PowerShell определите поле StsRefreshTokenValidFrom для этого пользователя. Поле StsRefreshTokenValidFrom необходимо обновить для каждого пользователя, доступ для которого будет отозван.

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

Примечание.

Модули 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 г.

Ниже описан процесс обновления и аннулирования маркера авторизации с помощью поля StsRefreshTokenValidFrom .

1. Подключитесь к PowerShell:

   Connect-MgGraph
   

2. Получите текущее значение StsRefreshTokensValidFrom для пользователя:

           $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
           $user.StsRefreshTokensValidFrom
   

3. Настройте новое значение StsRefreshTokensValidFrom для пользователя, равное текущей метке времени:

           Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")
   

Задаваемая дата должна быть в будущем. Если дата не в будущем, свойство StsRefreshTokensValidFrom не будет задано. Если дата в будущем, для StsRefreshTokensValidFrom задается актуальное время (не дата, указанная командой Set-MsolUser).

Общие сведения о проверке списка отзыва сертификатов (предварительная версия)

CRL — это запись цифровых сертификатов, которые были отозваны до окончания срока их действия центром сертификации (ЦС). Если ЦС отправляются в хранилище доверия Microsoft Entra, CRL или более конкретно атрибут CrlDistributionPoint, не требуется. ЦС можно отправить без конечной точки CRL, и проверка подлинности на основе сертификатов не завершится ошибкой, если у выданного ЦС нет указанного списка отзыва сертификатов.

Чтобы укрепить безопасность и избежать неправильной настройки, администратор политики проверки подлинности может потребовать проверки подлинности CBA, чтобы завершиться ошибкой, если для ЦС не настроен сертификат пользователя.

Включение проверки списка отзыва сертификатов

Чтобы включить проверку списка отзыва сертификатов, нажмите кнопку "Требовать проверку CRL" (рекомендуется).

После включения любой CBA завершится сбоем, если сертификат конечного пользователя был выдан ЦС без настройки CRL.

Администратор политики проверки подлинности может исключить ЦС, если его список отзыва сертификатов имеет проблемы, которые должны быть исправлены. Нажмите кнопку "Добавить исключение" и выберите все ЦС, которые должны быть исключены.

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

Примечание.

Существует известная проблема с средство выбора объектов, в котором выбранные элементы не отображаются правильно. Используйте вкладку "Центры сертификации", чтобы выбрать или удалить центры сертификации.

Как CBA работает с политикой надежности проверки подлинности условного доступа

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

Вы можете использовать встроенную надежность проверки подлинности MFA с устойчивостью к фишингу. Эта политика позволяет использовать только методы проверки подлинности, устойчивые к фишингу, такие как ключи безопасности CBA, FIDO2 и Windows Hello для бизнеса.

Вы также можете создать настраиваемую силу проверки подлинности, чтобы разрешить доступ только к конфиденциальным ресурсам CBA. Можно разрешить CBA как однофакторную, многофакторную или обе. Дополнительные сведения см. в разделе "Надежность проверки подлинности условного доступа".

Надежность проверки подлинности CBA с расширенными параметрами

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

Общие сведения о журналах входа

Журналы входа содержат сведения об операциях входа и использовании ресурсов пользователями. Дополнительные сведения о журналах входа см. в журналах входа в идентификаторе Microsoft Entra.

Давайте рассмотрим два сценария: один, где сертификат удовлетворяет однофакторной проверке подлинности, и другой, где сертификат удовлетворяет MFA.

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

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

Устранение неполадок входа с динамическими переменными в журналах входа

Несмотря на то, что журналы входа предоставляют все сведения для отладки проблем входа пользователя, возникают времена, когда требуются определенные значения и так как журналы входа не поддерживают динамические переменные, журналы входа будут иметь недостающие сведения. Например, причина сбоя в журнале входа будет отображаться примерно так: "Список отзыва сертификатов (CRL) завершился ошибкой проверки подписи. Ожидаемый идентификатор ключа субъекта {expectedSKI} не соответствует ключу центра CRL {crlAK}. Попросите администратора клиента проверить конфигурацию CRL, где {expectedSKI} и {crlAKI} не заполнены правильными значениями.

При сбое входа пользователей с помощью CBA скопируйте сведения о журнале из ссылки "Дополнительные сведения" на странице ошибки. Дополнительные сведения см. на странице ошибок CBA

Тестирование однофакторной проверки подлинности

Для первого тестового сценария настройте политику проверки подлинности, в которой правило субъекта издателя удовлетворяет однофакторной проверке подлинности.

1. Войдите в Центр администрирования Microsoft Entra в качестве тестового пользователя с помощью CBA. Политика проверки подлинности устанавливается, где правило субъекта издателя удовлетворяет однофакторной проверке подлинности.

2. Найдите и выберите журналы входа.

   Давайте подробнее рассмотрим некоторые записи, которые можно найти в журналах входа.

   Первая запись запрашивает у пользователя сертификат X.509. Состояние прервано означает, что идентификатор Microsoft Entra проверяет, включен ли CBA в клиенте, а сертификат запрашивается для проверки подлинности.

   

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

   

   раздел Дополнительные сведения содержит сведения о сертификате.

   

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

   

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

Для следующего тестового сценария настройте политику проверки подлинности, в которой правило policyOID удовлетворяет многофакторной проверке подлинности.

1. Войдите в Центр администрирования Microsoft Entra с помощью CBA. Так как политика была настроена для многофакторной проверки подлинности, вход пользователя выполняется успешно без второго фактора.

2. Найдите и выберите вход.

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

   

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

   

   Запись с состоянием Прервано содержит дополнительные диагностические сведения на вкладке Дополнительные сведения.

   

   Следующая таблица содержит описание каждого поля.

   Поле	Description
   Имя субъекта сертификата пользователя	Ссылается на поле имени субъекта в сертификате.
   Привязка сертификата пользователя	Сертификат: имя субъекта; атрибут пользователя: userPrincipalName; ранг: 1 Здесь указано, какое поле сертификата PrincipalName SAN было сопоставлено с атрибутом пользователя userPrincipalName и имело приоритет 1.
   Уровень проверки подлинности сертификата пользователя	multiFactorAuthentication
   Тип уровня проверки подлинности на основе сертификата пользователя	PolicyId Показывает, что идентификатор OID политики использовался для определения надежности проверки подлинности.
   Идентификатор уровня проверки подлинности на основе сертификата пользователя	1.2.3.4 Показывает значение идентификатора OID политики из сертификата.

Общие сведения об ошибке проверки подлинности на основе сертификатов

Проверка подлинности на основе сертификатов может завершиться ошибкой по таким причинам, как недопустимый сертификат, или пользователь выбрал неправильный сертификат или сертификат с истекшим сроком действия или из-за проблемы со списком отзыва сертификатов (CRL). При сбое проверки сертификата пользователь видит следующую ошибку:

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

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

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

Примечание.

Если вы повторяете CBA в браузере, это не будет происходить из-за проблемы кэширования браузера. Пользователям необходимо снова открыть новый сеанс браузера и войти снова.

Проверка подлинности на основе сертификатов в методах MostRecentlyUsed (MRU)

После успешной проверки подлинности пользователя с помощью CBA метод проверки подлинности MostRecentlyUsed (MRU) пользователя имеет значение CBA. При следующем вводе имени участника-пользователя и нажатии кнопки "Далее" пользователь напрямую переходит к методу CBA и не нужно выбирать сертификат или смарт-карту.

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

Поддержка внешних удостоверений

Внешнее удостоверение не может выполнять многофакторную проверку подлинности в клиенте ресурсов с помощью Microsoft Entra CBA. Вместо этого пользователь выполняет многофакторную проверку подлинности с помощью CBA в домашнем клиенте и настраивает межтенантные параметры для клиента ресурсов, чтобы доверять MFA из домашнего клиента.

Дополнительные сведения о том, как включить многофакторную проверку подлинности Trust из клиентов Microsoft Entra, см. в разделе "Настройка межтенантного доступа к службе совместной работы B2B".

Следующие шаги

• Обзор Microsoft Entra CBA
• Настройка Microsoft Entra CBA
• Microsoft Entra CBA на устройствах iOS
• Microsoft Entra CBA на устройствах Android
• Вход в систему смарт-карты Windows с помощью Microsoft Entra CBA
• Идентификаторы пользователей сертификата
• Перенос федеративных пользователей
• Вопросы и ответы
• Устранение неполадок Microsoft Entra CBA