Autenticación y seguridad de RPC a través de HTTP
Última modificación del tema: 2005-05-18
Las ventajas de autenticación y seguridad al utilizar RPC a través de HTTP son las siguientes:
- No es necesario que se permitan puertos de Internet que no sean los ya permitidos para Microsoft® Office Outlook® Web Access, Microsoft Exchange ActiveSync® o Outlook Mobile Access.
- Debe utilizarse el Nivel de sockets seguros (SSL).
- Outlook debe enviar solicitudes autenticadas.
- Tanto el servidor proxy RPC como el servidor de Exchange autentican solicitudes de Outlook que utilizan RPC a través de HTTP.
- No se expone el asignador de extremos.
- Los equipos clientes sólo pueden acceder a servicios de Exchange especificados en servidores de Exchange específicos.
Autenticación HTTP
Los Servicios de Internet Information Server (IIS) del servidor proxy RPC controlan la autenticación de una sesión HTTP. Cuando se configura el servidor proxy RPC, ha de definirse el directorio virtual de RPC para que utilice una autenticación básica, una autenticación NTLM, o ambas. Outlook puede enviar una autenticación básica o una autenticación NTLM para la sesión HTTP, dependiendo de cómo esté configurado el perfil de Outlook. El API de servidor de Internet (ISAPI) del servidor proxy RPC no acepta conexiones autenticadas de forma anónima.
Nota
Cuando utilice el Administrador del sistema de Exchange en el Server Pack 1 (SP1) de Exchange Server 2003 para configurar RPC a través de HTTP, el Administrador del sistema de Exchange le configura automáticamente los valores de autenticación en el directorio virtual de RPC.
Nota
La autenticación NTLM también se conoce como Autenticación de Windows integrada.
El mecanismo de autenticación que configure en el perfil de Outlook se utiliza sólo para la sesión HTTP del servidor proxy RPC. El mecanismo de autenticación entre Outlook y el servidor de Exchange, cuando Outlook accede al servidor de Exchange utilizando RPC a través de HTTP, es siempre NTLM. Se recomienda encarecidamente utilizar el cifrado SSL para la sesión HTTP del servidor proxy RPC, especialmente si utiliza una autenticación básica para la sesión HTTP. Si utiliza un cifrado SSL, evitará que su nombre de usuario y su contraseña se envíen mediante texto sin cifrar. Outlook no le permite utilizar la autenticación básica al conectarse con el servidor proxy RPC sin utilizar el cifrado SSL.
Si dispone de un servidor de seguridad que examina el tráfico HTTP y lo modifica de alguna forma, puede que deba utilizar la autenticación básica, en lugar de la autenticación NTLM. La autenticación NTLM no funciona si el servidor proxy RPC no confía en la información de la autenticación. Por ejemplo, puede que disponga de un servidor de seguridad que termine la sesión de Internet y establezca una nueva sesión para el servidor proxy RPC, en lugar de pasar la sesión HTTPS (SSL) al servidor de Exchange sin modificación. Este proceso se conoce como inversión de servidores proxy o Publicación Web. Ciertos servidores de seguridad, como Microsoft Internet Security and Acceleration (ISA) Server 2004, pueden invertir satisfactoriamente servidores proxy o realizar una publicación Web de la sesión y seguir permitiendo el uso de una autenticación NTLM.
Nota
ISA Server 2000 no puede invertir servidores proxy o realizar publicaciones Web de la sesión y seguir permitiendo que se realice con éxito la autenticación NTLM.
La autenticación básica no se ve afectada por la inversión de servidores proxy o la publicación Web y funciona independientemente de los servidores de seguridad. Sin embargo, si utiliza la autenticación básica, deberá escribir un dominio, un nombre de usuario y una contraseña cada vez que inicie una sesión de Outlook.
Autenticación básica y autenticación NTLM
La tabla siguiente muestra algunas de las diferencias entre una autenticación básica y una autenticación NTLM.
| Autenticación básica | Autenticación NTLM |
|---|---|
El equipo cliente envía un nombre de usuario y una contraseña mediante texto sin cifrar. Deberá utilizarse siempre SSL al utilizar una autenticación básica. Outlook no permite la selección de una autenticación básica sin seleccionar también SSL. El servidor proxy RPC también requiere SSL. |
El equipo cliente envía una solicitud de inicio de sesión al servidor. El servidor responde con un "testigo" generado aleatoriamente o desafía al equipo cliente. El equipo cliente crea un valor de hash para la contraseña protegida criptográficamente del usuario que tenga abierta la sesión en ese momento con el desafío y envía la "respuesta" resultante al servidor. El servidor recibe la respuesta para la que se ha creado un valor de hash del desafío y la compara con la que sabe que es la respuesta correcta. (El servidor realiza una copia del testigo original, que se ha generado, y le crea un valor de hash frente al que sabe que es el valor de hash de su propia base de datos de la cuenta del usuario.) Si la respuesta recibida coincide con la respuesta esperada, el usuario se autentica con éxito ante el host. |
Una autenticación básica funciona con servidores de seguridad proxy inversos. |
Una autenticación NTLM puede que no funcione con algunos servidores de seguridad proxy inversos. Si el servidor de seguridad examina el tráfico y lo modifica, la autenticación NTLM puede invalidarse. |
Una autenticación básica requiere que el usuario introduzca un dominio, un nombre de usuario y una contraseña. |
NTLM puede utilizar la información de inicio de sesión actual del sistema operativo Microsoft Windows®. |
Requisitos para que RPC a través de HTTP utilice la información de inicio de sesión actual del sistema operativo Windows
Para que RPC a través de HTTP utilice la información de inicio de sesión actual del sistema operativo Windows, deben cumplirse los requisitos siguientes:
- El usuario inicia una sesión en el equipo cliente con las credenciales de dominio correctas.
- El usuario selecciona la autenticación NTLM en el perfil de Outlook.
- El servidor de seguridad permite una autenticación NTLM. Esto puede ocurrir si el servidor de seguridad simplemente pasa la sesión SSL al servidor de Exchange sin modificación (filtrado del puerto) o si el servidor de seguridad es un servidor de seguridad avanzado, tal como ISA Server 2004. ISA Server 2004 puede invertir servidores proxy y realizar una publicación Web del servidor de Exchange y seguir permitiendo una autenticación NTLM satisfactoria.
- El usuario envía automáticamente información sobre la autenticación NTLM con la conexión. Esto ocurre cuando es cierta una de las condiciones siguientes:
- Configura Outlook para realizar una autenticación mutua a través de SSL. Esta método es el recomendado.
- LmCompatibilityLevel del equipo cliente tiene el valor 2 o 3.
Para obtener más información acerca de LmCompatibilityLevel, consulte en Microsoft Knowledge Base el artículo 820281, "Debe proporcionar credenciales de una cuenta de Windows al conectarse a Exchange Server 2003 con Outlook mediante HTTP" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=820281).
Autenticación RPC
El RPC solicita al servidor de Exchange que autentique siempre mediante una autenticación NTLM.
SSL
El equipo cliente debe confiar en el certificado que se utilice para SSL. Para que el equipo cliente confíe en el certificado que se utilice para SSL, deben ser ciertas las condiciones siguientes.
- El nombre del certificado coincide con el sitio Web al que se está accediendo.
- El certificado no ha caducado.
- El equipo cliente confía en la autoridad emisora de certificados que haya emitido el certificado.
Si ya ha configurado satisfactoriamente Outlook Web Access, Exchange ActiveSync u otro servicio Web que utilice el servidor de aplicaciones para el usuario de Exchange, el certificado cumple estos requisitos.
Puede ubicar el directorio virtual de RPC con Microsoft Internet Explorer para comprobar que el certificado es correcto. Si el certificado no es válido, Internet Explorer emite una advertencia.
Descarga de SSL.
Una descarga de SSL se produce cuando el servidor de seguridad delante del servidor proxy RPC cierra la sesión SSL y establece una nueva sesión no SSL para el servidor de aplicaciones para el usuario. De forma específica, no establece una nueva sesión SSL.
Si se utiliza una descarga de SSL, hay que ajustar la clave del Registro para que informe al servidor proxy RPC de que puede aceptar una sesión que no sea SSL. Para obtener información más detallada sobre cómo ajustar esta clave del Registro, consulte Cómo configurar el servidor proxy RPC para que permita la descarga de SSL en un servidor independiente.