Referência de porta de rede do Exchange

Artigo
05/20/2011

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

Caminho de dados	Portas necessárias	Autenticação padrão	Autenticação aceita	Criptografia aceita?	Criptografado por padrão?
Servidor de Transporte de Hub para servidor de Transporte de Hub	25/TCP (SMTP)	Kerberos	Kerberos	Sim, usando o protocolo TLS (Transport Layer Security)	Sim
Servidor de Transporte de Hub para servidor de Transporte de Borda	25/TCP (SMTP)	Confiança direta	Confiança direta	Sim, usando TLS	Sim
Servidor de Transporte de Borda para servidor de Transporte de Hub	25/TCP (SMTP)	Confiança direta	Confiança direta	Sim, usando TLS	Sim
Servidor de Transporte de Borda para servidor de Transporte de Borda	25/TCP SMTP	Anônimo, Certificado	Anônimo, Certificado	Sim, usando TLS	Sim
Servidor de Caixa de Correio para servidor de Transporte de Hub através do Serviço de Envio de Mensagens do Microsoft Exchange	135/TCP (RPC)	NTLM. Se as funções de servidor Transporte de Hub e Caixa de Correio estiverem no mesmo servidor, será utilizado o Kerberos.	NTLM/Kerberos	Sim, usando criptografia RPC	Sim
Transporte de Hub para servidor de Caixa de Correio via MAPI	135/TCP (RPC)	NTLM. Se as funções de servidor Transporte de Hub e Caixa de Correio estiverem no mesmo servidor, será utilizado o Kerberos.	NTLM/Kerberos	Sim, usando criptografia RPC	Sim
Servidor de Unificação de Mensagens para o servidor de Transporte de Hub	25/TCP (SMTP)	Kerberos	Kerberos	Sim, usando TLS	Sim
O serviço Microsoft Exchange EdgeSync do servidor de Transporte de Hub para o servidor de Transporte de Borda	50636/TCP (SSL)	Básica	Básica	Sim, usando LDAP sobre SSL (LDAPS)	Sim
Acesso do Active Directory do servidor de Transporte de Borda	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)	Kerberos	Kerberos	Sim, usando criptografia Kerberos	Sim
Acesso do Active Directory Rights Management Services (AD RMS) do servidor de Transporte de Hub	443/TCP (HTTPS)	NTLM/Kerberos	NTLM/Kerberos	Sim, usando SSL	Sim*
Clientes SMTP para o servidor de Transporte de Hub (por exemplo, usuários finais usando o Windows Live Mail)	587 (SMTP) 25/TCP (SMTP)	NTLM/Kerberos	NTLM/Kerberos	Sim, usando TLS	Sim

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

Caminho de dados	Portas necessárias	Autenticação padrão	Autenticação aceita	Criptografia aceita?	Criptografado por padrão?
Acesso ao Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)	Kerberos	Kerberos	Sim, usando criptografia Kerberos	Sim
Acesso remoto de Admin. (Registro remoto)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sim, usando IPsec	Não
Acesso remoto de Admin. (SMB/Arquivo)	445/TCP (SMB)	NTLM/Kerberos	NTLM/Kerberos	Sim, usando IPsec	Não
Serviço Web de Disponibilidade (Acesso para Cliente à Caixa de Correio)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sim, usando criptografia RPC	Sim
Agrupamento	135/TCP (RPC) Consulte Notas sobre servidores de Caixa de Correio depois desta tabela.	NTLM/Kerberos	NTLM/Kerberos	Sim, usando IPsec	Não
Indexação de conteúdo	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sim, usando criptografia RPC	Sim
Envio de logs	64327 (personalizável)	NTLM/Kerberos	NTLM/Kerberos	Sim	Não
Propagação	64327 (personalizável)	NTLM/Kerberos	NTLM/Kerberos	Sim	Não
Backup do VSS (serviço de cópias de sombra de volume)	Bloco de Mensagens Locais (SMB)	NTLM/Kerberos	NTLM/Kerberos	Não	Não
Assistentes de Caixa de Correio	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Não	Não
Acesso MAPI	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sim, usando criptografia RPC	Sim
Acesso ao serviço de Topologia do Active Directory do Microsoft Exchange	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sim, usando criptografia RPC	Sim
Acesso herdado do serviço Atendedor do Sistema do Microsoft Exchange (Ouvir solicitações)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Não	Não
Acesso herdado do serviço Atendedor do Sistema do Microsoft Exchange ao Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)	Kerberos	Kerberos	Sim, usando criptografia Kerberos	Sim
Acesso herdado do serviço Atendedor do Sistema do Microsoft Exchange (como Cliente MAPI)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sim, usando criptografia RPC	Sim
Catálogo de endereços offline (OAB) acessando o Active Directory	135/TCP (RPC)	Kerberos	Kerberos	Sim, usando criptografia RPC	Sim
Outlook acessando o OAB	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	NTLM/Kerberos	Sim, usando HTTPS	Não
Acesso de RPC ao Serviço de Atualização de Destinatários	135/TCP (RPC)	Kerberos	Kerberos	Sim, usando criptografia RPC	Sim
Atualização de destinatários para o Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)	Kerberos	Kerberos	Sim, usando criptografia Kerberos	Sim

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

Caminho de dados	Portas necessárias	Autenticação padrão	Autenticação aceita	Criptografia aceita?	Criptografado por padrão?
Acesso ao Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)	Kerberos	Kerberos	Sim, usando criptografia Kerberos	Sim
serviço de Descoberta Automática	80/TCP, 443/TCP (SSL)	Autenticação do Windows Integrada/Básica (Negociar)	Básica, Resumida, NTLM, Negociar (Kerberos)	Sim, usando HTTPS	Sim
Serviço de Disponibilidade	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	NTLM, Kerberos	Sim, usando HTTPS	Sim
Outlook Web App	80/TCP, 443/TCP (SSL)	Autenticação Baseada em Formulários	Autenticação Básica, Resumida, Baseada em Formulários, NTLM (somente v2), Kerberos, Certificado	Sim, usando HTTPS	Sim, usando um certificado autoassinado
POP3	110/TCP (TLS), 995/TCP (SSL)	Básica, Kerberos	Básica, Kerberos	Sim, usando SSL, TLS	Sim
IMAP4	143/TCP (TLS), 993/TCP (SSL)	Básica, Kerberos	Básica, Kerberos	Sim, usando SSL, TLS	Sim
Outlook Em Qualquer Lugar (conhecido anteriormente como RPC sobre HTTP).	80/TCP, 443/TCP (SSL)	Básica	Básica ou NTLM	Sim, usando HTTPS	Sim
Aplicativo do Exchange ActiveSync	80/TCP, 443/TCP (SSL)	Básica	Básica, Certificado	Sim, usando HTTPS	Sim
Servidor de Acesso para Cliente para servidor de Unificação de Mensagens	5060/TCP, 5061/TCP, 5062/TCP, uma porta dinâmica	Por endereço IP	Por endereço IP	Sim, usando SIP (Session Initiation Protocol) sobre TLS	Sim
O Servidor de Acesso para Cliente para um servidor de Caixa de Correio está executando uma versão anterior do Exchange Server	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	Negociar (Kerberos com fallback para NTLM ou opcionalmente Básico,) texto sem formatação de POP/IMAP	Sim, usando IPsec	Não
Servidor de Acesso para Cliente para servidor de Caixa de Correio do Exchange 2010	RPC. Consulte Notas sobre Servidores de Acesso para Cliente.	Kerberos	NTLM/Kerberos	Sim, usando criptografia RPC	Sim
Servidor de Acesso para Cliente para o servidor de Acesso para Cliente (Exchange ActiveSync)	80/TCP, 443/TCP (SSL)	Kerberos	Kerberos, Certificado	Sim, usando HTTPS	Sim, usando um certificado autoassinado
Servidor de Acesso para Cliente para o servidor de Acesso para Cliente (Outlook Web Access)	80/TCP, 443/TCP (HTTPS)	Kerberos	Kerberos	Sim, usando SSL	Sim
Servidor de Acesso para Cliente para servidor de Acesso para Cliente (Serviços Web do Exchange)	443/TCP (HTTPS)	Kerberos	Kerberos	Sim, usando SSL	Sim
Servidor de Acesso para Cliente para servidor de Acesso para Cliente (POP3)	995 (SSL)	Básica	Básica	Sim, usando SSL	Sim
Servidor de Acesso para Cliente para servidor de Acesso para Cliente (IMAP4)	993 (SSL)	Básica	Básica	Sim, usando SSL	Sim

Dica

Não há suporte para a autenticação integrada do Windows (NTLM) para a conectividade de cliente POP3 ou IMAP4. Para obter mais informações, consulte as seções "Recursos de Acesso do Cliente" em Descontinuar recursos e desenfatizar funcionalidades.

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

Caminho de dados	Portas necessárias	Autenticação padrão	Autenticação aceita	Criptografia aceita?	Criptografado por padrão?
Acesso ao Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)	Kerberos	Kerberos	Sim, usando criptografia Kerberos	Sim
Interação do Telefone da Unificação de Mensagens (IP PBX/VoIP Gateway)	5060/TCP , 5065/TCP, 5067/TCP (não segura), 5061/TCP, 5066/TCP, 5068/TCP (segura), uma porta dinâmica do intervalo 16000-17000/TCP (controle), portas UDP dinâmicas do intervalo 1024-65535/UDP (RTP)	Por endereço IP	Por endereço IP, MTLS	Sim, usando SIP/TLS, SRTP	Não
Serviço Web de Unificação de Mensagens	80/TCP, 443/TCP (SSL)	Autenticação Integrada do Windows (Negociar)	Básica, Resumida, NTLM, Negociar (Kerberos)	Sim, usando SSL	Sim
Servidor de Unificação de Mensagens para servidor de Acesso para Cliente	5075, 5076, 5077 (TCP)	Autenticação Integrada do Windows (Negociar)	Básica, Resumida, NTLM, Negociar (Kerberos)	Sim, usando SSL	Sim
Servidor de Unificação de Mensagens para servidor de Acesso para Cliente (Tocar no Telefone)	RPC dinâmico	NTLM/Kerberos	NTLM/Kerberos	Sim, usando criptografia RPC	Sim
Servidor de Unificação de Mensagens para o servidor de Transporte de Hub	25/TCP (TLS)	Kerberos	Kerberos	Sim, usando TLS	Sim
Servidor de Unificação de Mensagens para servidor de Caixa de Correio	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sim, usando criptografia RPC	Sim

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.

Nome da regra	Funções de servidor	Porta	Programa
MSExchangeADTopology - RPC (TCP-In)	Acesso para Cliente, Transporte de Hub, Caixa de Correio e Unificação de Mensagens	RPC dinâmico	Bin\MSExchangeADTopologyService.exe
MSExchangeMonitoring - RPC (TCP-In)	Acesso para Cliente, Transporte de Hub, Transporte de Borda, Unificação de Mensagens	RPC dinâmico	Bin\Microsoft.Exchange.Management.Monitoring.exe
MSExchangeServiceHost - RPC (TCP-In)	Todas as funções	RPC dinâmico	Bin\Microsoft.Exchange.ServiceHost.exe
MSExchangeServiceHost - RPCEPMap (TCP-In)	Todas as funções	RPC-EPMap	Bin\Microsoft.Exchange.Service.Host
MSExchangeRPCEPMap (GFW) (TCP-In)	Todas as funções	RPC-EPMap	Qualquer
MSExchangeRPC (GFW) (TCP-In)	Acesso para Cliente, Transporte de Hub, Caixa de Correio e Unificação de Mensagens	RPC dinâmico	Qualquer
MSExchange - IMAP4 (GFW) (TCP-In)	Acesso para Cliente	143, 993 (TCP)	Todos
MSExchangeIMAP4 (TCP-In)	Acesso para Cliente	143, 993 (TCP)	ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
MSExchange - POP3 (FGW) (TCP-In)	Acesso para Cliente	110, 995 (TCP)	Todos
MSExchange - POP3 (TCP-In)	Acesso para Cliente	110, 995 (TCP)	ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
MSExchange - OWA (GFW) (TCP-In)	Acesso para Cliente	5075, 5076, 5077 (TCP)	Todos
MSExchangeOWAAppPool (TCP-In)	Acesso para Cliente	5075, 5076, 5077 (TCP)	Inetsrv\w3wp.exe
MSExchangeAB-RPC (TCP-In)	Acesso para Cliente	RPC dinâmico	Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RPCEPMap (TCP-In)	Acesso para Cliente	RPC-EPMap	Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RpcHttp (TCP-In)	Acesso para Cliente	6002, 6004 (TCP)	Bin\Microsoft.Exchange.AddressBook.Service.exe
RpcHttpLBS (TCP-In)	Acesso para Cliente	RPC dinâmico	System32\Svchost.exe
MSExchangeRPC - RPC (TCP-In)	Acesso para Cliente, Caixa de Correio	RPC dinâmico	Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC - PRCEPMap (TCP-In)	Acesso para Cliente, Caixa de Correio	RPC-EPMap	Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC (TCP-In)	Acesso para Cliente, Caixa de Correio	6001 (TCP)	Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeMailboxReplication (GFW) (TCP-In)	Acesso para Cliente	808 (TCP)	Qualquer
MSExchangeMailboxReplication (TCP-In)	Acesso para Cliente	808 (TCP)	Bin\MSExchangeMailboxReplication.exe
MSExchangeIS - RPC (TCP-In)	Caixa de Correio	RPC dinâmico	Bin\Store.exe
MSExchangeIS RPCEPMap (TCP-In)	Caixa de Correio	RPC-EPMap	Bin\Store.exe
MSExchangeIS (GFW) (TCP-In)	Caixa de Correio	6001, 6002, 6003, 6004 (TCP)	Qualquer
MSExchangeIS (TCP-In)	Caixa de Correio	6001 (TCP)	Bin\Store.exe
MSExchangeMailboxAssistants - RPC (TCP-In)	Caixa de Correio	RPC dinâmico	Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailboxAssistants - RPCEPMap (TCP-In)	Caixa de Correio	RPC-EPMap	Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailSubmission - RPC (TCP-In)	Caixa de Correio	RPC dinâmico	Bin\MSExchangeMailSubmission.exe
MSExchangeMailSubmission - RPCEPMap (TCP-In)	Caixa de Correio	RPC-EPMap	Bin\MSExchangeMailSubmission.exe
MSExchangeMigration - RPC (TCP-In)	Caixa de Correio	RPC dinâmico	Bin\MSExchangeMigration.exe
MSExchangeMigration - RPCEPMap (TCP-In)	Caixa de Correio	RPC-EPMap	Bin\MSExchangeMigration.exe
MSExchangerepl - Log Copier (TCP-In)	Caixa de Correio	64327 (TCP)	Bin\MSExchangeRepl.exe
MSExchangerepl - RPC (TCP-In)	Caixa de Correio	RPC dinâmico	Bin\MSExchangeRepl.exe
MSExchangerepl - RPC-EPMap (TCP-In)	Caixa de Correio	RPC-EPMap	Bin\MSExchangeRepl.exe
MSExchangeSearch - RPC (TCP-In)	Caixa de Correio	RPC dinâmico	Bin\Microsoft.Exchange.Search.ExSearch.exe
MSExchangeThrottling - RPC (TCP-In)	Caixa de Correio	RPC dinâmico	Bin\MSExchangeThrottling.exe
MSExchangeThrottling - RPCEPMap (TCP-In)	Caixa de Correio	RPC-EPMap	Bin\MSExchangeThrottling.exe
MSFTED - RPC (TCP-In)	Caixa de Correio	RPC dinâmico	Bin\MSFTED.exe
MSFTED - RPCEPMap (TCP-In)	Caixa de Correio	RPC-EPMap	Bin\MSFTED.exe
MSExchangeEdgeSync - RPC (TCP-In)	Transporte de Hub	RPC dinâmico	Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeEdgeSync - RPCEPMap (TCP-In)	Transporte de Hub	RPC-EPMap	Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportWorker - RPC (TCP-In)	Transporte de Hub	RPC dinâmico	Bin\edgetransport.exe
MSExchangeTransportWorker - RPCEPMap (TCP-In)	Transporte de Hub	RPC-EPMap	Bin\edgetransport.exe
MSExchangeTransportWorker (GFW) (TCP-In)	Transporte de Hub	25, 587 (TCP)	Qualquer
MSExchangeTransportWorker (TCP-In)	Transporte de Hub	25, 587 (TCP)	Bin\edgetransport.exe
MSExchangeTransportLogSearch - RPC (TCP-In)	Transporte de Hub, Transporte de Borda, Caixa de Correio	RPC dinâmico	Bin\MSExchangeTransportLogSearch.exe
MSExchangeTransportLogSearch - RPCEPMap (TCP-In)	Transporte de Hub, Transporte de Borda, Caixa de Correio	RPC-EPMap	Bin\MSExchangeTransportLogSearch.exe
SESWorker (GFW) (TCP-In)	Unificação de Mensagens	Qualquer	Qualquer
SESWorker (TCP-In)	Unificação de Mensagens	Qualquer	UnifiedMessaging\SESWorker.exe
UMService (GFW) (TCP-In)	Unificação de Mensagens	5060, 5061	Qualquer
UMService (TCP-In)	Unificação de Mensagens	5060, 5061	Bin\UMService.exe
UMWorkerProcess (GFW) (TCP-In)	Unificação de Mensagens	5065, 5066, 5067, 5068	Qualquer
UMWorkerProcess (TCP-In)	Unificação de Mensagens	5065, 5066, 5067, 5068	Bin\UMWorkerProcess.exe
UMWorkerProcess - RPC (TCP-In)	Unificação de Mensagens	RPC dinâmico	Bin\UMWorkerProcess.exe

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.