Security Support Provider Interface Architecture
Este tema de referencia para profesionales de TI describe los protocolos de autenticación de Windows que se usan dentro de la arquitectura de la Interfaz de proveedor de soporte de seguridad (SSPI).
La interfaz del proveedor de compatibilidad para seguridad (SSPI) de Microsoft es la base de la autenticación de Windows. Las aplicaciones y los servicios de infraestructura que requieren autenticación utilizan SSPI para proporcionarla.
SSPI es la implementación de la API de servicio de seguridad genérica (GSSAPI) en los sistemas operativos de Windows Server. Para más información sobre GSSAPI, consulte los documentos RFC 2743 y RFC 2744 en la base de datos de RFC del IETF.
Los Proveedores de soporte de seguridad (SSP) predeterminados que invocan protocolos de autenticación específicos en Windows se incorporan a la SSPI como DLL. Estos SSP predeterminados se describen en las secciones siguientes. Se pueden incorporar SSP adicionales si pueden funcionar con la SSPI.
Como se muestra en la siguiente imagen, la SSPI de Windows proporciona un mecanismo que transporta los tokens de autenticación a través del canal de comunicación existente entre el equipo cliente y el servidor. Cuando dos equipos o dispositivos necesitan autenticarse para poder comunicarse de forma segura, las solicitudes de autenticación se dirigen a la SSPI, que completa el proceso de autenticación, independientemente del protocolo de red que se esté usando en ese momento. La SSPI devuelve objetos binarios transparentes de gran tamaño. Se pasan entre las aplicaciones, momento en el que pueden pasarse a la capa de la SSPI. Así, la SSPI permite a una aplicación usar varios modelos de seguridad disponibles en un equipo o una red sin cambiar la interfaz con el sistema de seguridad.
En las secciones siguientes se describen los SSP predeterminados que interactúan con la SSPI. Los SSP se usan de diferentes maneras en los sistemas operativos Windows para promover una comunicación segura en un entorno de red no seguro.
También se incluye en este tema:
Selección del proveedor de soporte de seguridad
Proveedor de soporte de seguridad Kerberos
Este SSP solo usa el protocolo Kerberos versión 5, tal como lo implementa Microsoft. Este protocolo se basa en el RFC 4120 del grupo de trabajo de red y en los borradores de revisiones. Es un protocolo estándar del sector que se usa con una contraseña o una tarjeta inteligente para un inicio de sesión interactivo. También es el método de autenticación preferido para los servicios en Windows.
Dado que el protocolo Kerberos ha sido el protocolo de autenticación predeterminado desde Windows 2000, todos los servicios de dominio admiten el SSP de Kerberos. Estos servicios incluyen:
Consultas de Active Directory que usan el Protocolo ligero de acceso a directorios (LDAP)
Administración remota de servidores o estaciones de trabajo que usa el servicio de llamada a procedimiento remoto
Servicios de impresión
Autenticación de cliente-servidor
Acceso remoto a archivos que usa el protocolo Bloque de mensajes del servidor (SMB) (también conocido como Sistema de archivos de Internet común o CIFS)
Administración y referencia del sistema de archivos distribuido
Autenticación de intranet en Internet Information Services (IIS)
Autenticación de la autoridad de seguridad para el protocolo de seguridad de Internet (IPsec)
Solicitudes de certificado a Servicios de certificados de Active Directory para usuarios y equipos de dominio
Ubicación: %Windir%\System32\kerberos.dll
Este proveedor se incluye de forma predeterminada en las versiones designadas en la lista Se aplica a al principio de este tema, además de Windows Server 2003 y Windows XP.
Recursos adicionales para el protocolo Kerberos y el SSP de Kerberos
Mejoras de Kerberos para Windows Vista
Cambios en la autenticación Kerberos para Windows 7
Proveedor de soporte de seguridad NTLM
El Proveedor de soporte de seguridad NTLM (NTLM SSP) es un protocolo de mensajería binaria usado por la Interfaz de proveedor de soporte de seguridad (SSPI) para permitir la autenticación NTLM desafío-respuesta y para negociar las opciones de integridad y confidencialidad. NTLM se usa siempre que se utiliza la autenticación SSPI, incluida la autenticación de Bloque de mensajes del servidor o CIFS, la autenticación HTTP Negotiate (por ejemplo, Autenticación web de Internet) y el servicio de Llamada a procedimiento remoto. El SSP NTLM incluye los protocolos de autenticación NTLM y NTLM versión 2 (NTLMv2).
Los sistemas operativos Windows compatibles pueden usar el SSP NTLM para lo siguiente:
Autenticación de cliente/servidor
Servicios de impresión
Acceso a archivos mediante CIFS (SMB)
Servicio de llamada de procedimiento remoto seguro o servicio DCOM
Ubicación: %Windir%\System32\msv1_0.dll
Este proveedor se incluye de forma predeterminada en las versiones designadas en la lista Se aplica a al principio de este tema, además de Windows Server 2003 y Windows XP.
Recursos adicionales para el protocolo NTLM y el SSP NTLM
Cambios en la autenticación NTLM en Windows 7
Proveedor de soporte de seguridad Digest
La autenticación Digest es un estándar del sector que se usa para el protocolo ligero de acceso a directorios (LDAP) y la autenticación web. La autenticación Digest transmite credenciales a través de la red como hash MD5 o resumen de mensajes.
El SSP de resumen (Wdigest.dll) se usa para lo siguiente:
Acceso a Internet Explorer e Internet Information Services (IIS)
Consultas LDAP
Ubicación: %Windir%\System32\Wdigest.dll
Este proveedor se incluye de forma predeterminada en las versiones designadas en la lista Se aplica a al principio de este tema, además de Windows Server 2003 y Windows XP.
Recursos adicionales para el protocolo Digest y el SSP de Digest
Proveedor de soporte de seguridad Schannel
El canal seguro (Schannel) se usa para la autenticación de servidor basada en web, como cuando un usuario intenta acceder a un servidor web seguro.
El protocolo TLS, el protocolo SSL, el protocolo de Tecnología de comunicaciones privadas (PCT) y el protocolo de Capa de transporte de datagramas (DTLS) se basan en la criptografía de clave pública. Schannel proporciona todos estos protocolos. Todos los protocolos de Schannel usan un modelo cliente/servidor. El SSP de SChannel usa certificados de clave pública para autenticar las partes. Al autentificar las partes, el SSP de Schannel selecciona un protocolo en el siguiente orden de preferencia:
Seguridad de la capa de transporte (TLS) versión 1.0
Seguridad de la capa de transporte (TLS) versión 1.1
Seguridad de la capa de transporte (TLS) versión 1.2
Capa de sockets seguros (SSL) versión 2.0
Capa de sockets seguros (SSL) versión 3.0
Tecnología de comunicaciones privadas (PCT)
Nota PCT está deshabilitado de forma predeterminada.
El protocolo seleccionado es el protocolo de autenticación preferido que el cliente y el servidor pueden admitir. Por ejemplo, si un servidor admite todos los protocolos Schannel y el cliente solo admite SSL 3.0 y SSL 2.0, el proceso de autenticación usa SSL 3.0.
DTLS se usa cuando la aplicación llama explícitamente. Para más información sobre DTLS y los demás protocolos que usa el proveedor Schannel, consulte Referencia técnica del proveedor de soporte de seguridad Schannel.
Ubicación: %Windir%\System32\Schannel.dll
Este proveedor se incluye de forma predeterminada en las versiones designadas en la lista Se aplica a al principio de este tema, además de Windows Server 2003 y Windows XP.
Nota
TLS 1.2 se introdujo en este proveedor en Windows Server 2008 R2 y Windows 7. DTLS se introdujo en este proveedor en Windows Server 2012 y Windows 8.
Recursos adicionales para los protocolos TLS y SSL y el SSP de Schannel
Proveedor de soporte de seguridad Negotiate
El Mecanismo de negociación de GSS-API simple y protegido (SPNEGO) constituye la base del SPNEGO, que puede usarse para negociar un protocolo de autenticación específico. Cuando una aplicación llama en SSPI para iniciar sesión en una red, puede especificar un SSP para que procese la solicitud. Si la aplicación especifica el SSP de Negotiate, este último analiza la solicitud y elige el proveedor apropiado para controlar la solicitud, basándose en las directivas de seguridad configuradas por el cliente.
SPNEGO se especifica en RFC 2478.
En las versiones compatibles de los sistemas operativos Windows, el proveedor de soporte de seguridad Negotiate selecciona entre el protocolo Kerberos y NTLM. Negotiate selecciona el protocolo Kerberos de manera predeterminada a menos que dicho protocolo no pueda ser utilizado por uno de los sistemas implicados en la autenticación, o que la aplicación que llama no haya proporcionado suficiente información para usar el protocolo Kerberos.
Ubicación: %Windir%\System32\lsasrv.dll
Este proveedor se incluye de forma predeterminada en las versiones designadas en la lista Se aplica a al principio de este tema, además de Windows Server 2003 y Windows XP.
Recursos adicionales para el SSP de Negotiate
[MS-SPNG]: Extensiones del Mecanismo de negociación de GSS-API simple y protegido (SPNEGO)
[MS-N2HT]: Especificación del protocolo de autenticación HTTP Negotiate y Nego2
Proveedor de compatibilidad para la seguridad de las credenciales
El Proveedor de servicios de seguridad de credenciales (CredSSP) proporciona una experiencia de usuario de inicio de sesión único (SSO) al iniciar nuevas sesiones de Terminal Services y Servicios de Escritorio remoto. CredSSP permite a las aplicaciones delegar las credenciales de los usuarios desde el equipo cliente (usando la SSP del lado del cliente) al servidor de destino (a través de la SSP del lado del servidor), basándose en las directivas del cliente. Las directivas CredSSP se configuran usando la directiva de grupo, y la delegación de credenciales está desactivada de forma predeterminada.
Ubicación: %Windir%\System32\credssp.dll
Este proveedor se incluye de forma predeterminada en las versiones designadas en la lista Se aplica a al principio de este tema.
Recursos adicionales para el SSP de credenciales
Proveedor de soporte de seguridad de Negotiate Extensions
Negotiate Extensions (NegoExts) es un paquete de autenticación que negocia el uso de SSP, que no sea NTLM o el protocolo Kerberos, para aplicaciones y escenarios implementados por Microsoft y otras empresas de software.
Esta extensión al paquete de Negotiate permite los siguientes escenarios:
Disponibilidad de cliente enriquecida dentro de un sistema federado. Se puede acceder a documentos en sitios de SharePoint y se pueden editar mediante una aplicación completa de Microsoft Office.
Compatibilidad de cliente enriquecida con los servicios de Microsoft Office. Los usuarios pueden iniciar sesión en los servicios de Microsoft Office y usar una aplicación completa de Microsoft Office.
Microsoft Exchange Server hospedado y Outlook. No se establece ninguna confianza de dominio porque Exchange Server se hospeda en la Web. Outlook usa el servicio Windows Live para autenticar a los usuarios.
Disponibilidad de cliente enriquecida entre los equipos cliente y los servidores. Se usan los componentes de autenticación y redes del sistema operativo.
El paquete de Windows Negotiate trata el SSP de NegoExts de la misma manera que lo hace para Kerberos y NTLM. NegoExts.dll se carga en la Autoridad del Sistema local (LSA) al iniciarse. Cuando se recibe una solicitud de autenticación, según el origen de la solicitud, NegoExts negocia entre los SSP admitidos. Recopila las credenciales y las directivas, las cifra y envía esa información al SSP adecuado, donde se crean los tokens de seguridad.
Los SSP admitidos por NegoExts no son SSP independientes, como Kerberos y NTLM. Por lo tanto, dentro del SSP NegoExts, cuando el método de autenticación falle por cualquier motivo, se mostrará o registrará un mensaje de fallo de autenticación. No es posible la renegociación ni los métodos de autenticación de reserva.
Ubicación: %Windir%\System32\negoexts.dll
Este proveedor se incluye de manera predeterminada en las versiones designadas en la lista Se aplica a al principio de este tema, excluyendo Windows Server 2008 y Windows Vista.
Proveedor de soporte de seguridad PKU2U
El protocolo PKU2U se introdujo e implementó como un SSP en Windows 7 y Windows Server 2008 R2 . Este SSP permite la autenticación entre iguales, en particular a través de la característica de uso compartido de archivos y medios denominada HomeGroup, que se introdujo en Windows 7 . Esta característica permite el uso compartido entre equipos que no son miembros de un dominio.
Ubicación: %Windir%\System32\pku2u.dll
Este proveedor se incluye de manera predeterminada en las versiones designadas en la lista Se aplica a al principio de este tema, excluyendo Windows Server 2008 y Windows Vista.
Recursos adicionales para el protocolo PKU2U y el SSP de PKU2U
Selección del proveedor de soporte de seguridad
La SSPI de Windows puede usar cualquiera de los protocolos compatibles a través de los proveedores de soporte de seguridad instalados. Sin embargo, como no todos los sistemas operativos son compatibles con los mismos paquetes de SSP que cualquier equipo que ejecute Windows Server, los clientes y los servidores deben negociar para usar un protocolo que ambos admitan. Windows Server prefiere que los equipos cliente y las aplicaciones usen el protocolo Kerberos, un protocolo sólido basado en estándares, siempre que sea posible, pero el sistema operativo sigue permitiendo autenticarse a los equipos cliente y las aplicaciones cliente que no sean compatibles con el protocolo Kerberos.
Antes de que la autenticación pueda tener lugar, los dos equipos que se comunican deben aceptar un protocolo que ambos puedan admitir. Para que cualquier protocolo pueda utilizarse a través de la SSPI, cada equipo debe disponer del SSP adecuado. Por ejemplo, para que un equipo cliente y un servidor usen el protocolo de autenticación Kerberos, ambos deben ser compatibles con Kerberos v5. Windows Server usa la función EnumerateSecurityPackages para identificar qué SSP son compatibles en un equipo y cuáles son las capacidades de esos SSP.
La selección de un protocolo de autenticación puede controlarse de una de las dos maneras siguientes:
Protocolo de autenticación única
Cuando se especifica un único protocolo aceptable en el servidor, el equipo cliente debe ser compatible con el protocolo especificado o la comunicación fallará. Cuando se especifica un único protocolo aceptable, el intercambio de autenticación tiene lugar del siguiente modo:
El equipo cliente solicita acceso a un servicio.
El servidor responde a la solicitud y especifica el protocolo que se usará.
El equipo cliente examina el contenido de la respuesta y comprueba si admite el protocolo especificado. Si el equipo cliente admite el protocolo especificado, la autenticación continúa. Si el equipo cliente no admite el protocolo, se produce un error en la autenticación, independientemente de si el equipo cliente está autorizado para acceder al recurso.
Opción Negotiate
La opción Negotiate se puede usar para permitir que el cliente y el servidor intenten encontrar un protocolo aceptable. Se basa en el Mecanismo de negociación de GSS-API simple y protegido (SPNEGO). Cuando la autenticación comienza con la opción de negociar un protocolo de autenticación, el intercambio de SPNEGO tiene lugar de la siguiente manera:
El equipo cliente solicita acceso a un servicio.
El servidor responde con una lista de protocolos de autenticación que puede admitir y un desafío o respuesta de autenticación, en función del protocolo que es su primera opción. Por ejemplo, el servidor podría enumerar el protocolo Kerberos y NTLM y enviar una respuesta de autenticación Kerberos.
El equipo cliente examina el contenido de la respuesta y comprueba si admite cualquiera de los protocolos especificados.
Si el equipo cliente admite el protocolo preferido, la autenticación continúa.
Si el equipo cliente no admite el protocolo preferido, pero admite uno de los otros protocolos enumerados por el servidor, el equipo cliente permite al servidor saber qué protocolo de autenticación admite y la autenticación continúa.
Si el equipo cliente no admite ninguno de los protocolos enumerados, se produce un error en el intercambio de autenticación.