Sugerir tradução
 
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Março 2009 >  Proteger o Office Communications Server (OCS) c...
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este é um conteúdo traduzido por máquina que os membros da comunidade podem editar. Incentivamos você a melhorar a tradução clicando no link Editar associado a qualquer sentença abaixo.
Office Communications Server
Securing OCS with ISA Server
Alan Maddison
 
At a Glance:
  • OCS 2007 R2 Edge Server roles and topologies
  • Configuring ISA Server in a 3-Leg Perimeter network
  • Understanding OCS certificate requirements
  • Creating a Web listener and a reverse proxy for OCS

Office Communications Server (OCS) 2007 R2 provides powerful capabilities that allow you to extend your Unified Communications infrastructure to users outside of your organization. This can have tremendous benefits. Functionality such as Web and audio/visual (A/V) conferencing, for example, can improve an organization's responsiveness and effectiveness in its daily business tasks.
If you choose to deploy OCS functionality to remote users and partners, however, you must complete two important steps. First, you will need to deploy OCS Edge Servers to best practices defined in the Office Communications Server 2007 R2 Security Guide. Second, you will need to provide reverse proxy access to the Edge Servers. In this article I'll take a look at using ISA Server 2006 with SP1 to secure your OCS deployment.

Edge Servers
To communicate with other OCS infrastructures and to allow remote access to your organization's network, you need to deploy one or more Edge Servers in your perimeter network (also known as a DMZ) so that users outside the firewall can gain secure access to your internal OCS deployment. OCS 2007 R2 includes three Edge Server roles, summarized in Figure 1, which also describes reverse proxy functionality.
Figure 1 Edge Server roles and reverse proxy for OCS 2007
Role Purpose
Access Edge Server Authenticated external user access including public IM connectivity, federation, Web conferences, and voice functionality.
Web Conferencing Edge Server External Web conferencing and data collaboration.
A/V Edge Server Any external user access to A/V conferences and point-to-point A/V calls.
Reverse Proxy Group expansion, address book file download, Web conferencing download of meeting content.

Prior to the R2 release of Office Communications Server 2007, Microsoft supported four different Edge Topologies that provided varying levels of sophistication and scalability. In general, the topologies differed in the location of the various Edge Server roles:
  • Consolidated Edge Topology
  • Single-Site Edge Topology
  • Scaled Single-Site Edge Topology
  • Multiple Site with a Remote Site Edge Topology
With the release of R2, Microsoft now require that all roles run on the same server with scalability provided by hardware load balancers (the Network Load Balancer, or NLB, component available in Windows is not supported). A Consolidated Edge Topo­logy is a cost-effective approach that has the added benefit of being the simplest to deploy and administer. This topology works for all organizations, and for the purposes of this article I'll focus on this design.
An important point to remember is that in addition to changes in OCS topology support, there have been some significant changes in the network topologies and technologies supported by R2. However, in R2 the A/V Edge Server role must have a public IP address on the external network interface card (NIC) due to the underlying requirement of the Simple Traversal of UDP through NAT (STUN) protocol.
Though Microsoft has been very adamant about this requirement, many Administrators have ignored the documentation and have attempted to implement the OCS Edge Servers in a Network Address Translation (NAT) environment. If you implement NAT in front of your A/V Edge Servers, your users could experience intermittent connectivity problems and may not even be able to establish a connection.
One important point to remember is that as of R2 Microsoft no longer supports Destination Network Address Translation (DNAT) in an OCS environment. This means that the firewall or Load Balancer must be configured with Source NAT (SNAT) before introducing R2 into your environment. Finally, your Edge Servers should not be members of an Active Directory domain.
If the Edge Servers are not configured correctly, you will only be creating more of a headache for yourself when ISA Server is thrown into the mix. Review, validate and test your Edge configuration before moving on.
Figure 2 3-Leg Perimeter deployment of Consolidated Edge Servers

Getting Ready
To deploy the OCS Edge Topology, I'll focus on a common implementation scenario in which a firewall, ISA Server in this case, is deployed in a 3-Leg Perimeter network; a simple, cost-effective approach that shares core concepts with more complex firewall topologies. In this design, the three legs correspond to the internal network, the perimeter network, and the external (Internet) network. This approach not only allows external user access to the OCS infrastructure, it also supports using ISA Server in a reverse proxy role.
Figure 2 depicts a logical view of an ISA Server 3-Leg implementation. Before beginning to configure ISA Server, it is a good idea to have already laid out the IP addressing and Fully Qualified Domain Name (FQDN) mappings for your Edge Servers and ISA Server. This will make the configuration process a lot simpler and quicker.
Figure 3 shows an example of a suitable check list. Note that I have used a private IP address range for informational purposes only; you will have to use public IP addresses.
Figure 3 Sample configuration
Role Fully Qualified Domain Name Public IP Address NIC External User Port Requirements Internal User Port Requirements
Access Edge Server sip.contoso.com 172.16.0.2/29 External 5061,443 5061
A/V Edge Server av.contoso.com 172.16.0.3/29 External 443,3478 50,000-59,999 443, 5062 50,000-59,999
Web Conferencing Edge Server webconference.contoso.com 172.16.0.4/29 External 443 8057

Figure 4 shows the IP addressing information for the ISA Server, including the IP address used to publish (reverse proxy) the OCS Address Book and Content Web site used by the Web Conferencing Server.
In a Consolidated Edge Deployment, there is typically a single physical server with two NICs, one for internal traffic and one for external traffic. The NIC connected to the corporate network (internal) will have an IP address from your existing internal IP address range. The NIC that connects to remote users (external) will use at least one public (fully routable) IP address for the A/V Edge Server. Although not strictly necessary, it is simpler to also assign public IP addresses to the other Edge roles, as in Figure 4.
Figure 4 ISA Server IP addresses
ISA Interface Fully Qualified Domain Name IP Address
External N/A 172.16.0.9/29
Reverse Proxy ocscontent.contoso.com 172.16.0.10/29
Perimeter N/A 172.16.0.1/29
Internal N/A 192.168.0.100/24

You will also need to create unique subnets for your public IP address space. ISA Server will need two IP addresses on its external interface (one of which will be used for the reverse proxy), and you will need four public IP addresses for your perimeter network (three for the Access Edge Servers and one for the ISA Server perimeter interface). As an example, this is shown in Figure 3 as 29-bit subnet mask (255.255.255.248), which would give you six usable IP addresses per subnet.
If you have been allocated only a small number of public IP addresses, you can use network address translation for the Access Edge Server and the Web Conferencing Edge Server roles and connect the A/V Edge Server directly to the Internet. However, this approach is a little less secure in that you are bypassing the packet inspection capabilities of ISA Server and would require a third network interface card for your Edge Server.

Configuring ISA Server 2006
To configure the 3-Leg Perimeter, you need to launch the ISA Server management console and select Networks under the Configuration node in the left-hand pane, as shown in Figure 5. Next, click on the Templates tab in the right-hand pane and select the 3-Leg Perimeter template to start the Network Template Wizard.
This process will erase any existing configuration and rules, so note that if you are not using a new system, you should take care to export the configuration, an option offered by the wizard on the second screen. Clicking Next on the second screen begins the configuration process by asking you to input the IP address ranges that define your internal network.
Figure 5 Selecting 3-Leg Perimeter template
You have a number of options to help define the internal address space. If your organization is small, simply adding the network adapter that is connected to the corporate network is sufficient. Larger organizations will need to use the other options, such as adding IP address ranges to fully define their internal address space.
After entering this information, click Next to move to the next screen to define the perimeter network address space. It is usually sufficient to add the adapter you have dedicated to the perimeter network. Next, you must select a firewall policy. Be sure to choose the "Allow Unrestricted Access" firewall policy, then click Next to go to the Summary screen where you can review your configuration. Select Finish to complete the wizard and then, to accept these changes, click Apply and then OK.
The basic 3-Leg Perimeter is functional at this point but it needs some additional configuration in order to permit network traffic between the OCS Edge Servers and external users. The first thing to note is that the default configuration of a 3-Leg Perimeter in ISA Server includes support for VPN users. If you don't need this type of remote access, remove this item.
To do so, select Firewall Policy in the left-hand pane of the ISA Management console and then right-click the rule called VPN Clients to Internal Network and select Delete. To accept the changes, choose Apply and then OK. Two rules remain: the Unrestricted Internet access rule and the Default rule.
The next step is to add the computer objects that represent your Edge Servers. Select Firewall Policy and then choose the Toolbox tab, as shown in Figure 6.
Figure 6 Firewall Policy rules
Click on the New button and select Computer from the dropdown menu. Add the name of the Edge Server, for example Access Edge, and then enter the IP address for that server. Repeat this step for the A/V Edge Server and the Web Conferencing Edge Server. When you are finished, you should see your three computer objects listed under the Computers container.
The next step is to add the protocols used by OCS to the ISA Server configuration. You will need to add two new protocols, as shown in Figure 7.
Figure 7 Protocols used by OCS
Protocol Name Protocol Type Protocol Direction Port Range
Mutual Transport Layer Security (MTLS)/Session Initiation Protocol (SIP) TCP Outbound 5061-5061
Simple Traversal of UDP through NAT (STUN) TCP Outbound 50,000-59,999
UDP Send *50,000-59,999
UDP Send 3478-3478

Note the asterisk in Figure 7. In OCS 2007 R2, this port requirement is necessary only if you use the A/V capabilities of OCS with a Federated Partner running Office Communications Server 2007. Remote users will not need these ports to be open.
It is worth emphasizing that it is a security best practice to only open ports that you require. For example, consider A/V conferencing with a Federated Partner, which requires UDP ports in the range 50,000–59,999. If you don't have a Federated Partner then you don't need to open these ports.
In the ISA Server management console, within the Firewall Policy and the Toolbox tab selected, click on Protocols, then on New and on Protocol to launch the New Protocol Definition Wizard. When the wizard launches, enter a name for the protocol, then click Next to go to the Primary Connection Information screen. On this screen click New and then add the information for the MTLS/SIP protocol, as shown in Figure 7.
To finish adding the protocol, click OK and then the Next button twice; you do not need to configure anything on the Secondary connections screen. Now click the Finish button on the Summary screen, and repeat these steps for the STUN protocol. Make sure you apply these changes to ISA Server when you have finished adding the protocols.
The Persistent Shared Object Model (PSOM) protocol (a proprietary protocol for transporting Web conferencing content) is not listed in Figure 7. This is because PSOM is used for traffic between the Web Conferencing Server and the Web Conferencing Edge Server. This traffic is sent out on the internal network card of the Edge Server.
After adding the above two protocols from Figure 7, the next step is to create the three Access rules that will permit users to connect to the Edge Server from the Internet. Once again, having this information at hand will make these configuration steps a lot simpler and less prone to error. Figure 8 shows the information you will need to create the three external access rules.
Figure 8 Access rule configuration
Access Rule Name Rule Action Protocols Access Rule Source Access Rule Destination User Sets
Access Edge Allow HTTPS MTLS/SIP External Access Edge All Users
A/V Edge Allow HTTPS STUN External A/V Edge All Users
Web Conferencing Edge Allow HTTPS External Web Conferencing Edge All Users

Start by selecting Firewall Policy and the Tasks tab in the ISA Server Management console and then click on Create Access Rule to launch the New Access Rule wizard. You can create the rules in any order, so let's start with the Access Edge rule. Once the wizard launches, enter a name for the rule and click Next. On the Rule Action screen, make sure that the Allow radio button is selected and click Next.
The following screen requires you to add the Protocols to which the rule applies. Click the Add button on the right-hand side of the screen to launch the Add Protocols window. Under the Common Protocols folder, select HTTPS and press Add, then select the STUN protocol—which should be listed under the User-Defined folder—and click Add. Click Close and then Next to move onto the Access Rule Sources screen.
This step requires you to select the Access Rule source, and in the case of the Access Edge rule, you will need to select the External network object by clicking Add and selecting it from the Networks folder. Then click Close and then Next to move to the Access Rule Destination screen. On this screen click Add and select the Access Edge computer object you created earlier from the Computers folder. Click the Close button and then Next to move to the User Sets screen.
Leave the All Users set default selection and click Next. Review the Summary, then click Finish to complete the process. You can now create the two remaining access rules using the information you compiled based on Figure 8. Make sure you apply these changes to ISA Server once you have finished.

A Word about Certificates
The last steps in this configuration process are focused on creating the SSL listener and creating the reverse proxy (publishing a Web application) for Office Communications Server. It's important to understand the certificate requirements of Office Communications Server and how these requirements impact ISA Server configuration.
The most important point to note here is that Office Communications Server requires the use of x.509 certificates and does not support wildcard certificates in the Common Name (Subject Name). You will need to specify a Subject Alternate Name (SAN) when requesting the certificate for the Edge Servers.
Since ISA Server 2006 SP1 introduced full support for SAN certificates, this will not present any problems. With this in mind, you need to address the certificate requirements for both the internal and external interfaces of the Edge Server. If your Active Directory environment does not use a top-level domain namespace, you will need to use a certificate from a trusted third-party Certificate Authority (CA) for the external interface and a certificate from an internal enterprise CA for the internal interfaces. In this scenario, the Root Certificate for your enterprise CA must be installed on clients that will access OCS internally as well as on the ISA Server; this ensures that the necessary trust relationships are in place for the OCS configuration. The external third-party certificate should already be trusted, and therefore the Root Certificate of the third-party CA doesn't need to be installed on all clients.
The certificate required for the reverse proxy configuration corresponds to the FQDN of the OCS address book and conference content download. In Figure 4, this was ocscontent.contoso.com but can obviously be anything you choose as long as the certificate comes from a trusted third party. Of course, your SAN certificate from this third party would also include the FQDNs of your Edge Servers, samples of which you can also see in Figure 3.

Reverse Proxy
The first step in creating a reverse proxy for OCS is to create an SSL Web Listener. To do this, click on the Firewall container in the left-hand pane and select the Toolbox tab in the right–hand pane. Select Network Object from the list, click the New button and select Web Listener from the dropdown menu. This will launch the New Web Listener wizard, which prompts you to enter a name for the Web Listener.
The name should be meaningful to you, but it doesn't necessarily have to be associated with OCS as the Web Listener could potentially have multiple uses. When you click Next, the Client Connection Security screen appears with the default option selected—Require SSL secured connections with clients. Leave the selection as is and click Next to move to the Web Listener IP Address screen, where you should check the External networks option. Next, click the Select IP Addresses button and choose the IP address that you have assigned to the reverse proxy (see Figure 4).
After clicking OK and then Next, you will see the Listener SSL Certificates screen. Select the option to Assign a certificate for each IP address and then click the Select Certificate button. Now select the certificate associated with the OCS address book and Web conference content that was discussed earlier. After selecting the certificate, click the Next button to configure Authentication Settings. Make sure that No Authentication is selected in the dropdown box and then click the Next button twice. Finally review the Summary screen and click the Finish button to complete the creation of the Web Listener.
Once the Web Listener is created, you can create the Web Site Publishing rule. To do this, click on the Firewall container and select the Tasks tab, then click on Publish Web Sites to launch the New Web Publishing Rule Wizard. The first piece of information to enter is the name of the rule, so enter a meaningful name such as OCS Content and click Next. On the Select Rule Action screen, select Allow and click Next to move to the Publishing Type screen where you will select Publish a single Web site or load balancer and then click Next.
To configure Server Connection Security, select the option to use SSL, then press Next to proceed to the Internal Publishing Details screen. Here you need to enter the internal name of the Web components server. Click Next and enter the path information, which should be /* to allow all paths. Click Next and enter the public name you created for the Address Book and Web Conference content downloads (in the example here it is ocscontent.contoso.com). Leave the other selections at the defaults and click Next.
Now select the Web Listener you created and click Next. On the Authentication Delegation screen, the dropdown box should read No delegation, but client may authenticate directly. Click Next and confirm that All Users is selected on the User Sets screen, then click Next again and then Finish to complete the process. The configuration of ISA Server is now complete.

Last Words
Extending Office Communications Server to support remote users and partners can yield tremendous benefits but requires a great deal of planning, particularly when it comes to securing your Edge Servers. ISA Server 2006 provides a robust, flexible, and scalable solution that is the ideal platform for securing Office Communications Server 2007.

Alan Maddison is a Senior Consultant specializing in Microsoft technologies with Strategic Business Systems, a division of Brocade.

O Office Communications Server
Protegendo OCS com o ISA Server
Alan Maddison
 
Visão geral:
  • Funções de servidor de borda OCS 2007 R2 e topologias
  • Configurando o ISA Server em uma rede de perímetro 3 lado
  • Noções básicas sobre requisitos de certificado OCS
  • Criar um ouvinte da Web e um proxy reverso para OCS

OCS (Office Communications Server) 2007 R2 fornece recursos poderosos que permitem a você estender sua infra-estrutura de comunicação unificada a usuários fora da sua organização. Isso pode ter benefícios enorme. Recursos como Web e audiovisual (A/V) conferência, por exemplo, pode melhorar capacidade de resposta e eficiência em suas tarefas comerciais diária de uma organização.
Se você optar por implantar OCS funcionalidade aos usuários remotos e parceiros, no entanto, você deve concluir duas etapas importantes. Em primeiro lugar, será necessário implantar os servidores de borda de OCS práticas definidas no guia de segurança Office Communications Server 2007 R2. Em segundo lugar, você precisará fornecer acesso de proxy reverso para os servidores de borda. Neste artigo vai dê uma olhada no usando o ISA Server 2006 com SP1 para proteger a sua implantação OCS.

Servidores de borda
Para se comunicar com outras infra-estruturas de OCS e para permitir o acesso remoto à rede da sua organização, você precisará implantar um ou mais servidores de borda em sua rede de perímetro (também conhecido como DMZ) para que os usuários fora do firewall podem ter acesso seguro à sua implantação OCS interno. OCS 2007 R2 inclui três funções de servidor de borda, resumidas na Figura 1 , que também descreve a funcionalidade de proxy reverso.
Figura 1 funções de servidor de borda e proxy reverso para o 2007 OCS
Função Finalidade
Servidor de perímetro de acesso Incluindo conectividade de IM pública, federação, conferências da Web e à funcionalidade de voz de acesso de usuário externo autenticado.
Servidor de borda de conferência Web Externa da conferência e dados de colaboração.
A/servidor de borda A/V Nenhum acesso de usuário externo à / V conferências e A ponto-a-ponto/V chama.
Reverter proxy Grupo expansão, download de arquivo do catálogo de endereços, download de conferência da Web de conteúdo de reunião.

Antes para a versão R2 do Office Communications Server 2007, Microsoft, suporte para quatro diferentes topologias de borda que forneceu vários níveis de sofisticação e escalabilidade. Em geral, as topologias diferente no local de várias funções de servidor de borda:
  • Topologia de borda consolidado
  • Topologia de borda de site único
  • Topologia de borda de site único em escala
  • Vários sites com uma topologia de borda de site remoto
Com o lançamento do R2, o Microsoft agora exigem que todas as funções execute no mesmo servidor com escalabilidade fornecida pelo balanceadores de carga de hardware (não há suporte para o balanceador de carga de rede, NLB, componente ou disponível no Windows). Um Topo­logy de borda Consolidated é uma abordagem econômica que possui o benefício adicional de ser o mais simples implantar e administrar. Essa topologia funciona para todas as organizações, e para os fins deste artigo falarei sobre esse design.
Um ponto importante lembrar é que com alterações no suporte de topologia de OCS, houve algumas alterações significativas nas topologias de rede e tecnologias com suporte R2. No entanto, no R2 o/função de servidor de borda A/V deve ter um endereço IP público na placa de interface de rede externa (NIC) devido à necessidade subjacente do Traversal simples de UDP por meio de protocolo NAT (STUN).
Embora Microsoft tiver sido muito adamant sobre esse requisito, muitos administradores tem ignorado a documentação e tentaram implementar os servidores de borda OCS em um ambiente (Network Address TRANSLATION). Se você implementar NAT na frente do seu A servidores de borda A/V, os usuários pode ter problemas de conectividade intermitentes e não mesmo consiga estabelecer uma conexão.
Um ponto importante a lembrar é que oferece como da Microsoft de R2 não há mais suporte destino DNAT (conversão de endereços da rede) em um ambiente de OCS. Isso significa que o firewall ou balanceador de carga deve ser configurado com fonte NAT (SNAT) antes de introduzir R2 em seu ambiente. Finalmente, os servidores de borda não deve ser membros de um domínio do Active Directory.
Se os servidores de borda não estiverem configurados corretamente, você só criará mais de uma dor de cabeça para si mesmo quando o ISA Server é lançado para a combinação. Revisar, validar e testar a configuração de borda antes de passar.
A Figura 2 3 lado perímetro implantação Consolidated servidores de borda

Preparando-se
Para implantar a topologia de borda de OCS, VOU me concentrar em um cenário comum de implementação no qual nesse caso, um firewall, o ISA Server é implantado em uma rede de perímetro de 3-lado; uma abordagem simples e econômica que compartilha principais conceitos com topologias de firewall mais complexos. Neste projeto, as pernas três correspondem a rede interna, a rede de perímetro e a rede externa (Internet). Essa abordagem não só permite acesso de usuário externo à infra-estrutura OCS, ele também oferece suporte usando o ISA Server em uma função de proxy reverso.
a Figura 2 mostra uma exibição lógica de uma implementação de 3-lado do ISA Server. Antes de começar a configurar o ISA Server, ele é uma boa idéia para ter já dispostas de endereçamento IP e nos mapeamentos de totalmente qualificado FQDN (nome de domínio) para seus servidores de borda e o ISA Server. Isso tornará o processo de configuração muito mais simples e rápido.
a Figura 3 mostra um exemplo de uma lista de seleção adequada. Observe que eu tenha usado um intervalo de endereços IP particular para fins informativos somente; você vai ter que use endereços IP públicos.
A Figura 3 Exemplo de configuração
Função Nome de domínio totalmente qualificado Endereço IP público NIC Requisitos de porta de usuário externa Requisitos de porta de usuário interno
Servidor de perímetro de acesso SIP.contoso.com 172.16.0.2/29 Externo 5061,443 5061
A/servidor de borda A/V AV.contoso.com 172.16.0.3/29 Externo 443,347850,000 59,999 443, 506250,000 59,999
Servidor de borda de conferência Web webconference.contoso.com 172.16.0.4/29 Externo 443 8057

A Figura 4 mostra o IP endereçamento informações para o ISA Server, incluindo o endereço IP usado para publicar o site de catálogo de endereços de OCS e conteúdo utilizado pelo servidor da Web conferência de proxy reverso.
Em uma implantação de borda Consolidated, há geralmente um único servidor físico com dois NICs, um para o tráfego interno e um para o tráfego externo. O adaptador conectado à rede corporativa (interno) será tem um endereço IP do seu intervalo de endereços IP interno existente. Da NIC que se conecta a usuários remotos (externo) será use pelo menos um endereço IP (totalmente roteável) público O/servidor de borda A/V. Embora não seja estritamente necessário, é mais simples também atribuir endereços IP públicos às outras funções de borda, como na Figura 4 .
Endereços IP de servidor do ISA a Figura 4
Interface do ISA Nome de domínio totalmente qualificado Endereço IP
Externo N/D 172.16.0.9/29
Reverter proxy ocscontent.contoso.com 172.16.0.10/29
Perímetro N/D 172.16.0.1/29
internal N/D 192.168.0.100/24

Você também precisará criar sub-redes exclusivos para seu espaço de endereço IP público. O ISA Server precisará de dois endereços IP em sua interface externa (um dos quais será usado para o proxy reverso), e você terá quatro endereços IP públicos para sua rede de perímetro (três para os servidores de borda de acesso) e outro para a interface de perímetro do ISA Server. Por exemplo, isso é mostrado na Figura 3 como máscara de sub-rede de 29 bits (255.255.255.248), que daria seis endereços IP utilizáveis por sub-rede.
Se você tiverem sido alocados apenas um pequeno número de endereços IP públicos, você pode usar a conversão de endereços de rede para o servidor de perímetro de acesso e as funções de servidor de borda de conferência Web e conectar-se O/servidor de borda A/V diretamente à Internet. No entanto, essa abordagem é um pouco menos segura em que você está ignorando os recursos de inspeção de pacotes do ISA Server e exigiria uma terceira placa de interface de rede para o servidor de borda.

Configurando o ISA Server 2006
Para definir o perímetro de 3-lado, você precisará iniciar o console de gerenciamento do ISA Server e selecione redes sob o nó Configuração no painel esquerdo, como mostrado na Figura 5 . Em seguida, clique na guia modelos no painel direito e selecione o modelo de perímetro 3 lado para iniciar o assistente de modelo de rede.
Esse processo apagará as configuração existente e regras; portanto, observe que se você não estiver usando um novo sistema, você deve ter cuidado para exportar a configuração, uma opção oferecida pelo assistente na segunda tela. Clicando em Avançar na segunda tela inicia o processo de configuração fazendo a entrada os intervalos de endereço IP que definem a sua rede interna.
A Figura 5 selecionando 3 lado perímetro modelo
Você tem um número de opções para ajudar a definir o espaço de endereço interno. Se sua organização for pequena, simplesmente adicionando o adaptador de rede que está conectado à rede corporativa é suficiente. Organizações maiores precisará usar as outras opções, como a adição de intervalos de endereços IP para definir totalmente seu espaço de endereço interno.
Depois de inserir essas informações, clique em Avançar para mover para a próxima tela para definir o espaço de endereço de rede de perímetro. Ele normalmente é suficiente adicionar o adaptador que você tenha dedicado a rede de perímetro. Em seguida, você deve selecionar uma diretiva de firewall. Certifique-se de escolher a diretiva de firewall permitir irrestrito acesso e clique em Next para ir para a tela resumo onde você pode analisar sua configuração. Selecione Concluir para concluir o assistente e em seguida, para aceitar essas alterações, clique em Aplicar e em seguida OK.
O perímetro de 3-lado básico está funcionando nesse momento, mas precisa alguma configuração adicional para permitir o tráfego de rede entre os servidores de borda de OCS e usuários externos. A primeira coisa a observar é que a configuração padrão de um perímetro de 3-lado no ISA Server inclui suporte para os usuários VPN. Se você não precisa esse tipo de acesso remoto, remova este item.
Portanto, selecione Firewall Policy no painel esquerdo do console de gerenciamento do ISA e, em seguida, clique com o botão direito do mouse a regra chamada VPN Clients to Internal Network e selecione Excluir. Para aceitar as alterações, escolha a aplicar e, em seguida, OK. Duas regras permanecem: a regra de acesso irrestrito de Internet e a regra padrão.
A próxima etapa é adicionar os objetos de computador que representam os servidores de borda. Selecione a diretiva de firewall e escolha guia caixa de ferramentas, conforme mostrado na Figura 6 .
A Figura 6 regras de diretiva de firewall
Clique no botão Novo e selecione o computador no menu suspenso. Adicione o nome do servidor de borda, por exemplo perímetro de acesso e digite o endereço IP do servidor. Repita essa etapa para O Server e o Web Conferencing borda Server de borda A/V. Quando tiver terminado, você deverá ver seus objetos de computador três listados no recipiente Computadores.
A próxima etapa é adicionar os protocolos usados por OCS para a configuração do ISA Server. Você precisará adicionar dois novos protocolos, como mostrado na Figura 7 .
Figura 7 protocolos usados por OCS
Nome do protocolo Tipo de protocolo Direção do protocolo Intervalo de porta
Mútua Transport Layer Security (MTLS) / protocolo de início de sessão (SIP) TCP Saída 5061 5061
Traversal simples do UDP por meio do NAT (STUN) TCP Saída 50.000 59,999
UDP Enviar *50, 000-59,999
UDP Enviar 3478 3478

Observe o asterisco na Figura 7 . No R2 de 2007 de OCS, esse requisito de porta é necessário somente se você usar o/recursos de V de OCS com um parceiro federado com o Office Communications Server 2007. Os usuários remotos não serão necessário essas portas a ser aberto.
É importante enfatizar que é uma prática melhor segurança apenas abrir portas que você precisa. Por exemplo, considere A/V conferência com um parceiro federado, que requer UDP portas no intervalo 50, 000–59, 999. Se você não tiver um parceiro federado, em seguida, você não precisará abrir essas portas.
No console de gerenciamento do ISA Server, a diretiva de firewall e a guia de caixa de ferramentas selecionada, clique em Protocols, em seguida, em Novo e em protocolo para iniciar o novo Assistente de definição de protocolo. Quando inicia o assistente, digite um nome para o protocolo e clique em Next para ir para a tela de informações de conexão principal. Nessa tela clique em Novo e, em seguida, adicione as informações para o protocolo MTLS/SIP, como mostrado na Figura 7 .
Para concluir a adicionar o protocolo, clique em OK e, em seguida, o botão Next duas vezes; você não precisa configurar nada na tela conexões secundárias. Agora clique no botão Concluir na tela de resumo e repetir essas etapas para o protocolo STUN. Verifique se que você aplicar essas alterações para o ISA Server quando tiver terminado de adicionar os protocolos.
O protocolo de modelo de objeto persistente compartilhados (PSOM) (um protocolo proprietário para transportar conteúdo de conferência da Web) não está listado na Figura 7 . Isso ocorre porque PSOM é usado para o tráfego entre o servidor de conferência Web e o servidor de borda de conferência Web. Esse tráfego é enviado check-out na placa de rede interna do servidor de borda.
Depois de adicionar os dois protocolos acima da Figura 7 , a próxima etapa é criar as três regras de acesso que permitirá que usuários se conectem ao servidor de borda da Internet. Uma vez, ter essas informações à mão tornará essas etapas de configuração muito mais simples e menos propenso a erro. a Figura 8 mostra as informações será necessário criar as três regras de acesso externo.
Configuração de regra de acesso a Figura 8
Nome da regra de acesso Ação de regra Protocolos Origem da regra de acesso Destino de regra de acesso Conjuntos de usuários
Borda de acesso Permitir HTTPSMTLS/SIP Externo Borda de acesso Todos os usuários
A/V borda Permitir HTTPSSTUN Externo A/V borda Todos os usuários
Borda de conferência da Web Permitir HTTPS Externo Borda de conferência da Web Todos os usuários

Comece selecionando diretiva de firewall e a guia de tarefas no console do ISA Server Management e clique em Criar regra de acesso para iniciar o assistente New Access Rule. Você pode criar as regras em qualquer ordem, portanto, vamos começar com a regra de perímetro de acesso. Depois que o assistente for iniciado, digite um nome para a regra e clique em Avançar. Na tela ação de regra, verifique se que o botão de opção permitir está marcado e clique em Avançar.
Tela a seguir exige que você adicionar os protocolos aos quais a regra se aplica. Clique no botão Adicionar no lado direito da tela para iniciar a janela Add Protocols. Sob a pasta de protocolos comuns, selecione HTTPS e pressione adicionar e selecione o protocolo STUN — que devem ser listadas na pasta definida pelo usuário e clique em Adicionar. Clique em Fechar e, em seguida, Avançar para mover para a fontes de regra de acesso tela.
Esta etapa exige que você selecione a fonte da regra de acesso, e no caso da regra de perímetro de acesso, será necessário selecionar o objeto de rede externa clicando em Adicionar e selecionando-o na pasta redes. Em seguida, clique em Fechar e, em seguida, Avançar para mover para o destino de regra de acesso tela. Nessa tela clique em Adicionar e selecione o objeto de computador do perímetro de acesso criado anteriormente na pasta computadores. Clique no botão Fechar e, em seguida, Avançar para mover para os conjuntos de usuário tela.
Deixe a seleção de padrão de conjunto de todos os usuários e clique em Next. Revise o resumo e clique em Concluir para concluir o processo. Agora você pode criar as duas regras de acesso restantes usando as informações que você compilou com base na Figura 8 . Verifique se que você aplicar essas alterações para o ISA Server depois que terminar.

Uma palavra sobre certificados
As últimos etapas desse processo configuração estão concentradas no criação do ouvinte SSL e criar o proxy reverso (publicação de um aplicativo da Web) para o Office Communications Server. É importante compreender os requisitos de certificado do Office Communications Server e o impactam esses requisitos de configuração do ISA Server.
O ponto mais importante observar aqui é que o Office Communications Server requer o uso de certificados x.509 e não oferece suporte certificados curinga no nome comum (nome de entidade). Você precisará especificar um nome alternativo de assunto (SAN) quando solicitar o certificado para os servidores de borda.
Como o ISA Server 2006 SP1 introduzido suporte completo para certificados de SAN, isso não apresentará quaisquer problemas. Com isso em mente, você precisa atender os requisitos de certificado para as interfaces internas e externas do servidor de borda. Se seu ambiente do Active Directory não usar um espaço para nome de domínio de nível superior, você precisará usar um certificado de uma confiável terceiros (autoridade de certificação) para a interface externa e um certificado de uma autoridade de certificação corporativa interna para as interfaces internas. Nessa situação, o certificado raiz para sua empresa que autoridade de certificação deve ser instalada na clientes que acessarem OCS internamente assim como no ISA Server; isso garante que as relações de confiança necessário estão no local para a configuração de OCS. O certificado de terceiros externo já deve ser confiável e, portanto, o certificado raiz da autoridade de certificação terceiros não precisam ser instalados em todos os clientes.
O certificado necessário para a configuração de proxy reverso corresponde para o FQDN do OCS endereço livro e conferência conteúdo download. Na Figura 4 , isso foi ocscontent.contoso.com mas, obviamente, pode ser qualquer coisa que você escolher, desde que o certificado vem de um terceiro confiável. Obviamente, seu certificado de SAN deste terceiros também incluiria os FQDNs de seus servidores de borda, exemplos de que você também pode ver na Figura 3 .

Reverter proxy
A primeira etapa na criação de um proxy reverso para OCS é criar um ouvinte da Web do SSL. Para fazer isso, clique no recipiente de firewall no painel esquerdo e selecione a guia de caixa de ferramentas no painel de right–hand. Selecione o objeto de rede na lista, clique no botão Novo e selecione o ouvinte da Web no menu suspenso. Isso iniciará o assistente novo ouvinte da Web, que solicita que você digite um nome para o ouvinte da Web.
O nome deve ser significativo para você, mas não necessariamente não precisa ser associado a OCS quanto o ouvinte da Web potencialmente poderia ter diversos usos. Quando você clica em Next, a tela de segurança da conexão do cliente é exibida com a opção padrão selecionada — exigir SSL protegido conexões com clientes. Deixe a seleção como é e clique em Avançar para mover para a tela de endereço de IP do ouvinte da Web, onde você deve verificar a opção de redes externas. Em seguida, clique no botão Selecionar endereços de IP e escolher o endereço IP que você atribuiu ao proxy reverso (consulte a Figura 4 ).
Depois de clicar em OK e, em seguida, Avançar, você verá a tela de certificados SSL de ouvinte. Selecione a opção para atribuir um certificado para cada endereço IP e clique no botão Selecionar certificado. Agora, selecione o certificado associado ao catálogo de endereços de OCS e conteúdo de conferência da Web que foi discutido anteriormente. Depois de selecionar o certificado, clique no botão próximo para configurar definições de autenticação. Verifique se que no Authentication está marcado na caixa suspensa e, em seguida, clique no botão Avançar duas vezes. Por fim examine a tela resumo e clique em ' concluir ' para concluir a criação do ouvinte da Web.
Depois que o ouvinte da Web é criado, você pode criar a regra de publicação do site da Web. Clique para fazer isso, no recipiente de firewall e selecione a guia tarefas, clique em Publicar sites da Web para iniciar o novo Assistente regra publicação de Web. A primeira parte das informações para inserir é o nome da regra, portanto, digite um nome significativo, como conteúdo de OCS e clique em Avançar. Na tela Selecionar ação de regra, selecione Permitir e clique em Avançar para mover para a tela de tipo de publicação no qual você selecionará publicar um único site ou balanceador de carga e, em seguida, clique em Avançar.
Para configurar a segurança de conexão com servidores, selecione a opção para usar o SSL e pressione Avançar para avançar para a tela de detalhes de publicação interna. Aqui você precisará inserir o nome interno do servidor da Web componentes. Clique em Avançar e digite as informações de caminho, que devem ser / * para permitir que todos os caminhos. Clique em Avançar e digite o público nome que você criou para os downloads de conteúdo do catálogo de endereços e conferência da Web (neste exemplo é ocscontent.contoso.com). Deixe as outras seleções nos padrões e clique em Avançar.
Agora, selecione o ouvinte da Web você criou e clique em Avançar. Na tela de delegação de autenticação, a caixa suspensa deve ler sem delegação, mas cliente poderá autenticar diretamente. Clique em Next e confirme se todos os usuários está selecionado na tela User Sets, em seguida, clique em Avançar novamente e, em seguida, concluir para concluir o processo. A configuração do ISA Server agora é concluída.

Última palavras
Estendendo o Office Communications Server para oferecer suporte a usuários remotos e parceiros pode yield enorme benefícios, mas requer uma boa dose de planejamento, particularmente quando se trata proteger seus servidores de borda. O ISA Server 2006 oferece uma solução de robusta, flexível e escalonável que é a plataforma ideal para proteger o Office Communications Server 2007.

Alan Maddison é consultor sênior especializado em tecnologias da Microsoft com sistemas de negócios estratégicos, uma divisão de Brocade.

Page view tracker