Procesos de las credenciales en la autenticación de Windows

Este tema contiene las siguientes secciones:

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

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

• Autoridad de seguridad local

• Credenciales y validación almacenadas en caché

• Almacenamiento y validación de credenciales

• Base de datos Administrador de cuentas de seguridad

• Dominios locales y dominios de confianza

• Certificados en Windows autenticación

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áfica (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 gráfica y autenticación

La arquitectura de identificación y autenticación gráfica (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 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 un inicio de sesión interactivo se ejecutan en la sesión 0. La sesión 0 hospeda 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 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 diferentes métodos de autenticación, 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 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 valor 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. La entidad de seguridad local y los paquetes de autenticación aplican la seguridad.

Los proveedores de credenciales están registrados 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.

• 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 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 la red y las directivas de bloqueo o desbloqueo 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 realizar 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á pensado para usarse en los escenarios siguientes:

• La autenticación de red y el inicio de sesión del equipo se controlan mediante diferentes proveedores de credenciales. Entre las variaciones de este escenario se incluyen:

  • 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 Access Services conexión remota a través de VPN antes del inicio de sesión local para autenticar 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 Access Services remota a través de una conexión VPN antes de completar el inicio de sesión interactivo.

• El mismo proveedor de credenciales controla la autenticación de red y el inicio de sesión del equipo. 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. Normalmente, el proveedor de credenciales serializa las credenciales para la autenticación en la entidad de seguridad local. Este proceso muestra iconos específicos para 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 más de un usuario ha iniciado sesión, se muestran numerosos iconos.

• El proveedor de credenciales enumera los iconos en función de 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 solicitando 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 para 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

Windows autenticación está diseñada para administrar credenciales para 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 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 compatibilidad 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 cliente/servidor:

• La aplicación en el lado cliente de la conexión envía las 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 de SSPI y se repiten hasta que todos los mensajes de autenticación necesarios se han intercambiado para realizar la autenticación InitializeSecurityContext (General)AcceptSecurityContext (General) correcta o con errores.

• 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 SSPI ImpersonateSecurityContext para adjuntar el token de acceso a un subproceso de suplantación para el servicio.

Aplicaciones y modo de usuario

El modo de usuario de Windows se compone de dos sistemas capaces de pasar solicitudes de E/S a los controladores en 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 de sistema de seguridad (LSA), un servicio de estación de trabajo y un servicio de servidor. El proceso del sistema de seguridad se ocupa de 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 los recursos del sistema que el sistema operativo necesita auditar.

Las aplicaciones se pueden ejecutar en modo de usuario, donde la aplicación puede ejecutarse 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 los protocolos de nivel de aplicación y los protocolos de seguridad. Dado que las distintas aplicaciones requieren diferentes formas de identificar o autenticar a los usuarios y diferentes formas de cifrar los datos a medida que viajan a través de una red, SSPI proporciona una manera de acceder a las bibliotecas de vínculos dinámicos (DLL) que contienen funciones criptográficas y de autenticación diferentes. Estos archivos DLL se denominan proveedores de compatibilidad 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 fundamentales, 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 La documentación de cuentas de servicio administradas para Windows 7 y Windows Server 2008 R2 y Introducción a las cuentas de servicio administradas de grupo.

Servicios y modo kernel

Aunque la mayoría Windows aplicaciones se ejecutan en el contexto de seguridad del usuario que las inicia, esto no es cierto en los servicios. Muchos Windows, como los servicios de red e impresión, 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 funcionando después de que el último usuario humano se cierra la sesión.

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 del LSA. El Windows implementa una interfaz de programación que el administrador del controlador de servicio puede usar para controlar el servicio. Un Windows servicio 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 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. Para obtener una conexión autenticada, el servicio debe tener credenciales en las que confíe 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 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 compatibilidad de seguridad (SSP) en modo kernel y, en las 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 del 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 inicia sesión de 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 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, Local Security Authority Server Service (LSASS), realiza un seguimiento de las directivas de seguridad y 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 del 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 grupos locales. Sin embargo, estas cuentas se pueden usar para acceder solo 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 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 de 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 de 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 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 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 LSA, que son fragmentos secretos de datos a los que solo pueden acceder 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 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 Microsoft

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

Para obtener más información sobre estas protecciones adicionales, vea Configuring Additional LSA Protection.

Validación y credenciales almacenadas en caché

Los mecanismos de validación se basan en la presentación de las credenciales en el momento del inicio de sesión. Sin embargo, cuando el equipo se desconecta 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 acceder a recursos diferentes. Por ejemplo, un administrador podría querer usar credenciales administrativas en lugar de credenciales 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 que sean 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 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 realiza correctamente, 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 el 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 UNE de 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 correspondientes 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 la memoria cifrada a la que solo pueden acceder LSASS.exe. Cuando Windows update inicia un reinicio automático sin la presencia del usuario, estas credenciales se usan para configurar el inicio de sesión automático para el usuario.

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

Para obtener más información sobre ARSO, vea Winlogon Automatic Restart 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, Los nombres de usuario y contraseñas almacenados en Panel de control simplifican 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 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 al garantizar que, si una contraseña está en peligro, no pone en peligro toda la seguridad.

Una vez que un usuario inicia sesión e intenta acceder a recursos protegidos con contraseña adicionales, 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 los nombres de usuario almacenados y las contraseñas. 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 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 y contraseñas almacenados contienen credenciales no válidas o incorrectas para un recurso específico, se deniega el acceso al recurso y no aparece el cuadro de diálogo Nombres de usuario y contraseñas almacenados.

• Los nombres de usuario y contraseñas almacenados 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 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 se pueden recorrer 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 y contraseñas almacenados en el segundo equipo.

Windows Vault y Administrador de credenciales

Administrador de credenciales se introdujo en Windows Server 2008 R2 y Windows 7 como una característica Panel de control para almacenar y administrar nombres de usuario y contraseñas. Administrador de credenciales permite a los usuarios almacenar credenciales relevantes para otros sistemas y sitios web en el almacén Windows Vault. Algunas versiones de Internet Explorer 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 en el perfil del usuario. Las aplicaciones que admiten esta característica (mediante el uso de las API de 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 solicitan autenticación a través de 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. Esta aplicación que admite las API de Administrador de credenciales genera este cuadro de diálogo que permite a un usuario guardar las credenciales localmente. Si el usuario selecciona la casilla Guardar contraseña, Administrador de credenciales realiza un seguimiento del nombre de usuario, la contraseña y la información relacionada del servicio de autenticación que está en uso.

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

Base de datos Administrador de cuentas de seguridad

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

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 las 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, a continuación, construye el contexto de seguridad del equipo tal como lo hace 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 en un usuario, servicio o equipo de una red. Por ejemplo, el token de acceso contenido en el contexto de seguridad define los recursos (como un recurso compartido de archivos o 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, 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 que no sea la 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 Active Directory usuario.

Dominios locales y dominios de confianza

Cuando existe una confianza entre dos dominios, los mecanismos de autenticación de cada dominio se basan en 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 autoridad de confianza (el dominio de confianza). De esta manera, 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 un solo sentido, ya que proporcionan acceso desde el dominio de confianza a los recursos del dominio de confianza, o en dos sentidos, proporcionando acceso desde cada dominio a los recursos del otro dominio. Las confianzas también son no transparentes, en cuyo caso solo existe una confianza entre los dos dominios de asociado de confianza, o transitivas, en cuyo caso una confianza se extiende automáticamente a cualquier otro dominio en el 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, vea Relaciones de confianza y autenticación delegadas.

Certificados en Windows autenticación

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 por 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 mediante la obtención de un certificado de una entidad de certificación (CA). A su vez, la entidad de certificación puede tener la certificación de una autoridad superior, lo que crea una cadena de confianza. Para determinar si un certificado es de confianza, una aplicación debe determinar la identidad de la CA 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 Algoritmo hash seguro 1 (SHA1), para generar un resumen del mensaje. A continuación, la síntesis del mensaje se firma digitalmente mediante la clave privada del remitente para demostrar que el remitente produjo el resumen del mensaje.

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 a través de 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 Windows Referencia técnica de 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 de Módulo de plataforma segura (TPM) del dispositivo. De esta manera, el equipo se convierte realmente en la tarjeta inteligente que debe recibir el PIN del usuario para poder 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 de seguridad de nivel Protocol-Transport (EAP-TLS), el protocolo de autenticación extensible protegido (PEAP) o la seguridad de 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 de acceso a redes y certificados.

Consulte también

Conceptos de 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 Windows la autenticación 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 su futura presentación 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 algún tipo de prueba de autenticidad, como un certificado, una contraseña o un PIN.

De forma predeterminada, Windows credenciales se validan con la base de datos del Administrador de cuentas de seguridad (SAM) del 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 directivas, 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 toman a través del sistema para autenticar al usuario o al proceso para un inicio de sesión correcto.

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

Componentes de autenticación para todos los sistemas