Tipos de autenticación de extremos
El proceso de autenticación de extremos implica conceder permisos a los usuarios para que se conecten a extremos creados en el servidor y especificar cómo se lleva a cabo la autenticación.
La forma en que se lleva a cabo la autenticación se especifica usando la cláusula AUTHENTICATION de la instrucción CREATE ENDPOINT o la instrucción ALTER ENDPOINT. Esta cláusula proporciona las siguientes opciones para especificar el tipo de autenticación:
BASIC
DIGEST
NTLM
KERBEROS
INTEGRATED
[!NOTA]
No se admite la autenticación anónima en un extremo. Para que un usuario obtenga acceso a un extremo, debe ser un usuario de Windows autenticado válido, ya sea un usuario de Windows de confianza o una cuenta de miembro del equipo local.
Autenticación básica
La autenticación básica es uno de los dos mecanismos de autenticación necesarios en la especificación HTTP 1.1. La autenticación básica consta de un encabezado de autenticación que contiene el nombre de usuario y la contraseña separados por dos puntos y codificados en Base64. Para obtener más información, visite http://www.ietf.org/rfc/rfc2617.txt.
Si especifica BASIC, tenga en cuenta lo siguiente:
El valor PORTS no se puede establecer en CLEAR.
Las credenciales enviadas como autenticación HTTP básica deben estar asignadas a un inicio de sesión Windows válido.
La autenticación básica sólo se debe utilizar como último recurso. Si se especifica la autenticación básica, que utiliza la codificación Base64 fácilmente descodificable, la instancia de SQL Server requiere que se utilice un puerto SSL (Capa de sockets seguros) para la conexión HTTP. La autenticación básica se puede utilizar en situaciones en las que el usuario que dispone de permiso para el extremo es un usuario local del propio equipo servidor.
Autenticación implícita
Es el segundo mecanismo de autenticación necesario en HTTP 1.1. Esta autenticación consta del nombre de usuario y la contraseña. Se aplica el algoritmo hash MD5 (algoritmo hash de un sentido) y se envía al servidor. El servidor tiene acceso a la contraseña sin formato o al hash MD5 almacenado que se ha creado durante el establecimiento de la contraseña. De este modo, puede comparar el valor calculado almacenado con el que proporciona el cliente. Asimismo, el cliente puede probar que conoce la contraseña sin enviarla realmente al servidor. Para obtener más información, visite http://www.ietf.org/rfc/rfc2617.txt.
Las credenciales que se envían como parte de una autenticación implícita en HTTP deben estar asignadas a una cuenta de dominio Windows válida. Las cuentas de usuario local no se admiten en la autenticación implícita basada en Windows.
[!NOTA]
Por motivos de seguridad, la autenticación implícita basada en Windows sólo es compatible con el cifrado MD5-sess en controladores de dominio que se ejecutan en Windows Server 2003.
Autenticación NTLM
NTLM es el mecanismo de autenticación admitido por Windows 95, Windows 98 y Windows NT 4.0 (cliente y servidor). Se trata de un protocolo de respuesta a desafíos que ofrece una autenticación más segura que la básica o la implícita. NTLM se implementa en Windows 2000 y versiones posteriores mediante una interfaz del proveedor de compatibilidad para seguridad (SSPI). Para obtener más información, vea Microsoft NTLM.
Autenticación Kerberos
Es un mecanismo de autenticación estándar de Internet. Es compatible con Windows 2000 y versiones posteriores mediante una interfaz SSPI.
Cuando se utiliza la autenticación Kerberos, la instancia de SQL Server debe asociar un nombre principal de servicio (SPN) con la cuenta en la que se ejecuta. Para obtener más información, vea Registrar nombres principales de servicio de Kerberos mediante Http.sys.
Para obtener más información acerca de la autenticación Kerberos, vea Microsoft Kerberos.
Autenticación integrada
Los extremos configurados para admitir la autenticación integrada pueden responder con los siguientes tipos de autenticación como parte del desafío de autenticación: Kerberos o NTLM.
Con esta configuración, el servidor intentará autenticar el cliente con el tipo que éste utilice al solicitar la autenticación.
[!NOTA]
Si se produce un error en el proceso con un tipo de autenticación integrada, el servidor finalizará la conexión con el cliente. El servidor no intentará establecer la conexión con el otro tipo de autenticación.