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

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

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

Примечание.

Если не указано иное, все операции выполняются автоматически (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. Main содержимое структуры 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 шифруется с помощью ключа master KDC, а ключ сеанса шифруется временным ключом. Этот временный ключ основан на 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 и интеллектуальными карта resource manager осуществляется через канал 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) Не требуется для интеллектуальных сертификатов входа карта, если включен параметр групповая политика. (По умолчанию параметры групповая политика не включены.)
CRL Не требуется
UPN Не требуется
Примечания Вы можете включить любой сертификат, чтобы он был видимым для поставщика учетных данных интеллектуальной карта.

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

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

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

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

  • Корневой сертификат 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.