¿Cómo IIS autentica a los clientes de explorador

Este artículo describe los diferentes métodos de autenticación que están disponibles en IIS para Microsoft Windows NT 4.0 y Microsoft Windows 2000. Para obtener una descripción más completa de la información tratada en este artículo, consulte la Windows NT 4.0 y las guías de recursos de Windows 2000.

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

Anónimo -Inicio de sesión no es necesario y cualquier usuario tiene permiso para tener acceso a datos protegidos con este método. El servidor usa un integrada cuenta (IUSR_ nombre del equipo de forma predeterminada) para controlar los permisos de los archivos. El explorador no envía las credenciales o info de usuario con este tipo de solicitud.

• Navegadores soportados: cualquier
• Limitaciones: ninguno
• Derechos de usuario necesarios: La cuenta de usuario anónimo definida en el servidor debe tener permisos de "Inicio de sesión local".
• Tipo de cifrado: ninguno

Básica (texto sin cifrar) -El servidor solicita al usuario iniciar sesión y aparece un cuadro de diálogo en el explorador que permite al usuario que escriba las credenciales necesarias. Estas credenciales deben coincidir con las credenciales de usuario definidas en los archivos que el usuario está intentando tener acceso.

• Navegadores soportados: cualquier
• Limitaciones: No es muy segura. Las contraseñas son fácilmente descifradas.
• Derechos de usuario necesarios: La cuenta de usuario debe tener permisos de "Inicio de sesión local".
• Tipo de cifrado: Codificación Base 64 (true no cifrado)

Desafío/respuesta de Windows NT -El servidor solicita al usuario iniciar sesión. Si el explorador admite desafío/respuesta de Windows NT, envía automáticamente las credenciales del usuario si el usuario inicia sesión. Si el dominio que el usuario es diferente del dominio del servidor, o si el usuario no inicia sesión, aparece un cuadro de diálogo que solicita las credenciales para enviar. Desafío/respuesta de Windows NT utiliza un algoritmo para generar un valor hash basado en las credenciales del usuario y el equipo que está utilizando el usuario. A continuación, se envía este hash para el servidor. El explorador no envía la contraseña del usuario a través de al servidor.

• Navegadores compatibles: Versiones Internet Explorer 3.01 y posteriores
• Limitaciones: Se requiere conexión punto a punto. Normalmente, se cierra un circuito tras un error "401 no autorizado" del mensaje; Sin embargo, al negociar una secuencia de autenticación de desafío/respuesta de Windows NT (que requiere varios viajes de ida y), el servidor mantiene el circuito abierto para la duración de la secuencia después de que el cliente ha indicado que va a utilizar desafío/respuesta de Windows NT. Servidores proxy CERN y algunos otros dispositivos de Internet que no funcionen. Además, desafío/respuesta de Windows NT no es compatible con imitaciones de salto doble (en que una vez que se pasa al servidor IIS, las mismas credenciales no se puede pasar 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 de Hash NTLM también es uuencode.

Orden de precedencia:Cuando el explorador realiza una solicitud, siempre considera que la primera solicitud para ser anónimo. Por lo tanto, no envía ninguna credencial. Si el servidor no acepta anónimo o si la cuenta de usuario anónimo configurado en el servidor no tiene permisos para el archivo solicitado, el servidor IIS responde con un mensaje de error "Acceso denegado" y envía una lista de los tipos de autenticación que son compatibles con uno de los siguientes escenarios:

• Si es el único desafío/respuesta de Windows NT admite el método (o si se produce un error en anónimo), a continuación, 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 es la única Basic admite el método (o si se produce un error en anónimo), a continuación, un cuadro de diálogo aparece en el explorador para obtener las credenciales y, a continuación, pasa estas credenciales al servidor. Intente enviar estas credenciales hasta tres veces. Si no todos, el explorador no está conectado al servidor.
• Si se admiten Basic y desafío/respuesta de Windows NT, el explorador determina el método que utiliza. Si el explorador admite desafío/respuesta de Windows NT, se utiliza este método y no retroceso a texto básico. Si no se admite el desafío/respuesta de Windows NT, el explorador utiliza Basic.

Notas:

• Cuando el explorador establece una conexión con un sitio Web mediante la autenticación básica o NTLM, no retroceso a anónimo durante el resto de la sesión con el servidor. Si intenta conectarse a una página Web que está marcada para anónimo sólo después de autenticar, denegará. (Esto puede o no puede mantener cierto para Netscape).
• Cuando Internet Explorer ha establecido una conexión con el servidor mediante la autenticación básica o NTLM, pasa las credenciales para cada nueva solicitud para la duración de la sesión.

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

Anónimo -Inicio de sesión no es necesario y cualquier usuario tiene permiso para tener acceso a datos protegidos con este método. El servidor usa un integrada cuenta (IUSR_ nombre del equipo de forma predeterminada) para controlar los permisos de los archivos. El explorador no envía las credenciales o info de usuario con este tipo de solicitud.

• Navegadores soportados: cualquier
• Limitaciones: ninguno
• Derechos de usuario necesarios: La cuenta de usuario anónimo definida en el servidor debe tener permisos de "Inicio de sesión local".
• Tipo de cifrado: ninguno

Básica (texto sin cifrar) -El servidor solicita al usuario iniciar sesión y aparece un cuadro de diálogo en el explorador que permite al usuario que escriba las credenciales necesarias. Estas credenciales deben coincidir con las credenciales de usuario definidas en los archivos que el usuario está intentando tener acceso.

• Navegadores soportados: cualquier
• Limitaciones: No es muy segura. Las contraseñas son fácilmente descifradas.
• Derechos de usuario necesarios: La cuenta de usuario debe tener derechos "Inicio de sesión local"
• Tipo de cifrado: Codificación Base 64 (true no cifrado)

Resumen -El servidor pide al usuario iniciar sesión y también envía un NONCE utilizado para cifrar la contraseña. El explorador utiliza el valor NONCE para cifrar la contraseña y envía al servidor. El servidor, a continuación, cifra su propia copia de la contraseña del usuario y compara los dos. Si coinciden y el usuario tiene permisos de acceso.

• Navegadores compatibles: Internet Explorer 5 y versiones posteriores
• Limitaciones: No como secure como integrado. Requiere que el servidor tenga acceso a un servidor de Active Directory que se ha configurado para la autenticación implícita.
• Derechos de usuario necesarios: Requiere que las contraseñas tienen "Guardar contraseña como texto sencillo cifrado"
• Tipo de cifrado: Según NONCE enviado por el servidor.

Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:Fortezza -Para utilizar seguridad Fortezza en IIS 5.0, debe tener un archivo adecuado del proveedor de servicios criptográficos de API (CSP) de un proveedor de Fortezza, como http://www.spyrus.com.

Integrada de Windows (que se divide en dos categorías de sub)
Kerberos -El servidor solicita un usuario para iniciar sesión. Si el explorador admite Kerberos, lo siguiente:

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

Kerberos utiliza vales generados en un servidor de concesión de vale (KDC) para autenticar. Envía este vale para el servidor IIS. El explorador no envía la contraseña del usuario a través de al servidor.

• Navegadores compatibles: Versiones Internet Explorer 5.0 y superior
• Limitaciones: el servidor debe tener acceso a un servidor de Active Directory. El servidor y el cliente deben tener una conexión de confianza en un KDC.
• Derechos de usuario necesarios: La cuenta de usuario anónimo definida en el servidor debe tener permisos de "Inicio de sesión local".
• Tipo de cifrado: cifrar el vale.

Desafío/respuesta de Windows NT -El servidor solicita al usuario iniciar sesión. Si el explorador admite desafío/respuesta de Windows NT, envía automáticamente las credenciales del usuario si el usuario inicia sesión. Si el dominio que el usuario es diferente del dominio del servidor, o si el usuario no se ha iniciado sesión, aparece un cuadro de diálogo de Internet Explorer solicita las credenciales para enviar. Desafío/respuesta de Windows NT utiliza un algoritmo para generar un valor hash basado en las credenciales del usuario y el equipo que está utilizando el usuario. A continuación, se envía este hash para el servidor. El explorador no envía la contraseña del usuario a través de al servidor.

• Navegadores compatibles: Internet Explorer versión 3.01 y posteriores.
• Limitaciones: Se requiere conexión punto a punto. Normalmente, se cierra un circuito tras un error "401 no autorizado" del mensaje; Sin embargo, al negociar una secuencia de autenticación desafío/respuesta de Windows NT (que requiere varios viajes de ida y), el servidor mantiene el circuito abierto para la duración de la secuencia después de que el cliente ha indicado que va a utilizar desafío/respuesta de Windows NT. Servidores proxy CERN y algunos otros dispositivos de Internet que no funcionen. Además, desafío/respuesta de Windows NT no admite imitaciones de salto doble (lo que significa que una vez que se pasa al servidor IIS, las mismas credenciales no se puede pasar a un servidor back-end para la autenticación, por ejemplo, cuando IIS usa desafío/respuesta de Windows NT, no puede, a continuación, autenticar al usuario contra una base de datos SQL Server en otro equipo mediante la seguridad integrada de SQL).
• Derechos de usuario necesarios: El servidor de acceso a la cuenta de usuario debe tener permisos de "Acceso A este equipo desde la red".
• Tipo de cifrado: Algoritmo de Hash NTLM también es uuencode.

Orden de precedencia:Cuando el explorador realiza una solicitud, siempre considera que la primera solicitud para ser anónimo. Por lo tanto, no envía ninguna credencial. Si el servidor no acepta anónimo o si la cuenta de usuario anónimo configurado en el servidor no tiene permisos para el archivo solicitado, el servidor IIS responde con un mensaje de error "Acceso denegado" y envía una lista de los tipos de autenticación que son compatibles con uno de los siguientes escenarios:

• Si es la única integrada de Windows admite el método (o si se produce un error en anónimo), a continuación, el explorador debe admitir este método para comunicarse con el servidor. Si no lo consigue, el servidor intente cualquiera de los otros métodos.
• Si Basic es el único admitido método (o si se produce un error en anónimo), a continuación, un cuadro de diálogo que aparece en la para obtener las credenciales y, a continuación, pasa al servidor. Intenta enviar las credenciales hasta tres veces. Si no todos, el explorador no se conecta al servidor.
• Si se admiten Basic y Windows integrada, el explorador determina el método que utiliza. Si el explorador admite Kerberos o desafío/respuesta de Windows NT, se utiliza este método. No RETROCESO para Basic. Si no se admiten desafío/respuesta de Windows NT y Kerberos, el explorador utiliza básica, implícita o Fortezza si es compatible con estos. El orden de prioridad aquí es Basic, Digest y, a continuación, Fortezza.

Notas:

• Cuando el explorador establece una conexión con un sitio Web mediante la autenticación básica o integrada de Windows, no retroceso a anónimo durante el resto de la sesión con el servidor. Si intenta conectarse a una página Web que está marcada para anónimo sólo después de autenticar, se le denegará. (Esto puede o no puede mantener cierto para Netscape).
• Cuando Internet Explorer ha establecido una conexión con el servidor mediante el uso de un método de autenticación distinto del anónimo, pasa automáticamente las credenciales para cada nueva solicitud durante la duración de la sesión.

Para obtener más información acerca de cómo configurar la autenticación de sitio Web de IIS en Windows Server 2003, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:Para obtener más información acerca de los problemas que puede producirse si se recicla un grupo de aplicaciones del sitio Web está alojado en IIS 6.0 durante el proceso de autenticación, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base: