Criando um servidor virtual do Communicator Web Access

Tópico modificado em: 2009-03-06

Depois de instalar e ativar o Communicator Web Access (versão 2007 R2), você precisará criar pelo menos um servidor virtual do Communicator Web Access. Os usuários não podem utilizar o sistema de mensagens instantâneas, audioconferências ou qualquer outro recurso do Communicator Web Access, a menos que tenham um servidor virtual no qual fazer logon.

Observação:

Na maioria das vezes, um servidor virtual é simplesmente um site. Se os usuários fizerem logon no Communicator Web Access usando a URL https://im.contoso.com, ela será não só um site como também um servidor virtual do Communicator Web Access. A vantagem dos servidores virtuais está no fato de eles permitirem que um único computador de IIS (Serviços de Informações da Internet) hospede vários sites. Por exemplo, um computador pode hospedar https://im.fabrikam.com e https://im.contoso.com.

Se você pretende gerenciar solicitações de usuários internos (ou seja, usuários dentro do firewall da organização) e externos (fora do firewall), precisará criar dois servidores virtuais: um para usuários internos e outro para usuários externos. Você pode usar o Assistente para Implantação para criar o primeiro servidor virtual e, depois, usar o snap-in do Communicator Web Access para criar o segundo servidor virtual.

Observação:

Se você pretende gerenciar solicitações de usuários externos, é altamente recomendável usar um servidor proxy reverso para publicar o servidor virtual na Web. Para obter detalhes sobre como usar um servidor proxy reverso para publicar um servidor virtual do Communicator Web Access, consulte Usando um proxy reverso para habilitar o acesso de usuário remoto. Além disso, por motivos de segurança, é recomendável hospedar o servidor virtual para usuários internos e o servidor virtual para usuários externos em computadores separados.

Para criar o primeiro servidor virtual em um computador, consulte o procedimento em Criando um servidor virtual do Communicator Web Access com o uso do Assistente para Implantação. Se você deseja criar um segundo servidor virtual no mesmo computador, execute essa tarefa com o uso do snap-in do Communicator Web Access. Para criar um segundo servidor virtual em um computador, execute o seguinte procedimento:

• Abra o snap-in do Communicator Web Access, clique com o botão direito do mouse no nome do servidor em que o servidor virtual será criado e clique em Criar Servidor Virtual.
• Depois que o Assistente para Criação de Servidor Virtual aparecer, use a mesma abordagem usada para criar o primeiro servidor virtual no computador.

Antes de criar um servidor virtual, é preciso escolher um método de autenticação, um tipo de conectividade e um servidor de próximo salto.

Métodos de autenticação

Ao criar um servidor virtual, é preciso especificar valores para várias propriedades, começando pelo mecanismo de autenticação. O Communicator Web Access fornece várias opções de autenticação.

Autenticação de senha integrada (NTLM/Kerberos)

Este é o tipo mais seguro de autenticação e a opção que exige o mínimo esforço. Com a autenticação de senha integrada, os usuários não precisam inserir um nome de usuário e uma senha. Em vez disso, eles são autenticados com o uso das mesmas credenciais inseridas para fazer logon em seus computadores.

No entanto, existem dois obstáculos para a autenticação de senha integrada. Em primeiro lugar, esse tipo de autenticação só pode ser usada com servidores virtuais internos; usuários externos sempre precisam fornecer credenciais; ou seja, sites que gerenciam solicitações de logon externas precisam usar autenticação baseada em formulários ou personalizada.

Em segundo lugar, a autenticação de senha integrada pode ser usada apenas por pessoas que: fazem logon em um computador que executa o Microsoft Windows e que usam um navegador da Web com suporte para autenticação NTLM ou Kerberos. Se todos os usuários forem internos e estiverem executando o Internet Explorer e o Microsoft Windows, você poderá usar a autenticação de senha integrada como único mecanismo de autenticação. Caso contrário, será preciso usar a autenticação de senha integrada e a autenticação baseada em formulários ou um método de autenticação personalizado.

Observação:
Se você usar a autenticação de senha integrada e a autenticação baseada em formulários, o Communicator Web Access tentará primeiro fazer logon de um usuário utilizando a autenticação de senha integrada. Se ela falhar, o usuário terá a oportunidade de fazer logon usando a autenticação baseada em formulários.

Autenticação baseada em formulários

Com a autenticação baseada em formulários, um usuário que tente acessar um servidor virtual do Communicator Web Access verá uma caixa de diálogo de logon. O usuário deverá informar suas credenciais (ou seja, domínio, nome de usuário e senha) para poder ser autenticado e acessar o site. A autenticação baseada em formulários permite oferecer suporte a:

• Usuários do Macintosh e do Linux
• Usuários que executam o Internet Explorer
• Usuários externos (ou seja, que fazem logon de fora do firewall da organização)

A desvantagem da autenticação baseada em formulários é o fato de que ela não é um mecanismo muito seguro. Por exemplo, as credenciais do usuário são passadas para o servidor no formato de texto simples. Por isso, é altamente recomendável empregar a conectividade HTTPS para qualquer servidor virtual que permita a autenticação baseada em formulários.

Autenticação personalizada

Além dos mecanismos de autenticação internos do sistema operacional Windows, o Communicator Web Access também oferece suporte para métodos de autenticação personalizados ou de terceiros. Por exemplo, o Communicator Web Access oferece suporte ao uso de autenticação de dois fatores, na qual dois itens de identificação (geralmente um cartão inteligente e um PIN) devem ser apresentados para que um usuário seja autenticado.

Além disso, o Communicator Web Access oferece suporte à autenticação de logon único, embora somente com o Microsoft Internet Security and Acceleration (ISA) Server 2006. Com o logon único, um usuário pode fazer logon uma vez e ter acesso a vários aplicativos. Por exemplo, um usuário pode fazer logon no Microsoft Outlook Web Access e ser automaticamente conectado ao Communicator Web Access também (ou vice-versa).

Observação:
Se usar o logon único, você poderá especificar a opção URL de Saída, uma URL à qual o usuário será encaminhado sempre que sair do Communicator Web Access. Visitando essa página, o usuário terá certeza de que os cookies de autenticação armazenados no seu computador serão excluídos. Para obter detalhes, consulte a documentação do seu método de autenticação personalizado.

Tipo de conectividade

Depois de especificar o mecanismo de autenticação, você precisará especificar o tipo de conectividade. O Communicator Web Access dá suporte a dois diferentes protocolos de conectividade: HTTP e HTTPS. Entre os dois, o HTTPS é o preferido por ser o mais seguro. Entre outras questões, o HTTPS criptografa todo o tráfego entre o servidor e o navegador. Se você decidir usar o HTTPS (o protocolo recomendado), precisará atribuir um certificado a essa conexão. Para obter detalhes, consulte Preparando certificados para o Communicator Web Access.

Observação:

O protocolo HTTPS é necessário se você pretende implementar o compartilhamento de área de trabalho. Se você fizer logon em um site do Communicator Web Access que use o protocolo HTTP, o botão do compartilhamento de área de trabalho será desabilitado. Se você mantiver o ponteiro do mouse sobre o botão, uma dica de ferramenta aparecerá informando que “O compartilhamento da área de trabalho requer uma conexão segura (HTTPS). Contate o administrador do sistema”.

Você também deve atribuir a cada servidor virtual um endereço IP e uma porta. Os servidores virtuais podem compartilhar endereços IP, mas não podem compartilhar portas: cada servidor virtual precisa ter sua própria porta, que não seja usada por qualquer outro aplicativo. Por padrão, a Instalação sugere usar a porta 443 para conexões HTTPS e a porta 80 para conexões HTTP. Como também existem portas usadas pelo Site Padrão no IIS (Serviços de Informações da Internet), será preciso fechar esse site para que essas portas possam ser atribuídas ao Communicator Web Access.

Conforme observado, ao criar um servidor virtual, você precisa especificar uma porta a ser usada por esse servidor. Se a porta especificada já estiver sendo usada por outro aplicativo, o programa de instalação informará a você que a porta já foi reservada e solicitará a escolha de um número de porta diferente. Por exemplo, a porta 443 é usada pelo Site Padrão no IIS. Se você não tiver desabilitado esse site, a instalação não permitirá que você use a porta 443 como uma porta de servidor virtual.

No entanto, o Communicator Web Access nem sempre reconhece portas que estão sendo usadas no momento por um componente de sistema do Windows. Por exemplo, suponha que você tenha selecionado a porta 137 ao criar um servidor virtual. A instalação permitirá que você use esse número de porta e criará o servidor virtual para você. No entanto, você não poderá iniciar esse novo servidor virtual. Isso ocorre porque essa porta é usada pelo Compartilhamento de Arquivo e Impressora. Se isso ocorrer, você precisará usar o snap-in do Communicator Web Access para alterar o número da porta.

Servidor do próximo salto

Finalmente, você precisará atribuir ao servidor virtual um “servidor de próximo salto”. Quando um usuário participa de uma conferência, as mensagens precisam ser passadas entre o servidor do Communicator Web Access e o servidor primário do usuário. Os usuários anônimos (aqueles que não têm uma conta no seu domínio do Active Directory ou no domínio de um parceiro federado) podem participar de conferências. No entanto, como os usuários anônimos não têm um servidor primário, o Communicator Web Access não têm onde retransmitir as mensagens.

Por isso, você precisa atribuir a cada servidor virtual um servidor de “próximo salto”, um servidor (ou pool de servidores) que possa atuar como um servidor primário para usuários anônimos. Um servidor de próximo salto pode ser qualquer computador na floresta que esteja executando o Office Communications Server 2007 R2.

Ao atribuir um servidor de próximo salto, verifique se ele está configurado e em execução. Não atribua um servidor de próximo salto que esteja offline no momento ou que vá ficar offline. Se o servidor de próximo salto apresentar falha, o Communicator Web Access também falhará. Por isso, é recomendável usar um pool de servidores como seu servidor de próximo salto. Dessa maneira, a falha de um único servidor não levará à falha do Communicator Web Access.

Novamente, observe que o Assistente para Instalação permite apenas que você crie um servidor virtual por computador do Communicator Web Access. Para criar um segundo servidor virtual no mesmo computador (por exemplo, para que um servidor do Communicator Web Access possa oferecer suporte aos usuários internos e externos), você precisa criar o segundo servidor usando o snap-in do Communicator Web Access. Para obter detalhes, consulte o tópico Criando um servidor virtual do Communicator Web Access com o uso do snap-in do Communicator Web Access.

Consulte Também

Tarefas

Criando um servidor virtual do Communicator Web Access usando a linha de comando