Пользовательский интерфейс входа запрашивает новые учетные данные у поставщика учетных данных смарт-карт. The sign-in UI requests the new credentials from the smart card credential provider. В ответ поставщик учетных данных смарт-карты предоставляет каждому входу сертификат пользовательского интерфейса входа, и отображаются соответствующие плитки входа. As a response, the smart card credential provider provides each sign-in certificate to the sign-in UI, and corresponding sign-in tiles are displayed. Пользователь выбирает плитку сертификата на основе смарт-карт, а в Windows отображается диалоговое окно PIN-кода. The user selects a smart card-based sign-in certificate tile, and Windows displays a PIN dialog box.

Пользователь вводит ПИН-код, а затем нажимает ВВОД. The user enters the PIN, and then presses ENTER. Поставщик учетных данных смарт-карт шифрует ПИН-код. The smart card credential provider encrypts the PIN.

Поставщик учетных данных, который находится в системе LogonUI, собирает ПИН-код. The credential provider that resides in the LogonUI system collects the PIN. В рамках упаковки учетных данных в поставщике учетных данных смарт-карт данные упаковываются в структуру KERB_CERTIFICATE_LOGON. As part of packaging credentials in the smart card credential provider, the data is packaged in a KERB_CERTIFICATE_LOGON structure. Основным содержимым структуры KERB_CERTIFICATE_LOGON являются ПИН-код смарт-карты, CSP-данные (например, имя читателя и имя контейнера), имя пользователя и доменное имя. The main contents of the KERB_CERTIFICATE_LOGON structure are the smart card PIN, CSP data (such as reader name and container name), user name, and domain name. Имя пользователя необходимо, если домен входной записи находится не в одном лесу, так как позволяет соотнося сертификат с несколькими учетными записями пользователей. User name is required if the sign-in domain is not in the same forest because it enables a certificate to be mapped to multiple user accounts.

Поставщик учетных данных заворачивает данные (например, зашифрованный ПИН-код, имя контейнера, имя читателя и спецификацию ключа карты) и отправляет их обратно в LogonUI. The credential provider wraps the data (such as the encrypted PIN, container name, reader name, and card key specification) and sends it back to LogonUI.

Winlogon представляет данные из LogonUI в LSA с данными пользователей в LSALogonUser. Winlogon presents the data from LogonUI to the LSA with the user information in LSALogonUser.

LSA вызывает пакет проверки подлинности Kerberos (Kerberos SSP) для создания запроса службы проверки подлинности Kerberos (KRB_AS_REQ), содержащего предавентикатор (как указано в RFC 4556: шифрование общедоступных ключей для начальной проверки подлинности в Kerberos (PKINIT)). LSA calls the Kerberos authentication package (Kerberos SSP) to create a Kerberos authentication service request (KRB_AS_REQ), which containing a preauthenticator (as specified in RFC 4556: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)).

Если проверка подлинности выполняется с помощью сертификата, использующего цифровую подпись, данные предварительной проверки состоят из открытого сертификата пользователя и сертификата, подписанного цифровой подписью с соответствующим закрытым ключом. If the authentication is performed by using a certificate that uses a digital signature, the preauthentication data consists of the user’s public certificate and the certificate that is digitally signed with the corresponding private key.
Если проверка подлинности выполняется с помощью сертификата, использующего шифрование ключей, данные предварительной проверки состоят из открытого сертификата пользователя и сертификата, шифруемого с помощью соответствующего закрытого ключа. If the authentication is performed by using a certificate that uses key encipherment, the preauthentication data consists of the user’s public certificate and the certificate that is encrypted with the corresponding private key.

Чтобы подписать запрос в цифровом формате (по RFC 4556), в соответствующий CSP для операции частного ключа будет выполнен вызов. To sign the request digitally (as per RFC 4556), a call is made to the corresponding CSP for a private key operation. Так как частный ключ в этом случае хранится в смарт-карте, подсистема смарт-карт называется, и необходимая операция завершена. Because the private key in this case is stored in a smart card, the smart card subsystem is called, and the necessary operation is completed. Результат отправляется обратно поставщику поддержки безопасности Kerberos (SSP). The result is sent back to the Kerberos security support provider (SSP).

Служба SSP Kerberos отправляет запрос на проверку подлинности для билета-билета (TGT) (за RFC 4556) в службу Key Distribution Center (KDC), которая работает на контроллере домена. The Kerberos SSP sends an authentication request for a ticket-granting-ticket (TGT) (per RFC 4556) to the Key Distribution Center (KDC) service that runs on a domain controller.

KDC находит объект учетной записи пользователя в Службе домена Active Directory (AD DS), как описано в требованиях и сопоставлениях сертификата клиента,и использует сертификат пользователя для проверки подписи. The KDC finds the user’s account object in Active Directory Domain Services (AD DS), as detailed in Client certificate requirements and mappings, and uses the user’s certificate to verify the signature.

KDC проверяет сертификат пользователя (время, путь и состояние отзыва), чтобы убедиться, что сертификат из надежного источника. The KDC validates the user’s certificate (time, path, and revocation status) to ensure that the certificate is from a trusted source. KDC использует CryptoAPI для построения пути сертификации от сертификата пользователя до сертификата корневого органа сертификации (CA), который находится в корневом хранилище на контроллере домена. The KDC uses CryptoAPI to build a certification path from the user’s certificate to a root certification authority (CA) certificate that resides in the root store on the domain controller. Затем KDC использует CryptoAPI для проверки цифровой подписи на подписанной проверке подлинности, которая была включена в поля данных предварительной проверки. The KDC then uses CryptoAPI to verify the digital signature on the signed authenticator that was included in the preauthentication data fields. Контроллер домена проверяет подпись и использует общедоступный ключ из сертификата пользователя, чтобы доказать, что запрос исходил от владельца закрытого ключа, соответствующего общественному ключу. The domain controller verifies the signature and uses the public key from the user’s certificate to prove that the request originated from the owner of the private key that corresponds to the public key. Кроме того, KDC проверяет доверие эмитента и появляется в хранилище сертификатов NTAUTH. The KDC also verifies that the issuer is trusted and appears in the NTAUTH certificate store.

Служба KDC извлекает сведения об учетных записях пользователей из AD DS. The KDC service retrieves user account information from AD DS. KDC строит TGT, основанный на данных учетных записей пользователей, полученных из AD DS. The KDC constructs a TGT, which is based on the user account information that it retrieves from AD DS. Поля данных авторизации TGT включают идентификатор безопасности пользователя (SID), siD-коды для универсальных и глобальных доменных групп, к которым принадлежит пользователь, и (в многодомной среде) siD для всех универсальных групп, членом которых является пользователь. The TGT’s authorization data fields include the user’s security identifier (SID), the SIDs for universal and global domain groups to which the user belongs, and (in a multidomain environment) the SIDs for any universal groups of which the user is a member.

Контроллер домена возвращает TGT клиенту в рамках ответа KRB_AS_REP. The domain controller returns the TGT to the client as part of the KRB_AS_REP response.

**** Примечание Пакет KRB_AS_REP состоит из: Note The KRB_AS_REP packet consists of:

• Сертификат атрибута привилегий (PAC) Privilege attribute certificate (PAC)
• SID пользователя User’s SID
• SID-данные всех групп, членом которых является пользователь SIDs of any groups of which the user is a member
• Запрос на службу предоставления билетов (TGS) A request for ticket-granting service (TGS)
• Данные предварительной оценки Preauthentication data

TGT шифруется главным ключом KDC, а ключ сеанса шифруется временным ключом. TGT is encrypted with the master key of the KDC, and the session key is encrypted with a temporary key. Этот временный ключ получен на основе RFC 4556. This temporary key is derived based on RFC 4556. С помощью CryptoAPI временный ключ расшифровываются. Using CryptoAPI, the temporary key is decrypted. В рамках процесса расшифровки, если частный ключ находится на смарт-карте, в подсистему смарт-карты делается вызов с помощью указанного CSP для извлечения сертификата, соответствующего общественному ключу пользователя. As part of the decryption process, if the private key is on a smart card, a call is made to the smart card subsystem by using the specified CSP to extract the certificate corresponding to the user’s public key. (Программные вызовы сертификата включают CryptAcquireContext, CryptSetProvParam с ПИН-кодом, CryptgetUserKey и CryptGetKeyParam.) После того, как временный ключ будет получен, SSP Kerberos расшифровка ключа сеанса. (Programmatic calls for the certificate include CryptAcquireContext, CryptSetProvParam with the PIN, CryptgetUserKey, and CryptGetKeyParam.) After the temporary key is obtained, the Kerberos SSP decrypts the session key.

Клиент проверяет ответ из состояния KDC (время, путь и отзыв). The client validates the reply from the KDC (time, path, and revocation status). Сначала он проверяет подпись KDC путем строительства пути сертификации от сертификата KDC до доверенного корневого центра, а затем использует общедоступный ключ KDC для проверки подписи ответа. It first verifies the KDC’s signature by the construction of a certification path from the KDC’s certificate to a trusted root CA, and then it uses the KDC’s public key to verify the reply signature.

После получения TGT клиент получает талон службы, который используется для регистрации на локальном компьютере. Now that a TGT has been obtained, the client obtains a service ticket, which is used to sign in to the local computer.

С успехом LSA сохраняет билеты и возвращает сообщение об успехе в LSALogonUser. With success, LSA stores the tickets and returns a success message to LSALogonUser. После выпуска этого сообщения об успехе выбирается и задан профиль пользователя для устройства, выполняется мгновенное обновление групповой политики и выполняются другие действия. After this success message is issued, user profile for the device is selected and set, Group Policy refresh is instantiated, and other actions are performed.

После загрузки профиля пользователя служба распространения сертификации (CertPropSvc) обнаруживает это событие, считывает сертификаты с смарт-карты (включая корневые сертификаты), а затем заполняет их в хранилище сертификатов пользователя (MYSTORE). After the user profile is loaded, the Certification Propagation Service (CertPropSvc) detects this event, reads the certificates from the smart card (including the root certificates), and then populates them into the user’s certificate store (MYSTORE).

Связь CSP с диспетчером ресурсов смарт-карт происходит на канале LRPC. CSP to smart card resource manager communication happens on the LRPC Channel.

При успешной проверке подлинности сертификаты распространяются в хранилище пользователя асинхронно службой распространения сертификатов (CertPropSvc). On successful authentication, certificates are propagated to the user’s store asynchronously by the Certificate Propagation Service (CertPropSvc).

При удалении карты удаляются сертификаты в хранилище временного безопасного кэша. When the card is removed, certificates in the temporary secure cache store are removed. Сертификаты больше не доступны для регистрации, но они остаются в хранилище сертификатов пользователя. The Certificates are no longer available for sign-in, but they remain in the user’s certificate store.

**** Примечание Sid создается для каждого пользователя или группы в момент создания учетной записи пользователя или учетной записи группы в локальной базе данных учетных записей безопасности или в AD DS. Note A SID is created for each user or group at the time a user account or a group account is created within the local security accounts database or within AD DS. Sid никогда не изменяется, даже если пользователь или учетная запись группы переименована. The SID never changes, even if the user or group account is renamed.

Дополнительные сведения о протоколе Kerberos см. в сайте Microsoft Kerberos. For more information about the Kerberos protocol, see Microsoft Kerberos.

По умолчанию KDC проверяет, что сертификат клиента содержит проверку подлинности клиента смарт-карты EKU szOID_KP_SMARTCARD_LOGON. By default, the KDC verifies that the client’s certificate contains the smart card client authentication EKU szOID_KP_SMARTCARD_LOGON. Однако, если включено, сертификаты Allow без атрибута атрибута групповой политики сертификата расширенного ключевого использования позволяют KDC не требовать EKU SC-LOGON. However, if enabled, the Allow certificates with no extended key usage certificate attribute Group Policy setting allows the KDC to not require the SC-LOGON EKU. SC-LOGON EKU не требуется для сопоставлений учетных записей, основанных на общедоступных ключах. SC-LOGON EKU is not required for account mappings that are based on the public key.

Сертификат KDC KDC certificate

Службы сертификатов Active Directory предоставляют три типа шаблонов сертификатов: Active Directory Certificate Services provides three kinds of certificate templates:

Контроллер домена Domain controller

Проверка подлинности контроллера домена Domain controller authentication

Проверка подлинности Kerberos Kerberos authentication

В зависимости от конфигурации контроллера домена один из этих типов сертификатов отправляется в составе пакета AS_REP. Depending on the configuration of the domain controller, one of these types of certificates is sent as a part of the AS_REP packet.

Требования и сопоставления сертификатов клиентов Client certificate requirements and mappings

Требования к сертификатам перечислены в версиях операционной системы Windows. Certificate requirements are listed by versions of the Windows operating system. Сопоставление сертификатов описывает сопоставление сведений из сертификата с учетной записью пользователя. Certificate mapping describes how information from the certificate is mapped to the user account.

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

Сертификат смарт-карты имеет определенные требования к формату при его работе с Windows XP и более ранними операционными системами. The smart card certificate has specific format requirements when it is used with Windows XP and earlier operating systems. Вы можете включить любой сертификат, который будет виден поставщику учетных данных смарт-карт. You can enable any certificate to be visible for the smart card credential provider.

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

Сопоставление сертификатов основано на поле UPN, которое содержится в поле subjectAltName (SAN) сертификата. Certificate mapping is based on the UPN that is contained in the subjectAltName (SAN) field of the certificate. Кроме того, поддерживаются клиентские сертификаты, не содержащие сведений в поле SAN. Client certificates that do not contain information in the SAN field are also supported.

SSL/TLS может сопоставление сертификатов, не использующих SAN, и сопоставление делается с помощью атрибутов AltSecID на клиентских учетных записях. SSL/TLS can map certificates that do not have SAN, and the mapping is done by using the AltSecID attributes on client accounts. X509 AltSecID, который используется для проверки подлинности клиента SSL/TLS, имеет форму «X509: * Имя*эмитента » * *. The X509 AltSecID, which is used by SSL/TLS client authentication is of the form «X509: » » » . Имя * имя* * * субъекта эмитента взяты из клиентского сертификата, а «\r» и «\n» заменены на «,». The and are taken from the client certificate, with ‘\r’ and ‘\n’ replaced with ‘,’.

Точки рассылки списков отзыва сертификатов Certificate revocation list distribution points

UPN в поле Альтернативное имя субъекта UPN in Subject Alternative Name field

Поля Subject и Issuer Subject and Issuer fields

Это сопоставление учетных записей поддерживается KDC в дополнение к шести другим методам сопоставления. This account mapping is supported by the KDC in addition to six other mapping methods. На следующем рисунке демонстрируется поток логики сопоставления учетных записей пользователей, используемый KDC. The following figure demonstrates a flow of user account mapping logic that is used by the KDC.

Высокоуровневый поток обработки сертификатов для регистрации High-level flow of certificate processing for sign-in

Объект сертификата выполняет анализ содержимого для выполнения сопоставления учетных записей пользователей. The certificate object is parsed to look for content to perform user account mapping.

Когда имя пользователя предоставляется сертификатом, имя пользователя используется для поиска объекта учетной записи. When a user name is provided with the certificate, the user name is used to locate the account object. Эта операция является самой быстрой, так как происходит соответствие строкам. This operation is the fastest, because string matching occurs.

Когда предоставляется только объект сертификата, выполняется серия операций, чтобы найти имя пользователя, чтобы соотоставить имя пользователя с объектом учетной записи. When only the certificate object is provided, a series of operations are performed to locate the user name to map the user name to an account object.

Если для проверки подлинности нет сведений о домене, локальный домен используется по умолчанию. When no domain information is available for authentication, the local domain is used by default. Если какой-либо другой домен будет использоваться для lookup, для выполнения сопоставления и привязки должен быть предоставлен подсказка доменного имени. If any other domain is to be used for lookup, a domain name hint should be provided to perform the mapping and binding.

Сопоставление на основе общих атрибутов невозможно, так как нет универсального API для получения атрибутов из сертификата. Mapping based on generic attributes is not possible because there is no generic API to retrieve attributes from a certificate. В настоящее время первый метод, который находит учетную запись, успешно останавливает поиск. Currently, the first method that locates an account successfully stops the search. Но ошибка конфигурации возникает, если два метода соотносят один и тот же сертификат с разными учетными записьми пользователей, когда клиент не сообщает имя клиента через подсказки сопоставления. But a configuration error occurs if two methods map the same certificate to different user accounts when the client does not supply the client name through the mapping hints.

На следующем рисунке иллюстрируется процесс сопоставления учетных записей пользователей для входов в каталог, просматривая различные записи в сертификате. The following figure illustrates the process of mapping user accounts for sign-in in the directory by viewing various entries in the certificate.

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

Политика NT_AUTH лучше всего описана в разделе CERT_CHAIN_POLICY_NT_AUTH параметра функции CertVerifyCertificateChainPolicy. NT_AUTH policy is best described in the CERT_CHAIN_POLICY_NT_AUTH parameter section of the CertVerifyCertificateChainPolicy function. Дополнительные сведения см. в дополнительных сведениях в certVerifyCertificateChainPolicy. For more information, see CertVerifyCertificateChainPolicy.

Вход смарт-карты для одного пользователя с одним сертификатом на несколько учетных записей Smart card sign-in for a single user with one certificate into multiple accounts

Один сертификат пользователя можно соотнося с несколькими учетной записью. A single user certificate can be mapped to multiple accounts. Например, пользователь может войти в учетную запись пользователя, а также войти в качестве администратора домена. For example, a user might be able to sign in to a user account and also to sign in as a domain administrator. Сопоставление делается с помощью построенного AltSecID на основе атрибутов из клиентских учетных записей. The mapping is done by using the constructed AltSecID based on attributes from client accounts. Сведения о том, как оценивается это сопоставление, см. в справке о требованиях к сертификатам клиента и сопоставлениях. For information about how this mapping is evaluated, see Client certificate requirements and mappings.

**** Примечание Поскольку каждая учетная запись имеет свое имя **** пользователя, рекомендуется включить параметр Групповой политики намека на имя пользователя (ключ реестра X509HintsNeeded), чтобы предоставить необязательные поля, позволяющие пользователям вводить имена пользователей и сведения о домене для входа. Note Because each account has a different user name, we recommend that you enable the Allow user name hint Group Policy setting (X509HintsNeeded registry key) to provide the optional fields that allow users to enter their user names and domain information to sign in.

На основе сведений, доступных в сертификате, условия регистрации: Based on the information that is available in the certificate, the sign-in conditions are:

Если в сертификате нет upN: If no UPN is present in the certificate:

Вход может происходить в локальном лесу или в другом лесу, если одному пользователю с одним сертификатом необходимо войти в различные учетные записи. Sign-in can occur in the local forest or in another forest if a single user with one certificate needs to sign in to different accounts.

Подсказка должна быть предоставлена, если сопоставление не является уникальным (например, если несколько пользователей сопоставлены с одним и тем же сертификатом). A hint must be supplied if mapping is not unique (for example, if multiple users are mapped to the same certificate).

Если в сертификате присутствует upN: If a UPN is present in the certificate:

Сертификат не может быть соедан нескольким пользователям в одном лесу. The certificate cannot be mapped to multiple users in the same forest.

Сертификат может быть соедан нескольким пользователям в разных лесах. The certificate can be mapped to multiple users in different forests. Чтобы пользователь въехал в другие леса, пользователю должен быть предоставлен подсказка X509. For a user to sign in to other forests, an X509 hint must be supplied to the user.

Вход смарт-карты для нескольких пользователей в одну учетную запись Smart card sign-in for multiple users into a single account

Группа пользователей может войти в одну учетную запись (например, учетную запись администратора). A group of users might sign in to a single account (for example, an administrator account). Для этой учетной записи сертификаты пользователей соотносят так, чтобы они были включены для входа. For that account, user certificates are mapped so that they are enabled for sign-in.

Несколько различных сертификатов можно соотносять с одной учетной записью. Several distinct certificates can be mapped to a single account. Чтобы это работало должным образом, сертификат не может иметь upNs. For this to work properly, the certificate cannot have UPNs.

Например, если в Certificate1 есть CN=CNName1, у Certificate2 есть CN=User1, а у Certificate3 есть CN=User2, AltSecID этих сертификатов можно сопоставлено с одной учетной записью с помощью сопоставления имен Пользователей и компьютеров Active Directory. For example, if Certificate1 has CN=CNName1, Certificate2 has CN=User1, and Certificate3 has CN=User2, the AltSecID of these certificates can be mapped to a single account by using the Active Directory Users and Computers name mapping.

Вход смарт-карты в лесах Smart card sign-in across forests

Чтобы сопоставление учетных записей работало в лесах, особенно в тех случаях, когда в сертификате недостаточно сведений, пользователь может ввести подсказку в виде имени пользователя, например домена\пользователя, или полностью квалифицированного upN, например user@contoso.com . For account mapping to work across forests, particularly in cases where there is not enough information available on the certificate, the user might enter a hint in the form of a user name, such as domain\user, or a fully qualified UPN such as user@contoso.com.

**** Примечание Чтобы поле подсказки появлялось во время **** входа в смарт-карточку, необходимо включить в клиенте параметр Разрешить параметр групповой политики подсказки пользователя (ключ реестра X509HintsNeeded). Note For the hint field to appear during smart card sign-in, the Allow user name hint Group Policy setting (X509HintsNeeded registry key) must be enabled on the client.

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

Протокол состояния сертификата в Интернете (OCSP), определенный в RFC 2560, позволяет приложениям получать сведения о состоянии отзыва сертификата вовремя. Online Certificate Status Protocol (OCSP), which is defined in RFC 2560, enables applications to obtain timely information about the revocation status of a certificate. Так как ответы OCSP являются небольшими и хорошо связанными, ограниченные клиенты могут использовать OCSP для проверки действительности сертификатов kerberos на KDC, чтобы избежать передачи больших crLs и сохранить пропускную способность в ограниченных сетях. Because OCSP responses are small and well bound, constrained clients might want to use OCSP to check the validity of the certificates for Kerberos on the KDC, to avoid transmission of large CRLs, and to save bandwidth on constrained networks. Сведения о ключах реестра CRL см. в группе smart Card Policy and Registry Settings. For information about CRL registry keys, see Smart Card Group Policy and Registry Settings.

KDCs в Windows пытаются получить ответы OCSP и использовать их при наличии. The KDCs in Windows attempt to get OCSP responses and use them when available. Это поведение нельзя отключить. This behavior cannot be disabled. CryptoAPI для кэшей OCSP ответов OCSP и состояния ответов. CryptoAPI for OCSP caches OCSP responses and the status of the responses. KDC поддерживает только ответы OCSP для сертификата подписавщика. The KDC supports only OCSP responses for the signer certificate.

Клиентские компьютеры Windows пытаются запрашивать ответы OCSP и использовать их в ответе, когда они доступны. Windows client computers attempt to request the OCSP responses and use them in the reply when they are available. Это поведение нельзя отключить. This behavior cannot be disabled.

Требования к корневому сертификату смарт-карты для использования при входе в домен Smart card root certificate requirements for use with domain sign-in

Чтобы войти в домен на основе смарт-карт, сертификат смарт-карты должен соответствовать следующим условиям: For sign-in to work in a smart card-based domain, the smart card certificate must meet the following conditions:

Корневой сертификат KDC на смарт-карте должен иметь пункт рассылки HTTP CRL, указанный в сертификате. The KDC root certificate on the smart card must have an HTTP CRL distribution point listed in its certificate.

Сертификат регистрации смарт-карты должен иметь точку распространения HTTP CRL, указанную в сертификате. The smart card sign-in certificate must have the HTTP CRL distribution point listed in its certificate.

Точка распространения CRL должна иметь допустимый crL опубликованный и дельта CRL, если применимо, даже если точка распространения CRL пуста. The CRL distribution point must have a valid CRL published and a delta CRL, if applicable, even if the CRL distribution point is empty.

Сертификат смарт-карты должен содержать один из следующих: The smart card certificate must contain one of the following:

Поле субъекта, содержаще доменное имя DNS в имени. A subject field that contains the DNS domain name in the distinguished name. Если этого не происходит, разрешение соответствующего домена не удается, поэтому удаленные службы настольных компьютеров и вход домена с помощью смарт-карты не удается. If it does not, resolution to an appropriate domain fails, so Remote Desktop Services and the domain sign-in with the smart card fail.

UpN, в котором доменное имя решается на фактический домен. A UPN where the domain name resolves to the actual domain. Например, если доменное имя — Engineering.Corp.Contoso, upN username@engineering.corp.contoso.com. For example, if the domain name is Engineering.Corp.Contoso, the UPN is username@engineering.corp.contoso.com. Если какой-либо части доменного имени не будет опущен, клиент Kerberos не сможет найти соответствующий домен. If any part of the domain name is omitted, the Kerberos client cannot find the appropriate domain.

Хотя точки распространения HTTP CRL по умолчанию включены в Windows Server 2008, последующие версии операционной системы Windows Server не включают точки распространения HTTP CRL. Although the HTTP CRL distribution points are on by default in Windows Server 2008, subsequent versions of the Windows Server operating system do not include HTTP CRL distribution points. Чтобы разрешить вход смарт-карты в домен в этих версиях, сделайте следующее: To allow smart card sign-in to a domain in these versions, do the following:

Включить точки распространения HTTP CRL в ЦС. Enable HTTP CRL distribution points on the CA.

Перезапустите ЦС. Restart the CA.

Переоценка сертификата KDC. Reissue the KDC certificate.

Выпуск или переоценка сертификата регистрации смарт-карты. Issue or reissue the smart card sign-in certificate.

Распространение обновленного корневого сертификата на смарт-карту, которую необходимо использовать для регистрации домена. Propagate the updated root certificate to the smart card that you want to use for the domain sign-in.

Обходной путь — включить **** параметр Групповой политики подсказки пользователя (ключ реестра X509HintsNeeded), который позволяет пользователю предоставить подсказку в пользовательском интерфейсе учетных данных для входа в домен. The workaround is to enable the Allow user name hint Group Policy setting (X509HintsNeeded registry key), which allows the user to supply a hint in the credentials user interface for domain sign-in.

Если клиентский компьютер не присоединяется к домену или присоединяется к другому домену, клиентский компьютер может разрешить домен сервера, только глядя на отличительное имя в сертификате, а не на upN. If the client computer is not joined to the domain or if it is joined to a different domain, the client computer can resolve the server domain only by looking at the distinguished name on the certificate, not the UPN. Чтобы этот сценарий работал, сертификат требует полного субъекта, включая DC=* *для разрешения доменных имен. For this scenario to work, the certificate requires a full subject, including DC= , for domain name resolution.

Чтобы развернуть корневые сертификаты на смарт-карте для в настоящее время присоединимых доменов, можно использовать следующую команду: To deploy root certificates on a smart card for the currently joined domain, you can use the following command:

certutil -scroots update certutil -scroots update

Дополнительные сведения об этом параметре для средства командной строки см. в пункте -SCRoots. For more information about this option for the command-line tool, see -SCRoots.