infraestructura de tarjeta inteligente de Windows Vista

Windows Vista® Smart Card Infrastructure proporciona detalles sobre la infraestructura de tarjetas inteligentes de Microsoft® Windows ® y cómo funcionan los componentes relacionados con tarjetas inteligentes en Windows. Este documento también contiene información sobre las herramientas de solución de problemas y depuración, y las herramientas que los desarrolladores y administradores de tecnologías de la información (TI) pueden usar para implementar la autenticación segura basada en tarjetas inteligentes en la empresa.

Público

En este documento se proporcionan detalles de bajo nivel de cómo funciona la infraestructura de tarjeta inteligente Windows. Debe tener conocimientos básicos sobre la infraestructura de clave pública (PKI) y los conceptos de tarjetas inteligentes para hacer un uso completo de las recomendaciones de este documento. Este documento está dirigido a:

• Desarrolladores y profesionales de TI empresariales que planean o implementan una implementación de tarjetas inteligentes. Esto incluye directores de TI y personal de TI.
• Proveedores de tarjetas inteligentes que escriben minicontrolador de tarjetas inteligentes o proveedores de credenciales. En este documento se detallan los trabajos internos de la arquitectura de tarjeta inteligente de Windows y se proporciona información sobre cómo los departamentos de TI planearán las implementaciones de tarjetas inteligentes.

infraestructura de tarjeta inteligente de Windows

La compatibilidad con tarjetas inteligentes se incluyó inicialmente en Windows 2000. Windows Server 2003 y Windows XP también admiten tarjetas inteligentes.

Nota

El servicio de tarjeta inteligente (SCardSvr.exe) y la API winSCard estaban disponibles como componentes opcionales para Windows 95, Windows 98 y Windows ME.

Dado que las tarjetas inteligentes se integraron en Windows 2000, los usuarios pueden iniciar sesión y firmar y cifrar el correo electrónico digitalmente. Sin embargo, hay algunas limitaciones en la implementación.

Antes de Windows Vista:

• Una tarjeta inteligente solo podría admitir un certificado para el inicio de sesión.
• Solo un contenedor de la tarjeta inteligente podría marcarse como predeterminado. Se podrían almacenar certificados adicionales en la tarjeta inteligente para otros fines, como S/MIME.
• El cambio del PIN y el desbloqueo de una tarjeta inteligente no se admitieron ni integraron de forma nativa. Como resultado, un usuario tuvo que iniciar sesión primero con un nombre de usuario estándar y una contraseña para realizar estas tareas.

mejoras de Windows Vista

Winlogon se ha rediseñado en Windows Vista. En versiones anteriores de Windows, se usaba una biblioteca de vínculos dinámicos (DLL) de GINA personalizada para admitir la autenticación y la identificación de usuarios personalizables. En Windows Vista, la funcionalidad de GINA se ha distribuido entre tres componentes:

• Winlogon
• Interfaz de usuario (UI) de inicio de sesión
• Proveedores de credenciales

MSGINA.DLL se ha quitado y las GBA personalizadas no se cargarán en sistemas que ejecutan Windows Vista y versiones posteriores. Tanto el proveedor de credenciales de contraseña como el proveedor de credenciales de tarjeta inteligente se proporcionan de forma predeterminada y la capacidad de admitir mecanismos de autenticación personalizados requerirá la creación de un proveedor de credenciales personalizado. Después de que Winlogon inicie la interfaz de usuario de inicio de sesión, carga los proveedores de credenciales registrados. El proveedor de credenciales de tarjeta inteligente usa interfaces que se exponen mediante el marco de trabajo del proveedor de credenciales para recopilar las credenciales necesarias, empaquetarlas y devolverlas a la interfaz de usuario de inicio de sesión. A continuación, la interfaz de usuario de inicio de sesión pasa las credenciales a Winlogon que se usará para la autenticación Kerberos.

En Vista, Winlogon admite varios certificados de inicio de sesión y contenedores en la misma tarjeta inteligente. El número de certificados que se pueden almacenar y de contenedores que se pueden crear depende de cuánto espacio hay disponible en la tarjeta inteligente.

Cada tarjeta inteligente debe tener un proveedor de servicios criptográficos (CSP). Un CSP usa las interfaces cryptography Application Programming Interface (CAPI) en la parte superior y las API de WinSCard en la parte inferior. (Para obtener información detallada, consulte Arquitectura del subsistema de tarjetas inteligentes).

En el pasado, escribir un CSP de tarjeta inteligente no era una tarea trivial. Sin embargo, un nuevo CSP denominado CSP base ahora ayuda a escribir un CSP de tarjeta inteligente. El CSP base permite a los proveedores de tarjetas inteligentes escribir módulos específicos de tarjetas denominadas minicontrolador de tarjetas inteligentes. Microsoft proporciona el CSP base como parte de la plataforma. Existe un paquete descargable para Windows XP SP2, Windows 2000 SP4 y Windows Server 2003 SP1. Un minicontrolador de tarjeta inteligente es una interfaz que Microsoft admite para que los proveedores de tarjetas inteligentes escriban implementaciones en su tarjeta inteligente. Esto es análogo a escribir un controlador de impresora para una impresora.

La API de WinSCard se ha ampliado para proporcionar almacenamiento en caché (almacenamiento de datos no confidenciales por usuario) en el nivel de administrador de recursos de tarjeta inteligente. El administrador de recursos de tarjeta inteligente se denominaba servicio de tarjeta inteligente.

Para admitir algoritmos criptográficos adicionales y proporcionar una arquitectura extensible, cryptography API: Next Generation (CNG) se diseñó. Arquitectónicamente, esto es paralelo a CAPI. Al igual que con CSP, un proveedor de almacenamiento de claves (KSP) está debajo del CNG. En Windows Vista, la implementación de KSP de tarjeta inteligente se proporciona de forma predeterminada. La misma interfaz de minicontrolador de tarjeta inteligente que está disponible para CSP base también es aplicable para KSP de tarjeta inteligente. La compatibilidad con minicontrolador de tarjeta inteligente para criptografía de curva elíptica rsa y elíptica (ECC) está disponible con KSP de tarjeta inteligente.

Architecture

La base de datos del Registro de tarjetas inteligentes se encuentra en HKLM\Software\Microsoft\Cryptography\Calais\SmartCard. Esta base de datos contiene información de lector de tarjetas inteligentes y tarjetas inteligentes. La infraestructura de tarjetas inteligentes de Windows incluye dos componentes principales:

• Windows arquitectura de inicio de sesión interactiva
• Arquitectura del subsistema de tarjetas inteligentes

Windows arquitectura de inicio de sesión interactiva

Antes de Windows Vista, la arquitectura de inicio de sesión interactiva de Windows incluía los componentes que se muestran en la tabla 1.

Tabla 1 Componentes de inicio de sesión interactivos de Vista anterior Windows

Componente	Descripción
Winlogon	Proporciona una infraestructura de inicio de sesión interactiva.
Componente de identificación gráfica y autenticación (GINA)	Proporciona representación interactiva de la interfaz de usuario.
Autoridad de seguridad local (LSA)	Procesa las credenciales de inicio de sesión.
Paquetes de autenticación	Incluye NTLM y Kerberos. Se comunica con paquetes de autenticación de servidor para autenticar a los usuarios.

Nota

Para obtener más información sobre la arquitectura de inicio de sesión interactiva basada en GINA, consulte Funcionamiento del inicio de sesión interactivo (https://go.microsoft.com/fwlink/?LinkId=93339).

arquitectura del proveedor de credenciales de Windows Vista

En la tabla 2 se muestran los componentes de la arquitectura de inicio de sesión interactivo de Windows Vista.

Tabla 2 Windows componentes de inicio de sesión interactivos de Vista

Componente	Descripción
Winlogon	Proporciona una infraestructura de inicio de sesión interactiva.
Interfaz de usuario de inicio de sesión	Proporciona representación interactiva de la interfaz de usuario.
Proveedores de credenciales (contraseña y tarjeta inteligente)	Describe la información de credenciales y la serialización de credenciales.
LSA	Procesa las credenciales de inicio de sesión.
Paquetes de autenticación	Incluye NTLM y Kerberos. Se comunica con paquetes de autenticación de servidor para autenticar a los usuarios.

Figura 1 Windows arquitectura del proveedor de credenciales

Windows inicios de sesión interactivos de Vista comienzan cuando el usuario presiona CTRL+ALT+SUPR. La combinación de teclas CTRL+ALT+SUPR se denomina secuencia de atención segura (SAS). Winlogon registra esta secuencia durante el proceso de arranque, con el fin de evitar que otros programas y procesos lo usen. A continuación, la interfaz de usuario de inicio de sesión genera el icono a partir de la información recibida de los proveedores de credenciales registrados. En la ilustración siguiente se muestra el cuadro de diálogo de inicio de sesión de Windows Vista.

Figura 2 Windows interfaz de usuario de inicio de sesión de Vista

Un usuario que inicie sesión en un equipo mediante una cuenta local o una cuenta de dominio debe escribir un nombre de usuario y una contraseña. Estas credenciales se usan para comprobar la identidad del usuario. Sin embargo, en el caso de los inicios de sesión de tarjeta inteligente, las credenciales de un usuario se encuentran en el chip de seguridad de la tarjeta inteligente. Un dispositivo externo denominado lector de tarjetas inteligentes lee el chip de seguridad. Durante un inicio de sesión de tarjeta inteligente, un usuario escribe un número de identificación personal (PIN) en lugar de un nombre de usuario, dominio y contraseña.

Los proveedores de credenciales son objetos COM en proceso que se usan para recopilar credenciales en Windows Vista y se ejecutan en el contexto del sistema local. En resumen, la interfaz de usuario de inicio de sesión proporciona representación interactiva de la interfaz de usuario, Winlogon proporciona infraestructura de inicio de sesión interactiva y proveedores de credenciales que ayudan a recopilar y procesar credenciales.

En Windows Vista, Winlogon indica a la interfaz de usuario de inicio de sesión que muestre iconos después de recibir un evento SAS. La interfaz de usuario de inicio de sesión consulta cada proveedor de credenciales para el número de credenciales que desea enumerar. Los proveedores de credenciales tienen la opción de especificar uno de estos iconos como predeterminado. Después de que todos los proveedores hayan enumerado sus iconos, la interfaz de usuario de inicio de sesión los muestra al usuario. El usuario interactúa con un icono para proporcionar sus credenciales. La interfaz de usuario de inicio de sesión envía estas credenciales para la autenticación.

Junto con el hardware auxiliar, los proveedores de credenciales pueden ampliar el sistema operativo de Microsoft Windows para permitir a los usuarios iniciar sesión mediante biometría (huella digital, retinal o reconocimiento de voz), contraseña, PIN, certificado de tarjeta inteligente o cualquier paquete de autenticación personalizado que un desarrollador de terceros quiera crear. Las empresas y los profesionales de TI pueden desarrollar e implementar mecanismos de autenticación personalizados para todos los usuarios del dominio y pueden requerir explícitamente que los usuarios usen este mecanismo de inicio de sesión personalizado.

Los proveedores de credenciales no son mecanismos de cumplimiento. Se usan para recopilar y serializar credenciales. Los paquetes de autenticación y LSA aplican la seguridad.

Los proveedores de credenciales pueden diseñarse para admitir el inicio de sesión único (SSO), autenticando a los usuarios en un punto de acceso de red seguro (mediante RADIUS y otras tecnologías), así como inicio de sesión en el equipo. Los proveedores de credenciales también están diseñados para admitir la recopilación de credenciales específicas de la aplicación y se pueden usar para la autenticación en recursos de red, unir equipos a un dominio o proporcionar consentimiento del administrador para el Control de cuentas de usuario (UAC).

Varios proveedores de credenciales pueden coexistir en un equipo.

Los proveedores de credenciales se registran en un equipo Windows Vista y son responsables de:

• Descripción de la información de credenciales necesaria para la autenticación.
• Control de la comunicación y la lógica con las autoridades de autenticación externas.
• Empaquetado de credenciales para el inicio de sesión interactivo y de red.

La API del proveedor de credenciales no diseña la interfaz de usuario. Describe lo que se debe representar. Solo el proveedor de credenciales de contraseña está disponible en modo seguro. El proveedor de credenciales de tarjeta inteligente integrada está disponible en modo seguro con redes.

Para obtener más información sobre los proveedores de credenciales y sus usos, consulte la Referencia técnica del proveedor de credenciales (https://go.microsoft.com/fwlink/?LinkId=93340).

En la figura 3 se muestra Windows flujo de pantalla de inicio de sesión de Vista con desbloqueo de PIN y cambio de PIN.

Figura 3 Experiencia de usuario de desbloqueo y cambio de PIN

Arquitectura del subsistema de tarjetas inteligentes

Los proveedores y asociados son muy importantes para el éxito de los escenarios basados en tarjetas inteligentes. Los proveedores proporcionan tarjetas inteligentes y lectores de tarjetas inteligentes y, en muchos casos, los proveedores de tarjetas inteligentes y lectores son diferentes. Los controladores de lector se escriben en la versión 1.0 estándar pc/SC. Cada tarjeta inteligente debe tener un CSP que use las interfaces CAPI en la parte superior y las API de WinSCard en la parte inferior. El módulo GINA también tiene la funcionalidad de inicio de sesión de tarjeta inteligente para proporcionar la interfaz de usuario pertinente para capturar las credenciales y la serialización posterior que se enviarán a LSALogonUser para la autenticación.

Arquitectura de minicontrolador de tarjeta inteligente y CSP base para Windows 2000, Windows XP y Windows 2003

Requisitos: se debe instalar el CSP base. El CSP base es una descarga gratuita y opcional disponible en el sitio web de Microsoft (https://go.microsoft.com/fwlink/?LinkId=93341).

En la figura 4 se muestra cómo CAPI, CSP, CSP base y minicontrolador de tarjetas inteligentes están en capas arquitectónicas.

Figura 4 Arquitectura de minicontrolador de CSP base y tarjeta inteligente

Heurística de selección de tarjetas inteligentes

Niveles de especificación de contenedor

En respuesta a una llamada a CryptAcquireContext , el CSP base intentará coincidir con el contenedor que el autor de la llamada especifica para una tarjeta y un lector específicos. El autor de la llamada puede proporcionar un nombre de contenedor con distintos niveles de especificidad, que se muestran en la lista siguiente, ordenados de solicitudes más específicas a menos específicas.

Del mismo modo, para la tarjeta inteligente KSP, NCryptOpenKey tiene el mismo formato que se muestra en la tabla 3. Antes de abrir la clave, se realiza una llamada a NCryptOpenStorageProvider(MS_SMART_CARD_KEY_STORAGE_PROVIDER).

Tabla 3 Niveles de especificación de contenedor

Tipo	Nombre	Formato
I	Nombre del lector y nombre del contenedor	\\.\<Reader Name>\<Container Name>
II	Nombre del lector y nombre del contenedor (NULL)	\\.\<Nombre> del lector\
III	Solo nombre de contenedor	<Nombre del contenedor>
IV	Contenedor predeterminado (NULL) solo	NULL

En los dos primeros casos, en los que se proporciona un nombre de lector, el CSP base normalmente buscará el lector especificado y realizará la operación solicitada en la tarjeta insertada en ese lector. En el segundo caso, en el que no se proporciona un nombre de lector de tarjetas inteligentes, el CSP base buscará una tarjeta y un lector adecuados para la solicitud actual, empezando por tarjetas ya conocidas por el CSP base y continuando con todas las tarjetas inteligentes y lectores disponibles con el subsistema de tarjetas inteligentes.

Para cada uno de los casos anteriores, el CSP base buscará primero una tarjeta coincidente en su lista de datos de tarjetas almacenadas en caché. Esta caché incluye una lista de tarjetas inteligentes y la información de estado de la tarjeta inteligente asociada que el CSP ha encontrado en la sesión actual (donde la sesión suele ser la duración del proceso actual). En general, si se encuentra una tarjeta inteligente coincidente en la memoria caché, se debe actualizar el identificador de tarjeta asociado al elemento de caché. Esto determina si la tarjeta todavía está en el lector, ya que es posible que la tarjeta inteligente se haya quitado desde que se creó el elemento de caché.

Si se encuentra una tarjeta inteligente coincidente almacenada en caché, pero el identificador de tarjeta inteligente almacenado en caché ya no es válido, la API SCardUIDlg se usa para actualizar el identificador de tarjeta. Se proporciona información adicional, como el número de serie de la tarjeta inteligente coincidente, a SCardUIDlg para ayudar a filtrar rápidamente las tarjetas inteligentes candidatas.

Operaciones de contenedor

Se pueden solicitar tres operaciones de contenedor principales mediante CryptAcquireContext. Dichos componentes son:

1. Creación de un contenedor (CRYPT_NEWKEYSET)
2. Apertura del contenedor existente
3. Eliminar contenedor (CRYPT_DELETEKEYSET)

La heurística que se usa para asociar un contexto de usuario a una tarjeta determinada y lector se basa principalmente en la operación de contenedor solicitada y el nivel de especificación de contenedor utilizado.

En la tabla 4 se muestran las restricciones de la operación de creación de contenedores.

Tabla 4 Restricciones de operación de creación de contenedores

Especificación	Restricción
Sin contexto silencioso	La creación de contenedores de claves siempre debe ser capaz de mostrar la interfaz de usuario, como el símbolo del sistema del PIN.
Sin sobrescribir contenedores existentes	Si el contenedor especificado ya existe en la tarjeta inteligente elegida, elija otra tarjeta o cancele la operación.

Marcas de contexto

En la tabla 5 se muestran las marcas de contexto para las restricciones de la operación de creación de contenedores.

Tabla 5 Marcas de restricción

Marca	Descripción
CRYPT_SILENT	No se puede mostrar ninguna interfaz de usuario durante esta operación.
CRYPT_MACHINE_KEYSET	No se deben usar datos almacenados en caché durante esta operación.
CRYPT_VERIFYCONTEXT	Solo se puede acceder a los datos públicos en la tarjeta inteligente.

Además de las operaciones de contenedor y la especificación del contenedor, debe tener en cuenta otras opciones de usuario, como las marcas de CryptAcquireContext anteriores, durante la selección de tarjetas.

Importante

La marca CRYPT_SILENT no se puede usar con la operación de contenedor A (crear nuevo contenedor).

Creación de un contenedor en contexto silencioso

Las aplicaciones pueden llamar al CSP base con CRYPT_DEFAULT_CONTAINER_OPTIONAL, establecer el PIN en contexto silencioso y, a continuación, crear un nuevo contenedor en contexto silencioso:

1. Llame a CryptAcquireContext pasando el nombre del lector de tarjetas inteligentes en como tipo II, especificando la marca CRYPT_DEFAULT_CONTAINER_OPTIONAL .
2. Llame a CryptSetProvParam especificando PP_KEYEXCHANGE_PIN o PP_SIGNATURE_PIN y un PIN ASCII terminado en null.
3. Libere el contexto adquirido en el paso 1.
4. Llame a CryptAcquireContext con CRYPT_NEWKEYSET especificando el formato de tipo I.
5. Llame a CryptGenKey para crear la clave.

Comportamiento de la selección de la tarjeta inteligente

En algunos de los escenarios siguientes, se puede solicitar al usuario que inserte una tarjeta inteligente. Si el contexto del usuario es silencioso, se produce un error en esta operación y no se muestra ninguna interfaz de usuario. De lo contrario, en respuesta a la interfaz de usuario, el usuario puede insertar una tarjeta inteligente o hacer clic en Cancelar. Si el usuario cancela la operación, se produce un error en la operación.

Figura 5 Comportamiento de selección de tarjetas inteligentes

En general, la API SCardUIDlgSelectCard controlará el comportamiento de la selección de tarjetas. El CSP base interactuará con esta API llamándolo directamente. El CSP base también enviará funciones de devolución de llamada, cuyo propósito será filtrar y hacer coincidir tarjetas inteligentes candidatas. Los autores de llamadas de CryptAcquireContext proporcionan información de coincidencia de tarjetas. Internamente, el CSP base usa una combinación de números de serie de tarjetas inteligentes, nombres de lector y nombres de contenedor para buscar tarjetas inteligentes específicas.

Cada llamada a SCardUI* puede dar lugar a información adicional leída desde una tarjeta inteligente candidata. Las devoluciones de llamada de selección de tarjeta inteligente csp base almacenan esta información en caché.

La API SCardUI* se usa para actualizar los identificadores de tarjeta inteligente, ya que se puede quitar o volver a insertar una tarjeta inteligente de destino después de almacenar en caché un identificador de tarjeta. FindCachedCard() detecta el número de serie coincidente, que se pasa a FindCard() junto con un estado que indica que la búsqueda se realizó correctamente, pero que el identificador de tarjeta debe volver a adquirirse. (O que se podría devolver la estructura de estado de la tarjeta inteligente correspondiente, en lugar de solo el número de serie. Esto impediría que la devolución de llamada tuviera que buscar de nuevo en la lista de tarjetas). FindCard proporcionará el número de serie a la devolución de llamada correspondiente a tarjetas mediante SCardUI*.

Hacer coincidir un lector

En el caso de los niveles de especificación de contenedor I e II, el proceso de selección de tarjetas inteligentes es menos complejo porque solo la tarjeta inteligente del lector con nombre se puede considerar una coincidencia.

1. Busque el lector solicitado. Si no se encuentra, se produce un error en el proceso. (Esto requiere una búsqueda en caché por nombre de lector).
2. Si no hay ninguna tarjeta inteligente en el lector, se le pedirá al usuario que inserte una tarjeta inteligente (solo en modo no silencioso; si la llamada se realiza en modo silencioso, se producirá un error).
3. Solo para el nivel II, se determina el nombre del contenedor predeterminado en la tarjeta inteligente elegida.
4. Para las operaciones de contenedor B (abrir existentes) y C (eliminar), busque el contenedor especificado. Si no se encuentra el contenedor especificado en esta tarjeta inteligente, se le pedirá al usuario que inserte una tarjeta inteligente.
5. Para la operación de contenedor A (crear nuevo), si el contenedor especificado ya existe en esta tarjeta inteligente, se produce un error en el proceso.

Hacer que una tarjeta inteligente coincida

En el caso de los niveles III y IV de especificación de contenedor, se usa un método más amplio para hacer coincidir una tarjeta adecuada con un contexto de usuario, ya que varias tarjetas inteligentes almacenadas en caché podrían cumplir los criterios proporcionados.

Abrir el contenedor predeterminado existente: no se ha especificado ningún lector

Nota

Este escenario requiere que use el KSP de tarjeta inteligente con el CSP base.

1. Para cada tarjeta inteligente ya conocida por el CSP base, busque un contenedor predeterminado válido. Se intenta realizar una operación en el SCARDHANDLE almacenado en caché para comprobar su actualización. Si el identificador de tarjeta inteligente no es válido, el CSP base continúa buscando una nueva tarjeta inteligente.
2. Si no se encuentra una tarjeta coincidente en la memoria caché de CSP base, llame al subsistema de tarjetas inteligentes. SCardUIDlgSelectCard() se usa con un filtro de devolución de llamada adecuado para buscar una tarjeta coincidente con un contenedor predeterminado válido.

Abra el contenedor con nombre GUID existente, no se especificó ningún lector.

Nota

Este escenario requiere que use el KSP de tarjeta inteligente con el CSP base.

1. Para cada tarjeta inteligente que ya conoce el CSP base, busque el contenedor solicitado. Intente una operación en el SCARDHANDLE almacenado en caché para comprobar su actualización. Si el identificador de tarjeta no es válido, el número de serie de la tarjeta inteligente se pasa a la API SCardUI* para seguir buscando esta tarjeta inteligente específica (en lugar de solo una coincidencia general para el nombre del contenedor).
2. Si no se encuentra una tarjeta coincidente en la memoria caché de CSP base, se realiza una llamada al subsistema de tarjetas inteligentes. SCardUIDlgSelectCard() se usa con un filtro de devolución de llamada adecuado para buscar una tarjeta coincidente con el contenedor solicitado. O bien, si un número de serie de tarjeta inteligente resultó de la búsqueda en el paso 1, el filtro de devolución de llamada intenta coincidir con el número de serie, no el nombre del contenedor.

Crear nuevo contenedor, sin lector especificado

Nota

Este escenario requiere que use el KSP de tarjeta inteligente con el CSP base.

Si el PIN no se almacena en caché, no se permite ningún CRYPT_SILENT en la creación del contenedor porque se debe solicitar al usuario un PIN, como mínimo.

Para otras operaciones, el autor de la llamada puede adquirir un contexto de "comprobación" en el contenedor predeterminado (CRYPT_DEFAULT_CONTAINER_OPTIONAL) y, a continuación, realizar una llamada a CryptSetProvParam para almacenar en caché el PIN de usuario para las operaciones posteriores.

1. Para cada tarjeta inteligente ya conocida por el CSP, actualice el SCARDHANDLE almacenado y realice las siguientes comprobaciones:
   1. Si se ha quitado la tarjeta inteligente, continúe con la búsqueda.
   2. Si la tarjeta inteligente sigue estando presente pero ya tiene el contenedor con nombre, continúe con la búsqueda.
   3. Si la tarjeta inteligente está disponible, pero una llamada a CardQueryFreeSpace indica que la tarjeta no tiene almacenamiento suficiente para un contenedor de claves adicional, continúe la búsqueda.
   4. De lo contrario, use la primera tarjeta inteligente disponible que cumpla los criterios anteriores para la creación del contenedor.
2. Si no se encuentra una tarjeta inteligente coincidente en la memoria caché de CSP, llame al subsistema de tarjetas inteligentes. La devolución de llamada utilizada para filtrar las tarjetas inteligentes enumeradas debe comprobar que una tarjeta inteligente candidata aún no tiene el contenedor con nombre y que CardQueryFreeSpace indica que la tarjeta tiene espacio suficiente para un contenedor adicional. Si no se encuentra ninguna tarjeta adecuada, muestre la interfaz de usuario que pide al usuario que inserte una tarjeta inteligente.

Eliminación de un contenedor

1. Si el nombre del contenedor especificado es NULL, se elimina el contenedor predeterminado. Al eliminar el contenedor predeterminado, se selecciona un nuevo contenedor predeterminado de forma arbitraria. Por este motivo, no se recomienda esta operación.
2. Para cada tarjeta inteligente ya conocida por el CSP, actualice el SCARDHANDLE almacenado y realice las siguientes comprobaciones.
   1. Si la tarjeta inteligente no tiene el contenedor con nombre, continúe con la búsqueda.
   2. Si la tarjeta inteligente tiene el contenedor con nombre, pero el identificador de tarjeta ya no es válido, almacene el número de serie de la tarjeta inteligente coincidente y páselo a SCardUI*.
3. Si no se encuentra una tarjeta coincidente en la memoria caché de CSP, llame al subsistema de tarjetas inteligentes. La devolución de llamada utilizada para filtrar las tarjetas enumeradas debe comprobar que una tarjeta candidata tiene el contenedor con nombre. Si se proporcionó un número de serie como resultado de la búsqueda de caché anterior, la devolución de llamada debe filtrar las tarjetas enumeradas en el número de serie en lugar de coincidencias de contenedor. Si el contexto no es silencioso y no se encuentra ninguna tarjeta inteligente adecuada, muestre la interfaz de usuario que pide al usuario que inserte una tarjeta inteligente.

Almacenamiento en caché con CSP base y KSP de tarjeta inteligente (solo Windows Vista)

Almacenamiento de datos en caché

Cada CSP implementa la caché de datos de tarjeta inteligente actual por separado. El CSP base, por ejemplo, implementa un mecanismo sólido de almacenamiento en caché que permite que un único proceso minimice las operaciones de E/S de tarjetas.

La caché en proceso existente funciona de la siguiente manera.

1. La aplicación solicita una operación CAPI. Por ejemplo, un certificado de usuario debe leerse desde la tarjeta.
2. El CSP comprueba primero la memoria caché del elemento.
3. Si el elemento no se encuentra en la memoria caché o si el elemento está almacenado en caché pero no está actualizado, el elemento se lee de la tarjeta inteligente.
4. Después de leer cualquier elemento de la tarjeta inteligente, se agrega a la memoria caché. Se reemplaza cualquier copia obsoleta existente de ese elemento.

El principal problema de la solución existente es que cada proceso compatible con tarjetas inteligentes del sistema debe duplicar el comportamiento anterior y mantener su propia copia de los mismos datos. El modelo actual no es suficiente. Un proceso debe ser capaz de usar datos de tarjeta leídos previamente por otros procesos.

La caché de datos global se hospeda en el administrador de recursos de tarjeta inteligente. Windows Vista incluye dos nuevas llamadas API de tarjeta inteligente de Windows públicas, SCardWriteCache y SCardReadCache. Estas llamadas API hacen que la funcionalidad de almacenamiento en caché de datos global esté disponible para las aplicaciones. Estas llamadas API solo se admiten en equipos cliente de Windows Vista.

1. Cada tarjeta inteligente que se ajusta a la nueva especificación de minicontrolador de tarjeta inteligente tiene un identificador de tarjeta de 16 bytes. Este valor se usará para identificar los datos almacenados en caché que pertenecen a una tarjeta inteligente determinada de forma única. Por motivos de simplicidad, se usará el tipo de GUID de Windows estándar.
2. Estas API permiten a una aplicación agregar datos y leer datos de la caché global.

Debe implementar dos nuevas API, RedirectedSCardWriteCache y RedirectedSCardReadCache, con las E/STL y los controladores correspondientes para ayudar a redirigir el servidor de terminal.

Almacenamiento en caché de PIN

La memoria caché del PIN ayuda a limitar el hecho de que el usuario tenga que volver a escribir un PIN cada vez que se des autentique la tarjeta inteligente. Después de autenticar una tarjeta inteligente, no se diferenciará entre las aplicaciones del lado host; cualquier aplicación puede acceder a datos privados en la tarjeta inteligente. Para mitigar esto, la tarjeta inteligente se coloca bajo un estado exclusivo cuando una aplicación se autentica en la tarjeta inteligente. Sin embargo, esto significa que otras aplicaciones no pueden comunicarse con la tarjeta inteligente y se bloquearán. Por lo tanto, estas conexiones exclusivas se minimizan. El problema es que un protocolo como Kerberos requiere varias operaciones de firma y, por tanto, requerirá acceso exclusivo a la tarjeta inteligente durante un período prolongado o requerirá varias operaciones de autenticación. Aquí es donde entra en juego la memoria caché del PIN y permite un uso exclusivo mínimo de la tarjeta inteligente sin forzar al usuario a escribir su PIN varias veces.

Este es un ejemplo que muestra exactamente cómo funciona. En este escenario, hay dos aplicaciones: Outlook e Internet Explorer. Ambas aplicaciones usan tarjetas inteligentes para diferentes propósitos.

1. El usuario inicia Outlook e intenta enviar un correo electrónico firmado. La clave privada está en la tarjeta inteligente.
2. Outlook solicita al usuario el PIN de la tarjeta inteligente. El usuario escribe el PIN correcto.
3. Los datos de correo electrónico se envían a la tarjeta inteligente para la operación de firma. El cliente Outlook da formato a la respuesta y envía el correo electrónico.
4. El usuario abre Internet Explorer e intenta acceder a un sitio protegido que requiere autenticación de cliente TLS.
5. Internet Explorer solicita al usuario el PIN de la tarjeta inteligente. El usuario escribe el PIN correcto.
6. La operación de clave privada relacionada con TLS se produce en la tarjeta inteligente y el usuario se autentica e inicia sesión.
7. El usuario vuelve a Outlook para enviar otro correo electrónico firmado. Esta vez, el usuario no se solicita un PIN, porque el PIN se almacena en caché de la operación anterior. De forma similar, si el usuario usa Internet Explorer de nuevo para realizar otra operación, Internet Explorer no solicitará al usuario un PIN.

El CSP base mantiene internamente una caché por proceso del PIN para habilitar el almacenamiento en caché. El PIN se almacena cifrado en memoria. Las funciones que se usan para proteger el PIN son RtlEncryptMemory, RtlDecryptMemory y RtlSecureZeroMemory, que eliminarán los búferes que contienen el PIN.

Arquitectura basada en CSP base y KSP en Windows Vista

Figura 6 Arquitectura de criptografía en Windows Vista

Propiedades de KSP de CSP base y tarjeta inteligente en Windows Vista

Las siguientes propiedades se admiten en Windows Vista.

Nota

Las definiciones de API se encuentran en WinCrypt.h y WinSCard.h.

Tabla 6 Propiedades de CSP base y KSP de tarjeta inteligente

Propiedad	Descripción
PP_USER_CERTSTORE	Se usa para devolver un HCERTSTORE que contiene todos los certificados de usuario de la tarjeta inteligente. Solo lectura (que solo usa CryptGetProvParam). Autor de la llamada responsable de cerrar el almacén de certificados. Certificado codificado mediante PKCS_7_ASN_ENCODING o X509_ASN_ENCODING CSP debe establecer KEY_PROV_INFO en certificados Se debe suponer que el almacén de certificados es un almacén en memoria. Los certificados deben tener un CRYPT_KEY_PROV_INFO válido como una propiedad
PP_ROOT_CERTSTORE	Lectura y escritura (tanto CryptGetProvParam como CryptSetProvParam) Se usa para escribir una colección de certificados raíz en la tarjeta inteligente o devolver un HCERTSTORE que contenga certificados raíz de la tarjeta inteligente. Se usa principalmente para la unión a un dominio con tarjeta inteligente Autor de la llamada responsable de cerrar el almacén de certificados
PP_SMARTCARD_READER	Solo lectura (solo CryptGetProvParam) Devuelve el nombre del lector de tarjetas inteligentes como una cadena ANSI que se usa para construir un nombre de contenedor completo (lector y contenedor)
PP_SMARTCARD_GUID	GUID de tarjeta de retorno (también conocido como número de serie), que debe ser único para cada tarjeta inteligente. Usado por el servicio de propagación de certificados para realizar un seguimiento del origen de un certificado raíz
PP_UI_PROMPT	Se usa para establecer la cadena de búsqueda para el cuadro de diálogo de inserción de tarjetas SCardUIDlgSelectCard Persistente para todo el proceso una vez establecido Solo escritura (que solo usa CryptSetProvParam)

Implicaciones de los CSP en Windows Vista

CSP seguirá siendo compatible con Windows Vista. Sin embargo, no se recomienda, especialmente si desea comunicarse con tarjetas inteligentes. El uso del CSP base existente y el KSP de tarjeta inteligente con el modelo de minicontrolador de tarjeta inteligente para tarjetas inteligentes proporciona ventajas significativas en términos de rendimiento y PIN y almacenamiento en caché de datos. El mismo minicontrolador se puede configurar para funcionar en capas CAPI y CNG, que se benefician de compatibilidad criptográfica mejorada, criptografía de curva elíptica y AES.

Si una tarjeta inteligente está registrada por un CSP y un minicontrolador de tarjeta inteligente, lo que se haya instalado más recientemente se usará para la comunicación con la tarjeta inteligente.

Cuándo escribir un minicontrolador de tarjeta inteligente, CSP o KSP

CSP y KSP están diseñados para escribirse solo si la funcionalidad específica no está disponible en la arquitectura actual del minicontrolador de tarjeta inteligente. Por ejemplo, la arquitectura de minicontrolador de tarjeta inteligente admite módulos de seguridad de hardware (HSM), por lo que no se requiere un CSP o KSP.

Para obtener más información sobre cómo escribir un minicontrolador de tarjeta inteligente, CSP o KSP, consulte Enterprise implementación de tarjetas inteligentes en Microsoft Windows Smart Card Framework (https://go.microsoft.com/fwlink/?LinkId=93348).

Windows Vista directiva de grupo Configuración

En la tabla siguiente se muestra la configuración de directiva de grupo que se puede usar por equipo. No hay ninguna configuración por usuario. Algunas de estas opciones de configuración solo se pueden aplicar a un dominio funcional de nivel Windows Vista, por ejemplo, Sugerencias de dominio. Todas las claves se encuentran en \Policies\Microsoft\Windows\SmartCardCredentialProvider y \Policies\Microsoft\Windows\CertProp

Desde el editor de directiva de grupo (gpedit.exe), puede editar y aplicar directiva de grupo a los equipos del dominio. Existen directivas relacionadas con tarjetas inteligentes en

Configuración del equipo\Plantillas administrativas\Windows Componentes\Tarjeta inteligente

Figura 7 Configuración relacionada con tarjetas inteligentes en directiva de grupo

Una vez que el administrador de dominio los aplique, en el equipo local del usuario residirán en HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SmartCardCredentialProvider

Configuración de directiva de grupo de la tabla 7

Clave	Descripción
AllowSignatureOnlyKeys	Permite claves de firma válidas para el inicio de sesión. Esta configuración también se aplica siempre que se llama a la interfaz de usuario de credenciales. El uso de esta configuración permite enumerar y estar disponibles para el inicio de sesión en los certificados basados en claves de firma. 1 (Habilitado): los certificados disponibles en la tarjeta inteligente con una clave de solo firma se mostrarán en la pantalla de inicio de sesión. 0 (Deshabilitado): los certificados basados en claves de firma de tarjeta inteligente disponibles no aparecerán en la pantalla de inicio de sesión. No configurado: los certificados basados en claves de firma de tarjeta inteligente disponibles no se mostrarán en la pantalla de inicio de sesión.
AllowCertificatesWithNoEKU	Permite que los certificados sin un conjunto de EKU se usen para el inicio de sesión. En versiones anteriores de Windows, la extensión de EKU era necesaria para que el identificador de objeto de inicio de sesión de tarjeta inteligente estuviera presente. Esta configuración controla esa restricción. 1 (Habilitado): solo los certificados basados en tarjetas inteligentes que contienen el identificador de objeto de inicio de sesión de tarjeta inteligente o ninguna extensión de EKU aparecerán en la pantalla de inicio de sesión. 0 (Deshabilitado): solo los certificados basados en tarjetas inteligentes que contienen el identificador de objeto de inicio de sesión de tarjeta inteligente se mostrarán en la pantalla de inicio de sesión. No configurado: solo los certificados basados en tarjetas inteligentes que contienen el identificador de objeto de inicio de sesión de tarjeta inteligente se mostrarán en la pantalla de inicio de sesión.
AllowTimeInvalidCertificates	Permite mostrar los certificados para el inicio de sesión que han expirado o aún no son válidos. En versiones anteriores de Windows, los certificados debían contener una hora válida y no expirar. El controlador de dominio debe seguir aceptando el certificado para poder usarse. Esta configuración controla solo si el certificado se muestra en el equipo cliente. 1 (Habilitado): los certificados aparecerán en la pantalla de inicio de sesión, independientemente de si tienen horas no válidas o si su validez de tiempo ha expirado. 0 (Deshabilitado): los certificados que han expirado o que aún no son válidos no aparecerán en la pantalla de inicio de sesión. No configurado: los certificados que han expirado o que aún no son válidos no aparecerán en la pantalla de inicio de sesión.
AllowIntegratedUnblock	Permite determinar si la característica de desbloqueo integrado estará disponible en la interfaz de usuario de inicio de sesión. Para usar la característica de desbloqueo integrado, la tarjeta inteligente debe admitir esta característica. Pregunte al fabricante del hardware si la tarjeta inteligente admite esta característica. 1 (Habilitado): la característica de desbloqueo integrado estará disponible. 0 (Deshabilitado): la característica de desbloqueo integrado no estará disponible. No configurado: la característica de desbloqueo integrado no estará disponible.
ReverseSubject	Permite invertir el nombre del firmante de cómo se almacena en el certificado al mostrarlo durante el inicio de sesión. De forma predeterminada, se muestra el nombre principal de usuario (UPN) además del nombre común, para ayudar a los usuarios a distinguir un certificado de otro. Por ejemplo, si el firmante del certificado es CN=User1, OU=Users, DN=contoso, DN=com y si tenía un UPN de user1@contoso.com, se mostrará "User1" junto con "user1@contoso.com". Si el UPN no está presente, se mostrará el nombre completo del firmante. Esta configuración controla la apariencia de ese nombre de sujeto y es posible que tenga que ajustarse por organización. 1 (Habilitado): se invertirá el nombre del firmante. 0 (Deshabilitado): el nombre del firmante se mostrará como aparece en el certificado. No configurado: se revertirá el nombre del firmante.
X509HintsNeededed	Permite determinar si se mostrará un campo opcional durante el inicio de sesión y la elevación que permite a un usuario escribir su nombre de usuario o nombre de usuario y dominio, asociando así un certificado con ese usuario. 1 (Habilitado): se mostrará un campo opcional que permite a un usuario escribir su nombre de usuario o nombre de usuario y dominio. 0 (Deshabilitado): no se muestra el campo opcional. No configurado: no se muestra el campo opcional.
IntegratedUnblockPromptString	Permite administrar una cadena específica cuando se bloquea una tarjeta inteligente. 1 (Habilitado): la cadena especificada se mostrará al usuario cuando se bloquee la tarjeta inteligente. Nota También debe asegurarse de habilitar la siguiente configuración en directiva de grupo: Permitir que la pantalla de desbloqueo integrado se muestre en el momento del inicio de sesión. 0 (Deshabilitado): la cadena predeterminada se mostrará al usuario cuando se bloquee la tarjeta inteligente, si la característica de desbloqueo integrado está habilitada. No configurado: la cadena predeterminada se mostrará al usuario cuando se bloquee la tarjeta inteligente, si la característica de desbloqueo integrado está habilitada.
CertPropEnabledString	Permite administrar la propagación del certificado que se produce cuando se inserta una tarjeta inteligente. 1 (Habilitado): la propagación de certificados se producirá al insertar la tarjeta inteligente. 0 (Deshabilitado): no se producirá la propagación del certificado y los certificados no estarán disponibles para aplicaciones como Outlook. No configurado: la propagación de certificados se producirá al insertar la tarjeta inteligente.
CertPropRootEnabledString	Permite administrar la propagación del certificado raíz que se produce cuando se inserta una tarjeta inteligente. 1 (Habilitado): la propagación del certificado raíz se producirá al insertar la tarjeta inteligente. Nota Para que esta configuración de directiva funcione, también se debe habilitar la siguiente configuración de directiva: Activar la propagación de certificados desde la tarjeta inteligente. 0 (Deshabilitado): los certificados raíz no se propagarán desde la tarjeta inteligente. No configurado: la propagación del certificado raíz se producirá al insertar la tarjeta inteligente.
RootsCleanupOption	Permite configurar la limpieza del certificado raíz. Esta opción se encuentra en HKLM\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\CertProp. Permite administrar el comportamiento de limpieza de los certificados raíz. Si habilita esta configuración de directiva, se producirá la limpieza del certificado raíz según la opción seleccionada. Si deshabilita o no establece esta configuración, la limpieza del certificado raíz se producirá en el inicio de sesión. Las opciones de limpieza de certificados raíz incluyen: Sin limpieza (valor predeterminado) Limpieza de certificados en la eliminación de tarjetas inteligentes Limpieza de certificados en el inicio de sesión de usuario Nota Esta directiva funciona junto con HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots\Flags. Si se establece (desactivado de forma predeterminada), los certificados raíz se deshabilitarán para la propagación, incluso desde la tarjeta inteligente.
Requerir tarjeta inteligente (directiva de equipo): directivas para el inicio de sesión interactivo. Vea la figura 9.	Aplica la tarjeta inteligente necesaria para iniciar sesión por equipo. Esta clave se encuentra en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Policies\System\scforceoption. A continuación se muestran los valores admitidos: 0: Sin acción 1: Habilitación de la tarjeta inteligente requerida para el inicio de sesión
Directiva de eliminación de tarjetas inteligentes: directivas para el inicio de sesión interactivo. Vea la figura 10.	Nota Si el servicio de directiva de eliminación de tarjetas inteligentes no se está ejecutando, inicie el servicio con el comando net start ScPolicySvc y establezca el tipo de inicio en Auto (sc config scpolicysvc start= auto). Esta clave se encuentra en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\scremoveoption. Si se establece (desactivado, 0, de forma predeterminada), la eliminación de la tarjeta inteligente bloqueará la estación de trabajo. A continuación se muestran los valores admitidos: 0: Sin acción 1: Bloquear estación de trabajo: sesión de usuario bloqueada en la eliminación de tarjetas inteligentes 2: Cerrar sesión : el usuario ha desactivado la eliminación de la tarjeta inteligente 3: Desconectar de la sesión remota de Terminal Server: la eliminación de la tarjeta inteligente desconecta la sesión sin cerrar la sesión. Esto permite al usuario insertar la tarjeta inteligente y reanudar la sesión más adelante, o en otro terminal equipado con lector de tarjetas inteligentes, sin tener que volver a iniciar sesión.
FilterDuplicateCertificates	Permite configurar si se muestran todos los certificados de inicio de sesión válidos. Durante el período de renovación de certificados, un usuario puede tener varios certificados de inicio de sesión válidos emitidos a partir de la misma plantilla de certificado. Esto puede provocar confusión en cuanto al certificado que se va a seleccionar para iniciar sesión. El caso común de este comportamiento es cuando se renueva un certificado y el antiguo aún no ha expirado. Se determina que dos certificados son los mismos si se emiten desde la misma plantilla con la misma versión principal y son para el mismo usuario (determinado por su UPN). Si dos o más del certificado "mismo" están en una tarjeta inteligente y esta directiva está habilitada, se mostrará el certificado que se usa para iniciar sesión en Windows 2000, Windows XP y Windows 2003 Server. De lo contrario, se mostrará el certificado con la hora de expiración más larga en el futuro. Nota Esta configuración se aplica después de la siguiente configuración: Permitir el tiempo certificados no válidos. 1 (Habilitado): se producirá el filtrado. 0 (Deshabilitado): no se producirá ningún filtrado. No configurado: se producirá el filtrado.
ForceReadingAllCertificates	Permite forzar la lectura de todos los certificados de la tarjeta inteligente, independientemente de la característica admitida establecida en el CSP. Esta directiva es aplicable cada vez que se llama al proveedor de credenciales de tarjeta inteligente o a la interfaz de usuario de credenciales. 1 (Habilitado): Windows intentará leer todos los certificados de la tarjeta inteligente, independientemente del conjunto de características del CSP. 0 (Deshabilitado): Windows solo leerá el contenedor predeterminado de la tarjeta inteligente para el inicio de sesión, a menos que admita la recuperación de todos los certificados en una sola llamada. Los certificados almacenados en otro lugar que en el contenedor predeterminado no estarán disponibles para el inicio de sesión. No configurado: Windows solo leerá el contenedor predeterminado de la tarjeta inteligente para el inicio de sesión, a menos que admita la recuperación de todos los certificados en una sola llamada. Los certificados almacenados en otro lugar que en el contenedor predeterminado no estarán disponibles para el inicio de sesión.

El siguiente valor de directiva de grupo se encuentra en el Registro en HKLM\SYSTEM\CCS\Services\Kdc\Parameters\.

Tabla 8

Clave	Descripción
SCLogonEKUNotRequired	Si habilita esta configuración, el KDC no requerirá el certificado de tarjeta inteligente que contiene la EKU de autenticación de tarjeta inteligente. Tipo: DWORD Valor predeterminado: 0

Nota

Durante la implementación, es posible que se requieran directivas adicionales para facilitar el uso o para mejorar la seguridad. Algunas de estas directivas incluyen:

Desactivar la delegación para equipos.

Inicio de sesión interactivo: no requiere CTRL+ALT+SUPR (no recomendado).

Configuración de directivas locales de CSP base

La configuración local del CSP base se encuentra en el registro en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Base proveedor criptográfico de tarjeta inteligente.

Nota

La configuración local de KSP de la tarjeta inteligente se encuentra en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Microsoft proveedor de claves de tarjeta inteligente Storage.

Puede configurar las mismas claves para el CSP base y el KSP. En la tabla 9 se muestran estas claves.

Tabla 9 Configuración de directivas locales para CSP base y KSP de tarjeta inteligente

Clave	Descripción
DefaultPrivateKeyLenBits	Tipo: DWORD Valor predeterminado: 00000400 Parámetro de generación de claves predeterminado: claves de 1024 bits
RequireOnCardPrivateKeyGen	Si se establece este valor, se puede importar una clave generada en un host en la tarjeta inteligente. Esto se usa para tarjetas inteligentes que no admiten la generación de claves en la tarjeta o donde se requiere custodia de claves. Tipo: DWORD Valor predeterminado: 00000000. Esto establece la marca para requerir la generación de claves privadas en la tarjeta (valor predeterminado).
TransactionTimeoutMilliseconds	Tipo: DWORD Valor predeterminado: 000005dc1500. 1,5 segundos es el tiempo de espera predeterminado para mantener transacciones en la tarjeta inteligente.
AllowPrivateECDHEKeyImport	Este valor permite la importación de la clave privada ECDHE para su uso en escenarios de archivado de claves. Tipo: DWORD Valor predeterminado: 00000000.
AllowPrivateECDSAKeyImport	Este valor permite la importación de la clave privada ECDSA para su uso en escenarios de archivado de claves. Tipo: DWORD Valor predeterminado: 00000000

directiva de grupo directrices para los administradores que implementan la tarjeta inteligente solo inician sesión

Configuración de una cuenta de usuario para el inicio de sesión solo con tarjeta inteligente

Para configurar una cuenta de usuario para el inicio de sesión de solo tarjeta inteligente de usuario

1. Inicie sesión en un equipo Windows Server como administrador de dominio.

2. Haga clic en Inicio, en Ejecutar, escriba DSA.msc y, a continuación, haga clic en Aceptar.

3. En el árbol de consola, expanda Usuarios y equipos de Active Directory, expanda el dominio que desea configurar y, a continuación, haga clic en Usuarios.

4. En el panel de detalles, haga clic con el botón derecho en el usuario para el que desea habilitar el inicio de sesión de solo tarjeta inteligente y, a continuación, haga clic en Propiedades.

5. En el cuadro de diálogo propiedades de la cuenta, haga clic en la pestaña Cuenta .

6. En Opciones de cuenta, active la casilla Tarjeta inteligente para el inicio de sesión interactivo y, a continuación, haga clic en Aceptar.

   En la figura 8 se muestra esta configuración.

Figura 8 Sin delegación y configuración de dominio de cuenta de usuario necesaria para tarjeta inteligente

En la figura 9 se muestra cómo la configuración de la figura 8 configurará la configuración de directiva local.

Figura 9 Requerir configuración de tarjeta inteligente (aplicada por equipo)

En la figura 10 se muestra cómo habilitar la directiva de eliminación de tarjetas inteligentes.

Figura 10 Configuración de eliminación de tarjetas inteligentes

En entornos de solo tarjeta inteligente, una configuración de directiva útil sería deshabilitar CTRL+ALT+SUPR. En la figura 11 se muestra dónde puede configurarlo en directiva de grupo.

Figura 11 No requerir CTRL+ALT+SUPR en la configuración de la pantalla de inicio de sesión

En la figura 12 se muestra cómo habilitar cuentas de usuario o equipos para la delegación. Le recomendamos encarecidamente que considere cuidadosamente los cambios que realice en la delegación de usuarios y equipos. Los riesgos de seguridad podrían ser muy altos en algunos escenarios. Sin embargo, la delegación puede ser útil al ejecutar Windows Instrumentación administrada (WMI).

Figura 12 Configuración de delegación de usuarios y equipos

Si los administradores de tarjetas inteligentes usan el equipo, se recomienda encarecidamente deshabilitar la delegación en el equipo. En la figura 13 se muestra esta configuración en directiva de grupo.

Figura 13 No confiar en la configuración del dominio de delegación

servicios de Windows Vista

Tres servicios en Windows Vista permiten la administración de tarjetas inteligentes:

• Servicio administrador de recursos de tarjeta inteligente
• Servicio de propagación de certificados
• Servicio de eliminación de tarjetas inteligentes

Servicio administrador de recursos de tarjeta inteligente

El administrador de recursos de tarjeta inteligente proporciona la infraestructura básica para todos los demás componentes de tarjeta inteligente. El administrador de recursos de tarjeta inteligente administra los lectores de tarjetas inteligentes y las interacciones de la aplicación en el equipo. Es totalmente compatible con PC/SC 1.0.

El administrador de recursos de tarjeta inteligente se ejecuta en el contexto de un servicio local y se implementa como un servicio compartido del proceso de svchost. El servicio resource manager de tarjeta inteligente tiene la siguiente descripción del servicio:

<serviceData name="SCardSvr"
displayName="@%SystemRoot%\System32\SCardSvr.dll,-1"
errorControl="normal" group="SmartCardGroup" 
imagePath="%SystemRoot%\system32\svchost.exe /k
LocalService" start="demand" tag="" 
type="win32ShareProcess" security=""
description="@%SystemRoot%\System32\SCardSvr.dll,-5
requiredPrivileges="SeCreateGlobalPrivilege,SeChangeNotifyPrivilege,SeImpersonatePrivilege" 
dependOnGroup="" dependOnService="PlugPlay" 
objectName="NT AUTHORITY\LocalService">
     <failureActions resetPeriod="900">
       <actions>
         <action type="restartService" delay="120000"/>
         <action type="restartService" delay="300000"/>
         <action type="none" delay="0"/>
       </actions>
     </failureActions>
     <registryKeys>
       <registryKey keyName="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SCardSvr\Parameters">
        <registryValue name="ServiceDll" valueType="REG_EXPAND_SZ" value="%SystemRoot%\System32\SCardSvr.dll" buildFilter=""></registryValue>
        <registryValue name="ServiceMain" valueType="REG_SZ" value="CalaisMain" buildFilter=""></registryValue>
        <registryValue name="ServiceDllUnloadOnStop" valueType="REG_DWORD" value="1" buildFilter=""></registryValue>
       </registryKey>
       <securityDescriptor name="ServiceXKeySecurity"/>
     </registryKeys>
     <securityDescriptor name="ServiceXSecurity" buildFilter=""/>
  </serviceData>

Nota

El archivo inf debe especificar lo siguiente para Class y ClassGUID para que winscard.dll se invoque como el instalador de clase adecuado:

Class=SmartCardReader

ClassGuid={50DD5230-BA8A-11D1-BF5D-0000F805F530}

De forma predeterminada, el servicio está configurado para el modo manual. Los autores de controladores lectores de tarjetas inteligentes deben configurar el servicio para iniciarse automáticamente y llamar a un punto de entrada predefinido en winscard.dll que iniciará el servicio. El uso de este método garantiza que el servicio está habilitado cuando es necesario, pero también está deshabilitado para la gran mayoría de los usuarios que no usan tarjetas inteligentes.

Cuando se inicia el servicio, realiza varias funciones de contabilidad. El servicio se registra primero para las notificaciones del servicio. También se registra para las notificaciones de Plug and Play (PnP) para la eliminación y adiciones de dispositivos. También inicializa su caché de datos y un evento global que indica que el servicio se ha iniciado.

Se recomienda encarecidamente enviar todas las comunicaciones con lectores de tarjetas inteligentes en Windows a través del administrador de recursos de tarjeta inteligente. Proporciona una interfaz enriquecida para realizar un seguimiento, seleccionar y comunicarse con todos los controladores que declaran a sí mismos miembros del grupo de dispositivos lectores de tarjetas inteligentes. El administrador de recursos de tarjeta inteligente clasifica cada ranura de lector de tarjetas inteligentes como lector único. Cada ranura también se administra por separado, independientemente de las características físicas del dispositivo. El administrador de recursos de tarjeta inteligente controla las siguientes acciones de alto nivel:

• Introducción al dispositivo
• Inicialización del lector
• Notificar a los clientes de nuevos lectores
• Serialización del acceso a los lectores
• Acceso a tarjetas inteligentes
• Tunelización de comandos específicos del lector

Servicio de propagación de certificados

El servicio de propagación de certificados se aplica cuando un usuario que ha iniciado sesión inserta una tarjeta inteligente en un lector que está conectado al equipo. Esta acción hace que los certificados se lean desde la tarjeta inteligente. A continuación, los certificados se agregan al almacén personal del usuario. La acción de servicio se controla con directiva de grupo, como se muestra en la tabla 7.

En la figura 14 se muestra el flujo del modelo de propagación de certificados. En el diagrama, un usuario que ha iniciado sesión inserta una tarjeta inteligente. La primera flecha indica que el controlador de servicio notifica a CertPropSvc cuando un usuario ha iniciado sesión. En la notificación de inicio de sesión, CertPropSvc comienza a supervisar las tarjetas inteligentes que son visibles desde la sesión del usuario. La flecha marcada como R representa la posibilidad de una sesión remota y el uso de redireccionamiento de tarjetas inteligentes.

Figura 14 Servicio de propagación de certificados

1. Un usuario que ha iniciado sesión inserta una tarjeta inteligente.
2. CertPropSvc recibe una notificación de que se ha insertado una tarjeta inteligente.
3. CertPropSvc lee todos los certificados de todas las tarjetas inteligentes insertadas. Los certificados se escriben en el almacén de certificados personal del usuario.

Nota

El servicio de propagación de certificados se inicia como una dependencia del servicio Terminal Services.

A continuación se enumeran las propiedades del servicio de propagación de certificados:

• El servicio usa la propiedad CERT_STORE_ADD_REPLACE_EXISTING_INHERIT_PROPERTIES para agregar certificados al almacén Personal de un usuario.
• Si el certificado tiene la propiedad CERT_ENROLLMENT_PROP_ID (definida por wincrypt.h), no propagará solicitudes vacías al almacén Personal del usuario, pero los filtrará para colocarlos en el almacén de solicitudes del usuario actual.
• El servicio no propagará ningún certificado de equipo al almacén Personal de un usuario o viceversa.
• El servicio propaga los certificados según directiva de grupo opciones. Estas opciones se detallan en la tabla 7.
  • CertPropEnabledString: especifica si se debe propagar el certificado de un usuario.
  • CertPropRootEnabledString: especifica si se deben propagar los certificados raíz, incluidas las opciones de limpieza.

Propagación del certificado raíz

La propagación del certificado raíz es responsable de escenarios específicos de implementación de tarjetas inteligentes, donde aún no se ha establecido la confianza de PKI:

• Unión al dominio
• Acceso a una red de forma remota

En ambos casos, el equipo no está unido a un dominio y, por lo tanto, la confianza no se administra mediante directiva de grupo. Sin embargo, el objetivo es autenticarse en un servidor remoto (el controlador de dominio o el servidor RADIUS). La propagación del certificado raíz proporciona la capacidad de usar la tarjeta inteligente para incluir la cadena de confianza que falta.

En la inserción de tarjetas inteligentes, el servicio de propagación de certificados propagará los certificados raíz de la tarjeta a los almacenes de certificados del equipo raíz de tarjeta inteligente de confianza. Este proceso establece una relación de confianza con la empresa. También puede usar una acción de limpieza posterior cuando la tarjeta inteligente del usuario se quita del lector o cuando el usuario cierra sesión. En la tabla 7 se muestra cómo se puede configurar con directiva de grupo.

Para obtener más información sobre los requisitos de certificado raíz, consulte Requisitos de certificado raíz de tarjeta inteligente para el usuario con una unión a un dominio.

Servicio de directiva de eliminación de tarjetas inteligentes

La directiva de eliminación de tarjetas inteligentes es aplicable cuando un usuario ha iniciado sesión con una tarjeta inteligente y, posteriormente, quita esa tarjeta inteligente del lector. La acción que se realiza cuando se quita la tarjeta inteligente se controla con directiva de grupo, como se muestra en la tabla 7.

Figura 15 Servicio de directiva de eliminación de tarjetas inteligentes

1. En Windows Vista, Winlogon ya no participa directamente en la supervisión de eventos de eliminación de tarjetas inteligentes. La secuencia de pasos implicados en la directiva de eliminación comienza con el proveedor de credenciales de tarjeta inteligente en el proceso de interfaz de usuario de inicio de sesión. Cuando un usuario inicia sesión correctamente con una tarjeta inteligente, el proveedor de credenciales de tarjeta inteligente captura el número de veces que la tarjeta inteligente se ha insertado o quitado del lector (el recuento de actividades), así como el nombre del lector. A continuación, esta información se almacena en el registro, junto con el identificador de sesión donde se inició el inicio de sesión. El recuento de actividades es los 16 bits superiores del campo dwEventState del lector, como se ve en SCardGetStatusChange.
2. El administrador de recursos de tarjeta inteligente notifica al servicio de directiva de eliminación de tarjetas inteligentes que se ha producido un inicio de sesión.
3. ScPolicySvc recupera las estadísticas de la tarjeta inteligente del registro que el proveedor de credenciales de tarjeta inteligente había almacenado. Estas estadísticas se usan para asegurarse de que la tarjeta inteligente no se quitó y que podría haberse reinsertado durante la entrega entre cuando el proveedor de credenciales de tarjeta inteligente cuando y ScPolicySvc comenzaron a supervisar la tarjeta inteligente para las eliminaciones. Esta llamada se redirige si el usuario está en una sesión remota. Una vez que el usuario quite la tarjeta inteligente o si la tarjeta inteligente se quitó durante la entrega, se notifica a ScPolicySvc.
4. ScPolicySvc llama a Terminal Server para realizar la acción adecuada si la solicitud es cerrar la sesión del usuario o desconectar la sesión del usuario. (Esto podría dar lugar a una pérdida de datos). Si la configuración está configurada para bloquear el equipo cuando se quita la tarjeta inteligente, ScPolicySvc envía un mensaje a Winlogon para bloquear el equipo.

Escenarios de Windows Vista

Requisitos de certificado para el inicio de sesión de tarjeta inteligente

Requisitos de certificado para Windows XP y versiones anteriores

El certificado de tarjeta inteligente tiene requisitos de formato específicos cuando se usa con Windows XP y plataformas anteriores.

Tabla 10 Requisitos de certificado previos a Windows Vista

Componente	Requisito
Ubicación del punto de distribución de CRL (CDP)	La ubicación debe rellenarse, en línea y estar disponible. Por ejemplo: [1] Punto de distribución CRL Nombre del punto de distribución: Nombre completo: URL=http://server1.contoso.com/CertEnroll/caname.crl
Uso de las claves	Firma digital
Restricciones básicas	[Subject Type=End Entity, Path Length Constraint=None] (Opcional)
Uso mejorado de clave	Autenticación de cliente (1.3.6.1.5.5.7.3.2) (El identificador de objeto de autenticación de cliente solo es necesario si se usa un certificado para la autenticación SSL). Inicio de sesión de tarjeta inteligente (1.3.6.1.4.1.311.20.2.2)
Nombre alternativo del sujeto	Otro nombre: nombre principal= (UPN). Por ejemplo: UPN = user1@contoso.com El OID de UPN OtherName es "1.3.6.1.4.1.311.20.2.3". El valor de UPN OtherName debe ser cadena UTF8 codificada en ASN1.
Asunto	Nombre distintivo del usuario. Este campo es una extensión obligatoria, pero el rellenado de este campo es opcional.

Hay dos tipos predefinidos de claves privadas. Estas claves son Solo firma (AT_SIGNATURE) y Exchange de clave (AT_KEYEXCHANGE). Los certificados de inicio de sesión de tarjeta inteligente deben tener un tipo de clave privada Exchange (AT_KEYEXCHANGE) para que el inicio de sesión de tarjeta inteligente funcione correctamente.

Requisitos de certificado para Windows Vista

Tabla 11 Windows requisitos de certificado de Vista

Componente	Requisito
CRL	No se requiere
UPN	No se requiere
Uso de las claves	Firma digital
Uso mejorado de clave	El identificador de objeto de inicio de sesión de tarjeta inteligente no es necesario. Consulte la tabla 7.
Nombre alternativo del sujeto	El identificador de correo electrónico no es necesario para el inicio de sesión de tarjeta inteligente. Consulte la tabla 7.
Intercambio de claves (campo AT_KEYEXCHANGE)	No es necesario para los certificados de inicio de sesión de tarjeta inteligente.

Puede permitir que cualquier certificado sea visible para el proveedor de credenciales de tarjeta inteligente. Si hay una EKU presente, debe contener la EKU de inicio de sesión de tarjeta inteligente. Los certificados sin EKU se pueden usar para iniciar sesión.

¿Cómo funciona el inicio de sesión de tarjeta inteligente en Windows?

Aunque Microsoft Windows 2000 y versiones posteriores incluían compatibilidad con tarjetas inteligentes, los tipos de certificados que las tarjetas inteligentes podían contener eran limitadas. Las limitaciones eran:

• Cada certificado necesario para tener un nombre principal de usuario (UPN) y necesario para contener el identificador de objeto de inicio de sesión de tarjeta inteligente (también conocido como OID) en el campo atributo EKU. Si la EKU está presente, debe tener el OID de inicio de sesión de tarjeta inteligente presente. Hay una configuración de directiva de grupo para que EKU sea opcional.

• Cada certificado tenía que almacenarse en la parte AT_KEYEXCHANGE del contenedor CAPI predeterminado.

  Nota

  No se admiten contenedores CAPI no predeterminados.

• Los certificados deben tener un valor de uso de clave de firma digital. Este requisito continúa para Windows Vista.

Para mejorar la compatibilidad con las implementaciones de tarjetas inteligentes, se realizaron cambios en Windows para habilitar la compatibilidad con un intervalo de certificados que no tienen las limitaciones anteriores.

Inicio de sesión basado en tarjeta inteligente en Windows Vista

El inicio de sesión de tarjeta inteligente en Windows Vista ha cambiado en varios aspectos clave. A continuación se resaltan las diferencias principales:

• El inicio de sesión ya no se desencadena en la inserción de tarjetas inteligentes. Normalmente, los usuarios deben presionar CTRL+ALT+SUPR para iniciar el proceso de inicio de sesión.
• Los certificados válidos se enumeran y muestran desde todas las tarjetas inteligentes y se presentan al usuario. La tarjeta inteligente debe insertarse para que el usuario pueda escribir el PIN.
• Las claves ya no están restringidas a estar en el contenedor predeterminado y se pueden elegir certificados en diferentes tarjetas inteligentes.
• Se accede al CSP (como se describe en inicio de sesión de tarjeta inteligente Flow en Windows Vista) en lsass.exe. El CSP nunca se carga en el proceso de Winlogon.
• Se admiten varias sesiones de Terminal Services en un único proceso. Dado que Windows Vista está integrado con Terminal Services para proporcionar el cambio rápido de usuario, no debe pasar por alto este hecho.
• Los certificados basados en ECC no se admiten para el inicio de sesión de tarjeta inteligente en Windows. PKINIT basado en ECC todavía se está estandarizando como parte de IETF (http://www.ietf.org/html.charters/krb-wg-charter.html).

Enumeración de certificados

Cuando se inserta una tarjeta inteligente, se realizan los pasos siguientes:

Nota

A menos que se mencione lo contrario, todas las operaciones se realizan de forma silenciosa (CRYPT_SILENT se pasa a CryptAcquireContext).

1. La base de datos del administrador de recursos de tarjeta inteligente consulta el CSP de la tarjeta inteligente.
2. Un nombre de contenedor completo se construye mediante el nombre del lector obtenido y se pasa al CSP. El formato de ese nombre es el siguiente: \\.\<Nombre del lector>\
3. Se llama a CryptAcquireContext para recuperar un contexto en el contenedor predeterminado. Un error aquí provocaría que la tarjeta inteligente no se pueda usar para el inicio de sesión de tarjeta inteligente.
4. El nombre del contenedor se recupera solicitando el parámetro PP_CONTAINER mediante CryptGetProvParam.
5. Con el contexto adquirido en el paso 3, el CSP se consulta para el parámetro PP_USER_CERTSTORE, que se agregó en Windows Vista. (Consulte Arquitectura del subsistema de tarjeta inteligente para obtener más información). Si la operación se realiza correctamente, se devuelve un almacén de certificados y el flujo del programa pasa al paso 8.
6. Si se produce un error en la operación del paso 5, se consulta el contexto de contenedor predeterminado del paso 3 para la clave de AT_KEYEXCHANGE .
7. A continuación, el certificado se consulta desde el contexto de clave mediante KP_CERTIFICATE. El certificado se agrega a un almacén de certificados en memoria.
8. Para cada certificado del almacén de certificados del paso 5 o del paso 7, se realizan las siguientes comprobaciones:
   1. El certificado debe ser válido en función del reloj del sistema del equipo (no expirado o válido en el futuro).
   2. El certificado no debe estar en la parte AT_SIGNATURE de un contenedor.
   3. El certificado debe tener un UPN válido.
   4. El certificado debe tener el uso de clave de firma digital.
   5. El certificado debe tener la EKU de inicio de sesión de tarjeta inteligente.
      Estos requisitos son los mismos que en Windows 2003, pero se realizan antes de que el usuario escriba el PIN. Puede invalidar muchos de ellos mediante directiva de grupo configuración.
      Cualquier certificado que cumpla estos requisitos se muestra al usuario junto con el UPN del certificado (o dirección de correo electrónico o asunto, dependiendo de la presencia de las extensiones de certificado).
9. A continuación, se elige un certificado y se escribe el PIN.
10. LogonUI.exe empaqueta la información y la envía a lsass.exe para procesar el intento de inicio de sesión.
11. Si se ejecuta correctamente, logonUI.exe se descompone. Esto hace que el contexto adquirido en el paso 3 se libere.

Flujo de inicio de sesión de tarjeta inteligente en Windows Vista

La mayoría de los problemas durante la autenticación se producirán debido al comportamiento de la sesión. Además, el LSA no vuelve a adquirir el contexto; se basa en el CSP para controlar el cambio de sesión.

permite la compatibilidad con certificados de cliente que no contienen un UPN en el campo subjectAltName (SAN) del certificado y admite una variedad mucho más amplia de certificados, incluidos varios certificados.

Sin embargo, estos cambios no están habilitados de forma predeterminada, excepto para la compatibilidad con varios certificados. (Algunos certificados se excluyen). Los administradores deben establecer las claves del Registro en los clientes (por ejemplo, con directiva de grupo) para habilitar la funcionalidad.

De forma predeterminada, los clientes filtrarían los certificados del cliente en la tarjeta inteligente mediante la EKU de autenticación de cliente. El proveedor de credenciales también tiene una directiva, AllowSignatureOnlyKeys (correspondiente al valor de clave de AT_SIGNATURE en CAPI), para determinar si necesita filtrar los certificados de cliente en función de un requisito de que el certificado de inicio de sesión pueda realizar el cifrado al permitir que el usuario muestre y seleccione certificados de solo firma. Esta configuración de directiva tiene un efecto directo sobre el filtrado y la visualización resultante de los certificados en la interfaz de usuario de inicio de sesión.

En la figura 16 se muestra cómo funciona el inicio de sesión de tarjeta inteligente en Windows Vista.

Figura 16 Flujo de inicio de sesión de tarjeta inteligente

Flow secuencia:

1. WinLogon solicita la información de credenciales de la interfaz de usuario de inicio de sesión.

2. De forma asincrónica, se inicia el administrador de recursos de tarjeta inteligente. El proveedor de credenciales de tarjeta inteligente:

   1. Obtiene información de credenciales, una lista de credenciales conocidas o ninguna, o que Windows detectó un lector de tarjetas inteligentes.
   2. Obtiene una lista de lectores de tarjetas inteligentes (usa winSCard API) y la lista de tarjetas inteligentes insertadas en cada una de ellas.
   3. Enumera cada tarjeta para comprobar si hay un certificado de inicio de sesión (firma) controlado por directiva de grupo. Si el certificado está presente, el proveedor de credenciales de tarjeta inteligente lo copia en una caché segura temporal en el terminal.
   4. Notifica a la interfaz de usuario de inicio de sesión que tiene nuevas credenciales.

3. La interfaz de usuario de inicio de sesión solicita las nuevas credenciales del proveedor de credenciales de tarjeta inteligente. Como respuesta, el proveedor de credenciales de tarjeta inteligente proporciona a la interfaz de usuario de inicio de sesión cada certificado de inicio de sesión para el que se muestra un icono de inicio de sesión correspondiente. El usuario selecciona un icono de certificado de inicio de sesión basado en tarjeta inteligente y Windows muestra un cuadro de diálogo PIN.

4. El usuario escribe el PIN y hace clic en Ir. El proveedor de credenciales de tarjeta inteligente cifra el PIN.

5. El proveedor de credenciales que reside en el proceso logonUI (sistema) recopila el PIN. Como parte del empaquetado de credenciales en el proveedor de credenciales de tarjeta inteligente, los datos se empaquetan en una estructura de KERB_CERTIFICATE_LOGON (definida en CredentialProviders.h). El contenido principal de la estructura KERB_CERTIFICATE_LOGON son el PIN de tarjeta inteligente, cspdata (contiene el nombre del lector, el nombre del contenedor, etc.), el nombre de usuario y el nombre de dominio. El nombre de usuario es necesario si el dominio de inicio de sesión no está en el mismo bosque, ya que permite asignar un certificado a varias cuentas de usuario.

6. El proveedor de credenciales ahora encapsula los datos (como el PIN cifrado, el nombre del contenedor, el nombre del lector y la especificación de clave de tarjeta) y se devuelve a LogonUI.

7. LogonUI presenta los datos a LSA con Winlogon para LSALogonUser.

8. LSA llama al paquete de autenticación Kerberos (SSP de Kerberos) para crear una solicitud de servicio de autenticación Kerberos (KRB_AS_REQ) que contenga un autenticador previo (como se especifica en RFC 4556: criptografía de clave pública para la autenticación inicial en Kerberos (PKINIT) (https://go.microsoft.com/fwlink/?LinkId=93352)).
   Si la autenticación se realiza mediante un certificado con un uso clave de firma digital, los datos previos a la autenticación constan del certificado público del usuario y el certificado se firma digitalmente con la clave privada correspondiente.
   Si la autenticación está con un certificado con un uso clave de cifrado de clave, los datos de autenticación previa constan del certificado público del usuario y el certificado se cifra con la clave privada correspondiente.

9. Para firmar la solicitud digitalmente (según RFC 4556), se realiza una llamada al CSP correspondiente para una operación de clave privada. Dado que la clave privada en este caso se almacena en una tarjeta inteligente, se llama al subsistema de la tarjeta inteligente y se completa la operación necesaria. El resultado se devuelve al SSP de Kerberos.

10. El SSP de Kerberos envía una solicitud de autenticación (según RFC 4556) al servicio centro de distribución de claves (KDC) que se ejecuta en un controlador de dominio, para solicitar un vale de concesión de vales (TGT).

11. El KDC busca el objeto de cuenta del usuario en active directory, tal como se detalla en Asignaciones de certificados de cliente y usa el certificado del usuario para comprobar la firma.

12. El KDC valida el certificado del usuario (hora, ruta de acceso y estado de revocación) para asegurarse de que el certificado procede de un origen de confianza. El KDC usa CryptoAPI (CAPI2) para crear una ruta de certificación desde el certificado del usuario a un certificado de CA raíz que reside en el almacén raíz del controlador de dominio. A continuación, el KDC usa CryptoAPI (CAPI2) para comprobar la firma digital en el autenticador que se incluyó como datos firmados en los campos de datos de autenticación previa. El controlador de dominio comprueba la firma y usa la clave pública del certificado del usuario para demostrar que la solicitud se originó en el propietario de la clave privada que corresponde a la clave pública. El KDC también comprueba que el emisor es de confianza y aparece en el almacén de certificados NTAUTH.

13. El servicio KDC recupera información de la cuenta de usuario de Active Directory. El KDC construye un TGT basado en la información de la cuenta de usuario que recupera de Active Directory. El TGT incluye el identificador de seguridad (SID) del usuario, los SID para los grupos de dominios universales y globales a los que pertenece el usuario y (en un entorno de varios dominios) los SID para los grupos universales de los que es miembro el usuario. Los campos de datos de autorización de TGT incluyen la lista de SID.

14. El controlador de dominio devuelve el TGT al cliente como parte de la respuesta KRB_AS_REP.

    Nota

    El paquete KRB_AS_REP consta de:

    Certificado de atributo de privilegios (PAC)

    Identificador de seguridad (SID) del usuario

    SID de los grupos de los que el usuario es miembro

    Solicitud de servicio de concesión de vales (TGS)

    Datos de autenticación previa

    La respuesta es según RFC 4556. TGT se cifra con la clave maestra del KDC y la clave de sesión se cifra con una clave temporal. Esta clave temporal se deriva en función de RFC 4556. Con las API CAPI2, se descifra la clave temporal. Como parte del proceso de descifrado, si la clave privada para lo mismo sucede en una tarjeta inteligente, la llamada se realiza de nuevo al subsistema de tarjeta inteligente mediante el proveedor de servicios criptográficos especificado para extraer el certificado correspondiente a la clave pública del usuario. (Las llamadas mediante programación incluyen CryptAcquireContext, CryptSetProvParam con el PIN, CryptgetUserKey, CryptGetKeyParam para el certificado). Una vez obtenida la clave temporal, el SSP \ Kerberos descifra la clave de sesión.

15. El cliente valida la respuesta del KDC (hora, ruta de acceso y estado de revocación). Primero comprueba la firma del KDC mediante la construcción de una ruta de certificación desde el certificado del KDC a una ENTIDAD de certificación raíz de confianza y, a continuación, usa la clave pública del KDC para comprobar la firma de respuesta.

16. Ahora que se ha obtenido un TGT, el cliente obtiene una incidencia de servicio en el equipo local para iniciar sesión en el equipo.

17. Si se ejecuta correctamente, LSA almacena los vales y devuelve el éxito a LSALogonUser. En este mensaje de éxito, se realizan perfiles de usuario, directiva de grupo y otras acciones.

18. Una vez cargado el perfil de usuario, CertPropSvc recoge este evento, lee los certificados de la tarjeta (incluidos los certificados raíz) y, a continuación, los rellena en el almacén de certificados del usuario (MYSTORE).

19. La comunicación del administrador de recursos de CSP a tarjeta inteligente se produce en el canal LRPC.

20. En la autenticación correcta, los certificados se propagarán de forma asincrónica al almacén del usuario (MYSTORE) mediante el servicio de propagación de certificados (CertPropSvc).

21. Cuando se quita la tarjeta, se quitan los certificados del almacén de caché segura temporal. Los certificados ya no están disponibles para el inicio de sesión, pero seguirán siendo el almacén de certificados del usuario (MYSTORE).

Nota

Un SID es un identificador de seguridad que se crea para cada usuario o grupo, en el momento en que se crea una cuenta de usuario o una cuenta de grupo dentro de la base de datos de cuentas de seguridad local en Windows equipos NT o superiores, o dentro de Active Directory. El SID nunca cambia, incluso si se cambia el nombre de la cuenta de usuario o grupo.

Para obtener más información sobre Kerberos, consulte Funcionamiento del protocolo de autenticación kerberos versión 5 (https://go.microsoft.com/fwlink/?LinkID=27175).

De forma predeterminada, el KDC comprueba que el certificado del cliente contiene la EKU de autenticación de cliente de tarjeta inteligente szOID_KP_SMARTCARD_LOGON. Sin embargo, hay una directiva que permite que el KDC no requiera la EKU SC-LOGON (SCLogonEKUNotRequired: vea la tabla 7). La EKU SC-LOGON no es necesaria para las asignaciones de cuentas basadas en la clave pública.

Certificado KDC

Servicios de certificados de Active Directory proporciona tres tipos de plantillas de certificado:

• Controlador de dominio
• Autenticación del controlador de dominio
• Autenticación Kerberos (nueva en Windows Server® 2008)

Dependiendo de la configuración del controlador de dominio, uno de estos tipos de certificado se envía como parte del paquete AS_REP. Para obtener más información sobre las plantillas de certificado, vea Mejoras del servidor de certificados de Active Directory en Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=83212).

Asignaciones de certificados de cliente

La asignación de certificados se basa en el UPN contenido en el campo subjectAltName (SAN) del certificado. También se admiten los certificados de cliente que no contienen la extensión subjectAltName en el certificado.

SSL/TLS puede asignar certificados que no tienen SAN y la asignación se realiza mediante los atributos AltSecID en las cuentas de cliente. El altsecID X509 usado por la autenticación de cliente SSL/TLS tiene el formato "X509:<I>"<Nombre del emisor"<S>"<Nombre>> del firmante. Aquí, el nombre del emisor y <> el <nombre> del firmante se toman del certificado de cliente, con "\r" y "\n" reemplazados por ", ".

Figura 17 Puntos de distribución crL

Figura 18 UPN en el campo Nombre alternativo del firmante

Figura 19 Campos Asunto y Problema

Esta asignación de cuenta es compatible con el KDC. El KDC también admite seis otros métodos de asignación. En la ilustración siguiente se muestra un flujo de lógica de asignación de cuentas de usuario usada por KDC.

Figura 20 Flujo de alto nivel de procesamiento de certificados para el inicio de sesión

El objeto de certificado se analiza para buscar cierto contenido para realizar la asignación de cuentas de usuario. Cuando también se proporciona un nombre de usuario con el certificado, se usa el nombre de usuario para localizar el objeto de cuenta. Esta operación es la más rápida, ya que se produce la coincidencia de cadenas. Cuando solo se proporciona el objeto de certificado, se realiza una serie de operaciones para localizar al usuario para asignar el usuario a un objeto de cuenta. Cuando no hay información de dominio disponible para la autenticación, el dominio local se usa de forma predeterminada. Si se va a usar cualquier otro dominio para la búsqueda, se debe proporcionar una sugerencia de nombre de dominio para realizar la asignación y el enlace. La asignación basada en atributos genéricos no es posible, ya que no hay ninguna API genérica para recuperar atributos de un certificado.

Actualmente, el primer método que busca una cuenta gana correctamente y la búsqueda se detiene. Pero si dos métodos de asignación asignan el mismo certificado a cuentas de usuario diferentes cuando el cliente no proporciona el nombre de cliente a través de las sugerencias de asignación, se trata de un error de configuración.

Para obtener más información sobre cómo asignar certificados a cuentas de usuario, consulte Implementación de una infraestructura de clave pública (https://go.microsoft.com/fwlink/?LinkId=93737).

En la figura 21 se muestra el proceso de asignación de cuentas de usuario para el inicio de sesión en el directorio examinando varias entradas del certificado. NT_AUTH directiva se describe mejor en CertVerifyCertificateChainPolicy (https://go.microsoft.com/fwlink/?LinkId=93738) en CERT_CHAIN_POLICY_NT_AUTH.

Figura 21 Lógica de procesamiento de certificados

Inicio de sesión de tarjeta inteligente de un solo usuario con un certificado en varias cuentas

Un único certificado de usuario se puede asignar a varias cuentas. Por ejemplo, un usuario podría iniciar sesión en su cuenta de usuario y también iniciar sesión como administrador de dominio. La asignación se realiza mediante altsecID construido basado en atributos de cuentas de cliente. Consulte Asignaciones de certificados de cliente sobre cómo se evalúa esta asignación.

Nota

Dado que cada cuenta tiene un nombre de usuario diferente, le recomendamos que habilite el objeto X509Hints directiva de grupo para proporcionar la información del usuario para la que querrá iniciar sesión como.

A continuación se enumeran las condiciones para iniciar sesión, en función del contenido del certificado:

1. Si no hay ningún UPN presente en el certificado:
   1. El inicio de sesión puede producirse en el bosque local o en otro bosque si un único usuario con un certificado debe iniciar sesión en cuentas diferentes.
   2. Se debe proporcionar una sugerencia si la asignación no es única (más de un usuario asignado al mismo certificado).
2. Si un UPN está presente en el certificado:
   1. El certificado no se puede asignar a varios usuarios del mismo bosque.
   2. El certificado se puede asignar a varios usuarios en bosques diferentes. Para iniciar sesión en otros bosques, se debe proporcionar una sugerencia X509 al usuario.

Inicio de sesión de tarjeta inteligente de varios usuarios en una sola cuenta

Un grupo de usuarios podría iniciar sesión en una sola cuenta (por ejemplo, una cuenta de administrador). Para esa cuenta, los certificados de usuario se asignan para que estén habilitados para el inicio de sesión.

También se pueden asignar varios certificados distintos a una sola cuenta (para que esto funcione correctamente, el certificado no puede tener UPN). 

Por ejemplo, si Certificate1 tiene CN=CNName1, Certificate2 tiene CN=User1 y Certificate3 tiene CN=User2, el AltSecID de estos certificados se puede asignar a una sola cuenta mediante la asignación de nombres de Usuarios y equipos de Active Directory.

Inicio de sesión de tarjeta inteligente entre bosques

Para que la asignación de cuentas funcione entre bosques, especialmente en los casos en los que no haya suficiente información disponible en el certificado, el usuario puede escribir una sugerencia (en forma de un nombre de usuario, como Domain\User o un UPN completo, como User@DNSNameOfDomain.com).

Nota

Para que el campo de sugerencia aparezca durante el inicio de sesión de tarjeta inteligente, la clave del Registro X509HintsNeededed debe establecerse en el cliente para habilitar la visualización de un campo de sugerencias adicionales en la interfaz de usuario de inicio de sesión con el campo PIN (consulte la tabla 7).

Compatibilidad de OCSP con PKINIT

El Protocolo de estado de certificado en línea (OCSP), definido en RFC 2560, permite a las aplicaciones obtener información oportuna sobre el estado de revocación de un certificado. Dado que las respuestas OCSP son pequeñas y bien limitadas, es posible que los clientes restringidos quieran usar OCSP para comprobar la validez de los certificados para KDC de Kerberos, con el fin de evitar la transmisión de listas de revocación de certificados grandes (CRL) y ahorrar ancho de banda en redes restringidas.

El KDC de Microsoft siempre intentará obtener las respuestas OCSP y usarlas cuando estén disponibles. No hay ninguna directiva que se pueda usar para desactivarla. CAPI2 API para OCSP almacena en caché las respuestas OCSP y el estado de las respuestas. KDC solo admite la respuesta OCSP para el certificado de firmante.

Windows clientes siempre intentarán solicitar las respuestas OCSP y usarlas en la respuesta, cuando estén disponibles. No hay ninguna directiva que se pueda usar para desactivarla.

Compatibilidad con la revocación de certificados

En la tabla 12 se detallan las claves y los valores correspondientes para desactivar la comprobación de CRL (en la conexión) en el KDC o el cliente. Se requieren ambas configuraciones.

Tabla 12 Claves del Registro de comprobación de CRL

Clave	Descripción
HKLM\SYSTEM\CCS\Services\Kdc\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors	Type = DWORD Valor = 1
HKLM\SYSTEM\CCS\Control\LSA\Kerberos\Parameters\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors	Type = DWORD Valor = 1

Requisitos de certificado raíz de tarjeta inteligente para su uso con unión a un dominio

Hay algunas condiciones específicas que el certificado de tarjeta inteligente debe cumplir para que la unión a un dominio basado en tarjeta inteligente funcione.

• El certificado de tarjeta inteligente debe contener un campo Asunto que contenga el nombre de dominio DNS en el DN. Si no lo hace, se producirá un error en la resolución en el dominio adecuado y se producirá un error en TS y unión a un dominio con tarjeta inteligente.

O BIEN

• El certificado de tarjeta inteligente debe contener un UPN en el que la parte de dominio del UPN debe resolverse en el dominio real. Por ejemplo, EL UPN "username@engineering.corp.contoso.com" funcionaría, pero "username@engineering.contoso.com" no funcionaría, ya que el cliente Kerberos no podría encontrar el dominio adecuado.

La solución consiste en proporcionar una sugerencia (habilitada a través de la configuración de GPO X509HintsNeeded como se especifica en la tabla 7) en la interfaz de usuario de credenciales para la unión a un dominio.

Si el equipo cliente no está unido al dominio (o si está unido a otro dominio), el cliente solo podrá resolver el dominio del servidor examinando el DN en el certificado (no el UPN). Para que este escenario funcione, el certificado necesita un asunto completo (incluido "DC=...") para la resolución de nombres de dominio.

Para implementar certificados raíz en la tarjeta inteligente para el dominio unido actualmente, puede usar el siguiente comando:

certutil –scroots

Terminal Services y tarjetas inteligentes

En Vista, la lógica de redirección de tarjetas inteligentes y WinSCard se han combinado para admitir varias sesiones redirigidas en un solo proceso.

Se requiere compatibilidad con tarjetas inteligentes con Terminal Services para habilitar muchos escenarios. Entre ellas se incluyen las siguientes:

• Capacidad de RAS en un entorno de cambio rápido de usuario (o remoto mediante servicios de terminal). Un usuario no puede establecer una conexión RAS redirigida basada en tarjetas inteligentes. Es decir, el intento de conexión no se realizará correctamente en el cambio rápido de usuario o desde una sesión de Terminal Services.
• EFS no podrá localizar el lector de tarjetas inteligentes del usuario desde el proceso de LSA en Cambio rápido de usuario o en una sesión de Terminal Services. Como resultado, EFS no podrá descifrar los archivos de usuario.

Redireccionamiento de Terminal Server

En un escenario de Terminal Server, un usuario usa un servidor remoto para ejecutar servicios. Pero la tarjeta inteligente es local para el sistema que está usando el usuario. En un escenario de inicio de sesión de tarjeta inteligente, el servicio de tarjeta inteligente del servidor remoto (SCardSvr.exe o SVCHost.exe) hablará correctamente (o redirigirá) al lector de tarjetas inteligentes conectado al sistema remoto desde el que el usuario está intentando iniciar sesión.

Figura 22 Redirección de Terminal Server

Notas sobre el modelo de redireccionamiento:

1. El escenario que se describe es una sesión de inicio de sesión remota en un equipo de Terminal Server. En la sesión remota (etiquetada como "Sesión de cliente"), el usuario ejecuta net use /smart card.
2. Las flechas representan el flujo del PIN que el usuario escribe desde el proceso del símbolo del sistema, cmd.exe, a la tarjeta inteligente del usuario en un lector conectado al equipo cliente de Terminal Services.
3. La LSA realiza el trabajo de autenticación en la sesión 0.
4. El trabajo de Crypto API se realiza en LSA (lsass.exe). Esto es posible porque rdpdr.sys permitirá el contexto por sesión, en lugar de por proceso.
5. Los componentes WinScard y SCRedir , que estaban estrechamente acoplados pero separados módulos antes de Vista, ahora están inscritos en un módulo. La biblioteca ScHelper es un contenedor de Crypto API específico de Kerberos.
6. La decisión de redireccionamiento se toma según cada contexto de tarjeta inteligente, en función de la sesión del subproceso que realiza la llamada SCardEstablishContext .
7. Se han realizado cambios en WinSCard.dll implementación en Vista para permitir el redireccionamiento de tarjetas inteligentes.

Experiencia de inicio de sesión único de Terminal Server

Como parte del cumplimiento de los criterios comunes (CC), el cliente MSTSC debe configurarse para usar el Administrador de credenciales para adquirir y guardar la contraseña del usuario o el PIN de tarjeta inteligente. CC requiere que las aplicaciones no tengan acceso directo a la contraseña o pin del usuario.

CC requiere específicamente que la contraseña/PIN nunca deje la LSA sin cifrar. Aplicado a un escenario distribuido, debe permitir que la contraseña o el PIN viajen entre una LSA de confianza y otra, siempre y cuando no esté en el estado claro durante el tránsito.

En la solución de inicio de sesión único de Windows Vista Terminal Services, al usar una tarjeta inteligente, los usuarios deberán iniciar sesión para cada nueva sesión de Terminal Services (sin compatibilidad con SSO). Sin embargo, no se solicita al usuario un PIN más de una vez para establecer una sesión de Terminal Services. Por ejemplo, después de que el usuario haga doble clic en un icono de documento de Microsoft Word que reside en un equipo remoto, se le pedirá al usuario que escriba un PIN. Este PIN se pasará mediante un canal seguro que el SSP de credenciales haya establecido. El PIN se enruta de nuevo al cliente de Terminal Services a través del canal seguro y se pasa a Winlogon, y el usuario no ve ninguna interfaz de usuario adicional (ningún aviso adicional para el PIN, a menos que el PIN sea incorrecto o haya errores relacionados con tarjetas inteligentes).

Terminal Services y inicio de sesión de tarjeta inteligente

El propósito de esta característica es permitir que los usuarios inicien sesión con una tarjeta inteligente escribiendo un PIN en el lado cliente de terminal Services y pasándolo al servidor de forma similar a la autenticación basada en el nombre de usuario y la contraseña.

El inicio de sesión de tarjeta inteligente con terminal services se introdujo por primera vez en Windows XP. No está disponible en ninguna versión anterior. En Windows XP, el usuario podría iniciar sesión con solo un certificado del contenedor predeterminado.

Nota

Si se usa un cliente de terminal Services de Windows Vista y se usa un servidor Windows 2003, solo se admite un certificado único en una tarjeta inteligente del contenedor predeterminado. Para aprovechar la compatibilidad de Windows Vista con varias características de certificados y sugerencias de dominio, use solo Windows Vista y Windows equipos de Server 2008.

Además de habilitar las directivas de grupo necesarias, las directivas específicas de los servicios de terminal deben habilitarse para el inicio de sesión basado en tarjeta inteligente.

Para habilitar el inicio de sesión de tarjeta inteligente en un servidor de terminal Services, el certificado KDC debe estar presente en el equipo local del cliente de Terminal Services. Si el equipo no está en el mismo dominio o grupo de trabajo, se puede usar la siguiente herramienta de línea de comandos para implementar el certificado.

Formato:

certutil –dspublish NTAuthCA "DSCDPContainer"

DSCDPContainer CN suele ser el nombre del equipo de ca.

Ejemplo:

certutil –dspublish NTAuthCA<CertFile>"CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=engineering,DC=contoso,DC=com"

Terminal Services y inicio de sesión de tarjeta inteligente entre dominios

Escenario: RAS en la empresa

Para habilitar este escenario, el certificado raíz del dominio debe aprovisionarse en la tarjeta inteligente. Para aprovisionar esto en la tarjeta inteligente desde un equipo unido a un dominio, ejecute lo siguiente en la línea de comandos:

certutil –scroots update

Para los servicios de terminal entre dominios, el certificado KDC del equipo del servidor de Terminal Services también debe estar presente en el almacén NTAUTH del equipo cliente. Para agregar el almacén, ejecute lo siguiente en la línea de comandos:

certutil –addstore –enterprise NTAUTH<CertFile>

Donde <CertFile> es el certificado raíz del emisor de certificados KDC.

Nota

Si usa el SSP de credenciales en Windows Vista para iniciar sesión con una tarjeta inteligente desde un equipo no unido a un dominio, la tarjeta inteligente debe contener la certificación raíz del controlador de dominio. No se puede establecer un canal seguro PKI sin la certificación raíz del controlador de dominio.

El inicio de sesión de servicios de terminal entre dominios solo funcionará si el UPN del certificado usa el siguiente formato: <Something>@<DomainDNSName>

El UPN del certificado debe incluir un dominio real que pueda resolverse. De lo contrario, Kerberos no tiene idea de dónde ir. Habilitar las sugerencias de dominio de GPO X509 es una manera de evitarlo. Para obtener más información sobre esta configuración, vea Tabla 7.

Terminal Services y configuración de inicio de sesión de tarjeta inteligente directiva de grupo

Windows aplica la configuración para el inicio de sesión de tarjeta inteligente con terminal services después de aplicar la credencial SSP y la directiva de seguridad local (establecida con secpol.msc).

Tabla 13 Terminal Services y configuración de inicio de sesión de tarjeta inteligente directiva de grupo

Directiva	Configuración
El inicio de sesión de tarjeta inteligente es el único método de inicio de sesión admitido.	HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation Nombre del valor: AllowFreshCredentials Tipo de valor: Binario Valor de configuración: 1
El usuario también tiene una cuenta habilitada para contraseña correspondiente.	HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation Nombre del valor: AllowFreshCredentialsWhenNTLMOnly Tipo de valor: Binario Valor de configuración: 1

Si usa servicios de terminal con inicio de sesión de tarjeta inteligente, no puede delegar las credenciales predeterminadas y guardadas. La siguiente configuración de directiva de grupo correspondiente se omite en HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation:

• AllowDefCredentials
• AllowDefCredentialsWhenNTLMOnly
• AllowSavedCredentials
• AllowSavedCredentialsWhenNTLMOnly

Cambio rápido de usuario

Esto es solo para la sesión activa.

Depuración e información para desarrolladores

Los desarrolladores pueden usar herramientas y servicios en Windows Vista, para ayudar a identificar problemas de certificados.

Certutil

Enumeración de certificados disponibles en la tarjeta inteligente

Comando para enumerar los certificados disponibles en la tarjeta inteligente: certutil –scinfo

No es necesario escribir un PIN para esta operación. Al presionar Escape en cada cuadro de diálogo PIN, el objetivo es leer los certificados públicos de la tarjeta.

Eliminación de certificados en la tarjeta inteligente

Cuando se elimina un certificado en la tarjeta, realmente se elimina un contenedor que corresponde a ese certificado. Cada certificado se incluye en un contenedor. Por ejemplo, para eliminar un contenedor, puede usar el siguiente comando:

Certutil –delkey –csp "Microsoft Base Smart Card Crypto Provider" "38f813f2-ec3b-4e96-ba19-38b830923be9"

Para implementar un certificado raíz de dominio en una tarjeta inteligente, consulte Requisitos de certificado raíz de tarjeta inteligente para el usuario con una unión a un dominio.

Para publicar certificados en el almacén NTAUTH, consulte Terminal Services y Inicio de sesión de tarjeta inteligente.

Depuración y seguimiento de Kerberos

Puede usar los siguientes recursos para empezar a solucionar problemas de Kerberos:

• Solución de problemas de errores de Kerberos (https://go.microsoft.com/fwlink/?LinkId=93730).
• Solución de problemas de delegación de Kerberos (https://go.microsoft.com/fwlink/?LinkId=93731).
• La herramienta Registro de seguimiento del kit de recursos de Windows 2000 (https://go.microsoft.com/fwlink/?LinkId=93732) es una utilidad que puede usar para depurar errores de autenticación Kerberos.

Para comenzar el seguimiento, puede usar tracelog.exe. Los distintos componentes usan diferentes GUID de control.

NTLM

Para habilitar el seguimiento de la autenticación NTLM, ejecute lo siguiente en la línea de comandos:

tracelog.exe -kd -rt -start ntlm -guid #5BBB6C18-AA45-49b1-A15F-085F7ED0AA90 -f .\ntlm.etl -flags 0x15003 -ft 1

Para detener el seguimiento de la autenticación NTLM, ejecute lo siguiente en la línea de comandos:

tracelog -stop ntlm

Kerberos

Para habilitar el seguimiento de la autenticación Kerberos, ejecute lo siguiente en la línea de comandos:

tracelog.exe -kd -rt -start kerb -guid #6B510852-3583-4e2d-AFFE-A67F9F223438 -f .\kerb.etl -flags 0x43 -ft 1

Para detener el seguimiento de la autenticación Kerberos, ejecute lo siguiente en la línea de comandos:

tracelog.exe -stop kerb

KDC

Para habilitar el seguimiento del KDC, ejecute lo siguiente en la línea de comandos:

tracelog.exe -kd -rt -start kdc -guid #1BBA8B19-7F31-43c0-9643-6E911F79A06B -f .\kdc.etl -flags 0x803 -ft 1

Para detener el seguimiento del KDC, ejecute lo siguiente en la línea de comandos:

tracelog.exe -stop kdc

Nota

Para detener el seguimiento de forma remota, ejecute lo siguiente en la línea de comandos: logman.exe -s<ComputerName>

La ubicación predeterminada de logman.exe es %systemroot%system32\. Use la opción -s para proporcionar un nombre de equipo.

Configuración del seguimiento con el Registro

También puede configurar el seguimiento editando los valores del Registro.

Tabla 14 Configuración del Registro de seguimiento de Kerberos

Método	Configuración de clave del Registro
NTLM	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 Nombre del valor: NtLmInfoLevel Tipo de valor: DWORD Datos de valor: c0015003
Kerberos	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Nombre del valor: KerbDebugLevel Tipo de valor: DWORD Datos de valor: c0000043 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos Nombre del valor: LogToFile Tipo de valor: DWORD Información del valor: 00000001 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Nombre del valor: LogToFile Tipo de valor: DWORD Información del valor: 00000001
KDC	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc Nombre del valor: KdcDebugLevel Tipo de valor: DWORD Datos de valor: c0000803

Si usó tracelog.exe, busque el archivo de registro kerb.etl/kdc.etl/ntlm.etl en el directorio actual. De lo contrario, si usó los archivos del Registro que se muestran en la tabla 13, busque los archivos de registro de seguimiento generados en las siguientes ubicaciones:

• NTLM: %systemroot%\tracing\msv1_0
• Kerberos: %systemroot%\tracing\kerberos
• KDC: %systemroot%\tracing\kdcsvc

Para descodificar archivos de seguimiento de eventos, puede usar Tracefmt (tracefmt.exe). Tracefmt es una herramienta de línea de comandos que da formato a los mensajes de seguimiento de un archivo de registro de seguimiento de eventos (.etl) o una sesión de seguimiento en tiempo real. Tracefmt puede mostrar los mensajes en la ventana del símbolo del sistema o guardarlos en un archivo de texto. Se encuentra en el subdirectorio \tools\tracing del Kit de controladores de Microsoft Windows (WDK). Para obtener más información sobre Tracefmt, vea Tracefmt en MSDN (https://go.microsoft.com/fwlink/?LinkId=93734).

Servicio de tarjetas inteligentes

Para comprobar si el servicio de tarjeta inteligente se está ejecutando

1. Presione CTRL+ALT+SUPR y, a continuación, haga clic en Iniciar administrador de tareas.

2. En el cuadro de diálogo Windows Administrador de tareas, haga clic en la pestaña Servicios.

3. Haga clic en la columna Nombre para ordenar la lista alfabéticamente y, a continuación, escriba s.

4. En la columna Nombre , busque SCardSvr y, a continuación, busque en la columna Estado para ver si el servicio se está ejecutando o detenido.

Para reiniciar el servicio de tarjeta inteligente

1. Haga clic en el botón Inicio, escriba cmd, haga clic con el botón derecho encmd.exey, a continuación, haga clic en Ejecutar como administrador.

2. Si aparece el cuadro de diálogo Control de cuentas de usuario, confirme que la acción que muestra es la que desea y, a continuación, haga clic en Continuar.

3. En el símbolo del sistema, escriba net stop SCardSvr.

4. En el símbolo del sistema, escriba net start SCardSvr.

Puede usar el siguiente comando en el símbolo del sistema para comprobar si el servicio se está ejecutando:

sc queryex scardsvr

A continuación se muestra un ejemplo de salida de la ejecución de este comando:

SERVICE_NAME: scardsvr
    TYPE        : 20 WIN32_SHARE_PROCESS
    STATE       : 4 RUNNING
                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
    WIN32_EXIT_CODE  : 0 (0x0)
    SERVICE_EXIT_CODE : 0 (0x0)
    CHECKPOINT     : 0x0
    WAIT_HINT     : 0x0
    PID        : 1320
    FLAGS       :
C:\>

Lectores de tarjetas inteligentes

Para comprobar si el lector de tarjetas inteligentes está conectado y funciona correctamente

1. Haga clic en el botón Inicio, haga clic con el botón derecho en Equipo y, a continuación, haga clic en Propiedades.

2. En Tareas, haga clic en Administrador de dispositivos.

3. En Administrador de dispositivos, expanda Lectores de tarjetas inteligentes, seleccione el lector de tarjetas inteligentes sobre el que desea información y, a continuación, haga clic en Propiedades.

   Nota

   Si el lector de tarjetas inteligentes no aparece en Administrador de dispositivos, en el menú Acción, haga clic en Buscar cambios de hardware.

Diagnóstico de CAPI2

CapI2 Diagnostics es una característica de Windows Vista y Windows Server 2008 que ayuda a los administradores a solucionar problemas de PKI. CAPI2 Diagnostics registra eventos en el registro de eventos de Windows que contiene información detallada sobre la validación de la cadena de certificados, las operaciones del almacén de certificados y la comprobación de firmas. Esta información facilita la identificación de las causas principales de los problemas y reduce el tiempo necesario para el diagnóstico.

Para obtener más información sobre los diagnósticos capi2, consulte Solución de problemas de PKI en Windows Vista (https://go.microsoft.com/fwlink/?LinkId=89570).

Referencias

1. Alias de preguntas del proveedor de credenciales: credprov@microsoft.com
2. Referencia técnica del proveedor de credenciales (https://go.microsoft.com/fwlink/?LinkId=93340)
3. Documentación del SDK de Windows Vista (https://go.microsoft.com/fwlink/?LinkId=93342)
4. Proveedor de servicios criptográficos de tarjeta inteligente base de Microsoft (CSP base) para Windows 2000, 2003 y XP (https://go.microsoft.com/fwlink/?LinkId=93341)
5. Especificación del mini controlador de tarjeta inteligente (https://go.microsoft.com/fwlink/?LinkId=93343)
6. Documentación del archivo de encabezado y la API del mini controlador de tarjeta inteligente (módulo de tarjeta) en MSDN (https://go.microsoft.com/fwlink/?LinkId=18885); Alias de comentarios: CardMod@microsoft.com ; Descarga de archivos de encabezado disponible como parte del SDK de CNG (https://go.microsoft.com/fwlink/?LinkId=93344)
7. Requisitos de certificación de tarjeta inteligente (https://go.microsoft.com/fwlink/?LinkId=93345)
8. Grupo de trabajo pc/SC (https://go.microsoft.com/fwlink/?LinkId=93346)
9. Referencia de la API de WinSCard (https://go.microsoft.com/fwlink/?LinkId=93347)
10. Compatibilidad de OSCP con PKINIT (https://go.microsoft.com/fwlink/?LinkId=93348)
11. Enterprise implementación de tarjeta inteligente en el marco de tarjeta inteligente de Microsoft Windows (https://go.microsoft.com/fwlink/?LinkId=93349)
12. Sesión 0 en Windows Vista (https://go.microsoft.com/fwlink/?LinkId=93350)
13. Especificaciones de la plataforma global (https://go.microsoft.com/fwlink/?LinkId=93351)
14. Solución de problemas de PKI en Windows Vista (https://go.microsoft.com/fwlink/?LinkId=89570)
15. RFC 4556: Criptografía de clave pública para la autenticación inicial en Kerberos (PKINIT) (https://go.microsoft.com/fwlink/?LinkId=93352)
16. Mejoras del servidor de certificados de Active Directory en Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=83212)
17. Blog de infraestructura de tarjeta inteligente para obtener información y comentarios más recientes (https://go.microsoft.com/fwlink/?LinkId=96591)