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


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

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

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

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

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

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

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

Внимание

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

Внимание

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

Внимание

В рамках текущих улучшений безопасности конечные точки Azure/M365 добавляют поддержку TLS1.3, и этот процесс, как ожидается, займет несколько месяцев, чтобы покрыть тысячи конечных точек службы в Azure/M365. Это включает конечную точку 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. По этой причине важно учитывать, как и когда ЦС могут выдавать сертификаты, а также как они реализуют повторно используемые идентификаторы. Если администраторам необходимо убедиться, что для проверки подлинности пользователя может использоваться только определенный сертификат, администраторы должны использовать исключительно привязки высокого соответствия для достижения более высокого уровня гарантии того, что только определенный сертификат может пройти проверку подлинности пользователя. Дополнительные сведения см. в привязках с высоким сходством.

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

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

Внимание

Microsoft рекомендует использовать роли с наименьшим количеством разрешений. Эта практика помогает повысить безопасность вашей организации. Глобальный администратор — это высоко привилегированная роль, которая должна быть ограничена сценариями чрезвычайных ситуаций или если вы не можете использовать существующую роль.

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

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

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

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

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

Примечание.

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

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

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

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

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

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

  2. Войдите в Центр администрирования Microsoft Entra в качестве администратора проверки подлинности привилегий.

  3. Перейдите к Entra ID>Secure Score идентичности>Инфраструктура открытых ключей (предварительная версия).

  4. Нажмите кнопку +Создать PKI.

  5. Введите отображаемое имя.

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

    Схема шагов, необходимых для создания PKI.

  7. Выберите столбцы для добавления или удаления столбцов.

  8. Выберите "Обновить", чтобы обновить список PKIs.

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

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

    Схема шагов, необходимых для удаления PKI.

Загрузите отдельные ЦС в объект контейнера инфраструктуры открытых ключей (PKI)

  1. Чтобы загрузить сертификат удостоверяющего центра в контейнер PKI:
    1. Нажмите кнопку + Добавить центр сертификации.

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

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

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

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

    6. Флаг подсказок эмитента включен по умолчанию. Отключите подсказки издателя, если ЦС не следует включать в подсказки издателя.

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

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

      Схема того, как удалить сертификат ЦС.

    9. Выберите столбцы для добавления или удаления столбцов.

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

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

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

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

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

    Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256
    

Изменение PKI

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

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

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

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

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

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

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

Понимание атрибута isIssuerHintEnabled в Центре сертификации

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

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

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

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

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

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

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

    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>
    

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

Все операции 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, выполните следующие действия.

  1. Войдите в Центр администрирования Microsoft Entra в качестве Администратора политик проверки подлинности или выше.

  2. Перейдите к>группе "Все группы> " выберите "Создать группу " и создайте группу для пользователей CBA.

  3. Перейдите к Entra ID>, Методы проверки подлинности>, Проверка подлинности с использованием сертификатов.

  4. В разделе Enable and Target выберите Включить и нажмите Подтверждаю.

  5. Нажмите кнопку "Выбрать группы", нажмите кнопку "Добавить группы".

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

  7. По завершении нажмите кнопку "Сохранить".

    Снимок экрана: включение CBA.

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

Примечание.

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

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

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

Внимание

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

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

  1. Войдите в Центр администрирования Microsoft Entra в качестве Администратора политик проверки подлинности или выше.

  2. Перейдите к Entra ID>методам проверки подлинности>политикам.

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

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

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

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

    Примечание.

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

    Снимок экрана: изменение политики по умолчанию на MFA.

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

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

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

    Снимок экрана: добавление правила.

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

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

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

      Снимок экрана: политика многофакторной проверки подлинности.

    Чтобы создать правило по идентификатору политики (OID), выберите OID политики.

    1. Введите значение для OID политики.

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

      Снимок экрана: сопоставление с OID политики.

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

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

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

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

    4. Для привязки сходства нажмите кнопку High.

      Снимок экрана: выбор привязки с низкой аффинностью.

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

      Снимок экрана, демонстрирующий процесс добавления привязки с низкой аффинитетом.

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

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

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

      Снимок экрана с издателем и серийным номером добавлен в Центр администрирования Microsoft Entra.

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

      Снимок экрана: выбор издателя и серийного номера.

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

      Снимок экрана: добавление издателя и серийного номера.

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

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

      Снимок экрана: журнал входа.

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

Внимание

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

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

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

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

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

Внимание

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

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

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

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

  2. Нажмите кнопку "Сохранить", чтобы сохранить изменения.

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

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

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

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

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

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

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

    Снимок экрана учетного имени пользователя.

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

    Снимок экрана: вход с сертификатом.

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

    Снимок экрана: альтернативный вход.

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

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

    Снимок экрана: пользовательский интерфейс средства выбора сертификатов.

  5. Пользователи должны войти на портал MyApps.

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

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

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

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

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

    CN = WoodgroveCA

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

    Снимок экрана правила политики OID.

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

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

    Снимок экрана учетного имени пользователя.

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

    Снимок экрана: вход с сертификатом.

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

    Снимок экрана: альтернативный вход.

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

    Снимок экрана: средство выбора клиента.

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

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

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

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

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

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

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

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

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

  • Выпускатель и Серийный Номер>Идентификатор Пользователя Сертификата
  • ИздательИПредмет>ИдентификаторыПользователейСертификата
  • Тема>CertificateUserIds

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

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

Внимание

Формат значений издателя, владельца и серийного номера должен быть в обратном порядке, как они представлены в сертификате. Не добавляйте пробелы в поле Издатель или Тема.

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

Вот пример ручного сопоставления издателя и серийного номера. Значение эмитента, которое необходимо добавить, это:

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 

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

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

Скриншот значения издателя при использовании нескольких привязок.

Значение темы следующее:

Снимок экрана значения Subject.

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

Проверка аффинитетного связывания

  1. Войдите в Центр администрирования Microsoft Entra в качестве Администратора политик проверки подлинности или выше.

  2. Перейдите к Entra ID>методам проверки подлинности>политикам.

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

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

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

    Внимание

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

    Снимок экрана: установка необходимой привязки аффинити.

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

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

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

    Снимок экрана, как добавить связь аффинности.

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

    Снимок завершенной привязки аффинности.

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

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

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

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

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

    Снимок экрана пользовательского правила.

  12. Обновите идентификаторы CertificateUserIds пользователя, используя корректное значение SKI из сертификата с политикой OID 9.8.7.5.

  13. Тестирование с сертификатом с политикой OID 9.8.7.5: пользователь должен пройти аутентификацию через привязку SKI и получить многофакторную аутентификацию исключительно с помощью сертификата.

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

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

  1. Перейдите в Обозреватель Microsoft Graph.

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

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

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

    GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
    
  5. ПОЛУЧЕНИЕ конфигурации для метода проверки подлинности сертификата x509:

    GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
    
  6. По умолчанию метод проверки подлинности сертификата 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
            }
        ]
    }
    
  7. Вы получите 204 No content код ответа. Повторно выполните запрос GET, чтобы убедиться, что политики обновлены правильно.

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

Включение CBA с помощью Microsoft 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"
    

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