Referência de porta de rede do Exchange
Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Tópico modificado em: 2016-11-28
Este tópico apresenta informações sobre portas, autenticação e criptografia para todos os caminhos de dados usados pelo MicrosoftExchange Server 2010. As seções de "Notas" após 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 servidor de Transporte de Hub |
25/TCP (SMTP) |
Kerberos |
Kerberos |
Sim, usando TLS |
Sim |
Microsoft Serviço 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 a partir do servidor de Transporte de Hub |
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) a partir 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 recomendamos que você faça isso, a menos que seja absolutamente necessário. Para 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 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, não importa se o certificado é autoassinado ou assinado por uma autoridade de certificação (CA). Quando um servidor de Transporte de Borda é inscrito 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 porta TCP 50389. Conexões a esta porta não usam SSL. É possível 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. Também por padrão, o Exchange 2010 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 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 oferece 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 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, é necessário um mínimo de comunicação com os computadores remotos. 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. Nesse caso, o diretório do AD LDS está no mesmo computador que o servidor de Transporte de Borda. Portanto, 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 recurso de reputação do remetente no Exchange 2010 usa o agente de análise de protocolo. 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.
Todos os outros usos das funcionalidades antispam, como dados para agregação de lista segura e dados de destinatário para filtragem de destinatários. Esses dados são reunidos, armazenados e acessados somente no computador local. Frequentemente, os dados são enviados para o diretório AD LDS local, usando-se do serviço MicrosoftExchange 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 use 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 repositório do Exchange. 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á NTLM. Por exemplo, o NTLM é usado quando você executa um cmdlet do Shell de Gerenciamento do Exchange que usa a camada de Lógica Comercial do Exchange.
O tráfego RPC é sempre criptografado.
A tabela a seguir fornece informações sobre portas, autenticação e criptografia referentes aos 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 |
Clustering |
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 |
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 do 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 do cluster se comunicam através da porta 3343 UDP (User Datagram Protocol). Cada nó no cluster troca datagramas UDP unicast em sequê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 em que Negociar é listado, o Kerberos é tentado em primeiro lugar, depois o NTLM.
Servidores de Acesso para Cliente
A menos que seja observado de outra forma, tecnologias de acesso para 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 |
Serviço de Replicação de Caixa de Correio (MRS) |
808/TCP |
Kerberos/NTLM |
Kerberos, NTLM |
Sim, usando criptografia RPC |
Sim |
Outlook acessando o OAB |
80/TCP, 443/TCP (SSL) |
NTLM/Kerberos |
NTLM/Kerberos |
Sim, usando HTTPS |
Não |
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 Anywhere (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 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 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 |
Acesso do Office Communications Server ao servidor Acesso para Cliente (quando a integração do Office Communications Server e do Outlook Web App estiver habilitada) |
5075-5077/TCP (ENTRADA), 5061/TCP (SAÍDA) |
mTLS (Obrigatório) |
mTLS (Obrigatório) |
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 mais informações, consulte as seções "Recursos de Acesso para Cliente" em Recursos descontinuados.
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 estiver se comunicando com um servidor de Caixa de Correio que esteja executando o MicrosoftExchange Server 2003, é uma prática recomendada usar o Kerberos e desabilitar as autenticações NTLM e Básica. Também é prática recomendada configurar o Outlook Web App para usar autenticação baseada em formulários com um certificado confiável. Para que clientes Exchange ActiveSync se comuniquem através do servidor de Acesso para Cliente do Exchange 2010 com o servidor back-end do Exchange 2003, a Autenticação Integrada do Windows deve estar habilitada no diretório virtual do Microsoft-Server-ActiveSync no servidor back-end do Exchange 2003. Para usar o Gerenciador de 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 mencionado no artigo 937031 da Base da Dados de Conhecimento da Microsoft 937031, ID de Evento 1036 está conectada a 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 back-end Exchange 2003.
Dica
Embora o artigo da Base de Conhecimento seja específico para o MicrosoftExchange Server 2007, também é aplicável ao Exchange 2010.
Quando um servidor de Acesso para Cliente encaminha por proxy solicitações POP3 para outro servidor de Acesso para Cliente, a comunicação ocorre pela porta 995/TCP. Isso é verdade, independente de o cliente fazendo a conexão usar POP3 e solicitar TLS (na porta 110/TCP) ou se conectar na porta 995/TCP usando SSL. Similarmente, para conexões IMAP4, o servidor fazendo a solicitação usa a porta 993/TCP para solicitações de proxy independente de o cliente fazendo a conexão usar IMAP4 e solicitar TLS (na porta 443/TCP) ou se conectar na porta 995 usando IMAP4 com criptografia SSL
Conectividade do Servidor de Acesso para Cliente
Além de ter um servidor de Acesso para Cliente em cada site do Active Directory que contém um servidor de Caixa de correio, é importante evitar restrições de tráfego entre os servidores do Exchange. Certifique-se de que todas as portas definidas que sejam usadas pelo Exchange estejam abertas em ambas as direções, entre todos os servidores de origem e de destino. A instalação de um firewall entre os servidores do Exchange ou entre um servidor de Caixa de Correio ou Acesso para Cliente do Exchange 2010 e o Active Directory não é suportada. Entretanto, você pode instalar um dispositivo de rede, se o tráfego não estiver restrito e todas as portas disponíveis estiverem abertas entre os vários servidores do Exchange e o Active Directory.
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, ao 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 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, o endereço IP do gateway IP físico ou IP PBX (Private Branch eXchange) deve ser definido. 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, ele pode ser associado 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, um registro de host também deve ser adicionado à 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 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 Windows Firewall com Segurança Avançada, consulte Windows Firewall com Segurança Avançada e IPsec.
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. É possível 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 um |
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) |
All |
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) |
All |
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 |
Bin\Microsoft.Exchange.RpcClientAccess.Service.exe |
MSExchangeRPC - PRCEPMap (TCP-In) |
Acesso para Cliente, Caixa de Correio |
RPC-EPMap |
Bin\Microsoft.Exchange.RpcClientAccess.Service.exe |
MSExchangeRPC (TCP-In) |
Acesso para Cliente, Caixa de Correio |
6001 (TCP) |
Bin\Microsoft.Exchange.RpcClientAccess.Service.exe |
MSExchangeMailboxReplication (GFW) (TCP-In) |
Acesso para cliente |
808 (TCP) |
qualquer um |
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 um |
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 um |
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 um |
qualquer um |
SESWorker (TCP-In) |
Unificação de Mensagens |
qualquer um |
UnifiedMessaging\SESWorker.exe |
UMService (GFW) (TCP-In) |
Unificação de Mensagens |
5060, 5061 |
qualquer um |
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 um |
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 especificar 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. É possível desabilitar ou remover as regras que não são restritas aos processos e manter as regras correspondentes restritas aos processos, se a implantação oferece suporte para elas. As regras que não são restritas a processos são diferenciadas pela palavra (GFW) no nome da regra.
Muitos 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âmico, consulte Permitindo o Tráfego de Rede de Entrada que usa RPC Dinâmico.
Dica
Não é possível modificar as regras de Firewall do Windows criadas pela Instalação do Exchange 2010. É possível criar regras personalizadas baseadas nelas, e então desabilitá-las ou excluí-las.
Para obter mais informações, consulte o artigo 179442 da Base de Dados de Conhecimento Microsoft, Como configurar um firewall para domínios e confianças.
© 2010 Microsoft Corporation. Todos os direitos reservados.