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

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

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

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

Ниже приведены шаги процесса Microsoft Entra CBA.

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

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

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

   

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

   Дополнительные сведения см. в разделе Как включить Microsoft Entra CBA?.

   Примечание.

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

   

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

   

5. После выбора CBA клиент перенаправляется в конечную точку проверки подлинности сертификата. Для общедоступной Microsoft Entra ID конечная точка проверки подлинности сертификата 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 завершается ошибкой при включении подсказок издателя.

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

   

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

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

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

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

Подсказки эмитента

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

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

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

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

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

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

MFA с одним фактором CBA

Microsoft Entra CBA подходит как для аутентификации первого фактора, так и второго фактора.

Ниже приведены некоторые поддерживаемые сочетания:

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

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

Варианты получения возможности MFA при включенном CBA

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

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

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

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

Если пользователь, поддерживающий CBA, не получил сертификат и должен пройти MFA, выберите один из следующих вариантов для проверки подлинности пользователя:

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

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

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

Настройка входа без пароля телефона с помощью CBA

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

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

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

   Внимание

   Убедитесь, что выбран параметр без пароля . Для любых групп, которые вы добавляете в вход без пароля, необходимо изменить значение режима проверки подлинности на Без пароля. Если выбрать Any, CBA и вход без пароля не работают.

3. Выберите Entra ID>Многофакторная аутентификация>Дополнительные настройки многофакторной аутентификации на основе облака.

   

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

   

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

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

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

   

2. Выберите "Использовать сертификат" или "Смарт-карта".

   

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

   

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

   

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

   

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

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

   

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

Политика привязки аутентификации

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

Сила сертификата

Администраторы политики проверки подлинности могут определить, является ли сила сертификата однофакторной или многофакторной. ```plaintext Для получения дополнительной информации см. документацию, которая сопоставляет уровни уверенности в аутентификации NIST Authentication Assurance Levels с методами аутентификации Microsoft Entra, которая основана на NIST 800-63B, Руководстве по цифровым идентичностям: Управление аутентификацией и жизненным циклом. ```

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

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

Несколько правил связывания политики аутентификации

Можно создать несколько пользовательских правил привязки политики проверки подлинности, используя различные атрибуты сертификата. Примером является использование издателя и OID политики, либо только OID политики, либо же только издателя.

Следующая последовательность определяет уровень защиты проверки подлинности при перекрывающихся пользовательских правилах:

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

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

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

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

Microsoft Entra поддерживают семь методов использования привязок сертификатов. Как правило, типы сопоставления считаются высокими сходствами, если они основаны на идентификаторах, которые нельзя использовать повторно, например SubjectKeyIdentifier (SKI) или SHA1PublicKey. Эти идентификаторы передают более высокую уверенность в том, что для проверки подлинности пользователя можно использовать только один сертификат.

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

Определение и переопределение привязки сходства

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

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

Несколько правил привязки политики имени пользователя

Чтобы устранить несколько правил привязки политики имени пользователя, Microsoft Entra ID использует привязку с наивысшим приоритетом (наименьшим числом):

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

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

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

Например, у вас есть две привязки имени пользователя, сопоставленные с PrincipalName и UPN, а SubjectKeyIdentifier (SKI) сопоставляется с certificateUserIds. Если вы хотите, чтобы сертификат использовался только для одной учетной записи, администратор политики проверки подлинности должен убедиться, что у учетной записи есть UPN, который присутствует в сертификате. Затем администратор реализует SKI сопоставление в certificateUserIds атрибуте той же учетной записи.

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

В некоторых сценариях организация выдает несколько сертификатов для одного удостоверения. Могут быть использованы производные идентификационные данные для мобильного устройства, но они также могут предназначаться для вторичной смарт-карты или устройства с поддержкой удостоверений X.509, например, YubiKey.

Облачные учетные записи (M:1)

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

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

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

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

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

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

Облачные учетные записи (1:M)

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

certificateUserIds Заполните поле уникальным значением, которое идентифицирует сертификат. Чтобы заполнить поле, перейдите на вкладку сведений об авторизации в Центре администрирования.

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

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

• IssuerAndSerialNumber > certificateUserIds
• SKI > certificateUserIds

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

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

Гибридные синхронизированные учетные записи (1:M)

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

В организации также может быть несколько лесов 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: Аккаунт 2 (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 ID.

Синхронизация с certificateUserIds:

1. Настройте Microsoft Entra Connect, чтобы добавить поле alternativeSecurityIds в метавселенную.
2. Для каждого локального леса 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 ID, а не только первое найденное.

Ниже приведен второй пример, в который показано, как отправить пустое значение, если атрибут элемента управления пуст:

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

Чтобы синхронизировать пустое значение:

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

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

Определение области центра сертификации (ЦС)

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

Определение границ использования ЦС полезно в многопользовательских PKI или сценариях B2B, когда несколько ЦС применяются среди различных групп пользователей. Это помогает предотвратить непреднамеренное доступ и поддерживать соответствие политикам организации.

Ключевые преимущества

• Ограничивает использование сертификата определенным группам пользователей
• Поддерживает сложные PKI-среды через несколько разных Удостоверяющих Центров
• Обеспечивает расширенную защиту от неправильного использования или компрометации сертификатов
• Обеспечивает видимость использования ЦС с помощью журналов входа и средств мониторинга

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

Настройка функции области ЦС

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

2. Перейдите к методам аутентификации Entra ID>>Аутентификация на основе сертификата.

3. В разделе "Настройка" перейдите к политике области издателя сертификатов.

   

4. Выберите "Добавить правило".

   

5. Выберите Отфильтровать ЦС по PKI.

   Классические ЦС отображают все ЦС из классического хранилища ЦС. При выборе конкретной PKI отображаются все ЦС из выбранной PKI.

6. Выберите PKI.

   

7. В списке издателей сертификатов отображаются все центры сертификации из выбранного PKI. Выберите УЦ, чтобы создать правило области.

   

8. Выберите "Добавить группу".

   

9. Выберите группу.

   

10. Нажмите кнопку "Добавить ", чтобы сохранить правило.

    

11. Установите флажок "Подтвердить" и нажмите кнопку "Сохранить".

    

12. Чтобы изменить или удалить политику области применения удостоверяющего центра (ЦС), выберите "..." в строке с правилом. Чтобы изменить правило, нажмите кнопку "Изменить". Чтобы удалить правило, нажмите кнопку "Удалить".

    

Известные ограничения

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

Записи журнала входа

• В журнале входа в систему отображается успешная попытка. На вкладке Дополнительные сведения отображается SKI УЦ из правила политики области применения.

  

• Когда CBA не удается из-за правила области действия CA, на вкладке "Основные сведения" в журнале входа отображается код ошибки 500189.

  

  Конечные пользователи видят следующее сообщение об ошибке:

  

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

Вы можете использовать встроенную устойчивую к фишингу МФА Microsoft Entra для создания политики условного доступа, которая указывает использование CBA для доступа к ресурсу. Политика позволяет использовать только методы проверки подлинности, устойчивые к фишингу, такие как ключи безопасности CBA, FIDO2 и Windows Hello for Business.

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

Мощность CBA с расширенными параметрами

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

Журналы входа

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

Далее рассмотрим два сценария. В одном сценарии сертификат удовлетворяет однофакторной проверке подлинности. Во втором сценарии сертификат удовлетворяет 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 правило удовлетворяет однофакторной проверке подлинности.

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

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

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

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

   

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

   

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

   

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

   

Проверка MFA

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

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

2. Найдите и выберите Входы в систему.

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

   

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

   

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

   

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

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

Страница ошибок CBA

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

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

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

   

2. Выберите другие способы входа и попробуйте другие доступные методы проверки подлинности для входа.

   

Сброс выбора сертификата в Microsoft Edge

В браузере Microsoft Edge добавлена функция, которая возвращает выбор сертификата без перезапуска браузера.

Пользователь выполняет следующие действия.

1. При сбое CBA появится страница ошибок.

   

2. Слева от URL-адреса выберите значок блокировки и выберите нужный сертификат.

   

3. Выберите Сбросить выбор сертификатов.

   

4. Выберите Сбросить выбор.

   

5. Выберите другие способы входа.

   

6. Выберите Использовать сертификат или смарт-карту и продолжите проверку подлинности CBA.

CBA в методах MostRecentlyUsed

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

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

Метод проверки подлинности MRU устанавливается на уровне пользователя. Если пользователь выполнил успешный вход на другое устройство, используя другой метод проверки подлинности, то МРУ сбрасывается до метода, которым он вошел на данный момент.

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

Гостевой пользователь B2B внешнего удостоверения может использовать CBA у домашнего арендатора. Если параметры межтенантного клиента для клиента ресурсов настроены для доверия MFA из домашнего клиента, то учетная запись пользователя на домашнем клиенте учитывается. Дополнительные сведения см. в разделе "Настройка межтенантного доступа для совместной работы B2B". В настоящее время CBA в тенанте ресурса не поддерживается.

Связанный контент

• Обзор Microsoft Entra CBA
• Техническое погружение в детали для Microsoft Entra CBA
• How to configure Microsoft Entra CBA
• Список отзыва сертификатов CBA Microsoft Entra
• Microsoft Entra CBA на устройствах Android
• Windows вход с помощью смарт-карты с использованием Microsoft Entra сертификационной аутентификации
• Идентификаторы пользователей для сертификата
• Как перенести федеративных пользователей
• Вопросы и ответы
• Список отзыва сертификатов CBA Microsoft Entra
• Microsoft Entra CBA на устройствах Android
• Windows вход с помощью смарт-карты с использованием Microsoft Entra сертификационной аутентификации
• Идентификаторы пользователей для сертификата
• Как перенести федеративных пользователей
• Вопросы и ответы