Техническое подробное руководство по проверке подлинности на основе сертификатов 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 для общедоступного идентификатора Записи. Для 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. После успешного входа в систему пользователь может получить доступ к приложению.

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

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

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

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

   Важно!

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

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

   

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

   

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

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

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

   

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

   

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

   

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

   

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

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

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

   

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

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

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

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

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

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

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

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

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

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

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

Политика привязки имени пользователя помогает проверить сертификат пользователя. По умолчанию имя субъекта-субъекта субъекта (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	низкая сходство
Subject	X509:\<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	низкая сходство
SKU	X509:\<SKI>123456789abcdef	certificateUserIds	высокая сходство
SHA1PublicKey	X509:\<SHA1-PUKEY>123456789abcdef	certificateUserIds	высокая сходство
IssuerAndSerialNumber	X509:\<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA\<SR>b24134139f069b49997212a86ba0ef48 Чтобы получить правильное значение для серийного номера, выполните следующую команду и сохраните значение, показанное в CertificateUserIds: Синтаксис Certutil –dump –v [~certificate path~] >> [~dumpFile path~] Пример: certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	высокая сходство

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

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

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

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

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

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

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

Важно!

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

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

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

Ниже приведен пример потенциальных значений для имени участника-участника и сертификатаUserID:

Имя участника-пользователя Microsoft Entra = Bob.Smith@Contoso.com
certificateUserIDs = [x509:<SKI>89b0f468c1abea65ec2f0a882b8fda6fd6750p]

Наличие значений PrincipalName и SKI из сертификата пользователя, сопоставленного с одной учетной записью, гарантирует, что, хотя политика клиента разрешает сопоставление значений PrincipalName с Microsoft Entra UPN & SKI в certificateUserIds, этот сертификат может соответствовать только одной учетной записи Microsoft Entra. При использовании уникального ограничения userPrincipalName и certificateUserIds другие учетные записи пользователя не могут иметь одинаковые значения и не могут успешно пройти проверку подлинности с одинаковым сертификатом.

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

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

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

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

Важно!

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

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

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

После ошибки идентификатор Microsoft Entra пытается скачать список отзыва сертификатов, подлежащих ограничениям на стороне службы (45 МБ в общедоступных идентификаторах записей и 150 МБ в облаках Azure для государственных организаций 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 проверка CRL выдачи ЦС и других ЦС в цепочке доверия PKI до корневого ЦС. У нас есть ограничение до 10 ЦС из конечного сертификата клиента для проверки CRL в цепочке PKI. Ограничение заключается в том, чтобы убедиться, что плохой субъект не приводит службу, отправляя цепочку PKI с огромным количеством ЦС с большим размером CRL. Если сеть PKI клиента имеет более 5 ЦС и в случае компрометации ЦС, администратор должен удалить скомпрометированного доверенного издателя из конфигурации клиента Microsoft Entra.

Важно!

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

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

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

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

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

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

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

1. Используя учетные данные администратора, подключитесь к службе MSOL:

           $msolcred = get-credential
            connect-msolservice -credential $msolcred
   

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).

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

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

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

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

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

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

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

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".

Известные проблемы

• На клиентах iOS возникает двойная проблема с запросом в рамках потока Microsoft Entra CBA, где пользователю необходимо выбрать сертификат или смарт-карта дважды. Мы знаем о проблеме взаимодействия с пользовательским интерфейсом и о работе над решением этой проблемы для простого пользовательского интерфейса.

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

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