Procesos de las credenciales en la autenticación de Windows
Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016
Este tema de referencia para profesionales de TI describe cómo la autenticación de Windows procesa las credenciales.
La administración de credenciales de Windows es el proceso por el que el sistema operativo recibe las credenciales del servicio o usuario y protege esa información para futuras presentaciones 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 manera predeterminada, las credenciales de Windows se validan con la base de datos del Administrador de cuentas de seguridad (SAM) en el equipo local, o con 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.
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 los sistemas operativos Windows 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 múltiples 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 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. |
| 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 a la que solo puede acceder 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 y autenticación gráficas (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 de identificación y autenticación gráficas
La arquitectura de identificación y autenticación gráficas (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 GINA se carga en el espacio de procesos 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 un inicio de sesión interactivo se ejecutan 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 para Windows Server 2003, Microsoft Windows 2000 Server, Windows XP y 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 el uso de proveedores de credenciales. Estos proveedores están representados por los diferentes iconos de inicio de sesión en el dispositivo de escritorio seguro que permiten cualquier número de escenarios de inicio de sesión: diferentes cuentas para el mismo usuario y diferentes métodos de autenticación, como contraseña, tarjeta inteligente y biometría.
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 a cada proveedor de credenciales 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:
Describir la información de credenciales necesaria para la autenticación.
Controlar la comunicación y la lógica con las autoridades de autenticación externas.
Empaquetar las 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 pantalla de 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 la red y las directivas de bloqueo/desbloqueo de las estaciones 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 predeterminado de acceso previo al inicio de sesión (PLAP), 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 Servicios de acceso remoto 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 Servicios de acceso remoto a través de una 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 siguientes instancias:
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 estación de trabajo. Normalmente, el proveedor de credenciales 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 ha iniciado sesión más de un usuario, 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 ha iniciado 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 la interfaz de usuario de credenciales. 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 utiliza en el Control de cuentas de usuario (UAC), que puede ayudar a evitar cambios no autorizados en un equipo solicitando permiso al usuario o una contraseña de administrador antes de permitir acciones que puedan afectar potencialmente al funcionamiento del equipo o que puedan cambiar parámetros que afecten 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.
Entrada de credenciales para el inicio de sesión de aplicación y servicio
La autenticación de Windows está diseñada para administrar credenciales de aplicaciones o servicios que no requieren la interacción del usuario. Las aplicaciones en modo de usuario están limitadas en cuanto a los recursos del sistema a los que tienen acceso, mientras que los servicios pueden acceder sin restricciones a la memoria del sistema y a los dispositivos externos.
Los servicios del sistema y las aplicaciones a nivel de transporte acceden a un Proveedor de soporte de seguridad (SSP) a través de la Interfaz de proveedor de soporte de seguridad (SSPI) de 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 SSPI
InitializeSecurityContext (General).La aplicación del lado servidor de la conexión responde con la función SSPI
AcceptSecurityContext (General).Las funciones SSPI
InitializeSecurityContext (General)yAcceptSecurityContext (General)se repiten hasta que se hayan intercambiado todos los mensajes de autenticación necesarios para que la autenticación tenga éxito o falle.Una vez autentificada la conexión, el LSA del servidor usa la información del cliente para construir el contexto de seguridad, que contiene los tokens de acceso.
Después, el servidor puede llamar a la función SSPI
ImpersonateSecurityContextpara adjuntar los tokens de acceso a un subproceso de suplantación para el servicio.
Modo de usuario y aplicaciones
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 entero, 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 controla los tokens de seguridad, concede o deniega permisos para acceder a las cuentas de usuario en función de los permisos de los 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 necesita auditar el sistema operativo.
Las aplicaciones pueden ejecutarse en modo de usuario, en el que la aplicación puede ejecutarse como cualquier entidad de seguridad, incluso en el contexto de seguridad del sistema local (SYSTEM). Las aplicaciones también pueden ejecutarse en modo kernel, en el que la aplicación puede ejecutarse en el contexto de seguridad del sistema local (SYSTEM).
SSPI está disponible a través del módulo Secur32.dll, que es una API utilizada 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 las 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 de seguridad (SSP).
Las cuentas de servicio administradas y las cuentas virtuales se introdujeron en Windows Server 2008 R2 y Windows 7 para proporcionar a las aplicaciones cruciales, como Microsoft SQL Server e Internet Information Services (IIS), el aislamiento de sus propias cuentas de dominio, eliminando al mismo tiempo la necesidad de que un administrador administre manualmente el nombre de entidad de servicio (SPN) y las credenciales de estas cuentas. Para 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 e Introducción a las cuentas de servicio administradas por grupo.
Servicios y modo kernel
Aunque la mayoría de las aplicaciones de Windows se ejecutan en el contexto de seguridad del usuario que las inicia, no ocurre lo mismo con los servicios. Muchos servicios de Windows, como los servicios de red y de impresión, son iniciados por el controlador de servicios cuando el usuario arranca 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 se desconecte.
Nota:
Los servicios se ejecutan normalmente en contextos de seguridad conocidos como Sistema local (SYSTEM), Servicio de red o Servicio local. Windows Server 2008 R2 introdujo servicios que se ejecutan bajo una cuenta de servicio administrada, que son entidades de dominio.
Antes de iniciar un servicio, el controlador del servicio se conecta usando la cuenta designada para el servicio, y después presenta las credenciales del servicio para su autenticación por el LSA. El servicio Windows implementa una interfaz programática que el administrador del controlador del servicio puede usar para controlar el servicio. Un servicio de Windows puede iniciarse automáticamente al arrancar el sistema o manualmente con un programa de control de servicios. Por ejemplo, cuando un equipo cliente de Windows se une a un dominio, el servicio de mensajería del equipo se conecta a un controlador de dominio y abre un canal seguro con él. Para obtener una conexión autenticada, el servicio debe disponer de credenciales en las que confíe la Autoridad de seguridad local (ASL) del equipo remoto. Cuando se comunica con otros equipos de la red, LSA usa las credenciales de la cuenta de dominio del equipo local, al igual que el resto de servicios que se ejecutan en el contexto de seguridad del Servicio de red y sistema local. Los servicios del equipo local se ejecutan como SISTEMA, por lo que no es necesario presentar las credenciales al LSA.
El archivo Ksecdd.sys administra y cifra estas credenciales y usa una llamada a procedimiento local en el LSA. El tipo de archivo es DRV (controlador) y se conoce como Proveedor de soporte de seguridad (SSP) en modo kernel y, en aquellas 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 del 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 de 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, el Servicio del servidor de la 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.
El 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. El LSA puede validar la información de usuario comprobando la base de datos del 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.
Autoridad 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 los archivos compartidos, los buzones de Exchange Server y los sitios de SharePoint, sin tener que 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 Administrador de LAN (LM)
Si el usuario inicia sesión en Windows mediante una tarjeta inteligente, LSASS no almacena ninguna contraseña en texto sin formato, sino que almacena el valor hash de NT que se corresponda con la cuenta y el PIN en texto sin formato de 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 del Administrador de LAN (LM), este autenticador estará 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 directamente asociadas con las sesiones de inicio de sesión del Subsistema de servicio 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 una sesión local o 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 pueden acceder los procesos de la cuenta de SISTEMA, 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 la cuenta de Active Directory Domain Services (AD DS) del equipo
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 una protección adicional al LSA para evitar la lectura de memoria y la inyección de código por parte de procesos no protegidos. Esto proporciona seguridad adicional para las credenciales que LSA almacena y administra.
Para más información sobre estas protecciones adicionales, consulte Configuración de la 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 se conecta a un dominio, Windows almacena en caché las credenciales suministradas y las guarda en la colmena de seguridad del registro del sistema operativo.
Con las credenciales almacenadas en caché, el usuario puede iniciar sesión en un miembro del 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 acceder a distintos recursos. Por ejemplo, un administrador puede querer usar credenciales administrativas en lugar de las de usuario cuando acceda a un servidor remoto. Del mismo modo, si un usuario accede a recursos externos, como una cuenta bancaria, solo podrá usar credenciales diferentes a las de su dominio. Las siguientes secciones describen las diferencias en la administración de credenciales entre las versiones actuales de los sistemas operativos Windows 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 uso del Cliente de escritorio remoto, que se introdujo en Windows 8. Las credenciales en forma de texto sin formato se envían al host de destino, donde intenta realizar el proceso de autenticación y, si tiene éxito, conecta al 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 los escenarios de inicio de sesión remoto. Este modo de Escritorio remoto hace que la aplicación cliente realice un desafío-respuesta de inicio de sesión de red con la función unidireccional NT (NTOWF) o use un ticket de servicio Kerberos cuando se autentique en el host remoto. Después de autenticar al administrador, no dispone de las respectivas credenciales de cuenta en LSASS porque no se suministraron 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 comienza un reinicio automático sin la presencia del usuario, estas credenciales se usan para configurar Autologon para el usuario.
Al reiniciarse, el usuario inicia sesión automáticamente mediante el mecanismo Autologon y después el equipo se bloquea adicionalmente 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 más información sobre ARSO, consulte Inicio de sesión con reinicio automático de Winlogon (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 y contraseñas almacenados en el 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 utilizados con tarjetas inteligentes y las credenciales de Windows Live (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 por 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 consulta Nombres de usuario y contraseñas almacenados. Si se han guardado credenciales alternativas con la información de inicio de sesión correcta en Nombres de usuario y contraseñas almacenados, estas credenciales se usan para obtener acceso. De lo contrario, se solicita al usuario que proporcione nuevas credenciales, que luego pueden guardarse para volver a utilizarse, ya sea más tarde 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 Nombres de usuario y contraseñas almacenados contiene credenciales no válidas o incorrectas para un recurso específico, se denegará el acceso al recurso y no aparecerá el cuadro de diálogo Nombres de usuario y contraseñas almacenados.
Nombres de usuario y contraseñas almacenados almacena solo credenciales para NTLM, protocolo Kerberos, cuenta Microsoft (antes denominado Windows Live ID) y autenticación de 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 Settings\Username\Application Data\Microsoft\Credentials. Como resultado, estas credenciales pueden itinerar con el usuario si su directiva de red es compatible con los perfiles de usuario itinerantes. Sin embargo, si el usuario tiene copias de Nombres de usuario y contraseñas almacenados en dos equipos diferentes y cambia las credenciales que están asociadas al recurso en uno de estos equipos, el cambio no se propaga a Nombres de usuario y contraseñas almacenados en el segundo equipo.
Administrador de credenciales y almacén de Windows
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. El Administrador de credenciales 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 dentro del perfil del usuario. Las aplicaciones que admiten esta característica (mediante el uso de 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 la autenticación mediante NTLM o el protocolo Kerberos, aparece un cuadro de diálogo en el que se selecciona la casilla Actualizar credenciales predeterminadas o Guardar contraseña. Este cuadro de diálogo que permite a un usuario guardar credenciales localmente es generado por una aplicación compatible con las API del Administrador de credenciales. Si el usuario selecciona 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 servicio de autenticación que se está usando.
La próxima vez que se use el servicio, el Administrador de credenciales suministrará 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 el acceso con las nuevas credenciales, el Administrador de credenciales sobrescribe la credencial anterior con la nueva y después 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 todos los sistemas operativos Windows. Sin embargo, cuando un equipo se une a un dominio, Active Directory administra las cuentas de dominio en los dominios de Active Directory.
Por ejemplo, los equipos cliente que ejecutan un sistema operativo Windows participan en un dominio de red comunicándose con un controlador de dominio incluso cuando no hay ningún usuario humano conectado. Para iniciar comunicaciones, el equipo debe tener una cuenta activa en el dominio. Antes de aceptar las comunicaciones del equipo, el LSA del controlador de dominio autentica la identidad del equipo y 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, o de un usuario, servicio o 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 Lectura, Escritura o Modificación) que puede realizar esa entidad de seguridad: un usuario, equipo o servicio en ese recurso.
El contexto de seguridad de un usuario o de un equipo puede variar de un equipo a otro, como cuando un usuario se conecta a un servidor o a una estación de trabajo distinta de la estación de trabajo principal del propio 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 autónoma, en red o como parte de un dominio de Active Directory.
Dominios locales y dominios de confianza
Cuando existe confianza entre dos dominios, los mecanismos de autenticación de cada dominio confían en la validez de las autenticaciones procedentes del otro dominio. La confianza ayuda a proporcionar acceso controlado a los recursos compartidos de un dominio de recursos (el dominio que confía) asegurando 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 la que una confianza específica pasa las solicitudes de autenticación depende de cómo esté configurada. 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 de 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 comerciales. 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 por la que fue emitido, un número de serie único o alguna otra identificación única, fechas de emisión y caducidad, y una huella digital.
La autenticación es el proceso de determinar si se puede confiar en un host remoto. Para establecer su fiabilidad, el host remoto debe proporcionar un certificado de autenticación aceptable.
Los hosts remotos establecen su fiabilidad obteniendo un certificado de una autoridad 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 SSPI y LSA 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 la criptografía mediante la emisión de un certificado de inicio de sesión para cada tarjeta inteligente.
Para obtener información sobre la autenticación con tarjeta inteligente, consulte la Referencia técnica sobre tarjetas inteligentes de Windows.
La tecnología de tarjeta inteligente virtual se introdujo en Windows 8. Almacena el certificado de la tarjeta inteligente en el PC y después lo protege usando el chip de seguridad del Módulo de plataforma segura (TPM) a prueba de manipulaciones 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 redes privadas virtuales usan el Protocolo de autenticación extensible-Seguridad de la capa de transporte (EAP-TLS), el Protocolo de autenticación extensible protegido (PEAP) o la seguridad del protocolo de Internet (IPsec) para realizar la autenticación basada en certificados para muchos tipos de acceso a la red, incluidas las conexiones de redes privadas virtuales (VPN) e inalámbricas.
Para obtener información sobre la autenticación basada en certificados en redes, consulte Autenticación de acceso a redes y certificados.