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

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

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

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

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

Предварительные условия

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

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

Соображения

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

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

• В рамках текущих улучшений безопасности добавлена поддержка TLS 1.3 для конечных точек Azure и Microsoft 365. Ожидается, что процесс займет несколько месяцев, чтобы покрыть тысячи конечных точек службы в Azure и Microsoft 365. Узлы Microsoft Entra, которые использует Microsoft Entra CBA, включены в обновление: *.certauth.login.microsoftonline.com и *.certauth.login.microsoftonline.us.

  TLS 1.3 — это самая последняя версия наиболее распространенного протокола безопасности в Интернете. TLS 1.3 шифрует данные для обеспечения безопасного канала связи между двумя конечными точками. Он устраняет устаревшие алгоритмы шифрования, повышает безопасность по сравнению с более ранними версиями и шифрует как можно больше рукопожатия. Мы настоятельно рекомендуем начать тестирование TLS 1.3 в приложениях и службах.

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

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

Настройка и проверка Microsoft Entra CBA

Перед включением Microsoft Entra CBA необходимо выполнить некоторые действия по настройке.

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

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

По завершении всех конфигураций включите Microsoft Entra CBA в клиенте.

Шаг 1. Настройка ЦС с использованием хранилища сертификатов доверия на основе PKI

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

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

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

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

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

Настройка сертификационных служб с помощью центра администрирования Microsoft Entra

Создание объекта контейнера PKI (Центр администрирования Microsoft Entra)

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

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

2. Перейдите к Entra ID>Identity Secure Score>Public key infrastructure.

3. Выберите "Создать PKI".

4. В поле Отображаемое имя введите имя.

5. Нажмите кнопку "Создать".

   

6. Чтобы добавить или удалить столбцы, выберите "Изменить столбцы".

7. Чтобы обновить список PKIs, нажмите кнопку "Обновить".

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

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

Загрузка отдельных удостоверяющих центров в объект контейнера PKI

Чтобы загрузить ЦС в контейнер PKI, следуйте приведенным инструкциям.

1. Выберите "Добавить центр сертификации".

2. Выберите файл Центра Сертификации.

3. Если ЦС является корневым сертификатом, нажмите кнопку "Да". В противном случае нажмите кнопку "Нет".

4. Для URL-адреса списка отзыва сертификатов введите URL-адрес, доступный в интернете, для основной ЦС, содержащей все отозванные сертификаты. Если URL-адрес не задан, попытка пройти проверку подлинности с помощью отозванного сертификата не приводит к ошибке.

5. Для URL-адреса разностного списка отзыва сертификатов введите интернет-адрес для CRL, который содержит все отозванные сертификаты с момента публикации последнего базового CRL.

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

7. Нажмите кнопку "Сохранить".

8. Чтобы удалить ЦС, выберите ЦС и нажмите кнопку "Удалить".

   

9. Чтобы добавить или удалить столбцы, выберите "Изменить столбцы".

10. Чтобы обновить список PKIs, нажмите кнопку "Обновить".

Изначально отображаются 100 сертификатов Центра сертификации. Больше элементов отображается при прокрутке вниз панели.

Загрузите все центры сертификации в объект контейнера PKI

Чтобы массово загрузить все сертификаты ЦС в контейнер PKI:

1. Создайте объект контейнера PKI или откройте существующий контейнер.

2. Выберите "Отправить PKI".

3. Введите URL-адрес HTTP для доступа к Интернету .p7b файла.

4. Введите контрольную сумму SHA-256 файла.

5. Выберите отправку.

   Процесс отправки PKI является асинхронным. По мере того, как загружается каждый центр сертификации (ЦС), он становится доступен в PKI. Вся отправка PKI может занять до 30 минут.

6. Выберите "Обновить", чтобы обновить список центров сертификации.

7. Каждый загруженный атрибут конечной точки ЦС CRL обновляется с помощью первого доступного HTTP-URL-адреса сертификата ЦС, указанного в качестве атрибута точек распространения CRL . Необходимо вручную обновить все конечные сертификаты.

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

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Изменение PKI

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

Редактирование Центра Сертификации

1. В строке CA выберите ... и Изменить.
2. Введите новые значения для типа ЦС (корневого или промежуточного), URL-адреса CRL, URL-адреса разностного списка отзыва сертификатов или флага включения подсказок издателя в соответствии с вашими требованиями.
3. Нажмите кнопку "Сохранить".

Пакетное редактирование атрибута подсказок эмитента

1. Чтобы изменить несколько центров сертификации и включить или отключить атрибут Подсказки издателя включены, выберите несколько центров сертификации.
2. Выберите "Изменить", а затем выберите "Изменить подсказки издателя".
3. Установите флажок "Подсказки издателя включены" для всех выбранных центров сертификации или снимите выбранный флажок, чтобы отключить флаг включения подсказок издателя для всех выбранных ЦС. Значение по умолчанию — indeterminate.
4. Нажмите кнопку "Сохранить".

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

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

Восстановление удостоверяющего центра

1. Перейдите на вкладку Удаленные ЦС.
2. Выберите ЦС-файл, а затем выберите "Восстановить центр сертификации".

Настройте атрибут isIssuerHintEnabled для ЦС

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

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

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

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

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

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

Создание объекта контейнера PKI (Microsoft Graph)

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

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.

1. Запустите PowerShell с помощью параметра "Запуск от имени администратора ".

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

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

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

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

Приоритезация между хранилищем доверия на основе PKI и классическим хранилищем ЦС

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

Приоритет отдается классическому хранилищу Центра Сертификации в следующих сценариях:

• Центр сертификации существует в обоих хранилищах: хранилище на основе инфраструктуры открытых ключей (PKI) не имеет списка отзыва (CRL), но классический центр сертификации хранилища имеет действительный список отзыва.
• Центр сертификации (ЦС) существует в обоих хранилищах, при этом CRL ЦС хранилища на основе PKI отличается от CRL ЦС классического хранилища.

Журнал входа

Прерванная запись в журнале входа Microsoft Entra имеет два атрибута в разделе Additional Details, чтобы указать, использовалось ли классическое или устаревшее хранилище доверия в процессе аутентификации.

• Используется устаревшее хранилище с значением 0 , чтобы указать, что используется PKI-хранилище. Значение 1 указывает, что используется классическое или устаревшее хранилище.
• Информация об использовании устаревшего хранилища объясняет причину, по которой используется классическое или устаревшее хранилище.

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

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

Миграция из классического хранилища Центра сертификации (ЦС) в хранилище на основе PKI

Администратор арендатора может загрузить все ЦС в PKI-хранилище. Затем хранилище удостоверяющего центра PKI имеет приоритет над классическим хранилищем, и вся аутентификация CBA осуществляется через PKI-хранилище. Администратор клиента может удалить ЦС из классического или устаревшего хранилища, если в журналах входа нет указаний на использование классического или устаревшего хранилища.

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

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

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

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

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

Как создать контрольную сумму SHA-256 для PKI-файла?

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

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

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

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

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

2. Перейдите в раздел "Группы>все группы".

3. Выберите новую группу и создайте группу для пользователей CBA.

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

5. В разделе "Включение" и "Цель" выберите "Включить", а затем установите флажок "Я подтверждаю".

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

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

8. Нажмите кнопку "Сохранить".

   

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

Шаг 3: Настройка политики привязки аутентификации

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

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

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

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

1. Войдите в Центр администрирования Microsoft Entra с учетной записью, которой назначена хотя бы роль Authentication Policy Administrator.

2. Перейдите к Entra ID>Методы аутентификации>Политики.

3. В разделе "Управление миграциями" выберите методы>проверки подлинности на основе сертификатов.

   

4. Чтобы настроить привязку проверки подлинности и привязку имени пользователя, выберите "Настроить".

5. Чтобы изменить значение по умолчанию на MFA, выберите многофакторную проверку подлинности. Атрибут уровня защиты имеет значение по умолчанию для однофакторной проверки подлинности.

   Примечание.

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

   

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

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

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

   

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

   1. Выберите издателя сертификатов.

   2. Для идентификатора издателя сертификатов выберите соответствующее значение.

   3. Для проверки подлинности выберите многофакторную проверку подлинности.

   4. Для привязки аффинности выберите низкий.

   5. Нажмите кнопку "Добавить".

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

      

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

   1. Выберите OID политики.

   2. Для идентификатора политики введите значение.

   3. Для проверки подлинности выберите однофакторную проверку подлинности.

   4. Для привязки сходства выберите "Низкий " для привязки сходства.

   5. Нажмите кнопку "Добавить".

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

      

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

   1. Выберите издателя сертификатов и идентификатор политики.

   2. Выберите издателя и введите идентификатор политики.

   3. Для проверки подлинности выберите многофакторную проверку подлинности.

   4. Для привязки по аффинности выберите „Низкий“.

   5. Нажмите кнопку "Добавить".

      

      

   6. Аутентификация с сертификатом, имеющим идентификатор политики 3.4.5.6 и выданным CN=CBATestRootProd. Убедитесь, что проверка подлинности проходит для многофакторной аутентификации.

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

   1. Добавьте политику привязки аутентификации. Для политики необходимо, чтобы любой сертификат, выданный CN=CBATestRootProd с идентификатором OID политики 1.2.3.4.6, требовал только высокой аффинности привязки. Используются эмитент и серийный номер.

      

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

      

   3. Поддерживается только атрибут пользователя certificateUserIds. Выберите certificateUserIds и нажмите кнопку "Добавить".

      

   4. Нажмите кнопку "Сохранить".

      В журнале входа показано, какая привязка использовалась для входа и сведения из сертификата.

      

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

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

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

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

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

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

   

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

2. Нажмите кнопку "Сохранить".

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

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

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

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

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

1. Введите имя пользователя (UPN).

   

2. Нажмите кнопку "Далее".

   

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

   

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

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

   

5. Убедитесь, что вы вошли на портал MyApps.

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

• Сертификат пользователя установлен на тестовом устройстве.
• Microsoft Entra ID настроен правильно для использования доверенных УЦ.
• Привязка имени пользователя настроена правильно. Пользователь найден и прошел проверку подлинности.

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

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

1. Создайте правило субъекта издателя с уровнем защиты однофакторной проверки подлинности. Установите значение для субъекта вашего Центра сертификации.

   Например:

   CN=WoodgroveCA

2. Создайте правило политики OID, которое имеет уровень защиты многофакторной аутентификации. Задайте значение для одного из идентификаторов политики в вашем сертификате. Примером является 1.2.3.4.

   

3. Создайте политику Условный доступ Microsoft Entra для пользователя, требующей многофакторную проверку подлинности. Выполните действия, описанные в разделе "Условный доступ" — требовать многофакторную проверку подлинности.

4. Перейдите на портал MyApps. Введите имя пользователя и выберите Далее.

   

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

   

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

   

6. Выберите сертификат клиента и выберите сведения о сертификате.

   

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

   

7. Чтобы просмотреть значения OID политики, выберите "Сведения".

   

8. Выберите сертификат клиента и нажмите кнопку "ОК".

Идентификатор политики в сертификате соответствует настроенному значению 1.2.3.4 и соответствует требованиям MFA. Издатель в сертификате соответствует настроенному значению CN=WoodgroveCA и удовлетворяет однофакторной аутентификации.

Так как правило OID политики имеет приоритет над правилом издателя, сертификат удовлетворяет MFA.

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

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

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

• IssuerAndSerialNumber > certificateUserIds
• IssuerAndSubject > certificateUserIds
• Subject > certificateUserIds

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

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

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

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

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

Добавляемое значение издателя :

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 

Значение серийного номера для добавления в certificateUserId.

b24134139f069b49997212a86ba0ef48

Значение certificateUserIds :

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

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

В следующем примере показывается ручное сопоставление издателя и субъекта.

Значение Издателя :

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

<с1><с0>Снимок экрана, демонстрирующий значение темы.

Значение 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

Ручное сопоставление тем

В следующем примере показано ручное сопоставление тем.

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

Значение certificateUserIds :

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

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

1. Войдите в Центр администрирования Microsoft Entra с учетной записью, которой назначена как минимум роль Authentication Policy Administrator.

2. Перейдите к Entra ID>Методы аутентификации>Политики.

3. В разделе "Управление" выберите методы>проверки подлинности на основе сертификатов.

4. Выберите "Настроить".

5. Установите обязательное связывание аффинности на уровне арендатора.

   Внимание

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

   

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

7. Добавьте привязку с высоким сходством, например идентификатор ключа субъекта (SKI). В разделе привязки имени пользователя выберите "Добавить правило".

8. Выберите SKI и нажмите кнопку "Добавить".

   

   По завершении правило выглядит примерно так:

   

9. Для всех пользовательских объектов обновите certificateUserIds атрибут с правильным значением SKI из сертификата пользователя.

   Дополнительные сведения см. в статье "Поддерживаемые шаблоны для сертификатовUserID".

10. Создайте настраиваемое правило для привязки аутентификации.

11. Нажмите кнопку "Добавить".

    

    Убедитесь, что завершенное правило выглядит примерно так:

    

12. Обновите значение пользователя certificateUserIds с правильным значением SKI из сертификата и идентификатора политики 9.8.7.5.

13. Проверьте с помощью сертификата с идентификатором политики 9.8.7.5. Убедитесь, что пользователь прошел проверку подлинности с помощью привязки SKI и что им будет предложено войти с помощью MFA и только сертификата.

Настройка CBA с помощью API Microsoft Graph

Чтобы настроить CBA и конфигурировать привязки имен пользователей с помощью API Microsoft Graph:

1. Перейдите к Microsoft Graph Explorer.

2. Выберите Войти в Graph Explorer и выполните вход в свою учетную запись арендатора.

3. Выполните действия, чтобы предоставить согласие на Policy.ReadWrite.AuthenticationMethod делегированное разрешение.

4. Получение всех методов проверки подлинности:

   GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
   

5. Получите конфигурацию для метода проверки подлинности сертификата X.509:

   GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
   

6. По умолчанию метод проверки подлинности сертификата X.509 отключен. Чтобы разрешить пользователям входить с помощью сертификата, необходимо включить метод проверки подлинности и настроить политики проверки подлинности и привязки имени пользователя с помощью операции обновления. Чтобы обновить политику, выполните 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
           }
       ]
   }
   

7. Убедитесь, что код ответа 204 No content возвращается. Повторно выполните GET запрос, чтобы убедиться, что политики обновлены правильно.

8. Проверьте конфигурацию, войдя в систему с помощью сертификата, удовлетворяющего политике.

Настройка CBA с помощью Майкрософт PowerShell

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

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

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

3. Создайте переменную для определения группы для пользователей CBA:

   $group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"
   

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

   $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
   

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

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

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

• Обзор Microsoft Entra CBA
• Технические концепции Microsoft Entra CBA
• Ограничения использования Microsoft Entra CBA
• Вход в Windows с помощью смарт-карты через Microsoft Entra CBA
• Microsoft Entra CBA на мобильных устройствах (Android и iOS)
• Идентификаторы пользователей для сертификата
• Перенос федеративных пользователей
• Вопросы и ответы