Exportar (0) Imprimir
Expandir Tudo
Tópicos relacionados da Ajuda
Loading
Nenhum recurso encontrado.
Artigos de blogs relacionados
Loading
Nenhum recurso encontrado.
Expandir Minimizar

Referência de porta de rede do Exchange

Exchange 2010
 

Aplica-se a: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Tópico modificado em: 2014-09-23

Este tópico apresenta 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" após cada tabela esclarecem ou definem métodos não padrão de autenticação ou criptografia.

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

  • 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.

    ObservaçãoObservação:
    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 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.

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 Notes on Mailbox Servers 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

  • 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.

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 Notes on Client Access Servers.

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

ObservaçãoObservação:
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.

  • 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 Microsoft Exchange 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.

    ObservaçãoObservação:
    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

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.

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

  • 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.

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

  • 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.

ObservaçãoObservação:
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.
Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft