IIS autentica clientes de explorador

Artículo
01/25/2022
Tiempo de lectura: 10 minutos

En este artículo se presenta cómo IIS autentica los clientes del explorador.

Versión del producto original: Internet Explorer
Número KB original: 264921

Resumen

En este artículo se describen los diferentes métodos de autenticación disponibles en IIS para Windows NT 4.0, Windows 2000 y versiones Windows posteriores. Para obtener una descripción más completa de la información que se describe en este artículo, vea las guías de recursos Windows NT 4.0 y Windows 2000.

Métodos de autenticación disponibles para Windows NT 4.0

Anónimo: no se requiere ningún inicio de sesión y nadie puede obtener acceso a los datos protegidos con este método. El servidor usa una cuenta integrada (IUSR_ [nombre de la máquina] de forma predeterminada) para controlar los permisos en los archivos. El explorador no envía credenciales ni información de usuario con este tipo de solicitud.

Exploradores compatibles: Cualquiera
Limitaciones: Ninguna
Derechos de usuario necesarios: la cuenta de usuario anónima definida en el servidor debe tener permisos de inicio de sesión localmente.
Tipo de cifrado: Ninguno

Básico (texto sin formato): el servidor solicita al usuario que inicie sesión y aparece un cuadro de diálogo en el explorador que permite al usuario escribir las credenciales necesarias. Estas credenciales deben coincidir con las credenciales de usuario definidas en los archivos a los que el usuario está intentando obtener acceso.

Exploradores compatibles: Cualquiera
Limitaciones: No es seguro. Las contraseñas se descifrarán fácilmente.
Derechos de usuario necesarios: la cuenta de usuario debe tener permisos de inicio de sesión localmente.
Tipo de cifrado: Codificación base 64 (no cifrado verdadero)

Windows o respuesta de NT: el servidor solicita al usuario que inicie sesión. Si el explorador admite Windows desafío o respuesta de NT, envía automáticamente las credenciales del usuario si el usuario ha iniciado sesión. Si el dominio en el que está el usuario es diferente del dominio del servidor o si el usuario no ha iniciado sesión, aparece un cuadro de diálogo para solicitar las credenciales que se enviarán. Windows NT Challenge/Response usa un algoritmo para generar un hash basado en las credenciales del usuario y el equipo que usa el usuario. A continuación, envía este hash al servidor. El explorador no envía la contraseña del usuario al servidor.

Exploradores compatibles: versiones 3.01 y posteriores de Internet Explorer
Limitaciones: requiere conexión punto a punto. Normalmente, un circuito se cierra después de un mensaje de error "401 no autorizado"; sin embargo, al negociar una secuencia de autenticación de desafío y respuesta de Windows NT (que requiere varios recorridos de ida y vuelta), el servidor mantiene el circuito abierto durante la secuencia después de que el cliente haya indicado que usará Windows NT Challenge/Response. Los servidores proxy CERN y otros dispositivos de Internet impiden que esto funcione. Además, Windows desafío/respuesta de NT no admite suplantaciones de salto doble (en el caso de que una vez pasado al servidor IIS, no se pueden pasar las mismas credenciales a un servidor back-end para la autenticación).
Derechos de usuario necesarios: la cuenta de usuario que tiene acceso al servidor debe tener permisos de "Acceso a este equipo desde la red".
Tipo de cifrado: algoritmo hash NTLM que también no está codificado.

Órdenes de prioridad: Cuando el explorador realiza una solicitud, siempre considera que la primera solicitud es Anónima. Por lo tanto, no envía ninguna credencial. Si el servidor no acepta Anonymous O si la cuenta de usuario anónima establecida en el servidor no tiene permisos para el archivo que se solicita, el servidor IIS responde con un mensaje de error Acceso denegado y envía una lista de los tipos de autenticación compatibles con uno de los siguientes escenarios:

Si Windows desafío/respuesta de NT es el único método admitido (o si se produce un error en Anonymous), el explorador debe admitir este método para comunicarse con el servidor. De lo contrario, no puede negociar con el servidor y el usuario recibe un mensaje de error Acceso denegado.
Si Basic es el único método admitido (o si se produce un error en Anonymous), aparece un cuadro de diálogo en el explorador para obtener las credenciales y, a continuación, pasa estas credenciales al servidor. Intenta enviar estas credenciales hasta tres veces. Si todos estos errores, el explorador no está conectado al servidor.
Si se admiten Windows desafío/respuesta de NT básico y de prueba, el explorador determina qué método se usa. Si el explorador admite Windows de NT Challenge/Response, usa este método y no vuelve a Basic. Si Windows no se admite el desafío o la respuesta de NT, el explorador usa Basic.

Nota

Cuando el explorador establece una conexión con un sitio web mediante o autenticación, no vuelve a Anonymous durante el resto de esa sesión Basic NTLM con el servidor. Si intenta conectarse a una página web marcada como Anónima solo después de la autenticación, se le denegará. (Esto puede o no ser true para Netscape).
Cuando Internet Explorer ha establecido una conexión con el servidor mediante o autenticación, pasa las credenciales de cada nueva solicitud durante Basic NTLM la sesión.

Métodos de autenticación disponibles para Windows 2000 y posteriores

Anónimo: no se requiere ningún inicio de sesión y se permite a cualquiera obtener acceso a los datos protegidos con este método. El servidor usa una cuenta integrada (IUSR_ [nombre de la máquina] de forma predeterminada) para controlar los permisos en los archivos. El explorador no envía credenciales ni información de usuario con este tipo de solicitud.

Exploradores compatibles: Cualquiera
Limitaciones: Ninguna
Derechos de usuario necesarios: la cuenta de usuario anónima definida en el servidor debe tener permisos de "inicio de sesión localmente".
Tipo de cifrado: Ninguno

Exploradores compatibles: Cualquiera
Limitaciones: No es seguro. Las contraseñas se descifrarán fácilmente.
Derechos de usuario necesarios: la cuenta de usuario debe tener los derechos de inicio de sesión local
Tipo de cifrado: Codificación base 64 (no cifrado verdadero)

Resumen: el servidor solicita al usuario que inicie sesión y también envía un NONCE usado para cifrar la contraseña. El explorador usa el NONCE para cifrar la contraseña y lo envía al servidor. A continuación, el servidor cifra su propia copia de la contraseña del usuario y compara los dos. Si coinciden y el usuario tiene permisos, se concede acceso.

Exploradores compatibles: Internet Explorer 5 y versiones posteriores
Limitaciones: no tan seguras como Integradas. Requiere que el servidor tenga acceso a un servidor de Active Directory configurado para la autenticación implícita.
Derechos de usuario necesarios: requiere que las contraseñas tengan "Guardar contraseña como texto sin cifrar"
Tipo de cifrado: basado en NONCE enviado por el servidor.

Windows integrado (dividido en dos subcategorías)

Kerberos: el servidor solicita al usuario que inicie sesión. Si el explorador admite Kerberos, se lleva a cabo lo siguiente:

IIS solicita autenticación.
Si el cliente no ha iniciado sesión en un dominio, aparecerá un cuadro de diálogo en Internet Explorer que solicita credenciales y, a continuación, se pone en contacto con KDC para solicitar y recibir un vale de concesión de vales. A continuación, envía el vale de concesión de vales junto con información sobre el servidor IIS al KDC.
Si el cliente de IE ya ha iniciado sesión correctamente en el dominio y ha recibido un vale de concesión de vales, envía este vale junto con información sobre el servidor IIS al KDC
El KDC emite al cliente un vale de recursos.
El cliente pasa este vale al servidor IIS.

Kerberos usa vales generados en un servidor de concesión de vales (KDC) para autenticar. Envía este vale al servidor IIS. El explorador NO envía la contraseña del usuario al servidor.

Exploradores compatibles: versiones 5.0 y posteriores de Internet Explorer
Limitaciones: el servidor debe tener acceso a un servidor de Active Directory. Tanto el servidor como el cliente deben tener una conexión de confianza a un KDC.
Derechos de usuario necesarios: la cuenta de usuario anónima definida en el servidor debe tener permisos de inicio de sesión localmente.
Tipo de cifrado: vale cifrado.

Windows o respuesta de NT: el servidor solicita al usuario que inicie sesión. Si el explorador admite Windows desafío o respuesta de NT, envía automáticamente las credenciales del usuario si el usuario ha iniciado sesión. Si el dominio en el que está el usuario es diferente del dominio del servidor o si el usuario no ha iniciado sesión, aparecerá un cuadro de diálogo en Internet Explorer solicitando las credenciales que se enviarán. Windows NT Challenge/Response usa un algoritmo para generar un hash basado en las credenciales del usuario y el equipo que usa el usuario. A continuación, envía este hash al servidor. El explorador no envía la contraseña del usuario al servidor.

Exploradores compatibles: Versiones 3.01 y posteriores de Internet Explorer.
Limitaciones: requiere conexión punto a punto. Normalmente, un circuito se cierra después de un mensaje de error "401 no autorizado"; sin embargo, al negociar una secuencia de autenticación de desafío y respuesta de Windows NT (que requiere varios recorridos de ida y vuelta), el servidor mantiene el circuito abierto durante la secuencia después de que el cliente haya indicado que usará Windows NT Challenge/Response. Los servidores proxy CERN y otros dispositivos de Internet impiden que esto funcione. Además, Windows NT Challenge/Response no admite suplantaciones de salto doble (lo que significa que, una vez pasado al servidor IIS, no se pueden pasar las mismas credenciales a un servidor back-end para la autenticación, por ejemplo, cuando IIS usa Windows NT Challenge/Response, no puede autenticar al usuario en una base de datos de SQL Server en otro equipo mediante SQL Seguridad integrada).
Derechos de usuario necesarios: la cuenta de usuario que accede al servidor debe tener permisos de "Acceso a este equipo desde la red".
Tipo de cifrado: algoritmo hash NTLM que también no está codificado.

Órdenes de prioridad: Cuando el explorador realiza una solicitud, siempre considera que la primera solicitud es Anónima. Por lo tanto, no envía ninguna credencial. Si el servidor no acepta Anónimo o si la cuenta de usuario anónima establecida en el servidor no tiene permisos para el archivo que se solicita, el servidor IIS responde con un mensaje de error Acceso denegado y envía una lista de los tipos de autenticación compatibles con uno de los siguientes escenarios:

Si Windows integrado es el único método admitido (o si se produce un error en Anonymous), el explorador debe admitir este método para comunicarse con el servidor. Si se produce un error, el servidor no prueba ninguno de los otros métodos.
Si Basic es el único método admitido (o si se produce un error en Anonymous), aparece un cuadro de diálogo en el para obtener las credenciales y, a continuación, las pasa al servidor. Intenta enviar las credenciales hasta tres veces. Si todos estos errores, el explorador no se conecta al servidor.
Si se admiten Basic y Windows Integrated, el explorador determina qué método se usa. Si el explorador admite Kerberos o Windows nt challenge/response, usa este método. No vuelve a Basic. Si Windows desafío/respuesta NT y Kerberos no son compatibles, el explorador usa Basic, Digest o Fortezza si los admite. El orden de prioridad aquí es Basic, Digest y, a continuación, Fortezza.

Nota

Cuando el explorador establece una conexión con un sitio web mediante la autenticación básica o Windows integrada, no vuelve a Anonymous durante el resto de esa sesión con el servidor. Si intenta conectarse a una página web marcada como Anónima solo después de la autenticación, se le denegará. (Esto puede o no ser true para Netscape).
Cuando Internet Explorer ha establecido una conexión con el servidor mediante un método de autenticación distinto de Anónimo, pasa automáticamente las credenciales para cada nueva solicitud durante la duración de la sesión.

Referencias

Para obtener más información acerca de cómo configurar la autenticación de sitios web de IIS en Windows Server 2003, vea How to configure IIS Web site authentication in Windows Server 2003.