Требования к сертификатам и их перечисление

• Применяется к:

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

В этом разделе для ИТ-специалистов и разработчиков смарт-карт описывается, как сертификаты управляются и используются для входа с помощью смарт-карты.

При вставке смарт-карты выполняются следующие действия.

Примечание.

Если не указано иное, все операции выполняются автоматически (CRYPT_SILENT передается в CryptAcquireContext).

1. База данных диспетчера ресурсов смарт-карт ищет поставщика служб шифрования (CSP) смарт-карты.

2. Полное имя контейнера создается с помощью имени средства чтения смарт-карт и передается в CSP. Формат : \\.<Reader name>\

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

4. Имя контейнера извлекается с помощью параметра PP_CONTAINER с CryptGetProvParam.

5. Используя контекст, полученный на шаге 3, поставщик служб CSP запрашивает параметр PP_USER_CERTSTORE. Дополнительные сведения см. в разделе Архитектура смарт-карт. Если операция выполнена успешно, возвращается имя хранилища сертификатов, а поток программы переходит к шагу 8.

6. Если операция на шаге 5 завершается сбоем, то в контексте контейнера по умолчанию из шага 3 запрашивается ключ AT_KEYEXCHANGE.

7. Затем сертификат запрашивается из контекста ключа с помощью KP_CERTIFICATE. Сертификат добавляется в хранилище сертификатов в памяти.

8. Для каждого сертификата в хранилище сертификатов из шага 5 или 7 выполняются следующие проверки:

   1. Сертификат должен быть действительным на основе системных часов компьютера (срок действия не истек или действителен с будущей датой).
   2. Сертификат не должен находиться в AT_SIGNATURE части контейнера
   3. Сертификат должен иметь допустимое имя участника-пользователя (UPN)
   4. Сертификат должен иметь использование ключа цифровой подписи.
   5. Сертификат должен иметь EKU для входа со смарт-картой.

   Любой сертификат, соответствующий этим требованиям, отображается пользователю с использованием имени участника-пользователя сертификата (или адреса электронной почты или субъекта в зависимости от наличия расширений сертификата).

9. Затем процесс выбирает сертификат и вводится ПИН-код.

10. LogonUI.exe упаковывает сведения и отправляет их в Lsass.exe для обработки попытки входа

11. В случае успешного LogonUI.exe выполнения закрывается. Это приводит к освобождению контекста, полученного на шаге 3.

Поток входа со смарт-картой в Windows

Большинство проблем во время проверки подлинности возникают из-за изменений в поведении сеанса. При внесении изменений локальный центр безопасности (LSA) не повторно запрашивает контекст сеанса; Вместо этого он использует поставщик служб шифрования для обработки изменений сеанса.

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

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

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

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

Поток входа со смарт-картой

Ниже приведены действия, выполняемые во время входа со смарт-картой.

1. Winlogon запрашивает учетные данные пользовательского интерфейса входа

2. Асинхронно запускается диспетчер ресурсов смарт-карт, а поставщик учетных данных смарт-карты выполняет следующие действия:

   1. Получает сведения об учетных данных (список известных учетных данных или, если учетные данные отсутствуют, сведения о средстве чтения смарт-карт, обнаруженных Windows)
   2. Возвращает список устройств чтения смарт-карт (с помощью API WinSCard) и список смарт-карт, вставленных в каждую из них.
   3. Перечисляет каждую карточку, чтобы убедиться в наличии сертификата входа, управляемого групповой политикой. Если сертификат присутствует, поставщик учетных данных смарт-карты копирует его во временный защищенный кэш на компьютере или в терминале.

   Примечание.

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

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

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

4. Пользователь вводит ПИН-код и нажимает клавишу ВВОД. Поставщик учетных данных смарт-карты шифрует ПИН-код

5. Поставщик учетных данных, который находится в системе LogonUI, собирает ПИН-код. В рамках упаковки учетных данных в поставщике учетных данных смарт-карты данные упаковывается в структуру KERB_CERTIFICATE_LOGON. Основное содержимое структуры KERB_CERTIFICATE_LOGON — ЭТО ПИН-код смарт-карты, данные CSP (например, имя читателя и имя контейнера), имя пользователя и доменное имя. Имя пользователя является обязательным, если домен входа находится не в одном лесу, так как он позволяет сопоставить сертификат с несколькими учетными записями пользователей.

6. Поставщик учетных данных заключает данные (например, зашифрованный ПИН-код, имя контейнера, имя средства чтения и спецификацию ключа карточки) и отправляет их обратно в LogonUI.

7. Winlogon представляет данные из LogonUI в LSA с информацией о пользователе в LSALogonUser

8. LSA вызывает пакет проверки подлинности Kerberos (Kerberos SSP) для создания запроса службы проверки подлинности Kerberos (KRB_AS_REQ), который содержит предварительное средство проверки подлинности (как указано в RFC 4556: шифрование с открытым ключом для начальной проверки подлинности в Kerberos (PKINIT)).

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

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

9. Для цифровой подписи запроса (в соответствии с RFC 4556) выполняется вызов соответствующего CSP для операции с закрытым ключом. Так как закрытый ключ в этом случае хранится на смарт-карте, вызывается подсистема смарт-карты и выполняется необходимая операция. Результат отправляется обратно поставщику поддержки безопасности Kerberos (SSP).

10. Поставщик служб SSP Kerberos отправляет запрос на проверку подлинности для билета предоставления билета (TGT) (в соответствии с RFC 4556) в службу Центра распространения ключей (KDC), которая выполняется на контроллере домена.

11. KDC находит объект учетной записи пользователя в доменных службах Active Directory (AD DS), как описано в разделе Требования к сертификатам клиента и сопоставления, и использует сертификат пользователя для проверки подписи.

12. KDC проверяет сертификат пользователя (время, путь и состояние отзыва), чтобы убедиться, что сертификат получен из доверенного источника. KDC использует CryptoAPI для создания пути сертификации от сертификата пользователя к сертификату корневого центра сертификации (ЦС), который находится в корневом хранилище на контроллере домена. Затем KDC использует CryptoAPI для проверки цифровой подписи на подписанном аутентификаторе, который был включен в поля данных предварительной проверки подлинности. Контроллер домена проверяет подпись и использует открытый ключ из сертификата пользователя, чтобы доказать, что запрос был получен от владельца закрытого ключа, соответствующего открытому ключу. KDC также проверяет, является ли издатель доверенным и отображается в хранилище сертификатов NTAUTH.

13. Служба KDC получает сведения об учетной записи пользователя из AD DS. KDC создает TGT, который основан на сведениях об учетной записи пользователя, которые он получает из AD DS. Поля данных авторизации TGT включают идентификатор безопасности пользователя (SID), идентификаторы безопасности для универсальных и глобальных групп доменов, к которым принадлежит пользователь, и (в среде с несколькими доменами) идентификаторы безопасности для любых универсальных групп, членом которых является пользователь.

14. Контроллер домена возвращает TGT клиенту в рамках ответа KRB_AS_REP.

    Примечание.

    Пакет KRB_AS_REP состоит из следующих элементов:

    • Сертификат атрибута привилегий (PAC)
    • Идентификатор безопасности пользователя
    • Идентификаторы безопасности любых групп, членом которых является пользователь
    • Запрос на службу предоставления билетов (TGS)
    • Данные предварительной проверки подлинности

    TGT шифруется с помощью главного ключа центра управления ключом, а ключ сеанса шифруется временным ключом. Этот временный ключ основан на RFC 4556. С помощью CryptoAPI расшифровывается временный ключ. В процессе расшифровки, если закрытый ключ находится на смарт-карте, вызов подсистемы смарт-карт выполняется с помощью указанного поставщика служб CSP для извлечения сертификата, соответствующего открытому ключу пользователя. (Программные вызовы для сертификата включают CryptAcquireContext, CryptSetProvParam с ПИН-кодом, CryptgetUserKey и CryptGetKeyParam.) После получения временного ключа поставщик служб SSP Kerberos расшифровывает ключ сеанса.

15. Клиент проверяет ответ из KDC (время, путь и состояние отзыва). Сначала он проверяет подпись KDC путем создания пути сертификации из сертификата KDC в доверенный корневой ЦС, а затем использует открытый ключ KDC для проверки подписи ответа.

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

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

18. После загрузки профиля пользователя служба распространения сертификации (CertPropSvc) обнаруживает это событие, считывает сертификаты со смарт-карты (включая корневые сертификаты), а затем заполняет их в хранилище сертификатов пользователя (MYSTORE).

19. Связь CSP с диспетчером ресурсов смарт-карт происходит по каналу LRPC.

20. При успешной проверке подлинности сертификаты передаются в хранилище пользователя асинхронно службой распространения сертификатов (CertPropSvc).

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

Примечание.

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

Дополнительные сведения о протоколе Kerberos см. в статье Microsoft Kerberos.

По умолчанию KDC проверяет, содержит ли сертификат клиента EKU проверки подлинности клиента смарт-карты szOID_KP_SMARTCARD_LOGON. Однако если этот параметр включен, параметр групповой политики Разрешить сертификаты без атрибута сертификата расширенного использования ключа позволяет KDC не требовать sc-LOGON EKU. SC-LOGON EKU не требуется для сопоставлений учетных записей, основанных на открытом ключе.

Сертификат KDC

Службы сертификатов Active Directory предоставляют три типа шаблонов сертификатов:

• Контроллер домена
• Проверка подлинности контроллера домена
• Проверка подлинности Kerberos

В зависимости от конфигурации контроллера домена один из этих типов сертификатов отправляется в составе пакета AS_REP.

Требования к сертификатам клиента и сопоставления

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

Требования к сертификатам

Компонент	Требования
Расположение точки распространения списка отзыва сертификатов	Не требуется
Использование ключей	Цифровая подпись
Основные ограничения	Не требуется
расширенное использование ключа (EKU)	Идентификатор объекта для входа со смарт-картой не требуется. Заметка Если EKU присутствует, он должен содержать EKU для входа со смарт-картой. Для входа можно использовать сертификаты без EKU.
Альтернативное имя субъекта	Идентификатор электронной почты не требуется для входа с помощью смарт-карты.
Субъект	Не требуется
Обмен ключами (поле AT_KEYEXCHANGE)	Не требуется для сертификатов входа со смарт-картой, если включен параметр групповой политики. (По умолчанию параметры групповой политики не включены.)
Список отзыва сертификатов	Не требуется
Имя участника-пользователя	Не требуется
Примечания	Вы можете включить любой сертификат, чтобы он был видимым для поставщика учетных данных смарт-карты.

Сопоставления сертификатов клиента

Сопоставление сертификатов основано на имени участника-пользователя, которое содержится в поле subjectAltName (SAN) сертификата. Также поддерживаются сертификаты клиента, которые не содержат сведения в поле SAN.

SSL/TLS может сопоставлять сертификаты, не имеющие san, и сопоставление выполняется с помощью атрибутов AltSecID в учетных записях клиентов. AltSecID X509, используемый для проверки подлинности клиента SSL/TLS, имеет форму "X509: <Issuer Name><Subject Name. И <Issuer Name><Subject Name> берутся из сертификата клиента, с "\r" и "\n" заменены на ",".

Точки распространения списка отзыва сертификатов

Имя участника-пользователя в поле "Альтернативное имя субъекта"

Поля "Тема" и "Издатель"

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

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

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

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

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

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

Логика обработки сертификатов

NT_AUTH политику лучше всего описать в разделе параметра CERT_CHAIN_POLICY_NT_AUTH функции CertVerifyCertificateChainPolicy. Дополнительные сведения см. в разделе CertVerifyCertificateChainPolicy.

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

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

Примечание.

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

На основе сведений, доступных в сертификате, условия входа:

1. Если в сертификате нет имени участника-пользователя:
   1. Вход может происходить в локальном лесу или в другом лесу, если один пользователь с одним сертификатом должен войти в разные учетные записи.
   2. Указание должно быть указано, если сопоставление не является уникальным (например, если несколько пользователей сопоставлены с тем же сертификатом).
2. Если имя участника-пользователя присутствует в сертификате:
   1. Сертификат не может быть сопоставлен с несколькими пользователями в одном лесу
   2. Сертификат можно сопоставить с несколькими пользователями в разных лесах. Для входа пользователя в другие леса пользователю необходимо предоставить указание X509.

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

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

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

Например, если certificate1 имеет CN=CNName1, Certificate2 — CN=User1, а Certificate3 — CN=User2, altSecID этих сертификатов можно сопоставить с одной учетной записью с помощью сопоставления имен пользователей и компьютеров Active Directory.

Вход со смарт-картой в лесах

Чтобы сопоставление учетных записей работало в лесах, особенно в тех случаях, когда в сертификате недостаточно сведений, пользователь может ввести подсказку в виде имени пользователя, например домен\пользователь, или полного имени участника-пользователя, например user@contoso.com.

Примечание.

Чтобы поле подсказки отображалось во время входа с помощью смарт-карты, на клиенте должен быть включен параметр групповой политики "Разрешить указание имени пользователя " (раздел реестра X509HintsNeeded ).

Поддержка OCSP для PKINIT

Протокол OCSP, определенный в RFC 2560, позволяет приложениям своевременно получать сведения о состоянии отзыва сертификата. Так как ответы OCSP невелики и хорошо привязаны, ограниченные клиенты могут использовать OCSP для проверки допустимости сертификатов Для Kerberos в KDC, чтобы избежать передачи больших списков отзыва сертификатов и сэкономить пропускную способность в ограниченных сетях. Сведения о разделах реестра списка отзыва сертификатов см. в разделе Параметры групповой политики и реестра смарт-карт.

KDC в Windows пытаются получить ответы OCSP и использовать их, когда они доступны. Это поведение нельзя отключить. CryptoAPI для OCSP кэширует ответы OCSP и состояние ответов. KDC поддерживает только ответы OCSP для сертификата подписывателя.

Клиентские компьютеры Windows пытаются запросить ответы OCSP и использовать их в ответе, когда они доступны. Это поведение нельзя отключить.

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

Чтобы вход работал в домене на основе смарт-карт, сертификат смарт-карты должен соответствовать следующим условиям:

• Корневой сертификат KDC на смарт-карте должен иметь точку распространения HTTP CRL, указанную в сертификате.
• В сертификате для входа со смарт-картой должна быть указана точка распространения HTTP CRL.
• Точка распространения CRL должна иметь допустимый опубликованный список отзыва сертификатов и разностный список отзыва сертификатов (если применимо), даже если точка распространения списка отзыва сертификатов пуста.
• Сертификат смарт-карты должен содержать одно из следующих компонентов:
  • Поле темы, содержащее доменное имя DNS в различающееся имя. Если это не так, разрешение в соответствующий домен завершается ошибкой, поэтому службы удаленных рабочих столов и вход в домен с помощью смарт-карты завершаются ошибкой.
  • Имя участника-пользователя, в котором доменное имя разрешается в фактический домен. Например, если доменное имя — Engineering.Corp.Contoso, имя участника-пользователя — username@engineering.corp.contoso.com. Если какая-либо часть доменного имени опущена, клиент Kerberos не сможет найти соответствующий домен.

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

1. Включение точек распространения http CRL в ЦС
2. Перезапуск ЦС
3. Перевыпуск сертификата KDC
4. Выдача или повторная выдача сертификата для входа со смарт-картой
5. Распространение обновленного корневого сертификата на смарт-карту, которую вы хотите использовать для входа в домен.

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

Если клиентский компьютер не присоединен к домену или присоединен к другому домену, клиентский компьютер может разрешить домен сервера только путем просмотра различающегося имени в сертификате, а не имени участника-пользователя. Чтобы этот сценарий работал, сертификату требуется полный субъект, включая DC=<DomainControllerName>, для разрешения доменного имени.

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

certutil.exe -scroots update

Дополнительные сведения об этом параметре для программы командной строки см. в разделе -SCRoots.