Referencia del puerto de red de Exchange

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2016-11-28

En este tema se proporciona información sobre los puertos, la autenticación y el cifrado de todas las rutas de acceso a datos que usa MicrosoftExchange Server 2010. Las secciones de notas que vienen después de cada tabla clarifican o definen métodos de cifrado o autenticación que no son estándar.

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 acceso a datos entre estos servidores de transporte, así como de otros servidores y servicios de Exchange 2010.

Rutas de datos de servidores de transporte

Notas sobre servidores de transporte

• Todo el tráfico entre servidores Transporte de concentradores está cifrado mediante TLS con certificados autofirmados que se instalan con el programa 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 recomendamos que haga esto 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 EdgeSync de MicrosoftExchange actualiza AD LDS junto 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 habilita de forma predeterminada. Esto permite a cualquier sistema de envío cifrar la sesión SMTP entrante para Exchange. También de forma predeterminada, Exchange 2010 intenta una 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 MicrosoftOutlook 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 un mínimo de 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 como servidor Transporte perimetral. Por lo tanto, no se requiere comunicación remota. Una vez que se ha instalado y configurado el filtrado de destinatarios en el servidor Transporte de concentradores, el filtrado de destinatarios obtiene acceso a Active Directory.

• La característica de reputación del remitente en Exchange 2010 utiliza 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 de correo no deseado usan dichos datos como agregación de lista segura y datos del destinatario para filtrado de destinatarios. Estos datos se reúnen, almacenan sólo en el equipo local, y se pueden acceder a ellos desde dicho equipo. Frecuentemente, los datos se envían al directorio AD LDS local usando el servicio MicrosoftExchange 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. Tienen acceso 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 uso de la autenticación NTLM o de Kerberos en servidores Buzón de correo depende del usuario o el contexto de procesos en el que se ejecute el cliente del nivel empresarial lógico de Exchange. En este contexto, el cliente es cualquier aplicación o proceso que utiliza el nivel empresarial lógico 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

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 también 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 de puertos, autenticación y 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

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 que está ejecutando MicrosoftExchange Server 2003, se aconseja 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 de Windows integrada tiene que estar habilitada en el directorio virtual Microsoft-Server-ActiveSync en el servidor back-end de Exchange 2003. Para usar el Administrador del sistema de Exchange en un servidor Exchange 2003 para administrar una autenticación en el 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 id. de evento 1036 ha iniciado sesión en un servidor Exchange 2007 con función CAS cuando los dispositivos móviles se conectan al servidor Exchange 2007 para obtener acceso a buzones de un servidor back-end de Exchange 2003.

  Nota

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

• Cuando un servidor de acceso de cliente envía solicitudes POP3 a otro servidor de acceso de cliente, la comunicación se produce a través del puerto 995/TCP. Esto es así independientemente de si el cliente que se conecta usa POP3 y solicita TLS (en puerto 110/TCP) o conecta un puerto 995/TCP usando SSL. De forma similar, en el caso de conexiones IMAP4, el servidor solicitante 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

Conectividad del servidor de acceso de clientes

Además de tener un servidor de acceso de clientes en cada sitio de Active Directory que contenga un servidor de buzones, es importante evitar la restricción del tráfico entre servidores Exchange. Asegúrese de que todos los puertos definidos que utilice Exchange estén abiertos en ambas direcciones entre todos los servidores de origen y de destino. No se admite la instalación de un firewall entre servidores de Exchange o entre un servidor de buzones de correo de Exchange 2010 o un servidor de acceso de cliente de Active Directory. Sin embargo, puede instalar un dispositivo de red si el tráfico no está restringido y están abiertos todos los puertos disponibles entre los distintos servidores de Exchange y Active Directory.

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

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 protegido) o en el puerto 5061/TCP (protegido) 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.

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, 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 luego 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.

• Muchos servicios de Exchange utilizan llamadas a procedimiento remoto (RPC) para 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.

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.

 © 2010 Microsoft Corporation. Reservados todos los derechos.