IIS autentica los clientes del explorador

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

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

Resumen

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

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

Anónimo: no se requiere ningún inicio de sesión y cualquier usuario puede obtener acceso a los datos protegidos con este método. El servidor usa una cuenta integrada (IUSR_[nombre de equipo] 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 admitidos: 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 local.
  • Tipo de cifrado: Ninguno

Básico (texto no cifrado): 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 acceder.

  • Exploradores admitidos: Cualquiera
  • Limitaciones: no es seguro. Las contraseñas se descifran 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)

Desafío o respuesta de Windows NT: el servidor solicita al usuario que inicie sesión. Si el explorador admite Windows NT Challenge/Response, 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 van a enviar. Desafío o respuesta de Windows NT usa un algoritmo para generar un hash basado en las credenciales del usuario y en 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 admitidos: versiones 3.01 y posteriores de Internet Explorer

  • Limitaciones: requiere conexión de 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 o respuesta de Windows NT (que requiere varios recorridos de ida y vuelta), el servidor mantiene abierto el circuito durante la secuencia después de que el cliente haya indicado que usará Desafío o respuesta de Windows NT. Los servidores proxy cern y algunos otros dispositivos de Internet impiden que funcione. Además, windows NT Challenge/Response no admite suplantaciones de salto doble (en el caso de que, una vez pasadas al servidor IIS, no se puedan pasar las mismas credenciales a un servidor back-end para la autenticación).

  • 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 está sin codificar.

Órdenes de precedencia: 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 OR anónimo 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 que se admiten mediante uno de los escenarios siguientes:

  • Si Desafío o respuesta de Windows 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 se produce un error en todos ellos, el explorador no está conectado al servidor.
  • Si se admiten desafío o respuesta de Windows NT y Básico, el explorador determina qué método se usa. Si el explorador admite Windows NT Challenge/Response, usa este método y no vuelve a Básico. Si no se admite desafío o respuesta de Windows NT, el explorador usa Básico.

Nota:

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

Métodos de autenticación que están disponibles para Windows 2000 y versiones posteriores

Anónimo: no se requiere ningún inicio de sesión y se permite a cualquier persona obtener acceso a los datos protegidos con este método. El servidor usa una cuenta integrada (IUSR_[nombre de equipo] 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 admitidos: 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 local".
  • Tipo de cifrado: Ninguno

Básico (texto no cifrado): 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 acceder.

  • Exploradores admitidos: Cualquiera
  • Limitaciones: no es seguro. Las contraseñas se descifran fácilmente.
  • Derechos de usuario necesarios: la cuenta de usuario debe tener derechos de inicio de sesión localmente
  • 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 NONCE para cifrar la contraseña y la envía al servidor. A continuación, el servidor cifra su propia copia de la contraseña del usuario y compara las dos. Si coinciden y el usuario tiene permisos, se concede acceso.

  • Exploradores admitidos: Internet Explorer 5 y versiones posteriores
  • Limitaciones: no tan segura como integrada. 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 no cifrado"
  • Tipo de cifrado: basado en NONCE enviado por el servidor.

Windows Integrado (dividido en dos subcategorías)

Kerberos: el servidor solicita a un usuario que inicie sesión. Si el explorador admite Kerberos, tiene lugar lo siguiente:

  • IIS solicita autenticación.
  • Si el cliente no ha iniciado sesión en un dominio, aparece un cuadro de diálogo en Internet Explorer que solicita credenciales y, a continuación, se pone en contacto con el 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 recurso.
  • El cliente pasa este vale al servidor IIS.

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

  • Exploradores admitidos: 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 local.
  • Tipo de cifrado: vale cifrado.

Desafío o respuesta de Windows NT: el servidor solicita al usuario que inicie sesión. Si el explorador admite Windows NT Challenge/Response, 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 en Internet Explorer que solicita las credenciales que se van a enviar. Desafío o respuesta de Windows NT usa un algoritmo para generar un hash basado en las credenciales del usuario y en 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 admitidos: versiones 3.01 y posteriores de Internet Explorer.
  • Limitaciones: requiere conexión de 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 o respuesta de Windows NT (que requiere varios recorridos de ida y vuelta), el servidor mantiene abierto el circuito durante la secuencia después de que el cliente haya indicado que usará Desafío o respuesta de Windows NT. Los servidores proxy cern y algunos otros dispositivos de Internet impiden que funcione. Además, windows NT Challenge/Response no admite suplantaciones de salto doble (lo que significa que, una vez pasadas al servidor IIS, no se pueden pasar las mismas credenciales a un servidor back-end para la autenticación; por ejemplo, cuando IIS usa Desafío o respuesta de Windows NT, no puede autenticar al usuario en una base de datos de SQL Server en otro equipo mediante la seguridad integrada de SQL).
  • 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 está sin codificar.

Órdenes de precedencia: 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 que se admiten mediante uno de los siguientes escenarios:

  • Si Windows Integrated 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 para obtener las credenciales y, a continuación, las pasa al servidor. Intenta enviar las credenciales hasta tres veces. Si se produce un error en todos ellos, 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 Básico. Si no se admiten Windows NT Challenge/Response y Kerberos, el explorador usa Basic, Digest o Fortezza si los admite. El orden de precedencia aquí es Básico, 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 integrada de Windows, no vuelve a Anonymous durante el resto de la sesión con el servidor. Si intenta conectarse a una página web marcada como Anónima solo después de autenticarse, se le deniega. (Esto puede o no ser válido 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 de cada nueva solicitud durante la sesión.

Referencias

Para obtener más información sobre cómo configurar la autenticación de sitio web de IIS en Windows Server 2003, vea Configuración de la autenticación de sitio web de IIS en Windows Server 2003.