Настройка проверки подлинности на основе сертификатов Microsoft Entra

Статья
01/07/2025

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

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

Следуйте этим инструкциям, чтобы настроить и использовать Microsoft Entra CBA для клиентов в планах Office 365 корпоративный и государственных организаций США. У вас уже должна быть настроена инфраструктура открытых ключей (PKI).

Необходимые компоненты

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

Настройте по крайней мере один центр сертификации (ЦС) и все промежуточные ЦС в идентификаторе Microsoft Entra.
Пользователь должен иметь доступ к сертификату пользователя (выданному из доверенной инфраструктуры открытого ключа, настроенной в клиенте) для проверки подлинности клиента с использованием идентификатора Microsoft Entra.
Каждый центр сертификации должен иметь список отзыва сертификатов (CRL), на который можно сослаться с помощью URL-адреса для Интернета. Если доверенный ЦС не настроен на CRL, идентификатор Microsoft Entra не выполняет проверку списка отзыва, отзыв сертификатов пользователей не работает, а проверка подлинности не блокируется.

Внимание

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

Внимание

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

Внимание

В рамках текущих улучшений безопасности конечные точки Azure/M365 добавляют поддержку TLS1.3, и этот процесс, как ожидается, займет несколько месяцев, чтобы покрыть тысячи конечных точек службы в Azure/M365. Сюда входят конечная точка Microsoft Entra, используемая проверкой подлинности на основе сертификатов (CBA) *.certauth.login.microsoftonline.com Microsoft Entra и *.certauth.login.microsoftonline.us. TLS 1.3 — это последняя версия наиболее развернутого протокола безопасности Интернета, который шифрует данные для обеспечения безопасного канала связи между двумя конечными точками. TLS 1.3 устраняет устаревшие алгоритмы шифрования, повышает безопасность более старых версий и стремится зашифровать как можно больше подтверждения. Мы настоятельно рекомендуем разработчикам начать тестирование TLS 1.3 в своих приложениях и службах.

Примечание.

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

Действия по настройке и тестированию Microsoft Entra CBA

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

Для управления этой функцией требуется глобальный администратор .

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

Схема шагов, необходимых для включения проверки подлинности на основе сертификата Microsoft Entra.

Шаг 1. Настройка центров сертификации с помощью хранилища доверия на основе PKI (предварительная версия)

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

Хранилище доверия на основе PKI имеет более высокие ограничения для количества ЦС и размера каждого файла ЦС. Хранилище доверия на основе PKI поддерживает до 250 ЦС и 8 КБ для каждого объекта ЦС. Мы настоятельно рекомендуем использовать новое хранилище доверия на основе PKI для хранения ЦС, которое является масштабируемым и поддерживает новые функции, такие как указания издателя.

Примечание.

Если вы используете старое хранилище доверия для настройки ЦС, мы рекомендуем настроить хранилище доверия на основе PKI.

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

Функция отправки PKI в хранилище доверия на основе PKI доступна только с лицензией Microsoft Entra ID P1 или P2. Однако с бесплатной лицензией администраторы могут отправлять все ЦС отдельно вместо PKI-файла и настраивать хранилище доверия на основе PKI.

Внимание

Из-за известной проблемы с новым хранилищем рекомендуется не удалять все ЦС в старом хранилище и иметь atleast один ЦС в старом хранилище. Мы работаем над устранением проблемы, чтобы удалить ограничение.

Настройка центров сертификации с помощью Центра администрирования Microsoft Entra

Создание объекта контейнера PKI

Создайте объект контейнера PKI.
Войдите в Центр администрирования Microsoft Entra в качестве администратора политики проверки подлинности.
Перейдите к разделу "Защита">
Нажмите кнопку + Создать PKI.
Введите отображаемое имя.
Нажмите кнопку Создать.
Выберите столбцы для добавления или удаления столбцов.
Выберите "Обновить", чтобы обновить список PKIs.

Удаление объекта контейнера PKI

Чтобы удалить PKI, выберите PKI и нажмите кнопку "Удалить". Если В PKI есть ЦС, введите имя PKI, чтобы подтвердить удаление всех ЦС в нем и нажмите кнопку "Удалить".

Отправка отдельных ЦС в объект контейнера PKI

Чтобы отправить ЦС в контейнер PKI, выполните следующие действия.
1. Нажмите кнопку +Добавить центр сертификации.
2. Выберите файл ЦС.
3. Выберите Да, если ЦС является корневым сертификатом, в противном случае выберите Нет.
4. Для URL-адреса списка отзыва сертификатов задайте URL-адрес, доступный в Интернете, для базового списка отзыва сертификатов ЦС, который содержит все отозванные сертификаты. Если URL-адрес не задан, проверка подлинности с отозванными сертификатами не завершается ошибкой.
5. Для URL-адреса списка отзыва разностных сертификатов задайте URL-адрес для списка отзыва сертификатов в Интернете, содержащий все отозванные сертификаты с момента публикации последнего базового списка отзыва сертификатов.
6. Флаг подсказок издателя включен по умолчанию. Отключите указания издателя, если ЦС не следует включать в подсказки издателя.
7. Выберите Сохранить.
8. Чтобы удалить сертификат ЦС, выберите сертификат и нажмите кнопку "Удалить".
9. Выберите столбцы для добавления или удаления столбцов.
10. Выберите "Обновить", чтобы обновить список центров сертификации.

Отправка всех ЦС с отправкой PKI в объект контейнера PKI

Чтобы отправить все ЦС одновременно в контейнер PKI, выполните следующие действия.
1. Создайте объект контейнера PKI или откройте его.
2. Выберите " Отправить PKI".
3. Введите URL-адрес для доступа к Интернету, где доступен P7b-файл.
4. Введите контрольную сумму SHA256 файла.
5. Выберите отправку.
6. Отправка PKI — это асинхронный процесс. По мере отправки каждого ЦС он доступен в PKI. Завершение отправки PKI может занять до 30 минут.
7. Выберите "Обновить", чтобы обновить ЦС.
Чтобы создать контрольную сумму SHA256 PKI P7b-файла, выполните следующую команду:
```
Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256
```

Изменение PKI

Чтобы изменить PKI, выберите ... , в строке PKI и нажмите кнопку "Изменить".
Введите новое имя PKI и нажмите кнопку "Сохранить".

Изменение ЦС

Чтобы изменить ЦС, выберите ... в строке ЦС и нажмите кнопку "Изменить".
Введите новые значения для типа центра сертификации (корневой или промежуточный), URL-адрес CRL, URL-адрес delta CRL, флаг указания издателя включен при необходимости и нажмите кнопку "Сохранить".

Восстановление PKI

Перейдите на вкладку "Удаленные PKIs".
Выберите PKI и выберите "Восстановить PKI".

Восстановление ЦС

Перейдите на вкладку "Удаленные ЦС".
Выберите файл ЦС и выберите центр сертификации восстановления.

Основные сведения об атрибуте isIssuerHintEnabled в ЦС

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

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

Существует ограничение в 16 КБ для подсказок издателя (имя субъекта ЦС), которые сервер может отправить обратно клиенту TLS. Рекомендуется задать для атрибута isIssuerHintEnabled значение true только для ЦС, которые выдают сертификаты пользователей.

Если несколько промежуточных ЦС из одного корневого сертификата выдают сертификаты конечных пользователей, то по умолчанию все сертификаты отображаются в средство выбора сертификатов. Но если задано значениеIssuerHintEnabled true для определенных центров сертификации, в средство выбора сертификатов отображаются только соответствующие сертификаты пользователей. Чтобы включить isIssuerHintEnabled, измените ЦС и обновите значение до true.

Настройка центров сертификации с помощью API Microsoft Graph

API Microsoft Graph можно использовать для настройки ЦС. В следующих примерах показано, как использовать Microsoft Graph для выполнения операций создания, чтения, обновления или удаления (CRUD) для PKI или ЦС.

Создание объекта контейнера PKI

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/
Content-Type: application/json
{
   "displayName": "ContosoPKI"
}

Получение всех объектов PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations
ConsistencyLevel: eventual

Получение объекта PKI по PKI-id

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/
ConsistencyLevel: eventual

Отправка ЦС с помощью P7B-файла

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
Content-Type: application/json
{
    	"uploadUrl":"https://CBA/demo/CBARootPKI.p7b,
    	"sha256FileHash": "AAAAAAD7F909EC2688567DE4B4B0C404443140D128FE14C577C5E0873F68C0FE861E6F"
}

Получение всех ЦС в PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities
ConsistencyLevel: eventual

Получение определенного ЦС в PKI по идентификатору ЦС

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
ConsistencyLevel: eventual

Обновление флага указания издателя ЦС

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
Content-Type: application/json
{
   "isIssuerHintEnabled": true
}

Настройте центры сертификации (ЦС) с помощью PowerShell для этой конфигурации, вы можете использовать [Microsoft Graph PowerShell] (/powershell/microsoftgraph/installation).

Запустите PowerShell с правами администратора.

Установите и импортируйте пакет SDK Microsoft Graph PowerShell.

Install-Module Microsoft.Graph -Scope AllUsers
Import-Module Microsoft.Graph.Authentication
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Подключитесь к клиенту и примите все.

   Connect-MGGraph -Scopes "Directory.ReadWrite.All", "User.ReadWrite.All" -TenantId <tenantId>

Журнал аудита

Все операции CRUD в PKI или ЦС в хранилище доверия вошли в журналы аудита Microsoft Entra.

Схема журналов аудита.

Вопросы и ответы

Вопрос. Почему отправка PKI завершается ошибкой?

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

Вопрос. Что такое соглашение об уровне обслуживания (SLA) для отправки PKI?

Ответ. Отправка PKI — это асинхронная операция и может занять до 30 минут для завершения.

Вопрос. Как создать контрольную сумму SHA256 для PKI-файла?

Ответ. Чтобы создать контрольную сумму SHA256 файла PKI.p7b, выполните следующую команду:

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Шаг 2. Включение CBA в клиенте

Внимание

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

Чтобы включить CBA в Центре администрирования Microsoft Entra, выполните следующие действия.

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

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

Примечание.

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

Шаг 3. Настройка политики привязки проверки подлинности

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

Администратор политики проверки подлинности может изменить значение по умолчанию с одного фактора на многофакторное и настроить пользовательские правила политики. Правила привязки проверки подлинности сопоставляют атрибуты сертификата, такие как издатель, или идентификатор объекта политики (OID), или издатель и идентификатор политики, значение и выбор уровня защиты по умолчанию для этого правила. Можно создать несколько правил.

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

Войдите в Центр администрирования Microsoft Entra как минимум администратор политики проверки подлинности.
Перейдите к >
В разделе Управление выберите Методы проверки подлинности>Проверка подлинности на основе сертификатов.
Выберите "Настроить", чтобы настроить привязку проверки подлинности и привязку имени пользователя.
Атрибут уровня защиты имеет значение по умолчанию Однофакторная проверка подлинности. Выберите многофакторную проверку подлинности , чтобы изменить значение по умолчанию на MFA.

Примечание.

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

Правила привязки проверки подлинности сопоставляют атрибуты сертификата (издателя или OID политики) со значением и выберите уровень защиты по умолчанию для этого правила. Можно создать несколько правил.

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

Чтобы создать правило издателем сертификатов, выберите издателя сертификатов.
1. Выберите Идентификатор издателя сертификата в списке.
2. Выберите многофакторную проверку подлинности, привязку с низким сходством и нажмите кнопку "Добавить". Когда появится запрос, нажмите кнопку " Подтвердить ", чтобы завершить добавление правила.
Чтобы создать правило по OID политики, выберите OID политики.
1. Введите значение для OID политики.
2. Выберите многофакторную проверку подлинности, привязку с низким сходством и нажмите кнопку "Добавить". Когда появится запрос, нажмите кнопку " Подтвердить ", чтобы завершить добавление правила.
Чтобы создать правило издателем и OID политики, выполните следующие действия.
1. Выберите издателя сертификатов и идентификатор политики.
2. Выберите издателя и введите идентификатор политики.
3. Для проверки подлинности выберите однофакторную проверку подлинности или многофакторную проверку подлинности.
4. Для привязки сходства выберите "Низкий".
5. Выберите Добавить.
6. Проверка подлинности с помощью сертификата с OID политики 3.4.5.6 и выдана CN=CBATestRootProd. Проверка подлинности должна пройти и получить многофакторное утверждение.

Внимание

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

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

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

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

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

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

Добавьте политику привязки проверки подлинности. Политика требует, чтобы любой сертификат, выданный CN=CBATestRootProd с policyOID 1.2.3.4.6, нуждался только в привязке с высоким сходством. Используются издатель и серийный номер.
Выберите поле сертификата. В этом примере выберите издателя и серийный номер.
Единственным поддерживаемым атрибутом пользователя является CertificateUserIds. Выберите Добавить.
Выберите Сохранить.

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

Внимание

Введите PolicyOID с помощью формата идентификатора объекта. Например, если политика сертификата говорит все политики выдачи, введите OID как 2.5.29.32.0 при добавлении правила. Строка "Все политики выдачи" является недопустимой для редактора правил и не вступают в силу.

Шаг 4. Настройка политики привязки имени пользователя

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

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

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

Внимание

Если политика привязки имени пользователя использует синхронизированные атрибуты, такие как certificateUserIds, onPremisesUserPrincipalName и userPrincipalName объекта пользователя, помните, что учетные записи с правами администратора в Active Directory (например, с делегированными правами на объекты пользователя или права администратора на сервере Microsoft Entra Connect) могут внести изменения, влияющие на эти атрибуты в идентификаторе Microsoft Entra ID.

Создайте привязку имени пользователя, выбрав одно из полей сертификата X.509 для привязки к одному из атрибутов пользователя. Порядок привязки имени пользователя представляет уровень приоритета привязки. Первый имеет самый высокий приоритет и т. д.

Если указанное поле сертификата X.509 найдено в сертификате, но идентификатор Microsoft Entra id не находит объект пользователя, используя это значение, проверка подлинности завершается ошибкой. Идентификатор Microsoft Entra пытается выполнить следующую привязку в списке.
Выберите Сохранить, чтобы сохранить изменения.

Последняя конфигурация выглядит следующим образом:

Снимок экрана: окончательная конфигурация.

Шаг 5. Проверка конфигурации

В этом разделе описано, как проверить сертификат и настраиваемые правила привязки проверки подлинности.

Проверка сертификата

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

Введите имя субъекта-пользователя (UPN).
Выберите Далее.

Если вы включили другие методы проверки подлинности, такие как вход в Телефон или FIDO2, пользователи могут увидеть другой экран входа.
Выберите Войти с помощью сертификата.
Выберите правильный сертификат пользователя в пользовательском интерфейсе средства выбора сертификатов клиента и нажмите кнопку "ОК".
Пользователи должны войти на портал MyApps.

Успешный вход подтверждает, что:

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

Проверка правил пользовательской привязки проверки подлинности

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

Создайте правило субъекта-издателя с уровнем защиты в качестве однофакторной проверки подлинности и значения, заданные для значения субъекта CAs. Например:

CN = WoodgroveCA
Создайте правило OID политики с уровнем защиты в качестве многофакторной проверки подлинности и значения, установленными для одного из идентификаторов политики в сертификате. Например, 1.2.3.4.
Создайте политику условного доступа для пользователя, чтобы требовать многофакторную проверку подлинности, выполнив действия по условному доступу. Требуется многофакторная проверка подлинности.
Перейдите на портал MyApps. Введите имя участника-участника-участника и нажмите кнопку "Далее".
Выберите Войти с помощью сертификата.

Если вы включили другие методы проверки подлинности, такие как вход в Телефон или ключи безопасности, пользователи могут увидеть другой экран входа.
Выберите сертификат клиента и выберите сведения о сертификате.
Появится сертификат, и вы можете проверить значения издателя и политики OID.
Чтобы просмотреть значения OID политики, выберите "Сведения".
Выберите сертификат клиента и нажмите кнопку "ОК".
Идентификатор политики в сертификате соответствует настроенном значению 1.2.3.4 и удовлетворяет многофакторной проверке подлинности. Аналогичным образом издатель в сертификате соответствует настроенном значению CN=WoodgroveCA и удовлетворяет однофакторной проверке подлинности.
Так как правило OID политики имеет приоритет над правилом издателя, сертификат удовлетворяет многофакторной проверке подлинности.
Политика условного доступа для пользователя требует многофакторной проверки подлинности и сертификат удовлетворяет многофакторной проверке подлинности, чтобы пользователь смог войти в приложение.

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

Политика привязки имени пользователя помогает проверить сертификат пользователя. Для политики привязки имени пользователя поддерживаются три привязки:

IssuerAndSerialNumber>CertificateUserIds
IssuerAndSubject>CertificateUserIds
Subject>CertificateUserIds

По умолчанию идентификатор Microsoft Entra сопоставляет имя субъекта в сертификате с UserPrincipalName в объекте пользователя, чтобы определить пользователя. Администратор политики проверки подлинности может переопределить значение по умолчанию и создать пользовательское сопоставление, как описано ранее.

Администратор политики проверки подлинности должен включить новые привязки. Чтобы подготовиться, они должны убедиться, что правильные значения соответствующих привязок имени пользователя обновляются в атрибуте CertificateUserIds объекта пользователя:

Для облачных пользователей используйте центр администрирования Microsoft Entra или API Microsoft Graph для обновления значения в CertificateUserIds.
Для локальных синхронизированных пользователей используйте Microsoft Entra Connect для синхронизации значений из локальной среды, следуя правилам Microsoft Entra Connect или синхронизируя значение AltSecId.

Внимание

Формат значений издателя, subject и SerialNumber должен быть в обратном порядке их формата в сертификате. Не добавляйте пробелы в издателе или субъекте.

Сопоставление издателя и серийного номера вручную

Ниже приведен пример сопоставления издателя и серийного номера вручную. Добавленное значение издателя:

C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate

Снимок экрана: значение издателя.

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

Certutil –dump –v [~certificate path~] >> [~dumpFile path~]

Например:

certutil -dump -v firstusercert.cer >> firstCertDump.txt

Ниже приведен пример команды certutil:

certutil -dump -v C:\save\CBA\certs\CBATestRootProd\mfausercer.cer 

X509 Certificate: 
Version: 3 
Serial Number: 48efa06ba8127299499b069f133441b2 

   b2 41 34 13 9f 06 9b 49 99 72 12 a8 6b a0 ef 48

Значение SerialNumber для добавления в CertificateUserId:

b24134139f069b49997212a86ba0ef48

CertificateUserId:

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<SR> b24134139f069b49997212a86ba0ef48

Сопоставление проблем и темы вручную

Ниже приведен пример сопоставления "Проблема" и "Тема" вручную. Значение издателя:

Снимок экрана: значение издателя при использовании с несколькими привязками.

Значение темы:

Снимок экрана: значение темы.

CertificateUserId:

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<S> DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

Сопоставление субъектов вручную

Ниже приведен пример сопоставления субъектов вручную. Значение темы:

Снимок экрана: другое значение темы.

CertificateUserId:

X509:<S>DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

Проверка привязки сходства

Войдите в Центр администрирования Microsoft Entra как минимум администратор политики проверки подлинности.
Перейдите к >
В разделе Управление выберите Методы проверки подлинности>Проверка подлинности на основе сертификатов.
Выберите Настроить.
Задайте требуемую привязку сопоставления на уровне клиента.

Внимание

Будьте осторожны с параметром сходства на уровне клиента. Вы можете заблокировать весь клиент, если изменить обязательную привязку affinity для клиента, и у вас нет правильных значений в объекте пользователя. Аналогичным образом, если вы создаете пользовательское правило, которое применяется ко всем пользователям и требует высокой привязки сходства, пользователи в клиенте могут быть заблокированы.
Чтобы проверить, выберите "Обязательная привязка сходства", чтобы быть низкой.
Добавьте привязку высокой сходства, например SKI. Выберите " Добавить правило " в разделе привязки имени пользователя.
Выберите SKI и нажмите кнопку "Добавить".

По завершении правило выглядит следующим образом:
Обновите атрибут CertificateUserIds всех пользовательских объектов, чтобы получить правильное значение SKI из сертификата пользователя. Дополнительные сведения см. в статье "Поддерживаемые шаблоны для сертификатовUserID".
Создайте настраиваемое правило для привязки проверки подлинности.
Выберите Добавить.

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

Включение CBA с помощью API Microsoft Graph

Чтобы включить CBA и настроить привязки пользователей с помощью API Graph, выполните следующие действия.

Запустите песочницу Microsoft Graph.
Выберите "Войти в graph Explorer" и войдите в клиент.
Следуйте инструкциям, чтобы дать согласие на делегированное разрешение Policy.ReadWrite.AuthenticationMethod.
Получите все способы проверки подлинности:
```
GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
```
ПОЛУЧЕНИЕ конфигурации для метода проверки подлинности сертификата x509:
```
GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
```

По умолчанию метод проверки подлинности сертификата x509 отключен. Чтобы разрешить пользователям выполнять вход с использованием сертификата, необходимо включить этот способ проверки подлинности и настроить политики привязки проверки подлинности и имен пользователя с помощью операции обновления. Чтобы обновить политику, выполните запрос PATCH.

Текст запроса:

PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate
Content-Type: application/json

{
    "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration",
    "id": "X509Certificate",
    "state": "enabled",
    "certificateUserBindings": [
        {
            "x509CertificateField": "PrincipalName",
            "userProperty": "onPremisesUserPrincipalName",
            "priority": 1
        },
        {
            "x509CertificateField": "RFC822Name",
            "userProperty": "userPrincipalName",
            "priority": 2
        }, 
        {
            "x509CertificateField": "PrincipalName",
            "userProperty": "certificateUserIds",
            "priority": 3
        }
    ],
    "authenticationModeConfiguration": {
        "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor",
        "rules": [
            {
                "x509CertificateRuleType": "issuerSubject",
                "identifier": "CN=WoodgroveCA ",
                "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
            },
            {
                "x509CertificateRuleType": "policyOID",
                "identifier": "1.2.3.4",
                "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
            }
        ]
    },
    "includeTargets": [
        {
            "targetType": "group",
            "id": "all_users",
            "isRegistrationRequired": false
        }
    ]
}

Вы получите 204 No content код ответа. Повторно выполните запрос GET, чтобы убедиться, что политики обновлены правильно.
Проверьте конфигурацию, войдя в систему с помощью сертификата, удовлетворяющего политике.

Включение CBA с помощью Microsoft PowerShell

Откройте средство PowerShell.

Подключение к Microsoft Graph:

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

Создайте переменную для определения группы для пользователей CBA:
```
$group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"
```

Определите текст запроса:

$body = @{
"@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration"
"id" = "X509Certificate"
"state" = "enabled"
"certificateUserBindings" = @(
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "SubjectKeyIdentifier"
        "userProperty" = "certificateUserIds"
        "priority" = 1
    },
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "PrincipalName"
        "userProperty" = "UserPrincipalName"
        "priority" = 2
    },
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "RFC822Name"
        "userProperty" = "userPrincipalName"
        "priority" = 3
    }
)
"authenticationModeConfiguration" = @{
    "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationModeConfiguration"
    "x509CertificateAuthenticationDefaultMode" = "x509CertificateMultiFactor"
    "rules" = @(
        @{
            "@odata.type" = "#microsoft.graph.x509CertificateRule"
            "x509CertificateRuleType" = "policyOID"
            "identifier" = "1.3.6.1.4.1.311.21.1"
            "x509CertificateAuthenticationMode" = "x509CertificateMultiFactor"
        }
    )
}
"includeTargets" = @(
    @{
        "targetType" = "group"
        "id" = $group.Id
        "isRegistrationRequired" = $false
    }
) } | ConvertTo-Json -Depth 5

Выполните запрос PATCH:

Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" -Body $body -ContentType "application/json"

Поделиться через

Настройка проверки подлинности на основе сертификатов Microsoft Entra

Необходимые компоненты

Действия по настройке и тестированию Microsoft Entra CBA

Шаг 1. Настройка центров сертификации с помощью хранилища доверия на основе PKI (предварительная версия)

Настройка центров сертификации с помощью Центра администрирования Microsoft Entra

Создание объекта контейнера PKI

Удаление объекта контейнера PKI

Отправка отдельных ЦС в объект контейнера PKI

Отправка всех ЦС с отправкой PKI в объект контейнера PKI

Изменение PKI

Изменение ЦС

Восстановление PKI

Восстановление ЦС

Основные сведения об атрибуте isIssuerHintEnabled в ЦС

Настройка центров сертификации с помощью API Microsoft Graph

Создание объекта контейнера PKI

Получение всех объектов PKI

Получение объекта PKI по PKI-id

Отправка ЦС с помощью P7B-файла

Получение всех ЦС в PKI

Получение определенного ЦС в PKI по идентификатору ЦС

Обновление флага указания издателя ЦС

Журнал аудита

Вопросы и ответы

Шаг 2. Включение CBA в клиенте

Шаг 3. Настройка политики привязки проверки подлинности

Шаг 4. Настройка политики привязки имени пользователя

Шаг 5. Проверка конфигурации

Проверка сертификата

Проверка правил пользовательской привязки проверки подлинности

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

Сопоставление издателя и серийного номера вручную

Сопоставление проблем и темы вручную

Сопоставление субъектов вручную

Проверка привязки сходства

Включение CBA с помощью API Microsoft Graph

Текст запроса:

Включение CBA с помощью Microsoft PowerShell

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

Обратная связь

Дополнительные ресурсы