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

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

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

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

Ниже приведены шаги, которые необходимо выполнить.

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

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

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

   

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

   Примечание.

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

   

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

   

5. После выбора проверки подлинности на основе сертификатов клиент перенаправляется в конечную точку certauth, которая используется https://certauth.login.microsoftonline.com для общедоступного идентификатора Microsoft Entra. Для azure для государственных организаций конечная точка certauth имеет значение https://certauth.login.microsoftonline.us.

   Конечная точка выполняет взаимную аутентификацию TLS и запрашивает сертификат клиента в рамках TLS-согласования. В журнале входа содержится запись об этом запросе.

   Примечание.

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

   Убедитесь, что отключение проверки TLS также работает для нового URL-адреса с указаниями издателя. Не жёстко задавайте URL-адрес с указанным tenantId, так как он может измениться для пользователей B2B. Используйте регулярное выражение, чтобы разрешить как старому, так и новому URL-адресу работать для отключения проверки TLS. Например, в зависимости от прокси-сервера, используйте *.certauth.login.microsoftonline.com или *certauth.login.microsoftonline.com. В Azure для государственных организаций используйте *.certauth.login.microsoftonline.us или *certauth.login.microsoftonline.us.

   Если доступ не разрешен, проверка подлинности на основе сертификатов завершается ошибкой при включении подсказок издателя.

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

   

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

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

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

10. После успешного входа в систему пользователь может получить доступ к приложению.

Общие сведения об указаниях эмитента (предварительный просмотр)

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

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

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

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

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

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

MFA с однофакторной проверкой подлинности на основе сертификата

Microsoft Entra CBA поддерживается как в роли первого, так и второго фактора аутентификации. Ниже приведены некоторые поддерживаемые сочетания:

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

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

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

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

Если у пользователя с поддержкой CBA есть только сертификат единого фактора (SF) и требуется выполнить MFA:

1. Использование пароля и сертификата SF (OR)
2. Администратор политики проверки подлинности может выдавать временный проход доступа (OR)
3. Администратор политики проверки подлинности добавляет номер телефона и разрешает проверку подлинности голосового и текстового сообщения для учетной записи пользователя.

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

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

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

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

Действия по настройке входа без пароля телефона (PSI) с помощью CBA

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

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

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

   Внимание

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

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

   

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

   

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

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

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

   

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

   

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

   

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

   

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

   

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

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

   

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

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

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

Сильные стороны сертификата

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

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

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

Как Microsoft Entra ID разрешает несколько правил связывания политики проверки подлинности

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

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

Общие сведения о политике привязки имени пользователя

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

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

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

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

Определите связность на уровне арендатора и замените пользовательскими правилами.

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

Как идентификатор Microsoft Entra ID обрабатывает несколько правил привязки политики имен пользователей

Используйте привязку с наивысшим приоритетом (наименьшим числом).

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

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

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

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

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

Существуют сценарии, в которых организация выдает несколько сертификатов для одного удостоверения. Чаще всего это могут быть производные учетные данные для мобильного устройства или для дополнительной смарт-карты, или устройства, поддерживающего учетные данные x509, такого как Yubikey.

Облачные только учетные записи Для облачных учетных записей можно сопоставить несколько сертификатов (до 5) для использования, заполняя поле certificateUserIds (сведения о авторизации на пользовательском портале) уникальными значениями, определяющими каждый сертификат. Если организация использует привязки с высоким сходством, например Issuer + SerialNumber, значения в CertificateUserIds могут выглядеть следующим образом:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

В этом примере первое значение представляет X509Certificate1, а второе значение представляет X509Certificate2. Пользователь может представить любой из сертификатов при входе в систему, и если для привязки имени пользователя CBA задано указание на поле certificateUserIds, чтобы найти конкретный тип привязки (то есть Issuer+SerialNumber в этом примере), то пользователь успешно войдет в систему.

Гибридные синхронизированные учетные записи Для синхронизированных учетных записей можно сопоставить несколько сертификатов для использования, заполив поле altSecurityIdentities в AD значения, определяющие каждый сертификат. Если организация использует привязки высокой аффинности (т. е. с сильной аутентификацией), например, издатель + серийный номер, это может выглядеть следующим образом:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

В этом примере первое значение представляет X509Certificate1, а второе значение представляет X509Certificate2. Затем эти значения должны быть синхронизированы с полем certificateUserIds в идентификаторе Microsoft Entra.

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

Существуют сценарии, когда организации необходимо, чтобы пользователь использовал один и тот же сертификат для проверки подлинности в нескольких удостоверениях. Чаще всего это касается учетных записей администрирования. Это также может быть для учетных записей разработчиков или временных служебных учетных записей. В традиционном поле AD altSecurityIdentities используется для заполнения значений сертификатов, а подсказка используется во время входа, чтобы направить AD в нужную учетную запись для проверки входа. При использовании Microsoft Entra CBA всё по-другому, и подсказка отсутствует. Вместо этого Home Realm Discovery определяет учетную запись, необходимую для проверки значений сертификата. Другое ключевое отличие заключается в том, что Microsoft Entra CBA обеспечивает уникальность в поле certificateUserIds. Это означает, что две учетные записи не могут заполнять одинаковые значения сертификатов.

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

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

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

• Издатель + серийный номер —> CertificateUserIds
• SKI —> CertificateUserIds

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

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

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

Заполните поле altSecurityIdentities в AD значениями, идентифицирующими нужный сертификат, и добавьте нужное значение сертификата для этого типа учетной записи пользователя (например, подкомандированный, администратор, разработчик и т. д.). Выберите ключевой атрибут в AD, который сообщает синхронизации, какой тип учетной записи пользователя оценивает пользователь (например, msDS-cloudExtensionAttribute1). Заполните этот атрибут значением типа пользователя, например прикомандированным, администратором или разработчиком. Если это основная учетная запись пользователя, значение можно оставить пустым или null.

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

Лес 1 — Аккаунт1 (bob@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Лес 1 — Аккаунт2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Лес 2 — ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Затем эти значения должны быть синхронизированы с полем certificateUserIds в идентификаторе Microsoft Entra.

Шаги по синхронизации с certificateUserIds

1. Настройте Microsoft Entra Connect для добавления поля alternativeSecurityIds в Метавселенную
2. Для каждого леса AD настройте новое пользовательское правило входящего трафика с высоким приоритетом (низкое число ниже 100). Добавьте преобразование выражения, используя поле altSecurityIdentities в роли источника. Целевое выражение использует выбранный и заполненный ключевой атрибут, а также выполненное вами сопоставление с определенными типами пользователей.
3. Например:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

В приведенном выше примере сначала проверяется, заполнены ли altSecurityIdentities и ключевой атрибут msDS-cloudExtensionAttribute1is. Если нет, проверяется, заполнено ли altSecurityIdentities. Если он пуст, то присвойте ему значение NULL. В противном случае учетная запись попадает в стандартный случай, и в этом примере мы отфильтруем только сопоставление Issuer+SerialNumber. Если ключевой атрибут заполнен, то значение проверяется, равно ли оно одному из определенных типов пользователей. В этом примере, если это значение является подробным, мы отфильтруем значение SHA1PublicKey из altSecurityIdentities. Если значение равно «разработчик», то мы фильтруем значение SubjectKeyIssuer из altSecurityIdentities. Может быть несколько значений сертификатов определенного типа. Например, несколько значений PrincipalName или несколько значений SKI или SHA1-PUKEY. Фильтр получает все значения и синхронизируется с идентификатором Microsoft Entra , а не только первым, который он находит.

1. Второй пример, показывающий, как отправить пустое значение, если атрибут элемента управления пуст:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
) 

Если значение в altSecurityIdentities не соответствует ни одному из значений поиска в управляющем атрибуте, передается AuthoritativeNull. Это гарантирует, что предыдущие или последующие правила, предназначенные для заполнения alternativeSecurityId, игнорируются, и в Microsoft Entra ID результат будет пустым.

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

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

Общие сведения о процессе отзыва сертификата

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

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

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

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

"Список отзыва сертификатов (CRL), скачанный из {URI}, превысил максимальный допустимый размер ({size} байт) для списков отзыва сертификатов в идентификаторе Microsoft Entra. Повторите попытку через несколько минут. Если проблема сохранится, обратитесь к администраторам клиента".

После ошибки Microsoft Entra ID пытается скачать список отзыва сертификатов (CRL), с учетом ограничений на стороне службы (45 МБ в общедоступных Microsoft Entra ID и 150 МБ в облаках Azure для государственных организаций США).

На данный момент мы не поддерживаем Online Certificate Status Protocol (OCSP) из соображений производительности и надежности. Вместо скачивания списка отзыва сертификатов клиентским браузером при каждом подключении в процессе OCSP, Microsoft Entra ID загружает его один раз при первом входе и кэширует. Это действие повышает производительность и надежность проверки CRL. Мы также индексируем кэш, чтобы значительно повысить скорость работы при каждом поиске. Пользователи должны публиковать списки отзыва сертификатов (CRL).

Ниже приведен типичный поток проверки списка отзыва сертификатов.

1. Microsoft Entra ID пытается загрузить список отзыва сертификатов при первом событии входа в систему любым пользователем с сертификатом соответствующего доверенного издателя или центра сертификации.
2. Идентификатор Microsoft Entra ID кэширует и повторно использует CRL для дальнейшего использования. Она учитывает дату следующего обновления и, если она доступна, в документе CRL дата публикации следующего списка отзыва сертификатов (используется центрами сертификации Windows Server).
3. Проверка подлинности на основе сертификата пользователя завершается ошибкой, если:

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

   • Сертификат пользователя указан в качестве отозванного в списке отозванных сертификатов.

     

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

На данный момент отсутствует возможность вручную принудительно или повторно инициировать загрузку списка отзыва сертификатов.

Настройка отзыва сертификата

Чтобы отозвать сертификат клиента, идентификатор Microsoft Entra извлекает список отзыва сертификатов (CRL) из URL-адресов, отправленных в рамках сведений центра сертификации и кэширует его. Последняя метка времени публикации (свойство Effective Date) в CRL используется, чтобы убедиться, что CRL все еще действителен. Список отзыва сертификатов периодически проверяется для отзыва доступа к сертификатам, включенным в список.

Если требуется более быстрый отзыв (например, если пользователь потерял устройство), то маркер авторизации пользователя можно сделать недействительным. Чтобы сделать маркер авторизации недействительным, задайте поле StsRefreshTokensValidFrom для этого конкретного пользователя с помощью Windows PowerShell. Необходимо обновить поле StsRefreshTokensValidFrom для каждого пользователя, для которого требуется отозвать доступ.

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

Ниже описан процесс обновления и аннулирования токена авторизации путем задания поля StsRefreshTokensValidFrom.

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"

# Get the user
$user = Get-MgUser -UserPrincipalName "test@yourdomain.com"

# Get the StsRefreshTokensValidFrom property
$user.StsRefreshTokensValidFrom

Задаваемая дата должна быть в будущем. Если дата не находится в будущем, свойство StsRefreshTokensValidFrom не задано. Если дата находится в будущем, stsRefreshTokensValidFrom имеет текущее время (а не дата, указанная командой Set-MsolUser).

Понимание проверки CRL

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

Чтобы усилить безопасность и избежать неправильной настройки, администратор политики проверки подлинности может потребовать завершения аутентификации CBA с ошибкой, если для ЦС, выдающего конечные пользовательские сертификаты, не настроен список отзыва сертификатов (CRL).

Включить проверку СПОС.

Чтобы включить проверку сертификатов, выберите "Требовать проверку списка отзыва сертификатов (CRL)" (рекомендуется).

После включения любой сбой CBA происходит из-за того, что сертификат конечного пользователя был выдан ЦС без настройки CRL.

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

Центры сертификации в исключенном списке не требуют настройки CRL и сертификатов конечных пользователей, которые они выдают, не завершают проверку подлинности.

Выберите ЦС и нажмите кнопку "Добавить". Текстовое поисковое поле можно использовать для фильтрации списков ЦС, чтобы выбрать определенные ЦС.

Центр сертификации (ЦС) (предварительная версия)

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

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

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

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

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

Шаги по включению функции области действия УЦ

1. Войдите в Центр администрирования Microsoft Entra с правами не ниже Администратора политики проверки подлинности.
2. Перейдите к Entra ID>, Методы проверки подлинности>, Проверка подлинности с использованием сертификатов.
3. В разделе "Настройка" перейдите к политике определения области действия издателя сертификатов

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

1. Выберите Отфильтровать ЦС по PKI. Классические ЦС будут отображать все ЦС из классического хранилища ЦС и выбор определенного PKI будет отображать все ЦС из выбранного PKI. Выберите PKI.

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

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

1. Выбор группы

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

1. Выберите "Подтвердить " и " Сохранить", чтобы сохранить конфигурацию CBA

1. Чтобы изменить или удалить политику области действия ЦС, выберите "..." в строке с правилом. Выберите "Изменить ", чтобы изменить правило и удалить его, чтобы удалить это правило.

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

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

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

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

• Если проверка подлинности на основе сертификатов (CBA) завершается ошибкой из-за правила области сертификационного центра (ЦС), вкладка "Основная информация" в журнале входа отобразит код ошибки 500189.

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

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

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

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

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

Надежность проверки подлинности CBA с расширенными параметрами

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

Общие сведения о журналах входа

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

Давайте рассмотрим два сценария: один, где сертификат удовлетворяет однофакторной проверке подлинности, и другой, где сертификат удовлетворяет MFA.

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

Сертификат пользователя должен быть настроен, как показано на следующем снимке экрана:

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

Несмотря на то, что журналы входа предоставляют все сведения для отладки проблем входа пользователя, возникает время, когда требуются определенные значения и так как журналы входа не поддерживают динамические переменные, журналы входа будут иметь недостающие сведения. Например, в журнале входа причина сбоя может быть показана как "Список отзыва сертификатов (CRL) не прошел проверку подписи. Ожидаемый идентификатор ключа субъекта {expectedSKI} не соответствует идентификатору ключа удостоверяющего центра CRL {crlAK}. Попросите администратора клиента проверить конфигурацию CRL, где {expectedSKI} и {crlAKI} не заполнены правильными значениями.

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

Тестирование однофакторной проверки подлинности

Для первого тестового сценария настройте политику проверки подлинности, в которой правило субъекта издателя удовлетворяет однофакторной проверке подлинности.

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

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

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

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

   

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

   

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

   

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

   

Тестирование многофакторной проверки подлинности

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

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

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

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

   

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

   

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

   

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

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

Понимание страницы ошибки проверки подлинности на основе сертификатов

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

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

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

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

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

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

• При сбое CBA пользователь будет отправлен на страницу ошибок

• Щелкните значок блокировки слева от URL-адреса адреса и выберите варианты сертификата.

• Выберите сброс выбора сертификатов

• Выберите Сбросить выбор в диалоговом окне

• Щелкните "Другие способы входа" на странице ошибки

• Выберите «Использовать сертификат или смарт-карту» в списке выбора и продолжайте проверку подлинности на основе сертификата (CBA).

Проверка подлинности на основе сертификатов в методах MostRecentlyUsed (MRU)

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

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

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

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

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

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

• Обзор Microsoft Entra CBA
• Настройка Microsoft Entra CBA
• Microsoft Entra CBA на устройствах iOS
• Microsoft Entra CBA на устройствах Android
• Вход в систему Windows с использованием смарт-карты через Microsoft Entra CBA
• Идентификаторы пользователей для сертификата
• Как перенести федеративных пользователей
• Вопросы и ответы
• Устранение неполадок Microsoft Entra CBA