Referencia del puerto de red de Exchange

Artículo
05/20/2011

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)	Sí
De servidor de transporte de concentradores a servidor de transporte perimetral	25/TCP (SMTP)	Confianza directa	Confianza directa	Sí, mediante TLS	Sí
De servidor de transporte perimetral a servidor de transporte de concentradores	25/TCP (SMTP)	Confianza directa	Confianza directa	Sí, mediante TLS	Sí
De servidor de transporte perimetral a servidor de transporte perimetral	25/TCP SMTP	Anónimo, Certificado	Anónimo, Certificado	Sí, mediante TLS	Sí
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	Sí
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	Sí
De servidor de mensajería unificada a servidor Transporte de concentradores	25/TCP (SMTP)	Kerberos	Kerberos	Sí, mediante TLS	Sí
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)	Sí
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	Sí
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	Sí

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	Sí
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	Sí
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	Sí
Trasvase de registros	64327 (personalizable)	NTLM/Kerberos	NTLM/Kerberos	Sí	No
Inicialización	64327 (personalizable)	NTLM/Kerberos	NTLM/Kerberos	Sí	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	Sí
Acceso de servicio de topología de Microsoft Exchange Active Directory	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sí, mediante cifrado RPC	Sí
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	Sí
Acceso heredado de servicio Operador de sistema de Microsoft Exchange (como cliente MAPI)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sí, mediante cifrado RPC	Sí
Libreta de direcciones sin conexión (OAB) que accede a Active Directory	135/TCP (RPC)	Kerberos	Kerberos	Sí, mediante cifrado RPC	Sí
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	Sí
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	Sí

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	Sí
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	Sí
Servicio de disponibilidad	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	NTLM, Kerberos	Sí, mediante HTTPS	Sí
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	Sí
IMAP4	143/TCP (TLS), 993/TCP (SSL)	Básica, Kerberos	Básica, Kerberos	Sí, mediante SSL, TLS	Sí
Outlook en cualquier lugar (conocido anteriormente como RPC sobre HTTP)	80/TCP, 443/TCP (SSL)	Básico	Básico o NTLM	Sí, mediante HTTPS	Sí
Aplicación de Exchange ActiveSync	80/TCP, 443/TCP (SSL)	Básico	Básico, Certificar	Sí, mediante HTTPS	Sí
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	Sí
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	Sí
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	Sí
De servidor de acceso de cliente a servidor de acceso de cliente (servicios web de Exchange)	443/TCP (HTTPS)	Kerberos	Kerberos	Sí, mediante SSL	Sí
De servidor de acceso de cliente a servidor de acceso de cliente (POP3)	995 (SSL)	Básico	Básico	Sí, mediante SSL	Sí
De servidor de acceso de cliente a servidor de acceso de cliente (IMAP4)	993 (SSL)	Básico	Básico	Sí, mediante SSL	Sí

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	Sí
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	Sí
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	Sí
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	Sí
De servidor de mensajería unificada a servidor Transporte de concentradores	25/TCP (TLS)	Kerberos	Kerberos	Sí, mediante TLS	Sí
De servidor de mensajería unificada a servidor de buzones	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sí, mediante cifrado RPC	Sí

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.