Техническое подробное руководство по проверке подлинности на основе сертификатов 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 издателя + политики имеют приоритет над правилами 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 на основе этого сертификата с политикой OID1.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).

Внимание

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

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

Регистрация устройств с помощью присоединения к рабочему месту, идентификатора записи и гибридных сценариев присоединения к устройству entra ID не влияет. Правила политики проверки подлинности 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>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 политики проверки подлинности можно настроить, может ли пользователь пройти проверку подлинности с помощью сопоставления с низким сходством или сопоставления с именем пользователя с высоким уровнем сопоставления пользователей. Для клиента можно задать обязательную привязку сходства, которая применяется ко всем пользователям. Можно также переопределить значение по умолчанию на уровне клиента, создав настраиваемые правила на основе издателя и 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 поддерживает несколько методов привязки в политике привязки имени пользователя, которая позволяет администратору разместить один сертификат в нескольких конфигурациях учетных записей пользователей Entra.

Внимание

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

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

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

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

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

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

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

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

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

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

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

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

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

Внимание

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

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

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

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

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

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

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

Примечание.

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

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

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

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

Лес 1 — Account1 (bob@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Лес 1 — Account2 (bob-admin@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Лес 2 — ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

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

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

1. Настройка Подключения Azure AD для добавления поля 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. Фильтр получит все значения и синхронизированы с идентификатором 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, игнорируются, и результат пуст в идентификаторе записи.

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

Убедитесь, что CBA в каждом клиенте настроен с помощью привязок имени пользователя, указывающих на поле certificateUserIds для типов полей, сопоставленных с сертификатом. Теперь любой из этих пользователей может представить сертификат при входе и после того, как уникальное значение сертификата проверяется в поле 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, а также убедиться, что этот сертификат есть в списке отзыва сертификатов.

Примечание.

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

Как 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
• Вход в систему smart карта Windows с помощью Microsoft Entra CBA
• Идентификаторы пользователей сертификата
• Перенос федеративных пользователей
• Вопросы и ответы
• Устранение неполадок Microsoft Entra CBA