Referencia de puertos de red de Exchange. Conexión de clientes de correo electrónico a Microsoft Exchange Server Rutas de datos para servidores de buzones de correo
[Este artículo es un documento preliminar y puede estar sujeto a cambios en ediciones futuras. Se incluyen secciones en blanco como marcadores de posición. Si desea escribir una reseña, estaremos encantados de recibirla. Envíanoslo por correo electrónico [correo electrónico protegido].]
Se aplica a: Exchange Server 2016
Obtenga información sobre los puertos de red que utiliza Exchange 2016 para el acceso de clientes y el flujo de correo.
Este tema proporciona información sobre los puertos de red que utiliza Microsoft Exchange Server 2016 para comunicarse con clientes de correo electrónico, servidores de correo en línea y otros servicios ubicados fuera de su organización Exchange local. Antes de comenzar, considere las siguientes reglas básicas.
No admitimos la restricción o modificación del tráfico de red entre servidores Exchange internos, entre servidores Exchange internos y servidores Lync o Skype for Business internos, ni entre servidores Exchange internos y controladores de dominio internos de Active Directory en ningún tipo de topología. Si utiliza firewalls o dispositivos de red que pueden restringir o modificar este tráfico de red, debe configurar reglas para garantizar una comunicación libre y sin restricciones entre estos servidores (reglas que permiten el tráfico de red hacia y desde cualquier puerto, incluidos los puertos RPC aleatorios y cualquier protocolo. que no cambia ni un bit).
Los servidores de transporte perimetral casi siempre están ubicados en la red perimetral, por lo que se espera que el tráfico de red entre el servidor de transporte perimetral e Internet, y entre el servidor de transporte perimetral y la organización interna de Exchange, sea limitado. Estos puertos de red se describen en esta sección.
Se espera que limite el tráfico de red entre clientes y servicios externos y la organización interna de Exchange. También puede restringir el tráfico entre clientes internos y servidores Exchange internos. Estos puertos de red se describen en esta sección.
Contenido
Puertos de red necesarios para clientes y servicios.
Puertos de red necesarios para el flujo de correo (sin servidores de transporte perimetral)
Puertos de red necesarios para el flujo de correo con servidores de transporte perimetral
Puertos de red necesarios para implementaciones híbridas
Puertos de red necesarios para la mensajería unificada
Los puertos de red que los clientes de correo electrónico necesitan para acceder a los buzones y otros servicios en la organización de Exchange se describen en el siguiente diagrama y tabla.
Notas
El destino de estos clientes y servicios son los servicios de acceso de cliente en el servidor de buzones. En Exchange 2016, los servicios de acceso de cliente (front-end) y los servicios de back-end se instalan juntos en el mismo servidor de buzones. Para más información, ver .
Aunque el diagrama muestra clientes y servicios de Internet, los conceptos son los mismos para los clientes internos (por ejemplo, clientes en un bosque de cuentas que acceden a servidores Exchange en un bosque de recursos). Del mismo modo, la tabla no tiene una columna Origen porque el origen puede ser cualquier ubicación externa a la organización de Exchange (por ejemplo, Internet o un bosque de cuentas).
Los servidores Edge Transport no participan en tráfico de red asociados con estos clientes y servicios.
Los siguientes clientes y servicios utilizan conexiones web cifradas. Servicio de descubrimiento automático Intercambio ActiveSync Servicios web de intercambio (EWS) Distribución de libreta de direcciones sin conexión Outlook móvil (RPC sobre HTTP) MAPI Outlook sobre HTTP perspectiva en la web | 443/TCP (HTTPS) | EWS para referencia de intercambio |
Los siguientes clientes y servicios utilizan conexiones web no cifradas. Publicar un calendario en línea Outlook en la web (redireccionamiento al puerto 443/TCP) Descubrimiento automático (alternativa cuando el puerto 443/TCP no está disponible) | 80/TCP (HTTP) | Siempre que sea posible, recomendamos utilizar conexiones web cifradas a través del puerto 443/TCP para proteger las credenciales y otros datos. Sin embargo, algunos servicios deben configurarse para utilizar conexiones web no cifradas a través del puerto 80/TCP a los servicios de acceso de cliente en los servidores de buzones de correo. Para obtener más información sobre estos clientes y servicios, consulte los siguientes artículos. |
Clientes IMAP4 | 143/TCP (IMAP), 993/TCP (IMAP seguro) | De forma predeterminada, IMAP4 está deshabilitado. Para más información, ver . El servicio IMAP4 en Servicios de acceso de cliente en el servidor de buzones de correo representa las conexiones al servicio IMAP4 interno en el servidor de buzones de correo. |
Clientes POP3 | 110/TCP (POP3), 995/TCP (POP3 seguro) | De forma predeterminada, POP3 está deshabilitado. Para más información, ver . El servicio POP3 en Servicios de acceso de cliente en el servidor de buzones de correo representa las conexiones al servicio POP3 interno en el servidor de buzones de correo. |
Clientes SMTP (autenticados) | 587/TCP (SMTP con autenticación) | El conector de recepción predeterminado es "Client Frontend" " en el servicio de transporte externo escucha mensajes de clientes SMTP autenticados en el puerto 587. Nota. Si tiene clientes de correo electrónico que solo pueden enviar mensajes autenticados SMTP en el puerto 25, puede cambiar el valor de enlace de este conector de recepción para que también rastree los mensajes autenticados SMTP enviados en el puerto 25. |
al principio
Puertos de red necesarios para el flujo de correoCorrespondencia saliente
25/TCP (SMTP)
Servidor de buzones
Internet (todos)
De forma predeterminada, Exchange no crea conectores de envío que le permitan enviar correo a Internet. Debe crear conectores de envío manualmente. Para más información, ver .
Correo saliente (si se envía a través de un servicio de transporte externo)
25/TCP (SMTP)
Servidor de buzones
Internet (todos)
El correo saliente se enruta a través del servicio de transporte externo solo si el conector de envío está habilitado con la opción Proxy de servidor de acceso de cliente en el EAC o la opción -FrontEndProxyEnabled $true en el Shell de administración de Exchange.
En este caso, el conector de recepción predeterminado es "Interfaz de proxy saliente " en el servicio de transporte externo escucha el correo saliente del servicio de transporte en el servidor de buzones. Para obtener más información, consulte .
Servidor DNS para la resolución del nombre del siguiente salto de correo (no se muestra en la imagen)
53/UDP, 53/TCP (DNS)
Servidor de buzones
servidor DNS
al principio
Un servidor de transporte perimetral suscrito instalado en una red perimetral afecta el flujo de correo de las siguientes maneras:
El correo de un servidor de transporte perimetral de Exchange 2016 o Exchange 2013 llega primero al servicio de transporte front-end y luego se reenvía al servicio de transporte en el servidor de buzones de correo de Exchange 2016.
El correo de un servidor de transporte perimetral de Exchange 2010 siempre va directamente al servicio de transporte en un servidor de buzones de correo de Exchange 2016.
El correo saliente de la organización Exchange nunca pasa por el servicio de transporte externo en los servidores de buzones. Siempre se redirige desde el servicio de transporte en el servidor de buzones de correo del sitio de Active Directory suscrito al servidor de transporte perimetral (independientemente de la versión de Exchange en el servidor de transporte perimetral).
El correo entrante se redirige desde el servidor de transporte perimetral al servidor de buzones de correo del sitio de Active Directory suscrito. Esto significa lo siguiente:
Los puertos de red necesarios para el flujo de correo en organizaciones de Exchange con servidores de transporte perimetral se describen en el siguiente diagrama y tabla.
Correo entrante: desde Internet al servidor Edge Transport | 25/TCP (SMTP) | Internet (todos) | Conector de recepción predeterminado denominado "Conector de recepción interno predeterminado" " en el servidor Edge Transport escucha el correo SMTP anónimo en el puerto 25. |
|
Correo entrante: desde el servidor de transporte perimetral a la organización interna de Exchange | 25/TCP (SMTP) | Servidor de transporte perimetral | El conector de envío predeterminado se denomina "EdgeSync - Entrante a "retransmite el correo entrante en el puerto 25 a cualquier servidor de buzones de correo en un sitio de Active Directory suscrito. Para obtener más información, consulte . Conector de recepción predeterminado "Frontal predeterminado" " en el servicio de transporte externo en el servidor de buzones escucha todo el correo entrante (incluido el correo de los servidores de transporte perimetral de Exchange 2016 y Exchange 2013) en el puerto 25. |
|
Correo saliente: desde la organización interna de Exchange al servidor de transporte perimetral | 25/TCP (SMTP) | Servidores de buzones de correo en un sitio de Active Directory suscrito | El correo saliente siempre pasa por alto el servicio de transporte externo en los servidores de buzones. El correo se retransmite desde el servicio de transporte en cualquier servidor de buzones de correo en un sitio de Active Directory suscrito al servidor de transporte perimetral mediante un conector de envío dentro de la organización implícito e invisible, que reenvía automáticamente el correo entre servidores Exchange de la misma organización. Conector de recepción interno predeterminado " en el servidor de transporte perimetral escucha el correo SMTP en el puerto 25 desde el servicio de transporte en cualquier servidor de buzones de correo en un sitio de Active Directory suscrito. |
|
Correo saliente: desde el servidor Edge Transport a Internet | 25/TCP (SMTP) | Servidor de transporte perimetral | Internet (todos) | El conector de envío predeterminado se denomina "EdgeSync - con a Internet" retransmite el correo saliente en el puerto 25 desde el servidor de transporte perimetral a Internet. |
Sincronización EdgeSync | 50636/TCP (LDAP seguro) | Servidores de buzones de correo en un sitio de Active Directory suscrito que participan en la sincronización de EdgeSync | Servidores de transporte perimetral | Si el servidor de transporte perimetral está suscrito a un sitio de Active Directory, todos los servidores de buzones de correo que existen actualmente en el sitio participan en la sincronización de EdgeSync. Pero si agrega otros servidores de buzones más adelante, no participarán automáticamente en la sincronización de EdgeSync. |
Servidor DNS para la resolución del nombre del próximo salto (no se muestra en la imagen) | 53/UDP, 53/TCP (DNS) | Servidor de transporte perimetral | servidor DNS | Consulte Resolución de nombres. |
Detección de proxy abierta en Reputación del remitente (no se muestra en la figura) | Ver notas | Servidor de transporte perimetral | Internet | De forma predeterminada, el Agente de análisis de protocolo utiliza la detección de proxy abierto como una de las condiciones para calcular el nivel de reputación del servidor de mensajería de origen. Para obtener más información, consulte el artículo. Los siguientes puertos TCP se utilizan para comprobar si los servidores de mensajería de origen tienen un proxy abierto: Además, si su organización utiliza un servidor proxy para controlar el tráfico saliente de Internet, debe determinar el nombre, el tipo y el puerto TCP del servidor proxy necesario para acceder a Internet y detectar un servidor proxy abierto. También puede desactivar la detección de proxy abierto. Para más información, ver . |
al principio
Resolución de nombresResolución de nombres
La resolución de correo DNS de siguiente salto es una parte fundamental del flujo de correo en cualquier organización de Exchange. Los servidores de Exchange responsables de recibir el correo entrante o entregar el correo saliente deben poder resolver nombres de host internos y externos para poder enrutar el correo correctamente. Todos los servidores internos de Exchange deben poder resolver nombres de host internos para un enrutamiento de correo adecuado. Hay muchas formas diferentes de diseñar una infraestructura DNS, pero el resultado importante es garantizar la resolución correcta del nombre del siguiente salto en todos los servidores Exchange.
¿Qué puertos TCP y UDP utiliza mi servidor Exchange 2000/2003?
Para configurar firewalls o solucionar problemas de comunicaciones, puede resultar útil saber qué puertos TCP/UDP utilizan Exchange 2000 Server y Exchange 2000 Conferencing Server. Este artículo también es válido para las instalaciones de Exchange Server 2003.
Protocolo: LDAP
- Puerto (TCP/UDP): 389 (TCP)
- Descripción: Protocolo ligero de acceso a directorios (LDAP), utilizado por Active Directory, Active Directory Connector y el directorio de Microsoft Exchange Server 5.5.
Protocolo: LDAP/SSL
- Puerto (TCP/UDP): 636 (TCP)
- Descripción: LDAP sobre Secure Sockets Layer (SSL). Cuando SSL está habilitado, los datos LDAP que se transmiten y reciben se cifran.
- Para habilitar SSL, debe instalar un certificado de computadora en el controlador de dominio o en la computadora con Exchange Server 5.5.
Protocolo: LDAP
- Puerto (TCP/UDP): 379 (TCP)
- Descripción: El Servicio de replicación de sitios (SRS) utiliza el puerto TCP 379.
Protocolo: LDAP
- Puerto (TCP/UDP): 390 (TCP)
- Descripción: Si bien no es un puerto LDAP estándar, el puerto TCP 390 es el puerto alternativo recomendado para configurar el protocolo LDAP de Exchange Server 5.5 cuando Exchange Server 5.5 se ejecuta en un Microsoft Windows 2000 Controlador de dominio de Active Directory.
Protocolo: LDAP
- Puerto (TCP/UDP): 3268 (TCP)
- Descripción: Catálogo global. El catálogo global de Active Directory de Windows 2000 (que en realidad es una “función” de controlador de dominio) escucha en el puerto TCP 3268. Cuando esté solucionando problemas que puedan estar relacionados con un catálogo global, conéctese al puerto 3268 en LDP.
Protocolo: LDAP/SSL
- Puerto (TCP/UDP): 3269 (TCP)
- Descripción: Catálogo global sobre SSL. Las aplicaciones que se conectan al puerto TCP 3269 de un servidor de catálogo global pueden transmitir y recibir datos cifrados SSL. Para configurar un catálogo global para admitir SSL, debe instalar un certificado de computadora en el catálogo global.
Protocolo: IMAP4
- Puerto (TCP/UDP): 143 (TCP)
- Descripción: El Protocolo de acceso a mensajes de Internet versión 4 puede ser utilizado por clientes "basados en estándares" como Microsoft Outlook Express o Netscape Communicator para acceder al servidor de correo electrónico. IMAP4 se ejecuta sobre el servicio de administración de Microsoft Internet Information Service (IIS) (Inetinfo.exe) y permite el acceso del cliente al almacén de información de Exchange 2000.
Protocolo: IMAP4/SSL
- Puerto (TCP/UDP): 993 (TCP)
- Descripción: IMAP4 sobre SSL utiliza el puerto TCP 993. Antes de que un servidor Exchange 2000 admita IMAP4 (o cualquier otro protocolo) sobre SSL, debe instalar un certificado de computadora en el servidor Exchange 2000.
Protocolo: POP3
- Puerto (TCP/UDP): 110 (TCP)
- Descripción: Post Office Protocol versión 3 permite que clientes "basados en estándares" como Outlook Express o Netscape Communicator accedan al servidor de correo electrónico. Al igual que IMAP4, POP3 se ejecuta sobre el servicio de administración de IIS y permite el acceso del cliente al almacén de información de Exchange 2000.
Protocolo: POP3/SSL
- Puerto (TCP/UDP): 995 (TCP)
- Descripción: POP3 sobre SSL. Para habilitar POP3 sobre SSL, debe instalar un certificado de computadora en el servidor Exchange 2000.
Protocolo: NNTP
- Puerto (TCP/UDP): 119 (TCP)
- Descripción: El protocolo de transporte de noticias en red, a veces llamado protocolo Usenet, permite el acceso de clientes "basado en estándares" a carpetas públicas en el almacén de información. Al igual que IMAP4 y POP3, NNTP depende del servicio de administración de IIS.
Protocolo: NNTP/SSL
Puerto (TCP/UDP): 563 (TCP)
Descripción: NNTP sobre SSL. Para habilitar NNTP sobre SSL, debe instalar un certificado de computadora en Exchange 2000 Server.
Protocolo: HTTP
- Puerto (TCP/UDP): 80 (TCP)
- Descripción: El Protocolo de transferencia de hipertexto es el protocolo utilizado principalmente por Microsoft Outlook Web Access (OWA), pero también permite algunas acciones administrativas en el Administrador del sistema Exchange. HTTP se implementa a través del Servicio de publicación World Wide Web (W3Svc) y se ejecuta sobre el Servicio de administración de IIS.
Protocolo: HTTP/SSL
- Puerto (TCP/UDP): 443 (TCP)
- Descripción: HTTP sobre SSL. Para habilitar HTTP sobre SSL, debe instalar un certificado de computadora en el servidor Exchange 2000.
Protocolo: SMTP
- Puerto (TCP/UDP): 25 (TCP)
- Descripción: El Protocolo simple de transferencia de correo es la base de todo el transporte de correo electrónico en Exchange 2000. El servicio SMTP (SMTPSvc) se ejecuta sobre el servicio de administración de IIS. A diferencia de IMAP4, POP3, NNTP y HTTP, SMTP en Exchange 2000 no es utiliza un puerto separado para comunicación segura (SSL), sino que emplea un "subsistema de seguridad dentro de banda" llamado Transport Layer Security (TLS).
Protocolo: SMTP/SSL
- Puerto (TCP/UDP): 465 (TCP)
- Descripción: SMTP sobre SSL. El puerto TCP 465 está reservado por la práctica común de la industria para la comunicación SMTP segura mediante el protocolo SSL. Sin embargo, a diferencia de IMAP4, POP3, NNTP y HTTP, SMTP en Exchange 2000 no utiliza un puerto separado para comunicación segura (SSL), sino que emplea un "subsistema de seguridad en banda" llamado Transport Layer Security (TLS). . Para permitir que TLS funcione en Exchange 2000, debe instalar un certificado de computadora en el servidor de Exchange 2000.
Protocolo: SMTP/LSA
- Puerto (TCP/UDP): 691 (TCP)
- Descripción: El motor de enrutamiento de Microsoft Exchange (también conocido como RESvc) escucha la información del estado del enlace de enrutamiento en el puerto TCP 691. Exchange 2000 utiliza información del estado del enlace de enrutamiento para enrutar mensajes y la tabla de enrutamiento se actualiza constantemente. El algoritmo de estado de enlace (LSA) propaga información de estado de salida entre servidores Exchange 2000. Este algoritmo se basa en el protocolo Open Shortest Path First (OSPF) de la tecnología de redes y transfiere información del estado del enlace entre grupos de enrutamiento mediante el uso del verbo de comando X-LSA-2 a través de SMTP y mediante el uso de una conexión de protocolo de control de transmisión (TCP) para puerto 691 en un grupo de enrutamiento.
Protocolo: RVP
- Puerto (TCP/UDP): 80 (TCP)
- Descripción: RVP es la base de la mensajería instantánea en Exchange 2000. Si bien la comunicación RVP comienza con el puerto TCP 80, el servidor configura rápidamente una nueva conexión con el cliente en un puerto TCP efímero superior a 1024. Debido a que este puerto no se conoce de antemano, Existen problemas al habilitar la mensajería instantánea a través de un firewall.
Protocolo: IRC/IRCX
- Puerto (TCP/UDP): 6667 (TCP)
- Descripción: Internet Relay Chat (IRC) es el protocolo de chat. IRCX es la versión extendida que ofrece Microsoft. Si bien el puerto TCP 6667 es el puerto más común para IRC, el puerto TCP 7000 también se usa con mucha frecuencia.
Protocolo: IRC/SSL
- Puerto (TCP/UDP): 994 (TCP)
- Descripción: IRC (o Chat) sobre SSL. IRC o IRCX sobre SSL no se admiten en Exchange 2000.
Protocolo: X.400
- Puerto (TCP/UDP): 102 (TCP)
- Descripción: La Recomendación UIT-T X.400 es en realidad una serie de recomendaciones sobre cómo debería ser un sistema de manejo de mensajes electrónicos (MHS). El puerto TCP 102 está definido en IETF RFC-1006, que describe las comunicaciones OSI a través de una red TCP/IP. En resumen, el puerto TCP 102 es el puerto que utiliza el agente de transferencia de mensajes (MTA) de Exchange para comunicarse con otros MTA compatibles con X.400.
Protocolo: MS-RPC
- Puerto (TCP/UDP): 135 (TCP)
- Descripción: La llamada a procedimiento remoto de Microsoft es una implementación de Microsoft de llamadas a procedimiento remoto (RPC). El puerto TCP 135 es en realidad sólo el servicio de localización RPC, que es como el registrador de todos los servicios habilitados para RPC que se ejecutan en un servidor en particular. En Exchange 2000, el conector del grupo de enrutamiento utiliza RPC en lugar de SMTP cuando el servidor cabeza de puente de destino ejecuta Exchange 5.5. Además, algunas operaciones administrativas requieren RPC. Para configurar un firewall para habilitar el tráfico RPC, se deben habilitar muchos más puertos además de 135.
Para obtener información adicional, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:
XADM: Configuración de números de puerto TCP/IP para firewalls de Internet
XCON: Configuración del número de puerto TCP/IP de MTA para escuchas X.400 y RPC
Protocolo: T.120
- Puerto (TCP/UDP): 1503 (TCP)
- Descripción: La Recomendación UIT-T T.120 es una serie de recomendaciones que definen las conferencias de datos. La conferencia de datos se implementa en el lado del servidor como un proveedor de tecnología de conferencia (CTP) en la unidad de control multipunto (MCU), que es un componente de los servicios de conferencia de Exchange (ECS). Las conferencias de datos se implementan en el lado del cliente como chat, uso compartido de aplicaciones, pizarra y transferencia de archivos en Microsoft NetMeeting.
Protocolo: ULS
- Puerto (TCP/UDP): 522 (TCP)
- Descripción: El servicio de localización de usuarios es un tipo de servicio de directorio de Internet para clientes de conferencias, como NetMeeting. Exchange 2000 Server y Exchange 2000 Conferencing Server no implementan ULS, sino que aprovechan Active Directory para servicios de directorio (mediante el puerto TCP 389).
Protocolo: H.323 (vídeo)
- Puerto (TCP/UDP): 1720 (TCP)
- Descripción: La Recomendación UIT-T H.323 define las conferencias multimedia. El puerto TCP 1720 es el puerto de configuración de llamadas H.323 (vídeo). Después de que un cliente se conecta, el servidor H.323 negocia un nuevo puerto UDP dinámico que se utilizará para la transmisión de datos.
Protocolo: Audio
- Puerto (TCP/UDP): 1731 (TCP)
- Descripción: Las audioconferencias se habilitan de forma muy similar a como se habilitan las videoconferencias H.323 en Exchange 2000 Server. Después de que los clientes se conectan al puerto TCP 1731, se negocia un nuevo puerto dinámico para transmitir más datos.
Firewalls para servidores de correo (Exchange Server), puertos de servidores de correo, servidores de correo front-end y back-end, Servidores virtuales SMTP, POP3, IMAP4
Como cualquier computadora conectada a Internet, la computadora que ejecuta el servidor de correo debe estar protegida con un firewall. Sin embargo, las opciones para instalar un servidor de correo en cuanto a configuración de red pueden ser muy diferentes:
· la opción más sencilla es instalar un servidor de correo en un ordenador que también sea un servidor proxy/firewall y luego abrir los puertos necesarios en la interfaz que da a Internet. Normalmente, este esquema se utiliza en organizaciones pequeñas;
Otra opción es instalar un servidor de correo en red local y configúrelo para que funcione a través de un servidor proxy. Para hacer esto, puede vincular una IP pública al servidor de correo y pasarla a través de un proxy, o usar herramientas como el mapeo de puertos en un servidor proxy. Muchos servidores proxy tienen asistentes especiales o reglas preparadas previamente para organizar dicha solución (por ejemplo, ISA Server). Esta opción se utiliza en la mayoría de las organizaciones.
· otra posibilidad fundamental es crear una DMZ y colocar en ella un front-end Exchange Server (esta opción aparece desde la versión 2000) o SMTP Relay basado en otro Exchange Server o, por ejemplo, sendmail en *nix. Normalmente se utiliza en redes de grandes organizaciones.
En cualquier caso, el servidor de correo debe comunicarse al menos en el puerto TCP 25 (SMTP) y UDP 53 (DNS). Otros puertos que Exchange Server puede requerir según la configuración de su red (todos TCP):
· 80 HTTP - para acceso a la interfaz web (OWA)
· 88 Protocolo de autenticación Kerberos: si se utiliza la autenticación Kerberos (raramente);
· 102 Conector MTA .X .400 sobre TCP /IP (si el conector X .400 se utiliza para la comunicación entre grupos de enrutamiento);
· 110 Protocolo de oficina postal 3 (POP 3) - para acceso de clientes;
· 119 Protocolo de transferencia de noticias en red (NNTP): si se utilizan grupos de noticias;
· 135 Comunicación cliente/servidor Administración RPC Exchange: puerto RPC estándar para administración remota de Exchange medios estándar Administrador de sistemas;
· 143 Protocolo de acceso a mensajes de Internet (IMAP): para acceso de clientes;
· 389 LDAP - para acceder al servicio de directorio;
· 443 HTTP (Capa de sockets seguros (SSL)) (e inferior): los mismos protocolos protegidos por SSL.
· 563 NNTP (SSL)
636 LDAP (SSL)
· 993 IMAP4 (SSL)
· 995 POP3 (SSL)
· 3268 y 3269: consultas al servidor de catálogo global (búsqueda en Active Directory y comprobación de pertenencia a grupos universales).
No tiene sentido cubrir la interfaz de Exchange Server que mira hacia el interior de la organización con un firewall: se utilizará para interactuar con controladores de dominio, utilidades de administración, sistemas de respaldo, etc. Para una interfaz abierta a Internet, se recomienda dejar los puertos 53 (si Exchange resolverá los nombres de host por sí mismo y no redirigirá las solicitudes al servidor local). servidor DNS) y 25. Muy a menudo, los clientes necesitan acceder a sus buzones desde fuera (desde casa, durante un viaje de negocios, etc.). La mejor solución en esta situación es configurar OWA (interfaz web para acceder a Exchange Server, que se instala de forma predeterminada, disponible en http://server_name/exchange) para que funcione a través de SSL y abra el acceso solo en el puerto 443. Además de resolver problemas con la autenticación segura y el cifrado de mensajes resuelve automáticamente el problema con SMTP Relay (más sobre esto más adelante) y la situación cuando un usuario descarga accidentalmente correo electrónico del trabajo en las carpetas del cliente de correo en computador de casa, y luego en el trabajo no puede encontrar estos mensajes (sin mencionar el hecho de que almacenar el correo electrónico del trabajo en casa es una violación de seguridad).
Una nueva característica que ha aparecido en Exchange Server. a partir de la versión 2000, la posibilidad de utilizar varios servidores SMTP y POP3 virtuales con diferentes configuraciones de seguridad. Por ejemplo, el servidor SMTP que interactúa con Internet se puede configurar con un modo de mayor seguridad y restricciones de entrega estrictas, y el servidor SMTP que utilizan los usuarios dentro de la organización se puede configurar con las configuraciones más potentes y fáciles de usar.
También es necesario mencionar una cierta confusión en la terminología: muy a menudo los firewalls para Exchange se denominan sistemas de filtrado de mensajes, lo cual se analizará a continuación.
Material de Rosalab Wiki
ObjetivoEste manual describe cómo conectar varios clientes de correo al servidor Microsoft Exchange. El objetivo es obtener un sistema que coincida en funcionalidad con Microsoft Outlook.
Datos de entradaLos ejemplos utilizan el servidor Microsoft Exchange 2010 (v14.03.0361.001) Service Pack 3 Update RollUp 18. Las pruebas se llevan a cabo dentro de la red corporativa. Los servidores DNS contienen direcciones de correo externas para el servidor de correo. Lo siguiente debería funcionar en el servidor Exchange:
Una cuestión importante para que los clientes que no sean de Microsoft se ejecuten correctamente en Exchange 2010 es la autenticación. Puede ver sus parámetros en un servidor Exchange con la función CAS (Client Access Server). Inicie el complemento Administrador de IIS y abra la pestaña Sitios/Sitio web predeterminado. Tenga en cuenta que la autenticación tiene tres componentes:
- OWA: estado habilitado para autenticación y verificación básicas Autenticidad de Windows »:
- OAB: estado habilitado para autenticación básica y autenticación de Windows:
- EWS: estado habilitado para autenticación anónima, autenticación básica y autenticación de Windows:
Algunos clientes de correo electrónico no pueden conectarse directamente a Microsoft Exchange y requieren el uso de un intermediario. En este ejemplo, se utiliza un servidor proxy como intermediario. DavMail.
- Instalar DavMail, habiendo obtenido derechos de administrador usando su o sudo:
- Correr DavMail:
- En la pestaña "Principal", en el campo "URL de OWA (Exchange)", ingrese la dirección de su servidor en el formato "https:///EWS/Exchange.asmx" o un enlace a OWA
en el formato "https:///owa".
- Recuerde los números de puerto “Puerto IMAP local” y “Puerto SMTP local”. En este ejemplo, son 1143 y 1025, respectivamente.
Para no iniciar manualmente el servidor cada vez DavMail, debes agregar su llamada al inicio.
- Vaya al menú “Configuración del sistema → Inicio y apagado → Ejecución automática”, haga clic en el botón [Agregar aplicación] e ingrese “davmail” en la barra de búsqueda, luego haga clic en [Aceptar]:
Ahora servidor proxy local DavMail se iniciará automáticamente cuando se inicie el sistema. Si su icono en la “Barra de tareas” le molesta, existe una opción para ocultarlo. Para hacer esto, en el archivo .davmail.properties, edite la línea davmail.server=false, cambiando false a true:
Sudo mcedit /home//.davmail.properties
Clientes de correo para conectarse a ExchangeAhora puede comenzar a configurar clientes de correo electrónico.
pájaro truenoMozilla Thunderbird es el principal cliente de correo electrónico para las distribuciones ROSA Linux y, muy probablemente, ya esté instalado en su sistema y listo para usar. Si no, puedes instalarlo desde los repositorios de ROSA. Este ejemplo utiliza la versión 52.2.1.
- Instalar pájaro trueno:
- Agregue una interfaz en ruso:
- Instale el complemento Lightning, que le permite utilizar calendarios:
- Correr pájaro trueno.
- En la sección "Cuentas", en la sección "Crear una cuenta", seleccione " Correo electrónico" Aparecerá una ventana de bienvenida.
- En la ventana que se abre, haga clic en el botón [Omitir esto y usar mi correo electrónico existente].
- En la ventana "Configuración de cuenta de correo", ingrese "Su nombre", "Dirección de correo electrónico" en los campos. mail" y "Contraseña" sus credenciales.
- Haga clic en [Continuar]. El programa intentará encontrar conexiones (sin éxito) y aparecerá un mensaje de error:
Aquí necesitará los números de puerto que recordó durante la configuración. DavMail.
- Para las categorías "Entrante" y "Saliente", cambie el nombre del servidor a "localhost".
- Especifique el puerto 1143 para "IMAP" y el puerto 1025 para "SMTP".
- En el campo "Nombre de usuario", ingrese UPN (Nombre principal de usuario): el nombre de dominio del usuario en el formato "Nombre de usuario@dominiodeorganización.ru".
- Haga clic en el botón [Reprobar].
Si ingresa sus credenciales correctamente, no habrá errores. Es posible que el sistema le solicite que acepte el certificado del servidor Exchange. Si esto no sucede, es posible que haya apagado la interfaz demasiado pronto DavMail.
Crear un calendario de usuario- En la categoría "Cuentas", seleccione "Crear un nuevo calendario".
- En la ventana que aparece, seleccione "En línea" y haga clic en [Siguiente].
- Seleccione el formato “CalDAV” y en el campo “Dirección” ingrese “http://localhost:1080/users/ /calendar”:
la libreta de direcciones pájaro trueno no admite el protocolo CardDAV y solo se puede conectar al directorio LDAP del servidor Exchange.
- Abra las libretas de direcciones existentes haciendo clic en el botón [Libreta de direcciones] y seleccionando “Archivo → Nuevo → Directorio LDAP”.
- En la ventana del asistente, especifique los siguientes parámetros:
- Nombre: cualquier nombre adecuado
- Nombre del servidor: localhost
- Elemento raíz (DN base) - ou=personas
- Puerto - 1389 (desde Davmail)
- Nombre de usuario (DN de enlace): nombre de usuario de UPN
- Haga clic en Aceptar]. El programa le pedirá que ingrese una contraseña.
- Ir al menú de opciones pájaro trueno. En la categoría "Redacción", seleccione la pestaña "Direcciones" y debajo del texto "Al ingresar una dirección, busque direcciones de correo adecuadas en" marque la opción "Servidor de directorio", seleccionando el nombre de su libreta de direcciones.
Un cliente de correo electrónico también está disponible en los repositorios de ROSA. Evolución(En este ejemplo se utiliza la versión 3.16.4).
- Instalar Evolución:
- Instale el conector Intercambio compatible con la versión 2007 y posteriores:
- Correr Evolución.
- En la ventana del asistente, haga clic en el botón [Siguiente] hasta ir a la pestaña "Cuenta".
- Complete los campos "Nombre completo" y "Correo electrónico".
- En la pestaña "Recepción de correo", en la lista "Tipo de servidor", seleccione "Servicios web de Exchange".
- Para el nombre, ingrese el nombre UPN del usuario en el formato "Nombre de [email protected]".
- En el campo "URL de host", ingrese "https://MailServerNameExchange/EWS/Exchange.asmx.
- En el campo URL de la OAB, ingrese la URL de la OAB.
- Seleccione "Básico" como tipo de autenticación.
Tras una configuración exitosa, el programa le pedirá una contraseña:
Después de ingresar la contraseña Evolución Tendrá acceso a su buzón, libreta de direcciones y calendarios.
Para cualquier pregunta relacionada con este artículo, por favor contacte [correo electrónico protegido].
Se aplica a: Exchange Server 2010 SP1
Esta sección fue modificada por última vez: 2011-04-22
Esta sección proporciona información sobre puertos, autenticación y cifrado para todas las rutas de datos utilizadas en Microsoft Exchange Server 2010. La sección "Observaciones" después de cada tabla aclara o define métodos de autenticación o cifrado no estándar.
Servidores de transporteEn Exchange 2010, hay dos funciones de servidor que realizan funciones de transporte de mensajes: el servidor de transporte de concentradores y el servidor de transporte perimetral.
La siguiente tabla proporciona información sobre puertos, autenticación y cifrado de rutas de datos entre estos servidores de transporte y otros servidores y servicios de Exchange 2010.
Rutas de datos para servidores de transporte|
Entre dos servidores Hub Transport |
Sí, usando TLS (Seguridad de la capa de transporte) |
||||
|
De un servidor de transporte de concentradores a un servidor de transporte perimetral |
confianza directa |
confianza directa |
Sí, usando TLS |
||
|
Del servidor de transporte perimetral al servidor de transporte concentrador |
confianza directa |
confianza directa |
Sí, usando TLS |
||
|
Entre dos servidores de transporte perimetral |
Anónimo, autenticación de certificado |
Anónimamente, utilizando un certificado |
Sí, usando TLS |
||
|
Desde un servidor de buzones de correo hasta a través del servicio de envío de correo de Microsoft Exchange |
NTLM. Cuando la función del servidor Transporte de concentradores y la función del servidor Buzón de correo se ejecutan en el mismo servidor, se utiliza el protocolo Kerberos. |
Sí, usando cifrado RPC |
|||
|
De un servidor Hub Transport a un servidor de buzones de correo a través de MAPI |
NTLM. Cuando la función del servidor Transporte de concentradores y la función del servidor Buzón de correo están instaladas en el mismo servidor, se utiliza el protocolo Kerberos. |
Sí, usando cifrado RPC |
|||
|
Sí, usando TLS |
|||||
|
Servicio Microsoft Exchange EdgeSync desde el servidor Hub Transport al servidor Edge Transport |
Sí, usando LDAP sobre SSL (LDAPS) |
||||
|
Acceder a Active Directory desde un servidor Hub Transport |
|||||
|
Acceso a los Servicios de administración de derechos de Active Directory (AD RMS) desde un servidor Hub Transport |
Sí, usando SSL |
||||
|
Clientes SMTP a un servidor Hub Transport (por ejemplo, usuarios finales que utilizan Windows Live Mail) |
Sí, usando TLS |
- Todo el tráfico entre los servidores Hub Transport se cifra mediante TLS y certificados autofirmados instalados por la instalación de Exchange 2010.
- Todo el tráfico entre los servidores de transporte perimetral y los servidores de transporte central se autentica y cifra. TLS mutuo se utiliza como mecanismo de autenticación y cifrado. En lugar de la autenticación X.509, Exchange 2010 utiliza confianza directa. La confianza directa significa que la presencia de un certificado en Active Directory o Active Directory Lightweight Directory Services (AD LDS) verifica la autenticidad del certificado. Active Directory se considera un motor de almacenamiento confiable. Cuando se utiliza la confianza directa, no importa si se utiliza un certificado autofirmado o un certificado firmado por una autoridad certificadora. Cuando un servidor de transporte perimetral se suscribe a una organización de Exchange, la suscripción perimetral publica el certificado del servidor de transporte perimetral en Active Directory para que los servidores de transporte central puedan validarlo. El servicio Microsoft Exchange EdgeSync agrega un conjunto de certificados del servidor Hub Transport a Active Directory Lightweight Directory Services (AD LDS) para que el servidor Edge Transport los valide.
- EdgeSync utiliza una conexión LDAP segura desde el servidor Hub Transport a los servidores Edge Transport suscritos en el puerto TCP 50636. Active Directory Lightweight Directory Services también escucha en el puerto TCP 50389. Las conexiones en este puerto no se utilizan protocolo SSL. Puede utilizar utilidades LDAP para conectarse a este puerto y verificar los datos de Active Directory Lightweight Directory Services.
- De forma predeterminada, el tráfico entre servidores de transporte perimetral ubicados en dos organizaciones diferentes está cifrado. La instalación de Exchange 2010 crea un certificado autofirmado y habilita TLS de forma predeterminada. Esto permite que cualquier sistema de envío cifre la sesión SMTP que ingresa a Exchange. De forma predeterminada, Exchange 2010 también intenta utilizar TLS para todas las conexiones remotas.
- Los métodos de autenticación para el tráfico entre los servidores de transporte de concentradores y los servidores de buzones de correo son diferentes cuando las funciones del servidor de transporte de concentradores y de buzones de correo están instaladas en la misma computadora. La transferencia de correo local utiliza autenticación Kerberos. La transferencia de correo remota utiliza autenticación NTLM.
- Exchange 2010 también admite la seguridad de dominio. Domain Security es un conjunto de funciones de Exchange 2010 y Microsoft Outlook 2010 que proporcionan una alternativa de bajo costo a S/MIME y otras soluciones de seguridad de mensajería de Internet. La seguridad de dominio proporciona una forma de gestionar rutas de mensajes seguras entre dominios en Internet. Una vez configuradas estas rutas seguras, los mensajes transmitidos correctamente desde un remitente autenticado aparecen como mensajes "protegidos por dominio" para los usuarios de Outlook y Outlook Web Access. Para obtener más información, consulte Descripción general de la seguridad del dominio.
- Muchos agentes pueden ejecutarse tanto en servidores Hub Transport como en servidores Edge Transport. Normalmente, los agentes antispam utilizan información de la computadora local en la que se ejecutan. Por lo tanto, prácticamente no se requiere interacción computadoras remotas. La excepción es el filtrado de destinatarios. El filtrado de destinatarios requiere una llamada a AD LDS o Active Directory. Le recomendamos que realice el filtrado de destinatarios en el servidor de transporte perimetral. En este caso, el directorio AD LDS está en la misma computadora que tiene instalada la función del servidor Transporte perimetral, por lo que no se requiere una conexión remota. Si el filtrado de destinatarios está instalado y configurado en un servidor de transporte de concentradores, debe tener acceso al servicio de directorio Active Directory.
- La función de reputación del remitente en Exchange 2010 utiliza el Agente de análisis de protocolo. Este agente también se conecta a varios servidores proxy externos para determinar las rutas de los mensajes entrantes para conexiones sospechosas.
- Todas las demás funciones antispam utilizan datos que se recopilan, almacenan y son accesibles únicamente en la computadora local. Normalmente, datos como una lista consolidada de remitentes seguros o datos de destinatarios para el filtrado de destinatarios se envían al directorio AD LDS local mediante el servicio Microsoft Exchange EdgeSync.
- Los agentes de Information Rights Management (IRM) en los servidores Hub Transport se conectan a los servidores de Active Directory Rights Management Services (AD RMS) de su organización. El Servicio de administración de derechos de Active Directory (AD RMS) es un servicio web que se recomienda proteger mediante SSL. Las conexiones a los servidores de Active Directory Rights Management Services se realizan mediante HTTPS y la autenticación utiliza Kerberos o NTLM, según la configuración del servidor de Active Directory Rights Management Services.
- Las reglas de registro, las reglas de transporte y las reglas de clasificación de mensajes se almacenan en los servicios de Active Directory y el Agente de registro en diario y el Agente de reglas de transporte en los servidores de transporte de concentradores acceden a ellas. Servidores de buzones
En los servidores de buzones de correo, si se utiliza la autenticación NTLM o Kerberos depende del contexto del usuario o del proceso dentro del cual se ejecuta el consumidor de la capa de lógica empresarial de Exchange. En este contexto, los consumidores son cualquier aplicación o proceso que utilice la capa de lógica empresarial de Exchange. Como resultado, la columna Autenticación predeterminada en la tabla Rutas de datos para servidores de buzones de correo tiene muchas filas configuradas en NTLM/Kerberos.
La capa de lógica empresarial de Exchange se utiliza para acceder al almacén de Exchange e interactuar con él. La capa de lógica empresarial de Exchange también se llama desde el almacén de Exchange para interactuar con aplicaciones y procesos externos.
Si el consumidor de la capa de lógica empresarial de Exchange se ejecuta en el contexto del sistema local, el método de autenticación utilizado cuando el consumidor accede al almacén de Exchange es siempre Kerberos. El método de autenticación Kerberos se utiliza porque la identidad del destinatario debe verificarse mediante cuenta"Sistema local" de la computadora y también requiere una confianza autenticada bidireccional.
Si el destinatario de la capa de lógica empresarial de Exchange no se ejecuta en el contexto del sistema local, el método de autenticación es NTLM. Por ejemplo, cuando un administrador ejecuta un cmdlet del Shell de administración de Exchange que utiliza la capa de lógica empresarial de Exchange, se aplica la autenticación NTLM.
El tráfico RPC siempre está cifrado.
La siguiente tabla proporciona información sobre puertos, autenticación y cifrado de rutas de datos para servidores de buzones de correo.
Rutas de datos para servidores de buzones de correo
Notas para servidores de acceso de cliente Servidores de mensajería unificadaRuta de datos Puertos necesarios Autenticación predeterminada admitida Método de autenticación Compatibilidad con cifrado Cifrado de datos predeterminado 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (inicio de sesión RPC de red)
Sí, usando cifrado Kerberos
Administrativo acceso remoto(registro remoto)
Sí, usando IPsec
Acceso remoto administrativo (SMB, archivos)
Sí, usando IPsec
Servicio web de disponibilidad (acceso de cliente al buzón)
Sí, usando cifrado RPC
Agrupación
Sí, usando cifrado RPC
Entre servidores de acceso de cliente (Exchange ActiveSync)
80/TCP, 443/TCP (SSL)
Autenticación de certificado Kerberos
Sí, usando HTTPS
Sí, utilizando un certificado autofirmado
Entre servidores de acceso de cliente (Outlook Web Access)
80/TCP, 443/TCP (HTTPS)
Sí, usando SSL
Servidor de acceso de cliente a servidor de acceso de cliente (servicios web de Exchange)
Sí, usando SSL
Servidor de acceso de cliente a servidor de acceso de cliente (POP3)
Sí, usando SSL
Servidor de acceso de cliente a servidor de acceso de cliente (IMAP4)
Sí, usando SSL
Office Communications Server a Client Access Server (cuando la integración de Office Communications Server y Outlook Web App está habilitada)
5075-5077/TCP (ENTRADA), 5061/TCP (SALIDA)
mTLS (obligatorio)
mTLS (obligatorio)
Sí, usando SSL
Las puertas de enlace IP y las PBX IP solo admiten la autenticación de certificados, que utiliza la autenticación TLS mutua para cifrar el tráfico SIP y la autenticación basada en direcciones IP para conexiones SIP o TCP. Las puertas de enlace IP no admiten la autenticación NTLM o Kerberos. Por lo tanto, cuando utiliza la autenticación basada en direcciones IP, las direcciones IP de las conexiones se utilizan como mecanismo de autenticación para conexiones no cifradas (TCP). Cuando se utiliza en mensajería unificada, la autenticación basada en IP comprueba si una dirección IP determinada tiene permiso para conectarse. La dirección IP se configura en la puerta de enlace IP o IP PBX.
Las puertas de enlace IP y las PBX IP admiten Mutual TLS para cifrar el tráfico SIP. Después de importar y exportar exitosamente los certificados confiables requeridos, la puerta de enlace IP o PBX IP solicitará un certificado del servidor de mensajería unificada y luego solicitará el certificado de la puerta de enlace IP o PBX IP. El intercambio de certificados confiables entre la puerta de enlace IP o IP PBX y el servidor de mensajería unificada permite que ambos dispositivos se comuniquen a través de un canal seguro utilizando Mutual TLS.
La siguiente tabla proporciona información de puerto, autenticación y cifrado para rutas de datos entre servidores de mensajería unificada y otros servidores.
Rutas de datos para servidores de mensajería unificada
Notas para servidores de mensajería unificadaRuta de datos Puertos necesarios Autenticación predeterminada admitida Método de autenticación Compatibilidad con cifrado Cifrado de datos predeterminado Acceso a Directorio Activo
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (inicio de sesión RPC de red)
Sí, usando cifrado Kerberos
Telefonía de mensajería unificada (IP PBX/VoIP Gateway)
5060/TCP, 5065/TCP, 5067/TCP (modo desprotegido), 5061/TCP, 5066/TCP, 5068/TCP (modo seguro), rango de puertos dinámicos 16000-17000/TCP (control), puertos UDP dinámicos del rango 1024-65535/UDP (RTP)
Por dirección IP
Por dirección IP, MTLS
Sí, usando SIP/TLS, SRTP
Servicio web de mensajería unificada
80/TCP, 443/TCP (SSL)
Autenticación de Windows integrada (negociar)
Sí, usando SSL
Del servidor de mensajería unificada al servidor de acceso de cliente
5075, 5076, 5077 (TCP)
Autenticación de Windows integrada (negociación)
Básico, Resumen, NTLM, Negociar (Kerberos)
Sí, usando SSL
Del servidor de mensajería unificada al servidor de acceso de cliente (reproducir en el teléfono)
RPC dinámico
Sí, usando cifrado RPC
De un servidor de mensajería unificada a un servidor de transporte de concentradores
Sí, usando TLS
De un servidor de mensajería unificada a un servidor de buzones de correo
Sí, usando cifrado RPC
- Cuando crea un objeto de puerta de enlace IP de mensajería unificada en Active Directory, debe especificar la dirección IP de la puerta de enlace IP física o IP PBX. Cuando determina la dirección IP de un objeto de puerta de enlace IP de mensajería unificada, la dirección IP se agrega a la lista de puertas de enlace IP válidas o IP PBX (también conocidas como participantes de sesión SIP) con las que el servidor de mensajería unificada puede comunicarse. Después de crear una puerta de enlace IP de Mensajería unificada, puede asociarla con un plan de marcado de Mensajería unificada. La asignación de una puerta de enlace IP de mensajería unificada a un plan de marcado permite que los servidores de mensajería unificada que están asignados al plan de marcado utilicen autenticación basada en direcciones IP para comunicarse con la puerta de enlace IP. Si no se ha creado una puerta de enlace IP de mensajería unificada o no se ha configurado para usar la dirección IP correcta, la autenticación fallará y los servidores de mensajería unificada no aceptarán conexiones desde la dirección IP de la puerta de enlace IP. Además, al implementar Mutual TLS, 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 para usar un nombre de dominio completo (FQDN). Después de configurar una puerta de enlace IP de mensajería unificada con un nombre de dominio completo, también debe agregar un registro de host para esa puerta de enlace a la zona de búsqueda DNS directa.
- En Exchange 2010, el servidor de mensajería unificada puede comunicarse en el puerto 5060/TCP (no seguro) o en el puerto 5061/TCP (seguro) y se puede configurar para usar ambos puertos.
Para obtener más información, consulte Descripción de la seguridad VoIP de mensajería unificada y Descripción de los protocolos, puertos y servicios de mensajería unificada.
Normas firewall de Windows creado por la configuración de Exchange 2010Firewall de Windows con seguridad avanzada es un firewall con estado basado en máquina que filtra el tráfico entrante y saliente según reglas de firewall. La instalación de Exchange 2010 crea reglas de Firewall de Windows para abrir los puertos necesarios para la comunicación servidor-cliente en cada función de servidor. Por lo tanto, ya no necesita utilizar el Asistente de configuración de seguridad para configurar estos ajustes. Para obtener más información sobre Firewall de Windows con seguridad avanzada, consulte Firewall de Windows con seguridad avanzada e IPsec.
La siguiente tabla muestra las reglas de Firewall de Windows que crea el programa de instalación de Exchange, incluidos los puertos que están abiertos en cada función de servidor. Puede ver estas reglas utilizando el complemento MMC Firewall de Windows con seguridad avanzada.
Notas sobre las reglas de Firewall de Windows creadas por la instalación de Exchange 2010Nombre de la regla Roles del servidor Puerto Programa MSExchangeADTopología: RPC (entrada TCP)
RPC dinámico
Bin\MSExchangeADTopologyService.exe
Monitoreo de MSExchange: RPC (entrada TCP)
Servidor de acceso de cliente, servidor de transporte de concentradores, servidor de transporte perimetral, servidor de mensajería unificada
RPC dinámico
Bin\Microsoft.Exchange.Management.Monitoring.exe
MSExchangeServiceHost - RPC (entrada TCP)
RPC dinámico
Papelera\Microsoft.Exchange.ServiceHost.exe
MSExchangeServiceHost - RPCEPMap (entrada TCP)
Papelera\Microsoft.Exchange.Service.Host
MSExchangeRPCEPMap (GFW) (entrada TCP)
MSExchangeRPC (GFW) (entrada TCP)
Servidor de acceso de cliente, servidor de transporte de concentradores, servidor de buzón de correo, servidor de mensajería unificada
RPC dinámico
MSExchange - IMAP4 (GFW) (entrada TCP)
Servidor de acceso de cliente
MSExchangeIMAP4 (entrada TCP)
Servidor de acceso de cliente
ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
MSExchange - POP3 (FGW) (entrada TCP)
Servidor de acceso de cliente
MSExchange - POP3 (entrada TCP)
Servidor de acceso de cliente
ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
MSExchange - OWA (GFW) (entrada TCP)
Servidor de acceso de cliente
5075, 5076, 5077 (TCP)
MSExchangeOWAAppPool (entrada TCP)
Servidor de acceso de cliente
5075, 5076, 5077 (TCP)
Inetsrv\w3wp.exe
MSExchangeAB RPC (entrada TCP)
Servidor de acceso de cliente
RPC dinámico
MSExchangeAB-RPCEPMap (entrada TCP)
Servidor de acceso de cliente
Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RpcHttp (entrada TCP)
Servidor de acceso de cliente
6002, 6004 (TCP)
Bin\Microsoft.Exchange.AddressBook.Service.exe
RpcHttpLBS (entrada TCP)
Servidor de acceso de cliente
RPC dinámico
System32\Svchost.exe
MSExchangeRPC - RPC (entrada TCP)
RPC dinámico
MSExchangeRPC - PRCEPMap (entrada TCP)
Servidor de acceso de cliente, servidor de buzón
Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC (entrada TCP)
Servidor de acceso de cliente, servidor de buzón
Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeMailboxReplication (GFW) (entrada TCP)
Servidor de acceso de cliente
MSExchangeMailboxReplication (entrada TCP)
Servidor de acceso de cliente
Bin\MSExchangeMailboxReplication.exe
MSExchangeIS - RPC (entrada TCP)
Servidor de buzones
RPC dinámico
MSExchangeIS RPCEPMap (entrada TCP)
Servidor de buzones
MSExchangeIS (GFW) (entrada TCP)
Servidor de buzones
6001, 6002, 6003, 6004 (TCP)
MSExchangeIS (entrada TCP)
Servidor de buzones
Asistentes de MSExchangeMailbox: RPC (entrada TCP)
Servidor de buzones
RPC dinámico
Asistentes de MSExchangeMailbox: RPCEPMap (entrada TCP)
Servidor de buzones
Bin\MSExchangeMailboxAssistants.exe
Envío de correo de MSExchange: RPC (entrada TCP)
Servidor de buzones
RPC dinámico
Envío de correo de MSExchange: RPCEPMap (entrada TCP)
Servidor de buzones
Bin\MSExchangeMailSubmission.exe
MSExchangeMigration - RPC (entrada TCP)
Servidor de buzones
RPC dinámico
Bin\MSExchangeMigration.exe
MSExchangeMigration: RPCEPMap (entrada TCP)
Servidor de buzones
Bin\MSExchangeMigration.exe
MSExchangerepl - Copiadora de registros (entrada TCP)
Servidor de buzones
Bin\MSExchangeRepl.exe
MSExchangerepl - RPC (entrada TCP)
Servidor de buzones
RPC dinámico
Bin\MSExchangeRepl.exe
MSExchangerepl - RPC-EPMap (entrada TCP)
Servidor de buzones
Bin\MSExchangeRepl.exe
MSExchangeSearch - RPC (entrada TCP)
Servidor de buzones
RPC dinámico
Bin\Microsoft.Exchange.Search.ExSearch.exe
Regulación de MSExchange: RPC (entrada TCP)
Servidor de buzones
RPC dinámico
Bin\MSExchangeThrottling.exe
Regulación de MSExchange: RPCEPMap (entrada TCP)
Servidor de buzones
Bin\MSExchangeThrottling.exe
MSFTED - RPC (entrada TCP)
Servidor de buzones
RPC dinámico
MSFTED - RPCEPMap (entrada TCP)
Servidor de buzones
MSExchangeEdgeSync - RPC (entrada TCP)
Servidor de transporte concentrador
RPC dinámico
MSExchangeEdgeSync RPCEPMap (entrada TCP)
Servidor de transporte concentrador
Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportWorker - RPC (entrada TCP)
Servidor de transporte concentrador
RPC dinámico
Bin\edgetransport.exe
MSExchangeTransportWorker - RPCEPMap (entrada TCP)
Servidor de transporte concentrador
Bin\edgetransport.exe
MSExchangeTransportWorker (GFW) (entrada TCP)
Servidor de transporte concentrador
MSExchangeTransportWorker (entrada TCP)
Servidor de transporte concentrador
Bin\edgetransport.exe
MSExchangeTransportLogSearch - RPC (entrada TCP)
RPC dinámico
MSExchangeTransportLogSearch - RPCEPMap (entrada TCP)
Servidor de transporte concentrador, servidor de transporte perimetral, servidor de buzones de correo
Bin\MSExchangeTransportLogSearch.exe
SESWorker (GFW) (entrada TCP)
Servidor de mensajería unificada
SESWorker (entrada TCP)
Servidor de mensajería unificada
Mensajería unificada\SESWorker.exe
UMService (GFW) (entrada TCP)
Servidor de mensajería unificada
UMService (entrada TCP)
Servidor de mensajería unificada
Bin\UMService.exe
UMWorkerProcess (GFW) (entrada TCP)
Servidor de mensajería unificada
5065, 5066, 5067, 5068
UMWorkerProcess (entrada TCP)
Servidor de mensajería unificada
5065, 5066, 5067, 5068
Bin\UMWorkerProcess.exe
UMWorkerProcess - RPC (entrada TCP)
Servidor de mensajería unificada
RPC dinámico
Bin\UMWorkerProcess.exe
- En servidores con IIS instalado, 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, estos puertos no aparecen en la tabla anterior.
- EN Servidor de windows En Windows Firewall 2008 y Windows Server 2008 R2, Windows Firewall con seguridad avanzada le permite especificar el proceso o servicio para el cual está abierto un puerto. Esto es más seguro porque el puerto solo puede ser utilizado por el proceso o servicio especificado en la regla. La instalación de Exchange crea reglas de firewall con el nombre de proceso especificado. En algunos casos, por motivos de compatibilidad, también se crea una regla adicional que no se limita a este proceso. Puede deshabilitar o eliminar reglas no restringidas por procesos y mantener las reglas restringidas por procesos correspondientes si su entorno de implementación actual las admite. Las reglas que no se limitan a procesos se pueden identificar mediante la palabra (GFW) en el nombre de la regla.
- Muchos servicios de Exchange utilizan llamadas a procedimientos remotos (RPC) para comunicarse. Los procesos de servidor que utilizan llamadas a procedimientos remotos se conectan al asignador de puntos finales RPC para obtener puntos finales dinámicos y registrarlos en la base de datos del asignador de puntos finales. Los clientes RPC interactúan con el asignador de puntos finales de RPC para determinar los puntos finales utilizados por el proceso del servidor. De forma predeterminada, el solucionador de punto final RPC escucha en el puerto 135 (TCP). Cuando configura el Firewall de Windows para un proceso que utiliza llamadas a procedimientos remotos, el programa de instalación de Exchange 2010 crea dos reglas de firewall para ese proceso. Una regla permite la interacción con el asignador de puntos finales de RPC y la segunda permite la interacción con un punto final asignado dinámicamente. Para obtener más información sobre las llamadas a procedimientos remotos, consulte este artículo. Para obtener más información sobre la creación de reglas de Firewall de Windows para llamadas dinámicas a procedimientos remotos, consulte este artículo.
Para obtener más información, consulte el artículo 179442 de Microsoft Knowledge Base.
