Crear un servidor virtual de Communicator Web Access
Última modificación del tema: 2009-03-06
Una vez instalado y activado Communicator Web Access (versión 2007 R2), debe crear al menos un servidor virtual Communicator Web Access. Los usuarios no pueden utilizar la mensajería instantánea, la audioconferencia ni ninguna otra característica de Communicator Web Access a menos que tengan un servidor virtual en el que puedan iniciar sesión.
Nota
En líneas generales, un servidor virtual es simplemente un sitio web. Si los usuarios inician sesión en Communicator Web Access utilizando la dirección URL https://im.contoso.com, https://im.contoso.com no solo es un sitio web, sino también un servidor virtual de Communicator Web Access. La ventaja de los servidores virtuales es que permiten a un equipo con Internet Information Services (IIS) hospedar varios sitios web. Por ejemplo, un único equipo podría hospedar https://im.fabrikam.com y https://im.contoso.com.
Si tiene previsto administrar recursos de usuarios internos (es decir, usuarios que se encuentran detrás del firewall de la organización) y de usuarios externos (usuarios que están fuera del firewall de la organización), tendrá que crear dos servidores virtuales: uno para los usuarios internos y otro para los usuarios externos. Puede utilizar el Asistente para la implementación para crear el primer servidor virtual y, a continuación, usar el complemento de Communicator Web Access para crear el segundo servidor virtual.
Nota
Si va a administrar solicitudes de usuarios externos, se recomienda utilizar un servidor proxy inverso para publicar ese servidor virtual en Internet. Para obtener información detallada sobre cómo utilizar un servidor proxy inverso para publicar un servidor virtual de Communicator Web Access, vea Utilizar un proxy inverso para habilitar el acceso de usuarios remotos. Además, es recomendable que hospede el servidor virtual de los usuarios internos y el servidor virtual de los usuarios externos en equipos distintos, por motivos de seguridad.
Para crear el primer servidor virtual en un equipo, vea al procedimiento Para crear el primer servidor virtual en Crear un servidor virtual de Communicator Web Access mediante el Asistente para la implementación. Si desea crear un segundo servidor virtual en el mismo equipo, esta tarea debe realizarse con el complemento de Communicator Web Access. Para crear un segundo servidor virtual en un equipo, siga este procedimiento:
- Abra el complemento de Communicator Web Access, haga clic con el botón secundario en el nombre del servidor donde se va a crear el servidor virtual y, a continuación, haga clic en Crear servidor virtual.
- Cuando se abra el Asistente para crear servidor virtual, siga el mismo procedimiento que usó para crear el primer servidor virtual en el equipo.
Antes de crear un servidor virtual, necesita elegir un método de autenticación, un tipo de conectividad y un servidor del próximo salto.
Métodos de autenticación
Al crear un servidor virtual tendrá que especificar valores para varias propiedades clave, empezando por el modo de autenticación. Communicator Web Access proporciona varias opciones de autenticación.
Autenticación de contraseña (NTLM/Kerberos) integrada
Este es el tipo de autenticación más seguro y la opción que requiere menos trabajo. Con la autenticación de contraseña integrada, los usuarios no tienen que escribir un nombre de usuario y contraseña. Se autentican utilizando las mismas credenciales que usaron para iniciar sesión en su equipo.
Sin embargo, este modo de autenticación presenta dos inconvenientes. En primer lugar, este tipo de autenticación solo se puede utilizar con servidores virtuales internos; los usuarios externos siempre tienen que proporcionar credenciales, lo que significa que los sitios que administran solicitudes de inicio de sesión externas deben usar la autenticación personalizada o basada en formularios.
En segundo lugar, la autenticación de contraseña integrada solo la pueden utilizar aquellas personas que: inicien sesión desde un equipo que ejecuta Microsoft Windows y utilice un explorador web compatible con la autenticación NTLM o Kerberos. Si todos los usuarios son usuarios internos que ejecutan Internet Explorer y Microsoft Windows, puede utilizar la autenticación de contraseña integrada como único modo de autenticación. En caso contrario, tendrá que utilizar la autenticación de contraseña integrada y la autenticación basada en formularios, o bien un método de autenticación personalizado.
Nota
Si utiliza la autenticación de contraseña integrada y la autenticación basada en formularios, Communicator Web Access intentará primero conectar a un usuario mediante la autenticación de contraseña integrada. Si no es posible, se le dará la opción al usuario de iniciar sesión mediante la autenticación basada en formularios.
Autenticación basada en formularios
Con la autenticación basada en formularios, se muestra un cuadro de diálogo de inicio de sesión al usuario que intenta tener acceso a un servidor virtual de Communicator Web Access. El usuario debe proporcionar sus credenciales (es decir, el dominio, nombre de usuario y contraseña) para que se le pueda autenticar y pueda tener acceso al sitio. La autenticación basada en formularios proporciona compatibilidad a:
- Los usuarios de Macintosh y Linux
- Los usuarios que no ejecutan Internet Explorer
- Los usuarios externos (es decir, los usuarios que inician sesión desde fuera del firewall de la organización)
El inconveniente de la autenticación basada en formularios es que no es un mecanismo muy seguro. Por ejemplo, las credenciales del usuario se pasan al servidor en formato de texto sin cifrar. Por ese motivo, es absolutamente recomendable emplear la conectividad HTTPS para cualquier servidor virtual que permita la autenticación basada en formularios.
Autenticación personalizada
Además de los mecanismos de autenticación integrados en el sistema operativo Windows, Communicator Web Access admite también métodos de autenticación personalizados o de otro fabricante. Por ejemplo, Communicator Web Access admite el uso de la autenticación en dos fases, en la que deben especificarse dos tipos de identificación (normalmente, una tarjeta inteligente y un número de identificación personal o PIN) para que se pueda autenticar a un usuario.
Communicator Web Access admite también la autenticación de inicio de sesión único, pero solo con Microsoft Internet Security and Acceleration Server (ISA) 2006. Con el inicio de sesión único, el usuario inicia sesión una sola vez y se le concede acceso a varias aplicaciones. Por ejemplo, un usuario puede iniciar sesión en Microsoft Outlook Web Access e iniciará también sesión automáticamente en Communicator Web Access (o viceversa).
Nota
Si utiliza el inicio de sesión único, debe especificar la opción Dirección URL de cierre de sesión, es decir, la dirección URL a la que obtendrá acceso el usuario cuando cierre la sesión de Communicator Web Access. Al tener acceso a esta página, se garantiza que se eliminarán las cookies de autenticación almacenadas en el equipo del usuario. Para obtener información detallada, consulte la documentación del método de autenticación personalizado.
Tipo de conectividad
Después de especificar el mecanismo de autenticación, debe especificar el tipo de conectividad. Communicator Web Access admite dos protocolos de conectividad diferentes: HTTP y HTTPS. De los dos, se prefiere HTTPS porque es más seguro. HTTP cifra todo el tráfico entre el servidor y el explorador, entre otras ventajas. Si decide utilizar HTTPS (el protocolo recomendado), debe asignar un certificado a esta conexión. Para obtener información detallada, vea Preparar certificados para Communicator Web Access.
Nota
Para implementar el uso compartido de escritorio, se requiere el protocolo HTTPS. Si inicia sesión en un sitio web de Communicator Web Access que utiliza el protocolo HTTP, se deshabilitará el botón de uso compartido del escritorio. Si mantiene el mouse sobre el botón, aparecerá información sobre la herramienta con el siguiente mensaje: "El uso compartido de escritorio requiere una conexión segura (HTTPS). Póngase en contacto con el administrador del sistema".
También debe asignar un dirección IP y un puerto a cada servidor virtual. Los servidores virtuales pueden compartir direcciones IP, pero no puertos: cada servidor virtual debe tener su propio puerto, que no esté siendo utilizado por ninguna aplicación. De forma predeterminada, el programa de instalación sugiere usar el puerto 443 para las conexiones HTTPS y el puerto 80 para las conexiones HTTP. Como estos puertos los utiliza también el sitio web predeterminado de Internet Information Services (IIS), tendrá que cerrar ese sitio para poder asignar estos puertos a Communicator Web Access.
Como se ha indicado previamente, al crear un servidor virtual debe especificar el puerto que va a usar el servidor. Si el puerto especificado ya lo utiliza otra aplicación, el programa de instalación le informará de que ese puerto ya está reservado y le pedirá que seleccione un número de puerto diferente. Por ejemplo, el sitio web predeterminado de IIS utiliza el puerto 443. Si no ha deshabilitado este sitio web, el programa de instalación no le permitirá utilizar el puerto 443 como puerto del servidor virtual.
Sin embargo, Communicator Web Access no siempre reconoce los puertos que están siendo utilizados actualmente por un componente del sistema Windows. Suponga, por ejemplo, que selecciona el puerto 137 al crear un servidor virtual. El programa de instalación le permitirá usar ese número de puerto y creará el servidor virtual. Sin embargo, no podrá iniciar este nuevo servidor virtual. Esto es debido a que Compartir archivos e impresoras utiliza este puerto. En este caso, deberá utilizar el complemento de Communicator Web Access para cambiar el número de puerto.
Servidor del próximo salto
Por último, deberá asignar un "servidor del próximo salto" al servidor virtual. Cuando un usuario participa en una conferencia, los mensajes deben transmitirse entre el servidor Communicator Web Access y el servidor principal del usuario. Los usuarios anónimos (es decir, los usuarios que no tienen una cuenta en su dominio de Active Directory o en el dominio de un socio federado) pueden participar en las conferencias. Sin embargo, como los usuarios anónimos no tienen un servidor principal, no hay ningún lugar para que Communicator Web Access retransmita los mensajes.
Por tanto, debe asignar a cada servidor virtual un servidor del "próximo salto", es decir, un servidor o grupo de servidores que pueda actuar como servidor principal para los usuarios anónimos. Un servidor del próximo salto puede ser cualquier equipo del bosque que ejecute Office Communications Server 2007 R2.
Cuando asigne un servidor del próximo salto, asegúrese de que dicho servidor está en funcionamiento. No asigne un servidor del próximo salto que esté desconectado actualmente o que se vaya a desconectar. Si se produce un error en el servidor del próximo salto, también se producirá un error en Communicator Web Access. Por este motivo, es recomendable que utilice un grupo de servidores como servidor del próximo salto. De esta forma, si se produce un error en uno de los servidores, Communicator Web Access no dejará de funcionar.
De nuevo, tenga en cuenta que el asistente de instalación solamente le permite crear un servidor virtual para cada equipo de Communicator Web Access. Si desea crear un segundo servidor virtual en este mismo equipo (por ejemplo, para que un servidor Communicator Web Access pueda admitir tanto a usuarios internos como externos), necesitará crear el segundo servidor mediante el complemento de Communicator Web Access. Para obtener información detallada, vea Crear un servidor virtual de Communicator Web Access mediante el complemento de Communicator Web Access.