Compartir a través de


Referencia del puerto de red de Exchange

Se aplica a: Exchange Server 2010

Última modificación del tema: 2010-01-26

En este tema se proporciona información sobre puertos, autenticación y cifrado para todas las rutas de datos que usa Microsoft Exchange Server 2010. En la sección Notas que sigue a cada tabla se aclaran o se definen la autenticación no estándar o los métodos de cifrado.

Servidores de transporte

Exchange 2010 incluye dos roles de servidor que realizan la tarea de transportar mensajes: el servidor de transporte de concentradores y el servidor de transporte perimetral

En la tabla siguiente se ofrece información sobre puertos, autenticación y cifrado de rutas de datos entre estos servidores de transporte, así como de otros servidores y servicios de Exchange 2010.

Rutas de datos de servidores de transporte

Ruta de datos Puertos necesarios Autenticación predeterminada Autenticación admitida ¿Se admite el cifrado? ¿Se cifra de forma predeterminada?

De servidor de transporte perimetral a servidor de transporte perimetral

25/TCP (SMTP)

Kerberos

Kerberos

Sí, mediante la Seguridad de la capa de transporte (TLS)

De servidor de transporte de concentradores a servidor de transporte perimetral

25/TCP (SMTP)

Confianza directa

Confianza directa

Sí, mediante TLS

De servidor de transporte perimetral a servidor de transporte de concentradores

25/TCP (SMTP)

Confianza directa

Confianza directa

Sí, mediante TLS

De servidor de transporte perimetral a servidor de transporte perimetral

25/TCP SMTP

Anónimo, Certificado

Anónimo, Certificado

Sí, mediante TLS

De servidor de buzones a servidor de transporte perimetral a través del Servicio de entrega de correo de Microsoft Exchange

135/TCP (RPC)

NTLM. Si las funciones del servidor Transporte de concentradores y Buzón de correo están en el mismo servidor, se usa Kerberos.

NTLM/Kerberos

Sí, mediante cifrado RPC

De servidor de transporte de concentradores a servidor de buzones a través de MAPI

135/TCP (RPC)

NTLM. Si las funciones del servidor Transporte de concentradores y Buzón de correo están en el mismo servidor, se usa Kerberos.

NTLM/Kerberos

Sí, mediante cifrado RPC

De servidor de mensajería unificada a servidor Transporte de concentradores

25/TCP (SMTP)

Kerberos

Kerberos

Sí, mediante TLS

Servicio Microsoft Exchange EdgeSync de servidor Transporte de concentradores a servidor Transporte perimetral

50636/TCP (SSL)

Básico

Básico

Sí, mediante LDAP sobre SSL (LDAPS)

Acceso a Active Directory desde el servidor Transporte de concentradores

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Sí, mediante cifrado Kerberos

Acceso a Active Directory Rights Management Services (AD RMS) desde un servidor Transporte de concentradores

443/TCP (HTTPS)

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante SSL

Sí*

De clientes SMTP a servidor Transporte de concentradores (por ejemplo, usuarios finales que usan Windows Live Mail)

587 (SMTP)

25/TCP (SMTP)

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante TLS

Notas sobre servidores de transporte

  • Todo el tráfico entre los servidores Transporte de concentradores está cifrado mediante TLS con certificados autofirmados que se instalan durante el proceso de instalación de Exchange 2010.

    Nota

    En Exchange 2010, se puede deshabilitar el servicio TLS en servidores Transporte de concentradores cuando se produce comunicación SMTP interna con otros servidores Transporte de concentradores en la misma organización de Exchange. No se recomienda hacerlo a menos que sea absolutamente necesario. Para obtener más información, consulte Deshabilitar TLS entre sitios de Active Directory para permitir la optimización de WAN.

  • Todo el tráfico entre servidores de transporte perimetral y servidores de transporte de concentradores está autenticado y cifrado. La autenticación TLS mutua es el mecanismo subyacente de autenticación y cifrado. En lugar de usar la validación X.509, Exchange 2010 usa la confianza directa para autenticar los certificados. Confianza directa significa que el certificado queda validado por su presencia en Active Directory o Active Directory Lightweight Directory Services (AD LDS). Active Directory se considera un mecanismo de almacenamiento de confianza. Si se usa la confianza directa, da igual que el certificado tenga una firma personal o esté firmado por una entidad de certificación. Al suscribir un servidor de transporte perimetral a la organización de Exchange, la suscripción perimetral publica el certificado del servidor de transporte perimetral en Active Directory para que se validen los servidores de transporte de concentradores. El servicio Microsoft Exchange Edgesync actualiza AD LDS con el conjunto de certificados de servidor Transporte de concentradores para que lo valide el servidor Transporte perimetral.

  • EdgeSync usa una conexión LDAP segura entre el servidor Transporte de concentradores y los servidores Transporte perimetral suscritos a través de TCP 50636. AD LDS también escucha en TCP 50389. Las conexiones a este puerto no usan SSL. Puede usar las utilidades LDPA para conectarse al puerto y comprobar los datos AD LDS.

  • De forma predeterminada, el tráfico entre los servidores de transporte perimetral en dos organizaciones diferentes está cifrado. La instalación de Exchange 2010 crea un certificado autofirmado y la TLS se activa de forma predeterminada. Esto permite a cualquier sistema de envío cifrar la sesión SMTP entrante para Exchange. De forma predeterminada, Exchange 2010 intenta también la TLS para todas las conexiones remotas.

  • Los métodos de autenticación para el tráfico entre servidores Transporte de concentradores y los servidores de buzones de correo difieren cuando los roles de servidor Transporte de concentradores y los roles de servidor Buzón de correo están instalados en el mismo equipo. Cuando la entrega de correo es local, se usa la autenticación Kerberos. Cuando la entrega de correo es remota, se usa la autenticación NTLM.

  • Exchange 2010 admite también la seguridad de dominio. La seguridad de dominio se refiere al conjunto de funcionalidades de Exchange 2010 y Microsoft Outlook 2010 que proporciona una alternativa económica a S/MIME u otras soluciones de seguridad para mensajes en Internet. La seguridad de dominio proporciona un modo de administrar rutas de mensajes seguras entre dominios en Internet. Una vez configuradas estas rutas de mensajes seguras, los mensajes que han viajado correctamente a través de la ruta segura desde un remitente autenticado se muestran a los usuarios de Outlook y Outlook Web Access como "dominio seguro". Para obtener más información, consulte Descripción de la seguridad de dominio.

  • Muchos agentes pueden ejecutarse en servidores Transporte de concentradores y servidores Transporte perimetral. Normalmente, los agentes contra correo no deseado confían en la información local del equipo en el que se ejecutan los agentes. Por lo tanto, se requiere poca comunicación con los equipos remotos. El filtrado de destinatarios es la excepción. El filtrado de destinatarios requiere llamadas a AD LDS o Active Directory. Se recomienda ejecutar el filtrado de destinatarios en el servidor Transporte perimetral. En este caso, el directorio AD LDS está en el mismo equipo que el servidor Transporte perimetral, por lo que no se requiere una comunicación remota. Una vez que se ha instalado y configurado el filtrado de destinatarios en el servidor de transporte de concentradores, el filtrado de destinatarios obtiene acceso a Active Directory.

  • La característica de reputación del remitente de Exchange 2010 usa el agente de análisis de protocolo. Este agente realiza también varias conexiones a servidores proxy externos para determinar las rutas de mensajes entrantes para conexiones sospechosas.

  • Todas las demás funciones contra correo electrónico no deseado usan datos recopilados, almacenados y a los que se obtiene acceso sólo en el equipo local. Con frecuencia, los datos como la agregación de listas seguras o los datos de destinatarios para el filtrado de destinatarios, se trasladan al directorio de AD LDS local mediante el servicio Microsoft Exchange EdgeSync.

  • Los agentes de Information Rights Management (IRM) en servidores Transporte de concentradores establecen conexiones con los servidores de Active Directory Rights Management Services (AD RMS) de la organización. AD RMS es un servicio web protegido mediante SSL, que se considera la mejor solución. La comunicación con los servidores AD RMS se produce a través de HTTPS, y se usa autenticación Kerberos o NTLM, según la configuración del servidor AD RMS.

  • Las reglas de diario, las reglas de transporte y las clasificaciones de mensajes se almacenan en Active Directory y pueden acceder a ellas el agente de registro en diario y el agente de reglas de transporte de los servidores Transporte de concentradores.

Servidores de buzones de correo

El hecho de que se use autenticación NTLM o Kerberos para servidores de buzones de correo depende del usuario o del contexto del proceso en el que se esté ejecutando el cliente del nivel de lógica de negocios de Exchange. En este contexto, se denomina cliente a cualquier aplicación o proceso que usa el nivel de lógica de negocios de Exchange. Por lo tanto, en muchas de las entradas de la columna Autenticación predeterminada de la tabla Rutas de datos de servidores de buzones aparece NTLM/Kerberos.

El nivel empresarial lógico de Exchange se usa para obtener acceso a y comunicarse con el almacén de Exchange. El nivel empresarial lógico de Exchange también se llama desde el almacén de Exchange para comunicarse con aplicaciones y procesos externos.

Si el cliente del nivel empresarial lógico de Exchange se está ejecutando como sistema local, el método de autenticación siempre es Kerberos desde el cliente hasta el almacén de Exchange. Se usa Kerberos porque el cliente debe ser autenticado mediante la cuenta de equipo de sistema local y debe existir una confianza autenticada bidireccional.

Si el cliente del nivel de lógica de negocios de Exchange no se está ejecutando como sistema local, el método de autenticación es NTLM. Por ejemplo, se usa NTLM cuando se ejecuta un cmdlet del Shell de administración de Exchange que usa el nivel de lógica de negocios de Exchange.

El tráfico RPC siempre está cifrado.

En la tabla siguiente se ofrece información acerca de puertos, autenticación y cifrado para rutas de datos, así como para y desde servidores de buzones.

Rutas de datos de servidores de buzones

Ruta de datos Puertos necesarios Autenticación predeterminada Autenticación admitida ¿Se admite el cifrado? ¿Se cifra de forma predeterminada?

Acceso de Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Sí, mediante cifrado Kerberos

Acceso remoto de administrador (Registro remoto)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante IPsec

No

Acceso remoto de administrador (SMB/archivo)

445/TCP (SMB)

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante IPsec

No

Servicio de Web de disponibilidad (Acceso de cliente a buzón)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante cifrado RPC

Organización por clústeres

135/TCP (RPC) Consulte el tema Notas sobre servidores de buzones tras esta tabla.

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante IPsec

No

Indización de contenido

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante cifrado RPC

Trasvase de registros

64327 (personalizable)

NTLM/Kerberos

NTLM/Kerberos

No

Inicialización

64327 (personalizable)

NTLM/Kerberos

NTLM/Kerberos

No

Copia de seguridad de Servicio de instantáneas de volumen (VSS)

Bloqueo de mensajes local (SMB)

NTLM/Kerberos

NTLM/Kerberos

No

No

Asistentes de buzones

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

No

No

Acceso MAPI

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante cifrado RPC

Acceso de servicio de topología de Microsoft Exchange Active Directory

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante cifrado RPC

Acceso heredado de servicio Operador de sistema de Microsoft Exchange (escuchar las convocatorias)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

No

No

Acceso heredado de servicio Operador de sistema de Microsoft Exchange para Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Sí, mediante cifrado Kerberos

Acceso heredado de servicio Operador de sistema de Microsoft Exchange (como cliente MAPI)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante cifrado RPC

Libreta de direcciones sin conexión (OAB) que accede a Active Directory

135/TCP (RPC)

Kerberos

Kerberos

Sí, mediante cifrado RPC

Outlook que accede a OAB

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante HTTPS

No

Acceso de servicio de actualización de destinatarios RPC

135/TCP (RPC)

Kerberos

Kerberos

Sí, mediante cifrado RPC

Actualización de destinatarios para Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Sí, mediante cifrado Kerberos

Notas sobre servidores de buzones

  • La ruta de datos de clúster que aparece en la tabla anterior usa RPC dinámico a través de TCP para comunicar el estado del clúster y la actividad entre los diferentes nodos del clúster. El servicio de clúster (ClusSvc.exe) usa también UDP/3343 y puertos TCP superiores asignados aleatoriamente para comunicarse entre nodos de clústeres.
  • Para comunicaciones entre nodos, los nodos en clúster se comunican a través de Protocolo de datagramas de usuario (UDP) puerto 3343. Cada nodo del clúster cambia periódicamente los datagramas UDP de unidifusión secuenciados con todos los demás nodos del clúster. El propósito de este cambio es determinar si todos los nodos se están ejecutando correctamente y supervisar el estado de los vínculos de red.
  • El puerto 64327/TCP es el puerto predeterminado que se usa para el trasvase de registros. Los administradores pueden especificar un puerto diferente para el trasvase de registros.
  • Para la autenticación HTTP en la que se indica Negociar, en primer lugar se intenta Kerberos y, a continuación, NTLM.

Servidores de acceso de cliente

A no ser que se indique, las tecnologías de acceso de cliente, tales como Outlook Web App, POP3 o IMAP4, se describen mediante la autenticación y cifrado de la aplicación cliente al servidor de acceso de cliente.

En la tabla siguiente se ofrece información acerca del puerto, la autenticación y el cifrado para rutas de datos entre servidores de acceso de cliente y otros servidores y clientes.

Rutas de datos del servidor de acceso de cliente

Ruta de datos Puertos necesarios Autenticación predeterminada Autenticación admitida ¿Se admite el cifrado? ¿Se cifra de forma predeterminada?

Acceso de Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Sí, mediante cifrado Kerberos

Servicio Detección automática

80/TCP, 443/TCP (SSL)

Autenticación de Windows integrada/básica (Negociar)

Básico, Digest, NTLM, Negociar (Kerberos)

Sí, mediante HTTPS

Servicio de disponibilidad

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM, Kerberos

Sí, mediante HTTPS

Outlook Web App

80/TCP, 443/TCP (SSL)

Autenticación basada en formularios

Básico, Digest, Autenticación basada en formularios, NTLM (sólo v2), Kerberos, Certificar

Sí, mediante HTTPS

Sí, mediante un certificado autofirmado

POP3

110/TCP (TLS), 995/TCP (SSL)

Básica, Kerberos

Básica, Kerberos

Sí, mediante SSL, TLS

IMAP4

143/TCP (TLS), 993/TCP (SSL)

Básica, Kerberos

Básica, Kerberos

Sí, mediante SSL, TLS

Outlook en cualquier lugar (conocido anteriormente como RPC sobre HTTP)

80/TCP, 443/TCP (SSL)

Básico

Básico o NTLM

Sí, mediante HTTPS

Aplicación de Exchange ActiveSync

80/TCP, 443/TCP (SSL)

Básico

Básico, Certificar

Sí, mediante HTTPS

De servidor de acceso de cliente a servidor de mensajería unificada

5060/TCP, 5061/TCP, 5062/TCP, un puerto dinámico

Mediante dirección IP

Mediante dirección IP

Sí, mediante Protocolo de inicio de sesión (SIP) sobre TLS

De servidor de acceso de cliente a un servidor de buzones que ejecute una versión anterior de Exchange Server

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

Negociar (Kerberos con retroceso a NTLM o Básico opcionalmente,) POP/IMAP texto sin formato

Sí, mediante IPsec

No

De servidor de acceso de cliente a servidor de buzones de correo de Exchange 2010

RPC. Consulte Notas sobre servidores de acceso de cliente.

Kerberos

NTLM/Kerberos

Sí, mediante cifrado RPC

De servidor de acceso de cliente a servidor de acceso de cliente (Exchange ActiveSync)

80/TCP, 443/TCP (SSL)

Kerberos

Kerberos, Certificar

Sí, mediante HTTPS

Sí, mediante un certificado autofirmado

De servidor de acceso de cliente a servidor de acceso de cliente (Outlook Web Access)

80/TCP, 443/TCP (HTTPS)

Kerberos

Kerberos

Sí, mediante SSL

De servidor de acceso de cliente a servidor de acceso de cliente (servicios web de Exchange)

443/TCP (HTTPS)

Kerberos

Kerberos

Sí, mediante SSL

De servidor de acceso de cliente a servidor de acceso de cliente (POP3)

995 (SSL)

Básico

Básico

Sí, mediante SSL

De servidor de acceso de cliente a servidor de acceso de cliente (IMAP4)

993 (SSL)

Básico

Básico

Sí, mediante SSL

Nota

La autenticación integrada de Windows (NTLM) no es compatible con la conectividad de cliente POP3 o IMAP4. Para obtener más información, consulte las secciones "Características de acceso de cliente" en Características suprimidas y funciones que ya no destacan.

Notas sobre servidores de acceso de cliente

  • En Exchange 2010, los clientes MAPI como Microsoft Outlook se conectan a servidores de acceso de cliente.

  • Los servidores de acceso de cliente usan muchos puertos para comunicarse con servidores de buzones de correo. Con algunas excepciones, estos puertos los determina el servicio RPC y no son fijos.

  • Para la autenticación HTTP en la que se indica Negociar, en primer lugar se intenta Kerberos y, a continuación, NTLM.

  • Cuando un servidor de acceso de cliente de Exchange 2010 se comunica con un servidor de buzones de correo que ejecuta Exchange Server 2003, se recomienda usar Kerberos y deshabilitar la autenticación NTLM y la autenticación básica. Asimismo, se recomienda configurar Outlook Web App para que use autenticaciones basadas en formularios con un certificado de confianza. Para que los clientes de Exchange ActiveSync se comuniquen a través del servidor de acceso de cliente de Exchange 2010 con el servidor back-end de Exchange 2003, la autenticación integrada de Windows debe estar habilitada en el directorio virtual Microsoft-Server-ActiveSync del servidor back-end de Exchange 2003. Para usar el Administrador del sistema de Exchange en un servidor de Exchange 2003 para administrar la autenticación en un directorio virtual de Exchange 2003, descargue e instale la revisión a la que se hace referencia en el artículo 937031 de Microsoft Knowledge Base, El identificador de evento 1036 está registrado en un servidor de Exchange 2007 que ejecuta la directiva de seguridad de acceso al código (CAS) cuando los dispositivos móviles se conectan al servidor de Exchange 2007 para obtener acceso a los buzones de correo de un servidor back-end de Exchange 2003.

    Nota

    Aunque el artículo de Knowledge Base se refiere específicamente a Exchange 2007, también es aplicable a Exchange 2010.

  • Cuando un servidor de acceso de cliente manda solicitudes POP3 a otro servidor de acceso de cliente, la comunicación se realiza a través del puerto 995/TCP, al margen de si el cliente que se conecta usa POP3 y solicita TLS (en el puerto 110/TCP) o se conecta al puerto 995/TCP mediante SSL. De forma similar, en el caso de conexiones IMAP4, se usa el puerto 993/TCP para mandar solicitudes, al margen de si el cliente que se conecta usa IMAP4 y solicita TLS (en el puerto 443/TCP) o se conecta al puerto 995 mediante IMAP4 con cifrado SSL.

Servidores de mensajería unificada

Las puertas de enlace IP PBX solo admiten la autenticación basada en certificados que use TLS mutua para el cifrado de tráfico SIP y autenticación basada en IP para conexiones del Protocolo de inicio de sesión (SIP)/TCP. Las puertas de enlace IP no admiten la autenticación NTLM ni Kerberos. Por lo tanto, cuando use una autenticación basada en IP, se usa la dirección o direcciones IP de conexión para ofrecer un mecanismo de autenticación para conexiones (TCP) no cifradas. Cuando se usa una autenticación basada en IP en mensajería unificada, el servidor de mensajería unificada comprueba que la dirección IP tiene permiso para conectarse. La dirección IP se configura en la puerta de enlace IP o en la IP PBX.

Las puertas de enlace IP y IP PBX admiten autenticación TLS mutua para cifrar el tráfico SIP. Una vez que haya importado y exportado correctamente los certificados de confianza necesarios, la puerta de enlace IP o IP PBX solicitará un certificado al servidor de mensajería unificada, que a su vez solicitará un certificado a la puerta de enlace IP o IP PBX. El intercambio de certificados de confianza entre la puerta de enlace IP o IP PBX y el servidor de mensajería unificada permite que la puerta de enlace IP o IP PBX y el servidor de mensajería unificada se comuniquen a través de una conexión cifrada mediante autenticación TLS mutua.

En la tabla siguiente se ofrece información acerca del puerto, la autenticación y el cifrado de rutas de datos entre servidores de mensajería unificada y otros servidores.

Rutas de datos de los servidores de mensajería unificada

Ruta de datos Puertos necesarios Autenticación predeterminada Autenticación admitida ¿Se admite el cifrado? ¿Se cifra de forma predeterminada?

Acceso de Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Sí, mediante cifrado Kerberos

Interacción telefónica de mensajería unificada (IP/PBX VoIP Gateway)

5060/TCP , 5065/TCP, 5067/TCP (no seguros), 5061/TCP, 5066/TCP, 5068/TCP (seguros), un intervalo de puerto dinámico 16000-17000/TCP (control), puertos UDP dinámicos del intervalo 1024-65535/UDP (RTP)

Mediante dirección IP

Mediante dirección IP, MTLS

Sí, mediante SIP/TLS, SRTP

No

Servicio Web de mensajería unificada

80/TCP, 443/TCP (SSL)

Autenticación de Windows integrada (Negociar)

Básico, Digest, NTLM, Negociar (Kerberos)

Sí, mediante SSL

De servidor de mensajería unificada a servidor de acceso de cliente

5075, 5076, 5077 (TCP)

Autenticación integrada de Windows (Negociar)

Básico, Digest, NTLM, Negociar (Kerberos)

Sí, mediante SSL

De servidor de mensajería unificada a servidor de acceso de cliente (Reproducir en teléfono)

RPC dinámica

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante cifrado RPC

De servidor de mensajería unificada a servidor Transporte de concentradores

25/TCP (TLS)

Kerberos

Kerberos

Sí, mediante TLS

De servidor de mensajería unificada a servidor de buzones

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Sí, mediante cifrado RPC

Notas sobre servidores de mensajería unificada

  • Cuando cree un objeto de puerta de enlace IP de mensajería unificada (UM) en Active Directory, debe definir la dirección IP de la puerta de enlace IP física o IP PBX (central de conmutación). Cuando defina la dirección IP en el objeto de puerta de enlace IP de mensajería unificada, la dirección IP se agrega a una lista de puertas de enlace IP válidas o IP PBX (también denominadas interlocutores SIP) con las que puede comunicarse el servidor de mensajería unificada. Cuando se crea una puerta de enlace IP de mensajería unificada, se puede asociar a un plan de marcado de mensajería unificada. La asociación de la puerta de enlace IP de mensajería unificada con un plan de marcado permite a los servidores de mensajería unificada asociados con el plan de marcado usar la autenticación basada en IP para comunicarse con la puerta de enlace IP. Si la puerta de enlace IP de mensajería unificada no se ha creado o no está configurada para usar la dirección IP correcta, se produce un error de autenticación y los servidores de mensajería unificada no aceptan conexiones desde esa dirección IP de la puerta de enlace IP. Además, cuando se implementa la autenticación TLS mutua, una puerta de enlace IP o IP PBX y servidores de mensajería unificada, la puerta de enlace IP de mensajería unificada debe configurarse usando el nombre de dominio completo (FQDN). Tras configurar una puerta de enlace de mensajería unificada con un FQDN, deberá agregar también un registro de host a la zona de búsqueda directa de DNS para dicha puerta.
  • En Exchange 2010, un servidor de mensajería unificada se puede comunicar en el puerto 5060/TCP (no seguro) o en el puerto 5061/TCP (seguro) y, a continuación, configurarse para usar ambos puertos.

Para obtener más información, consulte Descripción de la seguridad de la mensajería unificada VoIP y Descripción de protocolos, puertos y servicios de mensajería unificada.

Reglas de Firewall de Windows creadas por el programa de instalación de Exchange 2010

El Firewall de Windows con seguridad avanzada es un firewall con estado y basado en host que filtra el tráfico entrante y saliente según las reglas del firewall. El programa de instalación de Exchange 2010 crea las reglas del Firewall de Windows para abrir los puertos necesarios para la comunicación entre servidor y cliente en cada rol de servidor. Por lo tanto, ya no necesita usar el asistente para configuración de seguridad (SCW) para configurar estos parámetros. Para obtener más información sobre el Firewall de Windows con seguridad avanzada, consulte Guía básica del Firewall de Windows con seguridad avanzada.

En esta tabla se muestran las reglas de Firewall de Windows que se crean durante la instalación de Exchange, incluidos los puertos que se abren en cada rol de servidor. Puede ver estas reglas si una el Firewall de Windows con un complemento MMC de seguridad avanzada.

Nombre de regla Roles de servidor Puerto Programa

MSExchangeADTopology - RPC (TCP-In)

Acceso de clientes, Transporte de concentradores, Buzón de correo, Mensajería unificada

RPC dinámica

Bin\MSExchangeADTopologyService.exe

MSExchangeMonitoring - RPC (TCP-In)

Acceso de clientes, Transporte de concentradores, Transporte perimetral, Mensajería unificada

RPC dinámica

Bin\Microsoft.Exchange.Management.Monitoring.exe

MSExchangeServiceHost - RPC (TCP-In)

Todos los roles

RPC dinámica

Bin\Microsoft.Exchange.ServiceHost.exe

MSExchangeServiceHost - RPCEPMap (TCP-In)

Todos los roles

RPC-EPMap

Bin\Microsoft.Exchange.Service.Host

MSExchangeRPCEPMap (GFW) (TCP-In)

Todos los roles

RPC-EPMap

Cualquiera

MSExchangeRPC (GFW) (TCP-In)

Acceso de clientes, Transporte de concentradores, Buzón de correo, Mensajería unificada

RPC dinámica

Cualquiera

MSExchange - IMAP4 (GFW) (TCP-In)

Acceso de clientes

143, 993 (TCP)

Todos

MSExchangeIMAP4 (TCP-In)

Acceso de clientes

143, 993 (TCP)

ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe

MSExchange - POP3 (FGW) (TCP-In)

Acceso de clientes

110, 995 (TCP)

Todos

MSExchange - POP3 (TCP-In)

Acceso de clientes

110, 995 (TCP)

ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe

MSExchange - OWA (GFW) (TCP-In)

Acceso de clientes

5075, 5076, 5077 (TCP)

Todos

MSExchangeOWAAppPool (TCP-In)

Acceso de clientes

5075, 5076, 5077 (TCP)

Inetsrv\w3wp.exe

MSExchangeAB-RPC (TCP-In)

Acceso de clientes

RPC dinámica

Bin\Microsoft.Exchange.AddressBook.Service.exe

MSExchangeAB-RPCEPMap (TCP-In)

Acceso de clientes

RPC-EPMap

Bin\Microsoft.Exchange.AddressBook.Service.exe

MSExchangeAB-RpcHttp (TCP-In)

Acceso de clientes

6002, 6004 (TCP)

Bin\Microsoft.Exchange.AddressBook.Service.exe

RpcHttpLBS (TCP-In)

Acceso de clientes

RPC dinámica

System32\Svchost.exe

MSExchangeRPC - RPC (TCP-In)

Acceso de clientes, Buzón de correo

RPC dinámica

Bing\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeRPC - PRCEPMap (TCP-In)

Acceso de clientes, Buzón de correo

RPC-EPMap

Bing\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeRPC (TCP-In)

Acceso de clientes, Buzón de correo

6001 (TCP)

Bing\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeMailboxReplication (GFW) (TCP-In)

Acceso de clientes

808 (TCP)

Cualquiera

MSExchangeMailboxReplication (TCP-In)

Acceso de clientes

808 (TCP)

Bin\MSExchangeMailboxReplication.exe

MSExchangeIS - RPC (TCP-In)

Buzón de correo

RPC dinámica

Bin\Store.exe

MSExchangeIS RPCEPMap (TCP-In)

Buzón de correo

RPC-EPMap

Bin\Store.exe

MSExchangeIS (GFW) (TCP-In)

Buzón de correo

6001, 6002, 6003, 6004 (TCP)

Cualquiera

MSExchangeIS (TCP-In)

Buzón de correo

6001 (TCP)

Bin\Store.exe

MSExchangeMailboxAssistants - RPC (TCP-In)

Buzón de correo

RPC dinámica

Bin\MSExchangeMailboxAssistants.exe

MSExchangeMailboxAssistants - RPCEPMap (TCP-In)

Buzón de correo

RPC-EPMap

Bin\MSExchangeMailboxAssistants.exe

MSExchangeMailSubmission - RPC (TCP-In)

Buzón de correo

RPC dinámica

Bin\MSExchangeMailSubmission.exe

MSExchangeMailSubmission - RPCEPMap (TCP-In)

Buzón de correo

RPC-EPMap

Bin\MSExchangeMailSubmission.exe

MSExchangeMigration - RPC (TCP-In)

Buzón de correo

RPC dinámica

Bin\MSExchangeMigration.exe

MSExchangeMigration - RPCEPMap (TCP-In)

Buzón de correo

RPC-EPMap

Bin\MSExchangeMigration.exe

MSExchangerepl - Copiadora de registros (TCP-In)

Buzón de correo

64327 (TCP)

Bin\MSExchangeRepl.exe

MSExchangerepl - RPC (TCP-In)

Buzón de correo

RPC dinámica

Bin\MSExchangeRepl.exe

MSExchangerepl - RPC-EPMap (TCP-In)

Buzón de correo

RPC-EPMap

Bin\MSExchangeRepl.exe

MSExchangeSearch - RPC (TCP-In)

Buzón de correo

RPC dinámica

Bin\Microsoft.Exchange.Search.ExSearch.exe

MSExchangeThrottling - RPC (TCP-In)

Buzón de correo

RPC dinámica

Bin\MSExchangeThrottling.exe

MSExchangeThrottling - RPCEPMap (TCP-In)

Buzón de correo

RPC-EPMap

Bin\MSExchangeThrottling.exe

MSFTED - RPC (TCP-In)

Buzón de correo

RPC dinámica

Bin\MSFTED.exe

MSFTED - RPCEPMap (TCP-In)

Buzón de correo

RPC-EPMap

Bin\MSFTED.exe

MSExchangeEdgeSync - RPC (TCP-In)

Transporte de concentradores

RPC dinámica

Bin\Microsoft.Exchange.EdgeSyncSvc.exe

MSExchangeEdgeSync - RPCEPMap (TCP-In)

Transporte de concentradores

RPC-EPMap

Bin\Microsoft.Exchange.EdgeSyncSvc.exe

MSExchangeTransportWorker - RPC (TCP-In)

Transporte de concentradores

RPC dinámica

Bin\edgetransport.exe

MSExchangeTransportWorker - RPCEPMap (TCP-In)

Transporte de concentradores

RPC-EPMap

Bin\edgetransport.exe

MSExchangeTransportWorker (GFW) (TCP-In)

Transporte de concentradores

25, 587 (TCP)

Cualquiera

MSExchangeTransportWorker (TCP-In)

Transporte de concentradores

25, 587 (TCP)

Bin\edgetransport.exe

MSExchangeTransportLogSearch - RPC (TCP-In)

Transporte de concentradores, Transporte perimetral, Buzón de correo

RPC dinámica

Bin\MSExchangeTransportLogSearch.exe

MSExchangeTransportLogSearch - RPCEPMap (TCP-In)

Transporte de concentradores, Transporte perimetral, Buzón de correo

RPC-EPMap

Bin\MSExchangeTransportLogSearch.exe

SESWorker (GFW) (TCP-In)

Mensajería unificada

Cualquiera

Cualquiera

SESWorker (TCP-In)

Mensajería unificada

Cualquiera

UnifiedMessaging\SESWorker.exe

UMService (GFW) (TCP-In)

Mensajería unificada

5060, 5061

Cualquiera

UMService (TCP-In)

Mensajería unificada

5060, 5061

Bin\UMService.exe

UMWorkerProcess (GFW) (TCP-In)

Mensajería unificada

5065, 5066, 5067, 5068

Cualquiera

UMWorkerProcess (TCP-In)

Mensajería unificada

5065, 5066, 5067, 5068

Bin\UMWorkerProcess.exe

UMWorkerProcess - RPC (TCP-In)

Mensajería unificada

RPC dinámica

Bin\UMWorkerProcess.exe

Notas sobre las reglas del Firewall de Windows creadas por el programa de instalación de Exchange 2010

  • En los servidores que tienen instalado Internet Information Services (IIS), Windows abre los puertos HTTP (puerto 80, TCP) y HTTPS (puerto 443, TCP). La instalación de Exchange 2010 no abre estos puertos. Por lo tanto, dichos puertos no aparecen en la tabla anterior.
  • En Windows Server 2008 y Windows Server 2008 R2, el Firewall de Windows con seguridad avanzada permite especificar el proceso o servicio para el que se abre un puerto. Esta opción es más segura porque restringe el uso del puerto al proceso o servicio especificado en la regla. El programa de instalación de Exchange crea reglas de firewall con el nombre del proceso especificado. En algunos casos, y por motivos de compatibilidad, se crea una regla adicional que no está restringida al proceso. Puede deshabilitar o quitar las reglas que no están restringidas a los procesos y mantener las reglas correspondientes restringidas a procesos, en el caso de que la implementación lo admita. Las reglas que no están restringidas a procesos se distinguen con la palabra (GFW) en el nombre de regla.
  • Hay una serie de servicios de Exchange que usan llamadas a procedimientos remotos (RPC) para establecer la comunicación. Los procesos de servidor que usan RPC se ponen en contacto con el asignador de extremos de RPC para recibir extremos dinámicos y registrarlos en la base de datos del asignador de extremos. Los clientes RPC se ponen en contacto con el asignador de extremos de RPC para determinar los extremos que usa el proceso de servidor. De forma predeterminada, el asignador de extremos de RPC escucha en el puerto 135 (TCP). Cuando se configura el Firewall de Windows para un proceso que usa RPC, el programa de instalación de Exchange 2010 crea dos reglas de firewall para dicho proceso. Una regla permite la comunicación con el asignador de extremos de RCP y la otra permite la comunicación con el extremo asignado dinámicamente. Para obtener más información acerca de RPC, consulte Funcionamiento de RPC. Para obtener más información acerca de cómo crear reglas de Firewall de Windows para RPC dinámica, consulte Permitir trafico de red entrante que use RPC dinámica.

Nota

No se pueden modificar las reglas de Firewall de Windows creadas por el programa de instalación de Exchange 2010. Si acaso, puede crear reglas personalizadas basadas en las reglas de Firewall de Windows y luego deshabilitarlas o eliminarlas.

Para obtener más información, consulte el artículo 179442 de Microsoft Knowledge Base, Cómo configurar un firewall para dominios y relaciones de confianza.