Procesos de las credenciales en la autenticación de Windows

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema de referencia para profesionales de TI se describe cómo autenticación de Windows procesa las credenciales.

Windows administración de credenciales es el proceso por el que el sistema operativo recibe las credenciales del servicio o usuario y protege esa información para la presentación futura en el destino de autenticación. En el caso de un equipo unido a un dominio, el destino de autenticación es el controlador de dominio. Las credenciales usadas en la autenticación son documentos digitales que asocian la identidad del usuario a alguna forma de prueba de autenticidad, como un certificado, una contraseña o un PIN.

De forma predeterminada, las credenciales de Windows se validan en la base de datos administrador de cuentas de seguridad (SAM) del equipo local, o en Active Directory en un equipo unido a un dominio, a través del servicio Winlogon. Las credenciales se recopilan a través de la entrada del usuario en la interfaz de usuario de inicio de sesión o mediante programación a través de la interfaz de programación de aplicaciones (API) que se va a presentar al destino de autenticación.

La información de seguridad local se almacena en el registro en HKEY_LOCAL_MACHINE\SECURITY. La información almacenada incluye la configuración de directiva, los valores de seguridad predeterminados y la información de la cuenta, como las credenciales de inicio de sesión almacenadas en caché. Aquí también se almacena una copia de la base de datos SAM, aunque está protegida por escritura.

En el diagrama siguiente se muestran los componentes necesarios y las rutas de acceso que las credenciales realizan a través del sistema para autenticar al usuario o proceso para un inicio de sesión correcto.

Diagram that shows the components that are required and the paths that credentials take through the system to authenticate the user or process for a successful logon.

En la tabla siguiente se describe cada componente que administra las credenciales del proceso de autenticación en el punto de inicio de sesión.

Componentes de autenticación para todos los sistemas

Componente Descripción
Inicio de sesión del usuario Winlogon.exe es el archivo ejecutable responsable de administrar interacciones seguras del usuario. El servicio Winlogon inicia el proceso de inicio de sesión para Windows sistemas operativos pasando las credenciales recopiladas por la acción del usuario en el escritorio seguro (interfaz de usuario de inicio de sesión) a la autoridad de seguridad local (LSA) a través de Secur32.dll.
Inicio de sesión de la aplicación Inicios de sesión de aplicación o servicio que no requieren inicio de sesión interactivo. La mayoría de los procesos iniciados por el usuario se ejecutan en modo de usuario mediante Secur32.dll mientras que los procesos iniciados durante el inicio, como los servicios, se ejecutan en modo kernel mediante Ksecdd.sys.

Para obtener más información sobre el modo de usuario y el modo kernel, vea Aplicaciones y Modo de usuario o Servicios y Modo kernel en este tema.

Secur32.dll Los varios proveedores de autenticación que forman la base del proceso de autenticación.
Lsasrv.dll El servicio LSA Server, que aplica las directivas de seguridad y actúa como administrador de paquetes de seguridad para el LSA. El LSA contiene la función Negotiate, que selecciona el protocolo NTLM o Kerberos después de determinar qué protocolo se va a realizar correctamente.
Proveedores de soporte técnico de seguridad Conjunto de proveedores que pueden invocar individualmente uno o varios protocolos de autenticación. El conjunto predeterminado de proveedores puede cambiar con cada versión del sistema operativo Windows y se pueden escribir proveedores personalizados.
Netlogon.dll Los servicios que realiza el servicio Net Logon son los siguientes:

- Mantiene el canal seguro del equipo (no confundirse con Schannel) a un controlador de dominio.
- Pasa las credenciales del usuario a través de un canal seguro al controlador de dominio y devuelve los identificadores de seguridad de dominio (SID) y los derechos de usuario para el usuario.
- Publica registros de recursos de servicio en el Sistema de nombres de dominio (DNS) y usa DNS para resolver nombres en las direcciones del Protocolo de Internet (IP) de los controladores de dominio.
- Implementa el protocolo de replicación basado en la llamada a procedimiento remoto (RPC) para sincronizar controladores de dominio principales (PDC) y controladores de dominio de copia de seguridad (BDC).

Samsrv.dll El Administrador de cuentas de seguridad (SAM), que almacena cuentas de seguridad locales, aplica directivas almacenadas localmente y admite API.
Registro El Registro contiene una copia de la base de datos SAM, la configuración de la directiva de seguridad local, los valores de seguridad predeterminados y la información de la cuenta que solo es accesible para el sistema.

Este tema contiene las siguientes secciones:

Entrada de credenciales para el inicio de sesión de usuario

En Windows Server 2008 y Windows Vista, la arquitectura de identificación gráfica y autenticación (GINA) se reemplazó por un modelo de proveedor de credenciales, lo que hizo posible enumerar diferentes tipos de inicio de sesión mediante el uso de iconos de inicio de sesión. Ambos modelos se describen a continuación.

Arquitectura gráfica de identificación y autenticación

La arquitectura de identificación gráfica y autenticación (GINA) se aplica a los sistemas operativos Windows Server 2003, Microsoft Windows 2000 Server, Windows XP y Windows 2000 Professional. En estos sistemas, cada sesión de inicio de sesión interactiva crea una instancia independiente del servicio Winlogon. La arquitectura de GINA se carga en el espacio de proceso utilizado por Winlogon, recibe y procesa las credenciales y realiza las llamadas a las interfaces de autenticación a través de LSALogonUser.

Las instancias de Winlogon para una ejecución de inicio de sesión interactivo en la sesión 0. La sesión 0 hospeda los servicios del sistema y otros procesos críticos, incluido el proceso de autoridad de seguridad local (LSA).

En el diagrama siguiente se muestra el proceso de credenciales de Windows Server 2003, Microsoft Windows 2000 Server, Windows XP y Microsoft Windows 2000 Professional.

Diagram showing the credential process for Windows Server 2003, Microsoft Windows 2000 Server, Windows XP, and Microsoft Windows 2000 Professional

Arquitectura del proveedor de credenciales

La arquitectura del proveedor de credenciales se aplica a las versiones designadas en la lista Se aplica a al principio de este tema. En estos sistemas, la arquitectura de entrada de credenciales cambió a un diseño extensible mediante proveedores de credenciales. Estos proveedores se representan mediante los diferentes iconos de inicio de sesión en el escritorio seguro que permiten cualquier número de escenarios de inicio de sesión: cuentas diferentes para el mismo usuario y métodos de autenticación diferentes, como contraseña, tarjeta inteligente y biométrica.

Con la arquitectura del proveedor de credenciales, Winlogon siempre inicia la interfaz de usuario de inicio de sesión después de recibir un evento de secuencia de atención segura. La interfaz de usuario de inicio de sesión consulta cada proveedor de credenciales para el número de tipos de credenciales diferentes que el proveedor está configurado para enumerar. Los proveedores de credenciales tienen la opción de especificar uno de estos iconos como predeterminado. Una vez que todos los proveedores han 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.

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

Los proveedores de credenciales se registran en el equipo y son responsables de lo siguiente:

  • 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.

El empaquetado de credenciales para el inicio de sesión interactivo y de red incluye el proceso de serialización. Al serializar credenciales, se pueden mostrar varios iconos de inicio de sesión en la interfaz de usuario de inicio de sesión. Por lo tanto, su organización puede controlar la presentación del inicio de sesión, como los usuarios, los sistemas de destino para el inicio de sesión, el acceso previo al inicio de sesión a las directivas de bloqueo y desbloqueo de la red y de la estación de trabajo, mediante el uso de proveedores de credenciales personalizados. Varios proveedores de credenciales pueden coexistir en el mismo equipo.

Los proveedores de inicio de sesión único (SSO) se pueden desarrollar como proveedor de credenciales estándar o como proveedor de acceso previo al inicio de sesión.

Cada versión de Windows contiene un proveedor de credenciales predeterminado y un proveedor de acceso previo al inicio de sesión (PLAP) predeterminado, también conocido como proveedor de SSO. El proveedor de SSO permite a los usuarios establecer una conexión a una red antes de iniciar sesión en el equipo local. Cuando se implementa este proveedor, el proveedor no enumera los iconos en la interfaz de usuario de inicio de sesión.

Un proveedor de SSO está diseñado para usarse en los escenarios siguientes:

  • Los distintos proveedores de credenciales controlan la autenticación de red y el inicio de sesión del equipo. Entre las variaciones de este escenario se incluyen las siguientes:

    • Un usuario tiene la opción de conectarse a una red, como conectarse a una red privada virtual (VPN), antes de iniciar sesión en el equipo, pero no es necesario realizar esta conexión.

    • La autenticación de red es necesaria para recuperar la información utilizada durante la autenticación interactiva en el equipo local.

    • Varias autenticaciones de red van seguidas de uno de los otros escenarios. Por ejemplo, un usuario se autentica en un proveedor de servicios de Internet (ISP), se autentica en una VPN y, a continuación, usa sus credenciales de cuenta de usuario para iniciar sesión localmente.

    • Las credenciales almacenadas en caché están deshabilitadas y se requiere una conexión de Access Services remota a través de VPN antes de que el inicio de sesión local autentique al usuario.

    • Un usuario de dominio no tiene una cuenta local configurada en un equipo unido a un dominio y debe establecer una conexión de Access Services remota a través de la conexión VPN antes de completar el inicio de sesión interactivo.

  • La autenticación de red y el inicio de sesión del equipo se controlan mediante el mismo proveedor de credenciales. En este escenario, el usuario debe conectarse a la red antes de iniciar sesión en el equipo.

Enumeración de icono de inicio de sesión

El proveedor de credenciales enumera los iconos de inicio de sesión en las instancias siguientes:

  • Para los sistemas operativos designados en la lista Se aplica a al principio de este tema.

  • El proveedor de credenciales enumera los iconos para el inicio de sesión de la estación de trabajo. El proveedor de credenciales normalmente serializa las credenciales para la autenticación en la entidad de seguridad local. Este proceso muestra iconos específicos de cada usuario y específicos de los sistemas de destino de cada usuario.

  • La arquitectura de inicio de sesión y autenticación permite a un usuario usar iconos enumerados por el proveedor de credenciales para desbloquear una estación de trabajo. Normalmente, el usuario que ha iniciado sesión actualmente es el icono predeterminado, pero si más de un usuario ha iniciado sesión, se muestran numerosos iconos.

  • El proveedor de credenciales enumera los iconos en respuesta a una solicitud de usuario para cambiar su contraseña u otra información privada, como un PIN. Normalmente, el usuario que ha iniciado sesión actualmente es el icono predeterminado; Sin embargo, si se inicia sesión más de un usuario, se muestran numerosos iconos.

  • El proveedor de credenciales enumera iconos basados en las credenciales serializadas que se usarán para la autenticación en equipos remotos. La interfaz de usuario de credenciales no usa la misma instancia del proveedor que la interfaz de usuario de inicio de sesión, la estación de trabajo de desbloqueo o el cambio de contraseña. Por lo tanto, la información de estado no se puede mantener en el proveedor entre instancias de credential UI. Esta estructura da como resultado un icono para cada inicio de sesión de equipo remoto, suponiendo que las credenciales se han serializado correctamente. Este escenario también se usa en el Control de cuentas de usuario (UAC), que puede ayudar a evitar cambios no autorizados en un equipo al solicitar al usuario permiso o una contraseña de administrador antes de permitir acciones que podrían afectar a la operación del equipo o que podrían cambiar la configuración que afecta a otros usuarios del equipo.

En el diagrama siguiente se muestra el proceso de credenciales de los sistemas operativos designados en la lista Se aplica a al principio de este tema.

Diagram that shows the credential process for the operating systems designated in the Applies To list at the beginning of this topic

Entrada de credenciales para el inicio de sesión de aplicación y servicio

autenticación de Windows está diseñado para administrar credenciales para aplicaciones o servicios que no requieren interacción del usuario. Las aplicaciones en modo de usuario están limitadas en términos de los recursos del sistema a los que tienen acceso, mientras que los servicios pueden tener acceso sin restricciones a la memoria del sistema y a los dispositivos externos.

Los servicios del sistema y las aplicaciones de nivel de transporte acceden a un proveedor de soporte técnico de seguridad (SSP) a través de la interfaz del proveedor de soporte técnico de seguridad (SSPI) en Windows, que proporciona funciones para enumerar los paquetes de seguridad disponibles en un sistema, seleccionar un paquete y usar ese paquete para obtener una conexión autenticada.

Cuando se autentica una conexión de cliente o servidor:

  • La aplicación del lado cliente de la conexión envía credenciales al servidor mediante la función InitializeSecurityContext (General)SSPI .

  • La aplicación del lado servidor de la conexión responde con la función AcceptSecurityContext (General)SSPI .

  • Las funciones InitializeSecurityContext (General) SSPI y AcceptSecurityContext (General) se repiten hasta que se hayan intercambiado todos los mensajes de autenticación necesarios para que se realicen correctamente o se produzca un error en la autenticación.

  • Una vez autenticada la conexión, el LSA del servidor usa información del cliente para compilar el contexto de seguridad, que contiene un token de acceso.

  • A continuación, el servidor puede llamar a la función ImpersonateSecurityContext SSPI para adjuntar el token de acceso a un subproceso de suplantación para el servicio.

Aplicaciones y modo de usuario

El modo de usuario en Windows se compone de dos sistemas capaces de pasar solicitudes de E/S a los controladores de modo kernel adecuados: el sistema de entorno, que ejecuta aplicaciones escritas para muchos tipos diferentes de sistemas operativos y el sistema integral, que opera funciones específicas del sistema en nombre del sistema de entorno.

El sistema entero administra las funciones específicas del sistema operativo en nombre del sistema de entorno y consta de un proceso del sistema de seguridad (LSA), un servicio de estación de trabajo y un servicio de servidor. El proceso del sistema de seguridad trata los tokens de seguridad, concede o deniega permisos para acceder a las cuentas de usuario en función de los permisos de recursos, controla las solicitudes de inicio de sesión e inicia la autenticación de inicio de sesión y determina qué recursos del sistema debe auditar el sistema operativo.

Las aplicaciones se pueden ejecutar en modo de usuario donde la aplicación se puede ejecutar como cualquier entidad de seguridad, incluido en el contexto de seguridad del sistema local (SYSTEM). Las aplicaciones también se pueden ejecutar en modo kernel donde la aplicación se puede ejecutar en el contexto de seguridad del sistema local (SYSTEM).

SSPI está disponible a través del módulo Secur32.dll, que es una API que se usa para obtener servicios de seguridad integrados para la autenticación, la integridad de los mensajes y la privacidad de los mensajes. Proporciona una capa de abstracción entre protocolos de nivel de aplicación y protocolos de seguridad. Dado que diferentes aplicaciones requieren diferentes formas de identificar o autenticar a los usuarios y diferentes formas de cifrar los datos a medida que viaja a través de una red, SSPI proporciona una manera de acceder a las bibliotecas de vínculos dinámicos (DLL) que contienen diferentes funciones criptográficas y de autenticación. Estos archivos DLL se denominan proveedores de soporte técnico de seguridad (SSP).

Las cuentas de servicio administradas y las cuentas virtuales se introdujeron en Windows Server 2008 R2 y Windows 7 para proporcionar aplicaciones cruciales, como Microsoft SQL Server y Internet Information Services (IIS), con el aislamiento de sus propias cuentas de dominio, al tiempo que elimina la necesidad de que un administrador administre manualmente el nombre de entidad de seguridad de servicio (SPN) y las credenciales de estas cuentas. Para obtener más información sobre estas características y su rol en la autenticación, consulte Documentación de cuentas de servicio administradas para Windows 7 y Windows Server 2008 R2 y Información general sobre cuentas de servicio administradas de grupo.

Servicios y modo kernel

Aunque la mayoría de las aplicaciones Windows se ejecutan en el contexto de seguridad del usuario que los inicia, esto no es cierto para los servicios. Muchos servicios Windows, como los servicios de impresión y red, los inicia el controlador de servicio cuando el usuario inicia el equipo. Estos servicios pueden ejecutarse como servicio local o sistema local y pueden seguir ejecutándose después de que el último usuario humano cierre sesión.

Nota

Normalmente, los servicios se ejecutan en contextos de seguridad conocidos como Sistema local (SYSTEM), Servicio de red o Servicio local. Windows Server 2008 R2 introdujo servicios que se ejecutan en una cuenta de servicio administrada, que son entidades de seguridad de dominio.

Antes de iniciar un servicio, el controlador de servicio inicia sesión con la cuenta designada para el servicio y, a continuación, presenta las credenciales del servicio para la autenticación por parte de LSA. El servicio Windows implementa una interfaz mediante programación que el administrador del controlador de servicio puede usar para controlar el servicio. Un servicio de Windows se puede iniciar automáticamente cuando el sistema se inicia o manualmente con un programa de control de servicio. Por ejemplo, cuando un equipo cliente Windows se une a un dominio, el servicio messenger del equipo se conecta a un controlador de dominio y abre un canal seguro para él. Para obtener una conexión autenticada, el servicio debe tener credenciales en las que confía la autoridad de seguridad local (LSA) del equipo remoto. Al comunicarse con otros equipos de la red, LSA usa las credenciales de la cuenta de dominio del equipo local, al igual que todos los demás servicios que se ejecutan en el contexto de seguridad del sistema local y el servicio de red. Los servicios del equipo local se ejecutan como SYSTEM, por lo que no es necesario presentar las credenciales a la LSA.

El archivo Ksecdd.sys administra y cifra estas credenciales y usa una llamada de procedimiento local a la LSA. El tipo de archivo es DRV (controlador) y se conoce como proveedor de compatibilidad de seguridad en modo kernel (SSP) y, en esas versiones designadas en la lista Se aplica a al principio de este tema, es compatible con FIPS 140-2 nivel 1.

El modo kernel tiene acceso total a los recursos de hardware y sistema del equipo. El modo kernel impide que los servicios y las aplicaciones en modo de usuario accedan a áreas críticas del sistema operativo a las que no deben tener acceso.

Autoridad de seguridad local

La autoridad de seguridad local (LSA) es un proceso de sistema protegido que autentica y registra a los usuarios en el equipo local. Además, LSA mantiene información sobre todos los aspectos de la seguridad local en un equipo (estos aspectos se conocen colectivamente como la directiva de seguridad local) y proporciona varios servicios para la traducción entre nombres e identificadores de seguridad (SID). El proceso del sistema de seguridad, servicio de servidor de autoridad de seguridad local (LSASS), realiza un seguimiento de las directivas de seguridad y de las cuentas que están en vigor en un sistema informático.

LSA valida la identidad de un usuario en función de cuál de las dos entidades siguientes emitió la cuenta del usuario:

  • Autoridad de seguridad local. La LSA puede validar la información del usuario comprobando la base de datos administrador de cuentas de seguridad (SAM) ubicada en el mismo equipo. Cualquier estación de trabajo o servidor miembro puede almacenar cuentas de usuario locales e información sobre los grupos locales. Sin embargo, estas cuentas solo se pueden usar para acceder a esa estación de trabajo o equipo.

  • Entidad de seguridad para el dominio local o para un dominio de confianza. El LSA se pone en contacto con la entidad que emitió la cuenta y solicita la comprobación de que la cuenta es válida y que la solicitud se originó en el titular de la cuenta.

El Servicio de subsistema de autoridad de seguridad local (LSASS) almacena las credenciales en memoria en representación de los usuarios con sesiones de Windows activas. Las credenciales almacenadas permiten a los usuarios acceder sin problemas a los recursos de red, como recursos compartidos de archivos, buzones de Exchange Server y sitios de SharePoint, sin volver a escribir sus credenciales para cada servicio remoto.

LSASS puede almacenar credenciales de diferentes formas, por ejemplo:

  • Texto sin formato cifrado de manera reversible

  • Vales kerberos (vales de concesión de vales (TGT), vales de servicio)

  • Hash de NT

  • Hash de LAN Manager (LM)

Si el usuario inicia sesión en Windows mediante una tarjeta inteligente, LSASS no almacena una contraseña de texto no cifrado, pero almacena el valor hash NT correspondiente para la cuenta y el PIN de texto no cifrado para la tarjeta inteligente. Si se habilita el atributo de la cuenta para una tarjeta inteligente que sea necesaria para el inicio de sesión interactivo, se generará automáticamente un valor hash de NT para la cuenta, en lugar del hash de contraseña original. El hash de contraseña generado automáticamente al establecer el atributo no cambia.

Si un usuario inicia sesión en un equipo basado en Windows con una contraseña compatible con los hashes de LAN Manager (LM), este autenticador está presente en la memoria.

El almacenamiento en memoria de credenciales en texto sin formato no se puede deshabilitar, incluso si los proveedores de credenciales requieren que estén deshabilitados.

Las credenciales almacenadas están asociadas directamente a las sesiones de inicio de sesión del Servicio de subsistema de autoridad de seguridad local (LSASS) que se han iniciado después del último reinicio y no se han cerrado. Por ejemplo, las sesiones LSA con credenciales LSA almacenadas se crean cuando un usuario realiza una de las acciones siguientes:

  • Inicia sesión en una sesión local o en una sesión de Protocolo de escritorio remoto (RDP) en el equipo

  • Ejecuta una tarea mediante la opción Ejecutar como

  • Ejecuta un servicio de Windows activo en el equipo

  • Ejecuta una tarea programada o un trabajo por lotes

  • Ejecuta una tarea en el equipo local mediante una herramienta de administración remota

En algunas circunstancias, los secretos de LSA, que son fragmentos secretos de datos a los que solo se puede acceder a los procesos de la cuenta SYSTEM, se almacenan en la unidad de disco duro. Algunos de estos secretos son credenciales que deben persistir después de un reinicio y que se almacenan con formato cifrado en la unidad de disco duro. Las credenciales almacenadas como secretos de LSA son los siguientes:

  • Contraseña de cuenta para la cuenta de Servicios de dominio de Active Directory del equipo (AD DS)

  • Contraseñas de cuenta para servicios de Windows configurados en el equipo

  • Contraseñas de cuenta para tareas programadas configuradas

  • Contraseñas de cuenta para grupos de aplicaciones y sitios web de IIS

  • Contraseñas para cuentas de Microsoft

Introducido en Windows 8.1, el sistema operativo cliente proporciona protección adicional para el LSA para evitar la lectura de la memoria y la inyección de código por procesos no protegidos. Esta protección aumenta la seguridad de las credenciales que almacena y administra LSA.

Para obtener más información sobre estas protecciones adicionales, consulte Configuración de protección adicional de LSA.

Credenciales y validación almacenadas en caché

Los mecanismos de validación se basan en la presentación de credenciales en el momento del inicio de sesión. Sin embargo, cuando el equipo está desconectado de un controlador de dominio y el usuario presenta credenciales de dominio, Windows usa el proceso de credenciales almacenadas en caché en el mecanismo de validación.

Cada vez que un usuario inicia sesión en un dominio, Windows almacena en caché las credenciales proporcionadas y las almacena en el subárbol de seguridad en el registro del sistema operativo.

Con las credenciales almacenadas en caché, el usuario puede iniciar sesión en un miembro de dominio sin estar conectado a un controlador de dominio dentro de ese dominio.

Almacenamiento y validación de credenciales

No siempre es conveniente usar un conjunto de credenciales para el acceso a distintos recursos. Por ejemplo, un administrador podría querer usar credenciales administrativas en lugar de de usuario al acceder a un servidor remoto. De forma similar, si un usuario accede a recursos externos, como una cuenta bancaria, solo puede usar credenciales diferentes de sus credenciales de dominio. En las secciones siguientes se describen las diferencias en la administración de credenciales entre las versiones actuales de Windows sistemas operativos y los sistemas operativos Windows Vista y Windows XP.

Procesos de credenciales de inicio de sesión remoto

El Protocolo de escritorio remoto (RDP) administra las credenciales del usuario que se conecta a un equipo remoto mediante el cliente de Escritorio remoto, que se introdujo en Windows 8. Las credenciales en formato de texto no cifrado se envían al host de destino donde el host intenta realizar el proceso de autenticación y, si se ejecuta correctamente, conecta el usuario a los recursos permitidos. RDP no almacena las credenciales en el cliente, pero las credenciales de dominio del usuario se almacenan en LSASS.

Introducido en Windows Server 2012 R2 y Windows 8.1, el modo de administración restringida proporciona seguridad adicional a escenarios de inicio de sesión remoto. Este modo de Escritorio remoto hace que la aplicación cliente realice una respuesta de desafío de inicio de sesión de red con la función unidireccional NT (NTOWF) o use un vale de servicio Kerberos al autenticarse en el host remoto. Una vez autenticado el administrador, el administrador no tiene las credenciales de cuenta respectivas en LSASS porque no se proporcionaron al host remoto. En su lugar, el administrador tiene las credenciales de la cuenta de equipo para la sesión. Las credenciales de administrador no se proporcionan al host remoto, por lo que las acciones se realizan como la cuenta de equipo. Los recursos también se limitan a la cuenta de equipo y el administrador no puede acceder a los recursos con su propia cuenta.

Proceso de credenciales de inicio de sesión de reinicio automático

Cuando un usuario inicia sesión en un dispositivo Windows 8.1, LSA guarda las credenciales de usuario en memoria cifrada a las que solo LSASS.exe puede acceder. Cuando Windows Update inicia un reinicio automático sin presencia de usuario, estas credenciales se usan para configurar El registro automático para el usuario.

Al reiniciar, el usuario inicia sesión automáticamente a través del mecanismo autologon y, a continuación, el equipo se bloquea además para proteger la sesión del usuario. El bloqueo se inicia a través de Winlogon, mientras que LSA realiza la administración de credenciales. Al iniciar sesión y bloquear automáticamente la sesión del usuario en la consola, las aplicaciones de pantalla de bloqueo del usuario se reinician y están disponibles.

Para obtener más información sobre ARSO, consulte Reinicio automático de Winlogon Sign-On (ARSO).

Nombres de usuario y contraseñas almacenados en Windows Vista y Windows XP

En Windows Server 2008 , Windows Server 2003, Windows Vista y Windows XP, nombres de usuario almacenados y contraseñas en Panel de control simplifica la administración y el uso de varios conjuntos de credenciales de inicio de sesión, incluidos los certificados X.509 usados con tarjetas inteligentes y Windows Credenciales activas (ahora denominadas cuenta Microsoft). Las credenciales ( parte del perfil del usuario) se almacenan hasta que sea necesario. Esta acción puede aumentar la seguridad por recurso asegurándose de que, si una contraseña está en peligro, no pone en peligro toda la seguridad.

Después de que un usuario inicie sesión e intente acceder a recursos adicionales protegidos con contraseña, como un recurso compartido en un servidor, y si las credenciales de inicio de sesión predeterminadas del usuario no son suficientes para obtener acceso, se consultan nombres de usuario almacenados y contraseñas . Si se han guardado credenciales alternativas con la información de inicio de sesión correcta en Nombres de usuario almacenados y contraseñas, estas credenciales se usan para obtener acceso. De lo contrario, se pide al usuario que proporcione nuevas credenciales, que luego se pueden guardar para su reutilización, ya sea más adelante en la sesión de inicio de sesión o durante una sesión posterior.

Se aplican las restricciones que se indican a continuación:

  • Si los nombres de usuario almacenados y las contraseñas contienen credenciales no válidas o incorrectas para un recurso específico, no aparece el acceso al recurso y no aparece el cuadro de diálogo Nombres de usuario almacenados y contraseñas .

  • Los nombres de usuario almacenados y las contraseñas solo almacenan credenciales para NTLM, el protocolo Kerberos, la cuenta Microsoft (anteriormente Windows Live ID) y la autenticación capa de sockets seguros (SSL). Algunas versiones de Internet Explorer mantienen su propia memoria caché para la autenticación básica.

Estas credenciales se convierten en una parte cifrada del perfil local de un usuario en el directorio \Documents and Configuración\Username\Application Data\Microsoft\Credentials. Como resultado, estas credenciales pueden desplazarse con el usuario si la directiva de red del usuario admite perfiles de usuario móviles. Sin embargo, si el usuario tiene copias de nombres de usuario almacenados y contraseñas en dos equipos diferentes y cambia las credenciales asociadas al recurso en uno de estos equipos, el cambio no se propaga a Nombres de usuario almacenados y contraseñas en el segundo equipo.

Windows Vault y El Administrador de credenciales

El Administrador de credenciales se introdujo en Windows Server 2008 R2 y Windows 7 como una característica de Panel de control para almacenar y administrar nombres de usuario y contraseñas. Credential Manager permite a los usuarios almacenar credenciales relevantes para otros sistemas y sitios web en el almacén seguro de Windows. Algunas versiones de Internet Explorer usan esta característica para la autenticación en sitios web.

El usuario controla la administración de credenciales mediante el Administrador de credenciales en el equipo local. Los usuarios pueden guardar y almacenar credenciales desde exploradores y aplicaciones de Windows admitidos para poder iniciar sesión en estos recursos de forma cómoda cuando lo necesiten. Las credenciales se guardan en carpetas cifradas especiales en el equipo bajo el perfil del usuario. Las aplicaciones que admiten esta característica (mediante el uso de las API del Administrador de credenciales), como exploradores web y aplicaciones, pueden presentar las credenciales correctas a otros equipos y sitios web durante el proceso de inicio de sesión.

Cuando un sitio web, una aplicación u otro equipo solicita autenticación a través de NTLM o el protocolo Kerberos, aparece un cuadro de diálogo en el que se activa la casilla Actualizar credenciales predeterminadas o Guardar contraseña . Este cuadro de diálogo que permite a un usuario guardar las credenciales localmente se genera mediante una aplicación que admite las API del Administrador de credenciales. Si el usuario activa la casilla Guardar contraseña , el Administrador de credenciales realiza un seguimiento del nombre de usuario, la contraseña y la información relacionada del usuario para el servicio de autenticación que está en uso.

La próxima vez que se use el servicio, Credential Manager proporciona automáticamente la credencial almacenada en el almacén de Windows. Si no se acepta, se solicitará al usuario la información de acceso correcta. Si se concede acceso con las nuevas credenciales, Credential Manager sobrescribe la credencial anterior con la nueva y, a continuación, almacena la nueva credencial en el almacén de Windows.

Base de datos Administrador de cuentas de seguridad

El Administrador de cuentas de seguridad (SAM) es una base de datos que almacena cuentas y grupos de usuarios locales. Está presente en cada Windows sistema operativo; sin embargo, cuando un equipo está unido a un dominio, Active Directory administra cuentas de dominio en dominios de Active Directory.

Por ejemplo, los equipos cliente que ejecutan un sistema operativo Windows participan en un dominio de red mediante la comunicación con un controlador de dominio incluso cuando ningún usuario humano ha iniciado sesión. Para iniciar comunicaciones, el equipo debe tener una cuenta activa en el dominio. Antes de aceptar las comunicaciones del equipo, el LSA en el controlador de dominio autentica la identidad del equipo y, a continuación, construye el contexto de seguridad del equipo igual que para una entidad de seguridad humana. Este contexto de seguridad define la identidad y las funcionalidades de un usuario o servicio en un equipo determinado, un servicio o un equipo en una red. Por ejemplo, el token de acceso contenido en el contexto de seguridad define los recursos (como un recurso compartido de archivos o una impresora) a los que se puede acceder y las acciones (como Leer, Escribir o Modificar) que puede realizar esa entidad de seguridad: un usuario, un equipo o un servicio en ese recurso.

El contexto de seguridad de un usuario o equipo puede variar de un equipo a otro, como cuando un usuario inicia sesión en un servidor o una estación de trabajo distinta de la propia estación de trabajo principal del usuario. También puede variar de una sesión a otra, como cuando un administrador modifica los derechos y permisos del usuario. Además, el contexto de seguridad suele ser diferente cuando un usuario o equipo funciona de forma independiente, en una red o como parte de un dominio de Active Directory.

Dominios locales y dominios de confianza

Cuando existe una confianza entre dos dominios, los mecanismos de autenticación de cada dominio dependen de la validez de las autenticaciones procedentes del otro dominio. Las confianzas ayudan a proporcionar acceso controlado a los recursos compartidos en un dominio de recursos (el dominio de confianza) comprobando que las solicitudes de autenticación entrantes proceden de una entidad de confianza (el dominio de confianza). De este modo, las confianzas actúan como puentes que permiten que solo las solicitudes de autenticación validadas viajen entre dominios.

La forma en que una confianza específica pasa las solicitudes de autenticación depende de cómo se configure. Las relaciones de confianza pueden ser unidireccionales, proporcionando acceso desde el dominio de confianza a los recursos del dominio de confianza, o bidireccionalmente, proporcionando acceso desde cada dominio a los recursos del otro dominio. Las confianzas también son notransitivas, en cuyo caso existe una confianza solo entre los dos dominios de asociados de confianza, o transitiva, en cuyo caso una confianza se extiende automáticamente a cualquier otro dominio que confíe cualquiera de los asociados.

Para obtener información sobre las relaciones de confianza de dominio y bosque con respecto a la autenticación, consulte Relaciones de confianza y autenticación delegada.

Certificados en autenticación de Windows

Una infraestructura de clave pública (PKI) es la combinación de software, tecnologías de cifrado, procesos y servicios que permiten a una organización proteger sus comunicaciones y transacciones empresariales. La capacidad de una PKI para proteger las comunicaciones y las transacciones empresariales se basa en el intercambio de certificados digitales entre usuarios autenticados y recursos de confianza.

Un certificado digital es un documento electrónico que contiene información sobre la entidad a la que pertenece, la entidad a la que se emitió, un número de serie único o alguna otra identificación única, fechas de emisión y expiración, y una huella digital.

La autenticación es el proceso de determinar si un host remoto puede ser de confianza. Para establecer su confiabilidad, el host remoto debe proporcionar un certificado de autenticación aceptable.

Los hosts remotos establecen su confiabilidad obteniendo un certificado de una entidad de certificación (CA). La entidad de certificación puede, a su vez, tener una certificación de una autoridad superior, que crea una cadena de confianza. Para determinar si un certificado es de confianza, una aplicación debe determinar la identidad de la entidad de certificación raíz y, a continuación, determinar si es de confianza.

Del mismo modo, el host remoto o el equipo local deben determinar si el certificado presentado por el usuario o la aplicación es auténtico. El certificado presentado por el usuario a través de LSA y SSPI se evalúa para la autenticidad en el equipo local para el inicio de sesión local, en la red o en el dominio a través de los almacenes de certificados en Active Directory.

Para generar un certificado, los datos de autenticación pasan a través de algoritmos hash, como el algoritmo hash seguro 1 (SHA1), para generar un resumen de mensaje. A continuación, el resumen del mensaje se firma digitalmente mediante la clave privada del remitente para demostrar que el remitente generó el resumen del mensaje.

Nota

SHA1 es el valor predeterminado en Windows 7 y Windows Vista, pero se cambió a SHA2 en Windows 8.

Autenticación con tarjeta inteligente

La tecnología de tarjeta inteligente es un ejemplo de autenticación basada en certificados. El inicio de sesión en una red con una tarjeta inteligente proporciona una forma segura de autenticación porque usa la identificación basada en criptografía y la prueba de posesión al autenticar a un usuario en un dominio. Servicios de certificados de Active Directory (AD CS) proporciona la identificación basada en cifrado mediante la emisión de un certificado de inicio de sesión para cada tarjeta inteligente.

Para obtener información sobre la autenticación de tarjetas inteligentes, consulte la referencia técnica de Windows tarjeta inteligente.

La tecnología de tarjeta inteligente virtual se introdujo en Windows 8. Almacena el certificado de la tarjeta inteligente en el equipo y, a continuación, lo protege mediante el chip de seguridad del módulo de plataforma segura (TPM) de prueba de alteraciones del dispositivo. De este modo, el equipo se convierte en la tarjeta inteligente que debe recibir el PIN del usuario para autenticarse.

Autenticación remota e inalámbrica

La autenticación de red remota e inalámbrica es otra tecnología que usa certificados para la autenticación. El servicio de autenticación de Internet (IAS) y los servidores de red privada virtual usan la autenticación extensible Protocol-Transport seguridad de nivel (EAP-TLS), el protocolo de autenticación extensible protegido (PEAPP) o la seguridad del protocolo de Internet (IPsec) para realizar la autenticación basada en certificados para muchos tipos de acceso a la red, incluida la red privada virtual (VPN) y las conexiones inalámbricas.

Para obtener información sobre la autenticación basada en certificados en redes, consulte Autenticación y certificados de acceso a la red.

Vea también

Conceptos de autenticación de Windows