Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описываются технические понятия, описывающие принципы работы проверки подлинности на основе сертификатов (CBA) Microsoft Entra. Получите технический фон, чтобы лучше узнать, как настроить Microsoft Entra CBA и управлять ими в вашем клиенте.
Как работает проверка подлинности на основе сертификатов Microsoft Entra?
На следующем рисунке показано, что происходит, когда пользователь пытается войти в приложение в клиенте с настроенным Microsoft Entra CBA.
Ниже приведены сведения о процессе Microsoft Entra CBA.
Пользователь пытается получить доступ к приложению, например на портале MyApps.
Если пользователь еще не вошел в систему, он перенаправляется на страницу
https://login.microsoftonline.com/входа пользователя Microsoft Entra ID.Они введите имя пользователя на странице входа в Microsoft Entra и нажмите кнопку "Далее". Идентификатор Microsoft Entra завершает обнаружение домашней области с помощью имени клиента. Он использует имя пользователя для поиска пользователя в клиенте.
Идентификатор Microsoft Entra проверяет, настроена ли CBA для клиента. Если CBA настроен, пользователь видит ссылку на использование сертификата или смарт-карты на странице пароля. Если пользователь не видит ссылку для входа, убедитесь, что для клиента настроенА CBA.
Дополнительные сведения см. в статье "Как включить Microsoft Entra CBA?".
Примечание.
Если CBA настроен для клиента, все пользователи видят ссылку "Использовать сертификат" или ссылку смарт-карты на странице входа в пароль. Однако только пользователи, которые находятся в области CBA, могут успешно пройти проверку подлинности для приложения, использующего идентификатор Microsoft Entra в качестве поставщика удостоверений.
Если вы предоставляете другие методы проверки подлинности, такие как вход телефона или ключи безопасности, пользователи могут видеть другое диалоговое окно входа.
После выбора CBA клиент перенаправляется в конечную точку проверки подлинности сертификата. Для общедоступного идентификатора Microsoft Entra используется
https://certauth.login.microsoftonline.comконечная точка проверки подлинности сертификата. Для Azure для государственных организаций конечная точка проверки подлинности сертификата —https://certauth.login.microsoftonline.usэто .Конечная точка выполняет взаимную проверку подлинности tls и запрашивает сертификат клиента в рамках подтверждения TLS. В журнале входа содержится запись об этом запросе.
Примечание.
Администратор должен разрешить доступ к странице входа пользователя и к
*.certauth.login.microsoftonline.comконечной точке проверки подлинности сертификата для облачной среды. Отключите проверку TLS на конечной точке проверки подлинности сертификата, чтобы убедиться, что запрос сертификата клиента успешно выполнен в рамках подтверждения TLS.Убедитесь, что отключение проверки TLS также работает для подсказок издателя с новым URL-адресом. Не закодивайте URL-адрес с идентификатором клиента. Идентификатор клиента может измениться для пользователей бизнес-бизнеса (B2B). Используйте регулярное выражение, чтобы разрешить как предыдущий URL-адрес, так и новый URL-адрес для работы при отключении проверки TLS. Например, в зависимости от прокси-сервера, используйте
*.certauth.login.microsoftonline.comили*certauth.login.microsoftonline.com. В Azure для государственных организаций используйте*.certauth.login.microsoftonline.usили*certauth.login.microsoftonline.us.Если доступ не разрешен, CBA завершается ошибкой при включении подсказок издателя.
Идентификатор Microsoft Entra запрашивает сертификат клиента. Пользователь выбирает сертификат клиента, а затем нажимает кнопку "ОК".
Идентификатор Microsoft Entra проверяет список отзыва сертификатов (CRL), чтобы убедиться, что сертификат не отозван и что он действителен. Идентификатор Microsoft Entra определяет пользователя с помощью привязки имени пользователя, настроенной в клиенте для сопоставления значения поля сертификата со значением атрибута пользователя.
Если уникальный пользователь найден с помощью политики условного доступа Microsoft Entra, требующей многофакторной проверки подлинности (MFA), а правило привязки проверки подлинности сертификата удовлетворяет MFA, идентификатор Microsoft Entra ID сразу же выполняет вход пользователя. Если требуется MFA, но сертификат удовлетворяет только одному фактору, если пользователь уже зарегистрирован, вход без пароля и FIDO2 предлагаются в качестве второго фактора.
Идентификатор Microsoft Entra завершает процесс входа, отправляя первичный токен обновления обратно, тем самым подтверждая успешный вход.
Если вход пользователя выполнен успешно, пользователь может получить доступ к приложению.
Подсказки издателя (предварительная версия)
Подсказки издателя отправляют доверенный индикатор ЦС в рамках подтверждения TLS. Список доверенных ЦС задан для субъекта центров сертификации, которые клиент отправляет в хранилище доверия Microsoft Entra. Клиент браузера или клиент собственного приложения может использовать указания, которые сервер отправляет обратно для фильтрации сертификатов, отображаемых в средство выбора сертификатов. Клиент отображает только сертификаты проверки подлинности, выданные центрами сертификации в хранилище доверия.
Включение подсказок издателя
Чтобы включить указания издателя, установите флажок "Подсказки издателя ". Администратор политики проверки подлинности должен выбрать "Подтвердить", убедившись, что прокси-сервер с проверкой TLS настроен правильно, а затем сохраните изменения.
Примечание.
Если у вашей организации есть брандмауэры или прокси-серверы, использующие проверку TLS, убедитесь, что вы отключили проверку TLS конечной точки ЦС, которая может соответствовать любому имени в [*.]certauth.login.microsoftonline.comсоответствии с конкретным прокси-сервером.
Примечание.
После включения подсказок издателя URL-адрес ЦС имеет формат <tenantId>.certauth.login.microsoftonline.com.
Распространение обновлений доверенного хранилища ЦС
После включения подсказок издателя и добавления, обновления или удаления ЦС из хранилища доверия может возникнуть задержка до 10 минут, а подсказки издателя распространяются обратно на клиент. Администратор политики проверки подлинности должен войти с помощью сертификата после того, как указания издателя становятся доступными для инициирования распространения.
Пользователи не могут пройти проверку подлинности с помощью сертификатов, выданных новыми центрами сертификации, пока не будут распространяться подсказки. Пользователи видят следующее сообщение об ошибке при распространении обновлений хранилища доверия ЦС:
MFA с одним фактором CBA
Microsoft Entra CBA квалифифизируется как для проверки подлинности первого фактора, так и для проверки подлинности второго фактора.
Ниже приведены некоторые поддерживаемые сочетания:
- CBA (первый фактор) и секретные ключи (второй фактор)
- CBA (первый фактор) и вход без пароля (второй фактор)
- Ключи безопасности CBA (первый фактор) и FIDO2 (второй фактор)
- Пароль (первый фактор) и CBA (второй фактор)
Пользователи должны иметь способ получить MFA и зарегистрировать вход без пароля или FIDO2 перед входом с помощью Microsoft Entra CBA.
Внимание
Пользователь считается MFA способным, если его имя пользователя отображается в параметрах метода CBA. В этом сценарии пользователь не может использовать свое удостоверение в рамках проверки подлинности для регистрации других доступных методов. Убедитесь, что пользователи без допустимого сертификата не включены в параметры метода CBA. Дополнительные сведения о том, как работает проверка подлинности, см. в разделе Многофакторная проверка подлинности Microsoft Entra.
Варианты получения возможности MFA при включенном CBA
Microsoft Entra CBA может быть однофакторной или многофакторной в зависимости от конфигурации клиента. Включение CBA делает пользователя потенциально способным выполнять MFA. Для завершения многофакторной проверки подлинности пользователь, имеющий однофакторный сертификат или пароль, должен использовать другой фактор.
Мы не разрешаем регистрацию других методов без первого удовлетворения MFA. Если у пользователя нет другого метода MFA, и он находится в области CBA, пользователь не может использовать подтверждение удостоверения для регистрации других методов проверки подлинности и получения MFA.
Если пользователь, поддерживающий CBA, имеет только однофакторный сертификат и должен завершить MFA, выберите один из следующих вариантов для проверки подлинности пользователя:
- Пользователь может ввести пароль и использовать однофакторный сертификат.
- Администратор политики проверки подлинности может выдать временный проход доступа.
- Администратор политики проверки подлинности может добавить номер телефона и разрешить проверку подлинности голосового или текстового сообщения для учетной записи пользователя.
Если пользователь, поддерживающий CBA, не был выдан сертификат и должен завершить MFA, выберите один из следующих вариантов для проверки подлинности пользователя:
- Администратор политики проверки подлинности может выдать временный проход доступа.
- Администратор политики проверки подлинности может добавить номер телефона и разрешить проверку подлинности голосового или текстового сообщения для учетной записи пользователя.
Если пользователь, поддерживающий CBA, не может использовать многофакторный сертификат, например если он использует мобильное устройство без поддержки смарт-карт, но он должен завершить MFA, выберите один из следующих вариантов для проверки подлинности пользователя:
- Администратор политики проверки подлинности может выдать временный проход доступа.
- Пользователь может зарегистрировать другой метод MFA (если пользователь может использовать многофакторный сертификат на устройстве).
- Администратор политики проверки подлинности может добавить номер телефона и разрешить проверку подлинности голосового или текстового сообщения для учетной записи пользователя.
Настройка входа без пароля телефона с помощью CBA
Для работы входа без пароля в систему телефона сначала отключите устаревшее уведомление через мобильное приложение для пользователя.
Войдите в Центр администрирования Microsoft Entra с правами не ниже Администратора политики проверки подлинности.
Выполните действия, описанные в разделе "Включить проверку подлинности без пароля для телефона".
Внимание
Убедитесь, что выбран параметр без пароля . Для всех групп, добавленных в вход без пароля, необходимо изменить значение режима проверки подлинности на "Без пароля". Если выбрать Any, CBA и вход без пароля не работают.
Выберите Entra ID>многофакторную аутентификацию>Дополнительные параметры многофакторной аутентификации в облаке.
В разделе "Параметры проверки" снимите флажок "Уведомление через мобильное приложение " и нажмите кнопку "Сохранить".
Поток проверки подлинности MFA с помощью однофакторных сертификатов и входа без пароля
Рассмотрим пример пользователя, имеющего однофакторный сертификат и настроенный для входа без пароля. По мере того как пользователь выполнил следующие действия:
Введите имя участника-пользователя (UPN), а затем нажмите кнопку "Далее".
Выберите "Использовать сертификат" или "Смарт-карта".
Если вы предоставляете другие методы проверки подлинности, такие как вход телефона или ключи безопасности, пользователи могут видеть другое диалоговое окно входа.
В средство выбора сертификатов клиента выберите правильный сертификат пользователя и нажмите кнопку "ОК".
Так как сертификат настроен как сила однофакторной проверки подлинности, для соответствия требованиям MFA требуется второй фактор. Доступные второй факторы отображаются в диалоговом окне входа. В этом случае это вход без пароля. Выберите "Утвердить запрос" для приложения Microsoft Authenticator.
Вы получаете уведомление на телефоне. Выберите "Утвердить вход?".
В Microsoft Authenticator введите номер, который отображается в браузере или приложении.
Выберите "Да", и вы можете выполнить проверку подлинности и войти.
Политика привязки проверки подлинности
Политика привязки проверки подлинности помогает задать силу проверки подлинности как однофакторную или многофакторную. Администратор политики проверки подлинности может изменить метод по умолчанию с одного фактора на многофакторный. Администратор также может настроить пользовательские конфигурации политик с помощью IssuerAndSubjectили PolicyOIDIssuerPolicyOID в сертификате.
Сила сертификата
Администраторы политики проверки подлинности могут определить, является ли сила сертификата однофакторной или многофакторной. Дополнительные сведения можно найти в документации, которая сопоставляет уровни уверенности аутентификации NIST с методами проверки подлинности Microsoft Entra и основана на NIST SP 800-63B, Рекомендации по цифровой идентичности: проверка подлинности и управление жизненным циклом.
Многофакторная проверка подлинности сертификата
Если у пользователя есть многофакторный сертификат, он может выполнять многофакторную проверку подлинности только с помощью сертификатов. Однако администратор политики проверки подлинности должен убедиться, что сертификаты защищены ПИН-кодом или биометрией, чтобы считаться многофакторным.
Несколько правил привязки политики проверки подлинности
Можно создать несколько правил политики привязки пользовательской проверки подлинности с помощью различных атрибутов сертификата. Примером является использование издателя и OID политики, а также только OID политики или просто издателя.
Следующая последовательность определяет уровень защиты проверки подлинности при перекрывающихся пользовательских правилах:
- Правила OID издателя и политики имеют приоритет над правилами OID политики. Правила OID политики имеют приоритет над правилами издателя сертификатов.
- Сначала вычисляются правила издателя и политики OID. Если у вас есть настраиваемое правило с поставщиком ЦС1 и OID
1.2.3.4.5политики с MFA, то только сертификат A, удовлетворяющий значению издателя и идентификатору политики, присваивается MFA. - Вычисляются пользовательские правила, использующие OID политики. Если у вас есть сертификат A с идентификатором политики и производными учетными данными B на основе этого сертификата с OID
1.2.3.4.51.2.3.4.5.6политики, а настраиваемое правило определяется как идентификатор политики, имеющий значение1.2.3.4.5MFA, только сертификат A удовлетворяет MFA. Учетные данные B удовлетворяют только однофакторной проверке подлинности. Если пользователь использовал производные учетные данные во время входа и был настроен для MFA, пользователь запрашивает второй фактор успешной проверки подлинности. - Если существует конфликт между несколькими OID политики (например, если сертификат имеет два OID политики, где один привязывается к однофакторной проверке подлинности и другим привязывается к MFA), то обработайте сертификат как однофакторную проверку подлинности.
- Вычисляются пользовательские правила, использующие ЦС издателя. Если сертификат имеет соответствующие правила политики OID и издателя, идентификатор политики всегда проверяется. Если правило политики не найдено, проверяются привязки издателя. Идентификатор политики имеет более высокий приоритет привязки строгой проверки подлинности, чем издатель.
- Если один ЦС привязывается к MFA, все сертификаты пользователей, выдаваемые этим ЦС, квалифицируются как MFA. Та же логика применяется к однофакторной проверке подлинности.
- Если один идентификатор политики привязывается к MFA, все сертификаты пользователей, которые включают этот идентификатор политики, как один из идентификаторов OID, квалифицируются как MFA. (Сертификат пользователя может иметь несколько OID политик.)
- Один издатель сертификатов может иметь только одну допустимую привязку строгой проверки подлинности (т. е. сертификат не может привязаться как к однофакторной проверке подлинности, так и к MFA).
Внимание
В настоящее время в известной проблеме, которая устранена, если администратор политики проверки подлинности создает правило политики CBA с помощью издателя и идентификатора политики, некоторые сценарии регистрации устройств затрагиваются.
К затронутым сценариям относятся следующие:
- Регистрация Windows Hello для бизнеса
- Регистрация ключа безопасности FIDO2
- Вход без пароля Windows
Регистрация устройств с помощью Рабочей присоединения, идентификатора Microsoft Entra и гибридных сценариев, присоединенных к Microsoft Entra, не влияет. Правила политики CBA, использующие издателя или OID политики, не затрагиваются.
Чтобы устранить проблему, администратор политики проверки подлинности должен выполнить один из следующих вариантов:
- Измените правило политики CBA, которое в настоящее время использует издателя и идентификатор политики для удаления издателя или требования идентификатора политики.
- Удалите правило политики проверки подлинности, которое в настоящее время использует издателя и идентификатор политики, а затем создайте правило, которое использует только издателя или идентификатор политики.
Политика привязки имени пользователя
Политика привязки имени пользователя помогает проверить сертификат пользователя. По умолчанию альтернативное имя субъекта (SAN) в сертификате сопоставляется с userPrincipalName атрибутом объекта пользователя для идентификации пользователя.
Повышение безопасности с помощью привязок сертификатов
Microsoft Entra поддерживает семь методов использования привязок сертификатов. Как правило, типы сопоставления считаются высокими сходствами, если они основаны на идентификаторах, которые нельзя использовать повторно, например SubjectKeyIdentifier (SKI) или SHA1PublicKey. Эти идентификаторы передают более высокую уверенность в том, что для проверки подлинности пользователя можно использовать только один сертификат.
Типы сопоставления на основе имен пользователей и адресов электронной почты считаются низким сходством. Идентификатор Microsoft Entra реализует три сопоставления, которые считаются низким сходством на основе повторно используемых идентификаторов. Другие считаются привязками высокой сходства. Дополнительные сведения см. в разделе certificateUserIds.
| Поле сопоставления сертификатов | Примеры значений в certificateUserIds |
Атрибуты объекта пользователя | Тип |
|---|---|---|---|
PrincipalName |
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 |
Низкая сходство |
SKI |
X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR= |
certificateUserIds |
Высокая сходство |
SHA1PublicKey |
X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR Значение SHA1PublicKey (хэш SHA1 всего содержимого сертификата, включая открытый ключ) находится в свойстве отпечатка сертификата. |
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 |
Высокая сходство |
Внимание
Модуль PowerShell можно использоватьCertificateBasedAuthentication для поиска правильного certificateUserIds значения для пользователя в сертификате.
Определение и переопределение привязки сходства
Администратор политики проверки подлинности может настроить, могут ли пользователи проходить проверку подлинности с помощью сопоставления с низким сходством или сопоставления с именем пользователя с высоким сходством.
Задайте обязательную привязку сходства для клиента, которая применяется ко всем пользователям. Чтобы переопределить значение по умолчанию на уровне клиента, создайте пользовательские правила на основе издателя и идентификатора политики, а также только идентификатора политики или просто издателя.
Несколько правил привязки политики имени пользователя
Чтобы устранить несколько правил привязки политики имени пользователя, идентификатор Microsoft Entra использует привязку с наивысшим приоритетом (наименьшим числом):
- Поиск объекта пользователя с помощью имени пользователя или имени участника-пользователя.
- Возвращает список всех привязок имени пользователя, настроенных администратором политики проверки подлинности в конфигурации метода CBA, упорядоченной атрибутом
priority. В настоящее время приоритет не отображается в Центре администрирования. Microsoft Graph возвращает атрибут для каждойpriorityпривязки. Затем приоритеты используются в процессе оценки. - Если у клиента настроена привязка с высоким сходством или если значение сертификата соответствует пользовательскому правилу, требующее привязки с высоким сходством, удаляет все привязки с низким сходством из списка.
- Вычисляет каждую привязку в списке, пока не будет выполнена успешная проверка подлинности.
- Если поле сертификата X.509 настроенной привязки присутствует в представленном сертификате, Microsoft Entra ID сопоставляет значение в поле сертификата со значением атрибута пользовательского объекта.
- Если совпадение найдено, проверка подлинности пользователя выполнена успешно.
- Если совпадение не найдено, переходит к следующей привязке приоритета.
- Если поле сертификата X.509 отсутствует в представленном сертификате, перейдите к следующей привязке приоритета.
- Проверяет все настроенные привязки имени пользователя, пока один из них не приведет к успешному совпадению и проверке подлинности пользователя.
- Если совпадение не найдено ни в одной из настроенных привязок пользователей, проверка подлинности пользователя завершается ошибкой.
Защита конфигурации Microsoft Entra с помощью нескольких привязок имени пользователя
Каждый из атрибутов объекта пользователя Microsoft Entra, доступных для привязки сертификатов к учетным записям пользователей Microsoft Entra (userPrincipalName, onPremiseUserPrincipalNameи certificateUserIds) имеет уникальное ограничение, чтобы гарантировать, что сертификат соответствует только одной учетной записи пользователя Microsoft Entra. Однако Microsoft Entra CBA поддерживает несколько методов привязки в политике привязки имени пользователя. Администратор политики проверки подлинности может разместить один сертификат, используемый в нескольких конфигурациях учетных записей пользователей Microsoft Entra.
Внимание
Если вы настраиваете несколько привязок, проверка подлинности Microsoft Entra CBA является безопасной, так как привязка с наименьшим сходством, так как CBA проверяет каждую привязку для проверки подлинности пользователя. Чтобы предотвратить сценарий, в котором один сертификат соответствует нескольким учетным записям Microsoft Entra, администратор политики проверки подлинности может:
- Настройте один метод привязки в политике привязки имени пользователя.
- Если у клиента настроено несколько методов привязки и не требуется разрешить одному сертификату сопоставляться с несколькими учетными записями, администратор политики проверки подлинности должен убедиться, что все допустимые методы, настроенные в сопоставлении политик с одной учетной записью Microsoft Entra. Все учетные записи пользователей должны иметь значения, соответствующие всем привязкам.
- Если у клиента настроено несколько методов привязки, администратор политики проверки подлинности должен убедиться, что у них нет более одной привязки с низким сходством.
Например, у вас есть две привязки имени пользователя, сопоставленные с PrincipalName, и UPN (SubjectKeyIdentifier) сопоставляются с SKI.certificateUserIds Если требуется, чтобы сертификат использовался только для одной учетной записи, администратор политики проверки подлинности должен убедиться, что у учетной записи есть имя участника-пользователя, которое присутствует в сертификате. Затем администратор реализует SKI сопоставление в certificateUserIds атрибуте той же учетной записи.
Поддержка нескольких сертификатов с одной учетной записью пользователя Microsoft Entra (M:1)
В некоторых сценариях организация выдает несколько сертификатов для одного удостоверения. Это могут быть производные учетные данные для мобильного устройства, но оно также может быть для вторичной смарт-карты или устройства с поддержкой учетных данных X.509, например YubiKey.
Облачные учетные записи (M:1)
Для облачных учетных записей можно сопоставить до пяти сертификатов, заполняя certificateUserIds поле уникальными значениями для идентификации каждого сертификата. Чтобы сопоставить сертификаты, в Центре администрирования перейдите на вкладку сведений об авторизации .
Если в организации используются такие привязки IssuerAndSerialNumberс высоким уровнем сходства, значения могут 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 поле, чтобы найти конкретный тип привязки (в этом примере), IssuerAndSerialNumberпользователь успешно войдет в систему.
Гибридные синхронизированные учетные записи (M:1)
Для синхронизированных учетных записей можно сопоставить несколько сертификатов. В локальной среде Active Directory заполните altSecurityIdentities поле значениями, определяющими каждый сертификат. Если в организации используются привязки высокой сходства (то есть строгой проверки подлинности), IssuerAndSerialNumberнапример, значения могут выглядеть следующим образом:
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)
В некоторых сценариях организации требуется, чтобы пользователь использовал один и тот же сертификат для проверки подлинности в нескольких удостоверениях. Это может быть учетная запись администратора или для разработчика или временной учетной записи обязанностей.
В локальной среде Active Directory altSecurityIdentities поле заполняет значения сертификатов. Указание используется во время входа, чтобы направить Active Directory в предназначенную учетную запись для проверки входа.
Microsoft Entra CBA имеет другой процесс, и нет указания. Вместо этого обнаружение домашней области определяет предназначенную учетную запись и проверяет значения сертификата. Microsoft Entra CBA также обеспечивает уникальность в certificateUserIds поле. Две учетные записи не могут заполнять одинаковые значения сертификатов.
Внимание
Использование одинаковых учетных данных для проверки подлинности в разных учетных записях Microsoft Entra не является безопасной конфигурацией. Рекомендуется не разрешать использовать один сертификат для нескольких учетных записей пользователей Microsoft Entra.
Облачные учетные записи (1:M)
Для облачных учетных записей создайте несколько привязок имени пользователя и сопоставите уникальные значения с каждой учетной записью пользователя, используюющей сертификат. Доступ к каждой учетной записи проходит проверку подлинности с помощью другой привязки имени пользователя. Этот уровень проверки подлинности применяется к границе одного каталога или клиента. Администратор политики проверки подлинности может сопоставить сертификат с его использованием в другом каталоге или клиенте, если значения остаются уникальными для каждой учетной записи.
certificateUserIds Заполните поле уникальным значением, которое идентифицирует сертификат. Чтобы заполнить поле, перейдите на вкладку сведений об авторизации в Центре администрирования.
Если в организации используются привязки с высоким сходством (т. е. строгой проверки подлинности) и IssuerAndSerialNumberSKIзначения могут выглядеть следующим образом:
Привязки имени пользователя:
IssuerAndSerialNumber>certificateUserIdsSKI>certificateUserIds
Значения учетной записи certificateUserIds пользователя:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
Теперь, когда любой пользователь представляет тот же сертификат при входе, пользователь успешно войдет, так как его учетная запись соответствует уникальному значению этого сертификата. Одна учетная запись проходит проверку подлинности с IssuerAndSerialNumber помощью и другой с помощью SKI привязки.
Примечание.
Количество учетных записей, которые можно использовать таким образом, ограничивается количеством привязок пользователей, настроенных для клиента. Если организация использует только привязки с высоким сходством, максимальное количество поддерживаемых учетных записей составляет три. Если организация также использует привязки с низкой сходством, число увеличивается до семи учетных записей: один PrincipalName, один RFC822Name, SKIодин, один, один SHA1PublicKey, один IssuerAndSubject, IssuerAndSerialNumberодин и один Subject.
Гибридные синхронизированные учетные записи (1:M)
Синхронизированные учетные записи требуют другого подхода. Хотя администратор политики проверки подлинности может сопоставить уникальные значения с каждой учетной записью пользователя, использующую сертификат, распространенная практика заполнения всех значений каждой учетной записи в идентификаторе Microsoft Entra затрудняет этот подход. Вместо этого Microsoft Entra Connect должен фильтровать значения для каждой учетной записи по уникальным значениям, заполненным в учетной записи в идентификаторе Microsoft Entra. Правило уникальности применяется к границе одного каталога или клиента. Администратор политики проверки подлинности может сопоставить сертификат с его использованием в другом каталоге или клиенте, если значения остаются уникальными для каждой учетной записи.
В организации также может быть несколько лесов Active Directory, которые вносят вклад пользователей в один клиент Microsoft Entra. В этом случае Microsoft Entra Connect применяет фильтр к каждому лесу Active Directory с той же целью: заполните только определенное уникальное значение облачной учетной записи.
altSecurityIdentities Заполните поле в Active Directory значениями, определяющими сертификат. Включите определенное значение сертификата для этого типа учетной записи пользователя (напримерdetailed, или admindeveloper). Выберите ключевой атрибут в Active Directory. Атрибут сообщает синхронизации, какой тип учетной записи пользователя оценивает пользователь (например msDS-cloudExtensionAttribute1). Заполните этот атрибут значением типа пользователя, которое detailedвы хотите использовать, например , adminили developer. Если учетная запись является основной учетной записью пользователя, значение может быть пустым или 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:
- Настройте Microsoft Entra Connect, чтобы добавить
alternativeSecurityIdsполе в метавселенную. - Для каждого локального леса Active Directory настройте новое пользовательское правило входящего трафика с высоким приоритетом (низкое число ниже 100).
ExpressionДобавьте преобразование сaltSecurityIdentitiesполем в качестве источника. Целевое выражение использует выбранный и заполненный ключевой атрибут, а также использует сопоставление определенных типов пользователей.
Например:
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-cloudExtensionAttribute1 сначала проверяется, заполняются ли они. Если они не заполнены, altSecurityIdentities проверьте, заполняется ли он. Если он пуст, задайте для него значение NULL. В противном случае учетная запись является сценарием по умолчанию.
Кроме того, в этом примере фильтруйте только в сопоставлении IssuerAndSerialNumber . Если ключевой атрибут заполняется, проверяется значение, чтобы узнать, равен ли он одному из определенных типов пользователей. В примере, если это значение имеет detailedзначение, отфильтруйте SHA1PublicKey значение от altSecurityIdentities. Если значение равно developer, отфильтруйте SubjectKeyIssuer значение из altSecurityIdentities.
Может возникнуть несколько значений сертификатов определенного типа. Например, можно увидеть несколько PrincipalName значений или несколько SKI значений или SHA1-PUKEY значений. Фильтр получает все значения и синхронизирует их в идентификаторе Microsoft Entra, а не только первый, который он находит.
Ниже приведен второй пример, в который показано, как отправить пустое значение, если атрибут элемента управления пуст:
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 атрибуте элемента управления, AuthoritativeNull передается значение. Это значение гарантирует, что предыдущие или последующие правила, заполняемые alternativeSecurityId , игнорируются. Результат пуст в идентификаторе Microsoft Entra.
Чтобы синхронизировать пустое значение:
- Настройте новое настраиваемое правило исходящего трафика с низким приоритетом (большое число выше 160, но из нижней части списка).
- Добавьте прямое преобразование с
alternativeSecurityIdsполем в качестве источника иcertificateUserIdsполя в качестве целевого объекта. - Запустите цикл синхронизации, чтобы завершить заполнение данных в идентификаторе Microsoft Entra.
Убедитесь, что CBA в каждом клиенте настроен с привязками имени пользователя, указывающими на certificateUserIds поле для типов полей, сопоставленных с сертификатом. Теперь любой из этих пользователей может представить сертификат при входе. После проверки уникального значения из сертификата в certificateUserIds поле пользователь успешно войдет в систему.
Центр сертификации (ЦС) (предварительная версия)
Определение области ЦС в Microsoft Entra позволяет администраторам клиентов ограничить использование определенных центров сертификации определенным группам пользователей. Эта функция повышает безопасность и управляемость CBA, гарантируя, что только авторизованные пользователи могут проходить проверку подлинности с помощью сертификатов, выданных определенными центрами сертификации.
Определение области ЦС полезно в сценариях с несколькими PKI или B2B, в которых несколько ЦС используются в разных группах пользователей. Это помогает предотвратить непреднамеренное доступ и поддерживать соответствие политикам организации.
Ключевые преимущества
- Ограничивает использование сертификата определенным группам пользователей
- Поддерживает сложные среды PKI с помощью нескольких ЦС
- Обеспечивает расширенную защиту от неправильного использования или компрометации сертификатов
- Обеспечивает видимость использования ЦС с помощью журналов входа и средств мониторинга
Администратор может использовать области ЦС для определения правил, которые связывают ЦС (идентифицируется его SKI) с определенной группой Microsoft Entra. Когда пользователь пытается пройти проверку подлинности с помощью сертификата, система проверяет, является ли выдача ЦС для сертификата областью действия группы, включающей пользователя. Microsoft Entra продолжает цепочку ЦС. Он применяет все правила области, пока пользователь не будет найден в одной из групп во всех правилах области. Если пользователь не входит в группу с областью действия, проверка подлинности завершается ошибкой, даже если сертификат является допустимым.
Настройка области ЦС
Войдите в Центр администрирования Microsoft Entra с правами не ниже Администратора политики проверки подлинности.
Перейдите кметоду проверки подлинностина основе сертификата в методе > проверкиподлинности на основе> записи.
В разделе "Настройка" перейдите к политике области области издателя сертификатов.
Выберите "Добавить правило".
Выберите Отфильтровать ЦС по PKI.
Классические ЦС отображают все ЦС из классического хранилища ЦС. При выборе определенного PKI отображаются все ЦС из выбранного PKI.
Выберите PKI.
В списке издателей сертификатов отображаются все центры сертификации из выбранного PKI. Выберите УЦ, чтобы создать правило области.
Выберите "Добавить группу".
Выберите группу.
Нажмите кнопку "Добавить ", чтобы сохранить правило.
Установите флажок "Подтвердить" и нажмите кнопку "Сохранить".
Чтобы изменить или удалить политику области ЦС, выберите "..." в строке правила. Чтобы изменить правило, нажмите кнопку "Изменить". Чтобы удалить правило, нажмите кнопку "Удалить".
Известные ограничения
- На ЦС можно назначить только одну группу.
- Поддерживается не более 30 правил области видимости.
- Определение области применяется на промежуточном уровне ЦС.
- Недопустимая конфигурация может привести к блокировке пользователей, если допустимые правила области не существуют.
Записи журнала входа
В журнале входа показано успешное выполнение. На вкладке "Дополнительные сведения" появится лыжа ЦС из правила политики области.
При сбое CBA из-за правила области ЦС вкладка "Основные сведения " в журнале входа отображает код ошибки 500189.
Конечные пользователи видят следующее сообщение об ошибке:
Как CBA работает с политикой надежности проверки подлинности условного доступа
Для создания политики проверки подлинности условного доступа, указывающей использование CBA для доступа к ресурсу, можно использовать встроенную степень проверки подлинности Microsoft Entra Phishing . Политика позволяет использовать только методы проверки подлинности, устойчивые к фишингу, такие как ключи безопасности CBA, FIDO2 и Windows Hello для бизнеса.
Вы также можете создать настраиваемую силу проверки подлинности, чтобы разрешить доступ только к конфиденциальным ресурсам CBA. Можно разрешить CBA в виде однофакторной проверки подлинности, MFA или обоих. Дополнительные сведения см. в разделе "Надежность проверки подлинности условного доступа".
Сила CBA с расширенными параметрами
В политике метода CBA администратор политики проверки подлинности может определить силу сертификата с помощью политики привязки проверки подлинности в методе CBA. Теперь можно требовать, чтобы определенный сертификат использовался на основе издателя и OID политики, когда пользователи выполняют CBA для доступа к определенным конфиденциальным ресурсам. При создании настраиваемой силы проверки подлинности перейдите к дополнительным параметрам. Эта функция предоставляет более точную конфигурацию для определения сертификатов и пользователей, которые могут получить доступ к ресурсам. Дополнительные сведения см. в дополнительных параметрах для повышения надежности проверки подлинности условного доступа.
Журналы входа
Журналы входа содержат сведения о входах и способах использования ресурсов в организации. Дополнительные сведения см. в журналах входа в идентификаторе Microsoft Entra.
Далее рассмотрим два сценария. В одном сценарии сертификат удовлетворяет однофакторной проверке подлинности. Во втором сценарии сертификат удовлетворяет MFA.
В тестовых сценариях выберите пользователя, у которого есть политика условного доступа, требующая MFA.
Настройте политику привязки пользователей путем сопоставления альтернативного имени субъекта и userPrincipalName с объектом пользователя.
Сертификат пользователя должен быть настроен, как в примере, показанном на этом снимке экрана:
Устранение неполадок входа с динамическими переменными в журналах входа
Хотя журналы входа обычно предоставляют все сведения, необходимые для отладки проблемы входа, иногда требуются определенные значения. Журналы входа не поддерживают динамические переменные, поэтому в некоторых случаях журналы входа не имеют сведений, необходимых для отладки.
Например, причина сбоя в журналах входа может отображаться "The Certificate Revocation List (CRL) failed signature validation. Expected Subject Key Identifier <expectedSKI> doesn't match CRL Authority Key <crlAK>. Request your tenant administrator to check the CRL configuration." в этом сценарии и<expectedSKI><crlAKI> не заполняется правильными значениями.
При сбое входа пользователя с помощью CBA можно скопировать сведения журнала из ссылки " Дополнительные сведения " на странице ошибки. Дополнительные сведения см. на странице ошибок CBA.
Тестирование однофакторной проверки подлинности
В первом тестовом сценарии настройте политику проверки подлинности, в которой IssuerAndSubject правило удовлетворяет однофакторной проверке подлинности.
Войдите в Центр администрирования Microsoft Entra в качестве тестового пользователя с помощью CBA. Политика проверки подлинности устанавливается, где
IssuerAndSubjectправило удовлетворяет однофакторной проверке подлинности.Найдите и выберите журналы входа.
На следующем рисунке показаны некоторые записи, которые можно найти в журналах входа.
Первая запись запрашивает у пользователя сертификат X.509. Состояние прервано означает, что идентификатор Microsoft Entra проверяет, настроен ли CBA для клиента. Сертификат запрашивается для проверки подлинности.
Сведения о действиях показывают, что запрос является частью ожидаемого потока входа, в котором пользователь выбирает сертификат.
Дополнительные сведения содержат сведения о сертификате.
Другие записи показывают, что проверка подлинности завершена, основной маркер обновления отправляется в браузер, а пользователь получает доступ к ресурсу.
Проверка MFA
Для следующего тестового сценария настройте политику проверки подлинности, в которой policyOID правило удовлетворяет MFA.
Войдите в Центр администрирования Microsoft Entra с помощью CBA . Так как политика была задана для соответствия MFA, вход пользователя выполняется успешно без второго фактора.
Найдите и выберите вход.
Отображаются несколько записей в журналах входа, включая запись с прерванным состоянием.
Сведения о действиях показывают, что запрос является частью ожидаемого потока входа, в котором пользователь выбирает сертификат.
Запись с прерванным состоянием отображает дополнительные диагностические сведения на вкладке "Дополнительные сведения ".
Следующая таблица содержит описание каждого поля.
Поле Описание Имя субъекта сертификата пользователя Ссылается на поле имени субъекта в сертификате. Привязка сертификата пользователя Сертификат: ; атрибут пользователя: PrincipalNameuserPrincipalName; Ранг: 1
В этом поле показано, какое поле сертификата SANPrincipalNameсопоставлялось с атрибутомuserPrincipalNameпользователя и было приоритетом 1.Уровень проверки подлинности сертификата пользователя multiFactorAuthenticationТип уровня проверки подлинности сертификата пользователя PolicyId
В этом поле показано, что идентификатор политики использовался для определения надежности проверки подлинности.Идентификатор уровня проверки подлинности сертификата пользователя 1.2.3.4
Показывает значение идентификатора OID политики из сертификата.
Страница ошибок CBA
CBA может завершиться сбоем по нескольким причинам. Примеры включают недопустимый сертификат, пользователь выбрал неправильный сертификат или просроченный сертификат, или возникает проблема со списком отзыва сертификатов. При сбое проверки сертификата пользователь видит следующее сообщение об ошибке:
Если CBA завершается сбоем в браузере, даже если сбой связан с отменой средства выбора сертификатов, закройте сеанс браузера. Откройте новый сеанс, чтобы повторить попытку CBA. Требуется новый сеанс, так как браузеры кэшируют сертификаты. При извлечении CBA браузер отправляет кэшированный сертификат во время запроса TLS, который затем вызывает сбой входа и ошибку проверки.
Чтобы получить сведения о ведении журнала для отправки администратору политики проверки подлинности для получения дополнительных сведений из журналов входа, выберите дополнительные сведения.
Выберите другие способы входа и попробуйте другие доступные методы проверки подлинности для входа.
Сброс выбора сертификата в Microsoft Edge
Браузер Microsoft Edge добавил функцию, которая сбрасывает выбор сертификата без перезапуска браузера.
Пользователь выполняет следующие действия.
При сбое CBA появится страница ошибок.
Слева от URL-адреса выберите значок блокировки и выберите нужный сертификат.
Выберите варианты сброса сертификата.
Выберите варианты сброса.
Выберите другие способы входа.
Выберите "Использовать сертификат" или "Смарт-карта " и продолжайте проверку подлинности CBA.
CBA в методах MostRecentlyUsed
После успешной проверки подлинности пользователя с помощью CBA для метода проверки подлинности пользователя MostRecentlyUsed (MRU) задано значение CBA. При следующем вводе имени участника-пользователя и нажатии кнопки "Далее" они видят метод CBA и не нужно выбирать "Использовать сертификат" или смарт-карту.
Чтобы сбросить метод MRU, отмените средство выбора сертификатов и выберите другие способы входа. Выберите другой доступный метод и завершите проверку подлинности.
Метод проверки подлинности MRU устанавливается на уровне пользователя. Если пользователь успешно вошел на другое устройство с помощью другого метода проверки подлинности, МРУ сбрасывается для пользователя в текущий вход в систему.
Поддержка внешних удостоверений
Гостевой пользователь B2B внешнего удостоверения может использовать CBA в домашнем клиенте. Если параметры межтенантного клиента для клиента ресурсов настроены для доверия MFA из домашнего клиента, то учетная запись пользователя на домашнем клиенте учитывается. Дополнительные сведения см. в разделе "Настройка межтенантного доступа для совместной работы B2B". В настоящее время CBA в клиенте ресурсов не поддерживается.
Связанный контент
- Обзор Microsoft Entra CBA
- Настройка Microsoft Entra CBA
- Список отзыва сертификатов Microsoft Entra CBA
- Microsoft Entra CBA на устройствах iOS
- Microsoft Entra CBA на устройствах Android
- Вход с смарт-картой Windows с помощью Microsoft Entra CBA
- Идентификаторы пользователей для сертификата
- Перенос федеративных пользователей
- Вопросы и ответы
- Устранение неполадок Microsoft Entra CBA