Referência de porta de rede do Exchange

Aplica-se a: Exchange Server 2010

Tópico modificado em: 2010-01-26

Este tópico fornece informações sobre portas, autenticação e criptografia para todos os caminhos de dados usados pelo Microsoft Exchange Server 2010. As seções de Notas depois de cada tabela esclarecem ou definem métodos não-padrão de autenticação ou criptografia.

Servidores de transporte

O Exchange 2010 contém duas funções de servidor que executam a funcionalidade de transporte de mensagens: Servidores de Transporte de Hub e de Borda.

A tabela a seguir fornece informações sobre portas, autenticação e criptografia para os caminhos de dados entre esses servidores de transporte e outros servidores e serviços do Exchange 2010.

Caminhos de dados do servidor de transporte

Notas sobre os servidores de transporte

• Todo o tráfego entre os servidores de Transporte de Hub é criptografado usando TLS com certificados auto-assinados que são instalados pela Instalação do Exchange 2010.

  Dica

  No Exchange 2010, o TLS pode ser desabilitado nos servidores de Transporte de Hub para a comunicação SMTP interna com outros servidores de Transporte de Hub na mesma organização do Exchange. Não é recomendável, a menos que seja absolutamente necessário. Para obter mais informações, consulte Desabilitando TLS entre sites do Active Directory para otimização de WAN de suporte.

• Todo o tráfego entre os servidores de Transporte de Borda e de servidores de Transporte de Hub é autenticado e criptografado. O TLS mútuo é o mecanismo subjacente de autenticação e criptografia. Ao invés de usar a validação de X.509, o Exchange 2010 usa a confiança direta para autenticar os certificados. Confiança direta significa que a presença do certificado no Active Directory ou no Active Directory Lightweight Directory Services (AD LDS) age como validação para o certificado. O Active Directory é considerado um mecanismo de repositório confiável. Quando a confiança direta é usada, é indiferente se o certificado é auto-assinado ou assinado por uma autoridade de certificação (CA). Quando você inscreve um servidor de Transporte de Borda na organização do Exchange, a Inscrição de Borda publica o certificado do servidor de Transporte de Borda no Active Directory para que os servidores de Transporte de Hub o validem. O serviço Microsoft Exchange EdgeSync atualiza o AD LDS com o conjunto de certificados do servidor de Transporte de Hub para que o servidor de Transporte de Borda o valide.

• O EdgeSync usa uma conexão LDAP segura do servidor de Transporte de Hub para os servidores de Transporte de Borda assinados sobre TCP 50636. O AD LDS também escuta a TCP 50389. Conexões a esta porta não usam SSL. Você pode usar os utilitários do LDAP para se conectar à porta e verificar os dados do AD LDS.

• Por padrão, o tráfego entre os servidores de Transporte de Borda em duas organizações diferentes é criptografado. A Instalação do Exchange 2010 cria um certificado auto-assinado, e o TLS é habilitado por padrão. Isso permite que qualquer sistema de envio criptografe a sessão SMTP de entrada para o Exchange. Por padrão, o Exchange 2010 também testa o TLS em todas as conexões remotas.

• Os métodos de autenticação de tráfego entre os servidores de Transporte de Hub e de Caixa de Correio são diferentes quando as funções de servidor Transporte de Hub e Caixa de Correio estão instaladas no mesmo computador. Quando o envio de mensagens é local, a autenticação Kerberos é usada. Quando o envio de mensagens é remoto, a autenticação do NTLM é usada.

• O Exchange 2010 também oferece suporte para Segurança de Domínio. A Segurança de Domínio refere-se às funcionalidades no Exchange 2010 e no Microsoft Outlook 2010 que fornecem uma alternativa de baixo custo ao S/MIME ou outras soluções de segurança no nível de mensagens pela Internet. A Segurança de Domínio fornece uma forma de gerenciar caminhos de mensagens seguros entre domínios na Internet. Depois da configuração desses caminhos de mensagens protegidos, as mensagens que transitaram com êxito por esses caminhos a partir de um servidor autenticado são exibidas aos usuários do Outlook e do Outlook Web Access como "Domínio Seguro". Para obter mais informações, consulte Noções Básicas Sobre Segurança de Domínio.

• Vários agentes podem ser executados nos servidores de Transporte de Hub e de Transporte de Borda. Geralmente, os agentes anti-spam dependem de informações locais para o computador no qual os agentes são executados. Portanto, pouca comunicação com os computadores remotos é necessária. A filtragem de destinatários é a exceção. A filtragem de destinatários requer chamadas para o AD LDS ou o Active Directory. Como prática recomendada, execute a filtragem de destinatários no servidor de Transporte de Borda. Neste caso, o diretório do AD LDS está no mesmo computador que o servidor de Transporte de Borda e nenhuma comunicação remota é necessária. Quando a filtragem de destinatário foi instalada e configurada no servidor de Transporte de Hub, a filtragem de destinatário acessa o Active Directory.

• O agente de Análise de Protocolo é usado pelo recurso Reputação do Remetente no Exchange 2010. Esse agente também estabelece várias conexões com servidores proxy externos para determinar os caminhos de mensagem de entrada para conexões suspeitas.

• Todas as outras funcionalidades anti-spam usam os dados reunidos, armazenados e acessados somente no computador local. Frequentemente, dados como a agregação de lista segura ou dados de destinatário para a filtragem de destinatários são enviados para o diretório do AD LDS local usando o serviço Microsoft Exchange EdgeSync.

• Agentes do Gerenciamento de Direitos de Informação (IRM) nos servidores de Transporte de Hub fazem conexão com os servidores Active Directory Rights Management Services (AD RMS) na organização. AD RMS é um serviço Web protegido pelo SSL como prática recomendada. A comunicação com os servidores AD RMS ocorre usando HTTPS, e Kerberos ou NTLM é usado para autenticação, dependendo da configuração do servidor AD RMS.

• Regras de diário, regras de transporte e classificações de mensagens são armazenadas no Active Directory e acessadas pelo agente de Registro em Diário e o agente de Regras de Transporte em servidores de Transporte de Hub.

Servidores de Caixa de Correio

Se a autenticação NTLM ou Kerberos é usada para servidores de Caixa de Correio, depende do contexto do usuário ou processo em que o consumidor da Camada de Lógica Comercial do Exchange está em execução. Nesse contexto, o consumidor é qualquer aplicativo ou processo que usa a camada de Lógica Comercial do Exchange. Como resultado, muitas entradas na coluna Autenticação Padrão da tabela Caminhos de dados do servidor de Caixa de Correio são listadas como NTLM/Kerberos.

A camada de Lógica Comercial do Exchange é usada para acessar e se comunicar com o armazenamento do Exchange. A camada de Lógica Comercial do Exchange também é chamada a partir do armazenamento do Exchange para se comunicar com aplicativos e processos externos.

Se o consumidor da camada de Lógica Comercial do Exchange estiver em execução como Sistema Local, o método de autenticação será sempre Kerberos do consumidor para o armazenamento do Exchange. O Kerberos é usado porque o consumidor deve ser autenticado usando o Sistema Local da conta do computador, e deve existir a confiança autenticada bidirecional.

Se o consumidor da camada de Lógica Comercial do Exchange não estiver em execução como Sistema Local, o método de autenticação será o NTLM. Por exemplo, ao executar um cmdlet do Shell de Gerenciamento do Exchange que usa a camada de Lógica Comercial do Exchange, o NTLM é usado.

O tráfego RPC é sempre criptografado.

A tabela a seguir fornece informações sobre portas, autenticação e criptografia para os caminhos de dados para/de servidores de Caixa de Correio.

Caminhos de dados do servidor de Caixa de Correio

Notas sobre servidores de Caixa de Correio

• O caminho de dados Clustering listado na tabela anterior usa RPC dinâmico sobre TCP para comunicar o status e as atividades do cluster entre os diferentes nós de cluster. O serviço de Cluster (ClusSvc.exe) também usa a UDP/3343 e as portas TCP altas alocadas aleatoriamente, para se comunicar entre os nós do cluster.
• Para as comunicações entre nós, os nós de cluster se comunicam através da porta 3343 UDP (User Datagram Protocol). Cada nó no cluster troca datagramas UDP unicast em seqüência com cada nó alternado no cluster. A finalidade dessa troca é determinar se todos os nós estão sendo executados corretamente e monitorar a integridade dos links da rede.
• A porta 64327/TCP é a porta padrão usada para o envio de logs. Os administradores podem especificar uma porta diferente para o envio de logs.
• Para autenticação HTTP onde Negociar é listado, o Kerberos é tentado em primeiro lugar e depois o NTLM.

Servidores de Acesso para Cliente

A menos que seja observado de outra forma, tecnologias de acesso de clientes, como Outlook Web App, POP3 ou IMAP4, são descritas pela autenticação e criptografia do aplicativo cliente para o servidor de Acesso para Cliente.

A tabela a seguir fornece informações sobre portas, autenticação e criptografia para os caminhos de dados entre os servidores de Acesso para Cliente e outros servidores e clientes.

Caminhos de dados do servidor de Acesso para Cliente

Notas sobre Servidores de Acesso para Cliente

• No Exchange 2010, clientes MAPI como o Microsoft Outlook conectam-se a servidores de Acesso para Cliente.

• Os servidores de Acesso para Cliente usam várias portas para se comunicar com servidores de Caixa de Correio. Com algumas exceções, essas portas são determinadas pelo serviço RPC e não são fixas.

• Para autenticação HTTP onde Negociar é listado, o Kerberos é tentado em primeiro lugar e depois o NTLM.

• Quando um servidor de Acesso para Cliente do Exchange 2010 se comunica com um servidor de Caixa de Correio que está executando o Exchange Server 2003, é uma prática recomendada usar o Kerberos e desabilitar as autenticações NTLM e Básica. Além disso, é prática recomendada configurar o Outlook Web App para usar autenticação baseada em formulários com um certificado confiável. Para que os clientes do Exchange ActiveSync se comuniquem por meio do servidor de Acesso para Cliente do Exchange 2010 com o servidor de back-end do Exchange 2003, a Autenticação Integrada do Windows deve ser habilitada no diretório virtual do Microsoft-Server-ActiveSync no servidor de back-end do Exchange 2003. Para usar o Gerenciador do Sistema do Exchange em um servidor Exchange 2003 para gerenciar a autenticação em um diretório virtual do Exchange 2003, baixe e instale o hotfix citado no artigo 937031 da Base de Dados de Conhecimento Microsoft, O evento de ID 1036 está conectado em um servidor Exchange 2007 que está executando a função CAS quando dispositivos móveis se conectam ao servidor Exchange 2007 para acessar caixas de correio em um servidor de back-end do Exchange 2003.

  Dica

  Embora o artigo da Base de Conhecimento seja específico para o Exchange 2007, também é aplicável ao Exchange 2010.

• Quando um servidor de Acesso para Cliente envia solicitações POP3 por proxy a outro servidor de Acesso para Cliente, a comunicação ocorre sobre a porta 995/TCP, independente do cliente que está conectando usar POP3 e solicitar TLS (na porta 110/TCP) ou se conectar na porta 995/TCP usando SSL. Da mesma forma, para conexões IMAP4, a porta 993/TCP é usada para solicitações de proxy independente de o cliente que está conectando usar IMAP4 e solicitar TLS (na porta 443/TCP) ou se conectar na porta 995 usando IMAP4 com criptografia SSL.

Servidores de Unificação de Mensagens

Os gateways IP e IP PBXs só oferecem suporte para a autenticação baseada em certificados que utiliza TLS mútuo para criptografia e autenticação baseada em IP para conexões de protocolo (SIP)/TCP. Os gateways IP não oferecem suporte para a autenticação NTLM ou Kerberos. Portanto, quando você usar a autenticação baseada em IP, o endereço ou endereços IP da conexão são utilizados para oferecer o mecanismo de autenticação para as conexões (TCP) sem criptografia. Quando a autenticação baseada em IP é utilizada na Unificação de Mensagens (UM), o servidor de Unificação de Mensagens verifica se o endereço IP está autorizado a se conectar. O endereço IP é configurado no gateway IP ou no IP-PBX.

Gateways IP e IP PBXs suportam TLS mútuo para criptografar o tráfego SIP. Depois de importar e exportar com êxito os certificados confiáveis necessários, o gateway IP ou IP PBX solicitará um certificado do servidor de UM e um certificado do gateway IP ou IP PBX. Trocar os certificados confiáveis entre o gateway IP ou IP PBX e o servidor de UM permite que o gateway IP ou IP PBX e o servidor de UM se comuniquem por uma conexão criptografada usando TLS mútuo.

A tabela a seguir fornece informações sobre portas, autenticação e criptografia para os caminhos de dados entre os servidores de UM e outros servidores.

Caminhos de dados do servidor de Unificação de Mensagens

Notas sobre os Servidores de Unificação de Mensagens

• Ao criar um objeto de gateway IP da UM no Active Directory, você deve definir o endereço IP do gateway IP físico ou IP PBX (Private Branch eXchange). Ao definir o endereço IP no objeto de gateway IP da UM, esse endereço é adicionado a uma lista de gateways IP válidos ou IP PBXs (também chamados de pontos SIP), com os quais o servidor de UM está autorizado a se comunicar. Ao criar um gateway IP da UM, você pode associá-lo a um plano de discagem da UM. A associação do gateway IP do UM a um plano de discagem permite que os servidores de Unificação de Mensagens associados ao plano de discagem usem a autenticação baseada em IP para se comunicar com o gateway IP. Se o gateway IP da UM não tiver sido criado ou não estiver configurado para usar o endereço IP correto, ocorrerá falha na autenticação e os servidores de UM não aceitarão conexões provenientes do endereço IP desse gateway IP. Além disso, ao implementar o TLS mútuo e o gateway IP ou IP PBX e servidores de UM, o gateway IP da UM deve ser configurado para usar o FQDN. Depois de configurar o gateway IP da UM com um FQDN, você deve também adicionar um registro de host para a zona de pesquisa direta do DNS para o gateway IP da UM.
• No Exchange 2010, um servidor de UM pode se comunicar na porta 5060/TCP (não segura) ou na porta 5061/TCP (segura), e pode ser configurado para usar ambas.

Para obter mais informações, consulte Noções Básicas Sobre a Segurança VoIP da Unificação de Mensagens e Noções Básicas sobre Protocolos, Portas e Serviços da Unificação de Mensagens.

Regras de Firewall do Windows Criadas pela Instalação do Exchange 2010

O Firewall do Windows com Segurança Avançada é um firewall monitorador, com base em host, que filtra o tráfego de entrada e saída com base em regras de firewall. A Instalação do Exchange 2010 cria regras do Firewall do Windows para abrir as portas necessárias para a comunicação do servidor e do cliente em cada função de servidor. Portanto, não é mais necessário usar o Assistente de Configuração de Segurança (SCW) para configurar estas definições. Para saber mais sobre o Firewall do Windows com Segurança Avançada, consulte Firewall do Windows com Segurança Avançada - Mapa de Conteúdo.

Esta tabela lista as regras do Firewall do Windows criadas pela Instalação do Exchange, incluindo as portas abertas em cada função de servidor. Você pode visualizar estas regras utilizando o snap-in MMC do Firewall do Windows com Segurança Avançada.

Notas sobre Regras de Firewall do Windows Criadas pela Instalação do Exchange 2010

• Em servidores que possuem o IIS (Serviços de Informações da Internet) instalado, o Windows abre as portas HTTP (porta 80, TCP) e HTTPS (porta 443, TCP). A Instalação do Exchange 2010 não abre essas portas. Portanto, essas portas não aparecem na tabela anterior.
• No Windows Server 2008 e no Windows Server 2008 R2, o Firewall do Windows com Segurança Avançada permite que você especifique o processo ou serviço para o qual a porta é aberta. Isso é mais seguro porque restringe o uso da porta para o processo ou serviço especificado na regra. A Instalação do Exchange cria regras de firewall com o nome do processo especificado. Em alguns casos, uma regra adicional que não é restrita ao processo também é criada para fins de compatibilidade. Você pode desabilitar ou remover as regras que não são restritas aos processos e manter as regras correspondentes restritas aos processos se sua implantação oferece suporte para elas. As regras não restritas a processos são diferenciadas pela palavra (GFW) no nome da regra.
• Vários serviços do Exchange usam chamadas de procedimento remoto (RPCs) para comunicação. Os processos de servidor que usam RPCs contatam o Mapeador de Ponto de Extremidade RPC para receber pontos de extremidade dinâmicos e registrá-los no banco de dados do Mapeador de Ponto de Extremidade. Clientes RPC contatam o Mapeador de Ponto de Extremidade RPC para determinar os pontos de extremidade usados pelo processo do servidor. Por padrão, o Mapeador de Ponto de Extremidade RPC escuta na porta 135 (TCP). Ao configurar o Firewall do Windows para um processo que usa RPCs, a Instalação do Exchange 2010 cria duas regras de firewall para o processo. Um regra permite a comunicação com o Mapeador de Ponto de Extremidade RPC e a outra permite comunicação com o ponto de extremidade atribuído dinamicamente. Para saber mais sobre RPCs, consulte Como o RPC Funciona. Para mais informações sobre a criação de regras de Firewall do Windows para RPC dinâmica, consulte Permitindo o Tráfego de Rede de Entrada que usa RPC Dinâmico.

Para obter mais informações, consulte o artigo 179442 da Base de Dados de Conhecimento Microsoft, Como configurar um firewall para domínios e relações de confiança.