Puertos de red de Exchange Server 2010

Puertos de red de Exchange Server 2010

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.
    Bb331973.note(es-ES,EXCHG.141).gifNota:
    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
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 que accede a OAB 80/TCP, 443/TCP (SSL) NTLM/Kerberos NTLM/Kerberos Sí, mediante HTTPS No
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
Acceso de Office Communications Server al servidor de acceso de cliente (si está habilitada la integración de Office Communications Server y Outlook Web App) 5075-5077/TCP (entrada), 5061/TCP (salida) mTLS (requerido) mTLS (requerido) Sí, mediante SSL
Bb331973.note(es-ES,EXCHG.141).gifNota:
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.
    Bb331973.note(es-ES,EXCHG.141).gifNota:
    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, vea Firewall de Windows con seguridad avanzada e IPsec.

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.

 

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s