Arquitectura de Exchange y configuración TLS oportunista predeterminada |Parte 3#12
En el siguiente artículo, revisaremos con más detalle la implementación de TLS oportunista en el entorno basado en Exchange local y también en el entorno basado en Exchange Online.
Como se mencionó, en el entorno basado en Exchange, los conectores de correo de Exchange se configuran automáticamente para usar la opción de TLS oportunista .
La configuración de TLS oportunista se configura automáticamente en el conector de correo entrante predeterminado y, en el conector saliente predeterminado conector de correo.
Infraestructura local de Exchange | configuraciones TLS oportunistas
En la siguiente sección, revisaremos la configuración predeterminada de TLS oportunista en el servidor local de Exchange. ambiente.
La configuración de TLS oportunista se configura automáticamente en el Conector de envío y Conector de recepción .
Nota: En la sección actual, demostraremos la configuración TLS oportunista en Exchange 2010 local, pero el concepto y la configuración son casi idénticos a los de Exchange 2013 local.
Intercambio local | Enviar conector | configuraciones TLS oportunistas
En Exchange 2010 y Exchange 2013, la información sobre la configuración predeterminada del TLS oportunista que se utilizan mediante el conector de envío solo se puede mostrar mediante PowerShell.
Para poder obtener información sobre la configuración del Conector de envío, podemos usar el siguiente comando de PowerShell:
Get-SendConnector -Identity "<name of the send connector>" |FLEl parámetro que relaciona la configuración del TLS oportunista descrito como IgnoreSTARTTLS
En la siguiente captura de pantalla podemos ver que el valor de IgnoreSTARTTLS es False
El significado es que, de forma predeterminada, el conector de envío local de Exchange admite la opción de TLS oportunista.
Desactivar la opción de TLS oportunista
No puedo imaginar un escenario en el que necesitemos desactivar la opción de TLS oportunista, pero solo para conocimiento general, en caso de que, por alguna razón, necesitemos cancelar la opción de TLS oportunista, podemos usar PowerShell. dominio:
Set-SendConnector -Identity "<name>" -IgnoreSTARTTLS $trueIntercambio local | Conector de recepción | configuraciones TLS oportunistas
En las versiones de servidor Exchange 2010 y Exchange 2013, parte de la información sobre la configuración predeterminada del conector de recepción que hace referencia a la opción de TLS oportunista, se puede mostrar en la interfaz gráfica y, algunos La información solo se puede mostrar mediante PowerShell.
Visualización de la configuración del conector de recepción local de Exchange mediante PowerShell
Para poder obtener información sobre la configuración del Conector de recepción, podemos usar el siguiente comando de PowerShell:
Get-ReceiveConnector -Identity "<name of the receive connector>" |FLLa información sobre la “configuración TLS” del conector de recepción aparece en la sección denominada - AuthMechanism
El parámetro AuthMechanism puede contener varios valores, lo que significa que el conector de recepción de Exchange puede admitir muchos tipos de protocolos de autenticación.
En la siguiente captura de pantalla, podemos ver un ejemplo de la configuración del conector de recepción predeterminado del servidor Exchange local estándar.
Podemos ver que el valor de AuthMechanism incluye muchos tipos de protocolos de autenticación.
Configuración del mecanismo de autenticación
Podemos ver que Exchange Conector de recepción admite diferentes tipos de protocolo de autenticación.
Respecto al tema de TLS, podemos ver dos parámetros relevantes
1. Tls
Este es el parámetro que “activa” la opción de TLS oportunista
El significado es que, en un escenario en el que otro servidor de correo intenta comunicarse con el servidor Exchange, el servidor Exchange ofrecerá usar TLS.
Si el “otro servidor de correo” no admite TLS, el servidor Exchange “aceptará” utilizar el protocolo SMTP en su lugar.
Nota: Mi opinión es que las definiciones de TLS oportunista en la sección AuthMechanism son un poco inexactas porque, técnicamente, el protocolo TLS no exige una necesidad obligatoria de autenticación.
2. BasicAuthRequireTLS
Esta opción es relevante, principalmente para un escenario en el que un cliente de correo (como un cliente de correo POP3 o IMAP4) se dirige a Exchange local y solicita "recuperar" elementos de correo.
En este caso, el cliente de correo deberá identificarse proporcionando las credenciales de usuario.
La mayor parte del cliente de correo "entregará" las credenciales del usuario mediante la autenticación básica (BasicAuth), en la que las credenciales del usuario no estarán cifradas.
La opción de - BasicAuthRequireTLS indica al cliente de correo que entregue las credenciales del usuario a través de un canal de comunicación seguro (TLS) y no mediante un canal de comunicación estándar (canal de comunicación no cifrado).
3. Requerir TLS
El segundo parámetro en el conector de recepción local de Exchange incluye un parámetro adicional relacionado con la configuración de Forzar TLS named - Requerir TLS
Discutiremos brevemente esta opción en el artículo.
Visualización de la configuración del conector de recepción local de Exchange mediante la interfaz gráfica de Exchange
Cuando usamos la interfaz gráfica de Exchange, para ver las configuraciones relacionadas con la opción de TLS oportunista , es importante enfatizar que solo un parámetro está directamente relacionado con TLS oportunista.
En la siguiente captura de pantalla podemos ver que podemos seleccionar una de las siguientes opciones:
1. Seguridad de la capa de transporte (TLS)
Al seleccionar esta opción, se “activará” la opción de TLS oportunista en Exchange local Conector de recepción .
Esta es la única opción relevante para el tema de la comunicación “servidor a servidor” y la característica de TLS oportunista .
2. Habilite la seguridad del dominio (MutualAuth TLS).
Esta opción se relaciona con una configuración muy específica denominada seguridad de dominio.
Hasta donde tengo entendido, la opción de seguridad de dominio es relevante solo para un escenario en el que las dos partes involucradas son servidores basados en Exchange local.
3. Autenticación básica
La opción de -Ofrecer autenticación básica solo después de iniciar TLS es relevante para el escenario "cliente a servidor", en el que el cliente de correo que usa POP3/IMAP4 necesita conectarse a Exchange en -Servidor local mediante protocolo TLS. Las credenciales de usuario que deben "enviarse" al servidor de correo (Exchange local en nuestro escenario) se transferirán a través de la línea de comunicación segura TLS.
¿Cómo puedo saber si mi Exchange local admite TLS oportunista?
En caso de que queramos verificar si un servidor de correo específico admite la opción de comunicación mediante el protocolo TLS, podemos hacer Telnet al servidor específico y, usar el comando EHLO, para obtenga una lista de las opciones compatibles que existían en el "servidor de destino".
Por ejemplo, haremos Telnet al servidor de correo que representa el nombre de dominio: o365info.com utilizando la siguiente sintaxis Telnet:
En la siguiente captura de pantalla podemos ver los resultados:
Uno de los comandos que aparecen en la lista es - 250-STARTTLS
Si en la respuesta aparece "250-STARTTLS", se ofrece TLS oportunista.
Intercambio en línea | Conectores de correo saliente y entrante.
En la sección actual y en la siguiente, revisaremos el tema de TLS oportunista en Exchange Entorno basado en línea.
Como se mencionó, en un entorno basado en Exchange Online, utilizamos términos diferentes para describir los conectores de correo.
- Conectores de correo saliente denominados - conector saliente
- Conectores de correo entrante denominados - conector entrante
Bien, ahora pasemos a un dato interesante: de forma predeterminada, Exchange Online no incluye ningún conector de correo predeterminado que aparezca en la interfaz de administración de administración de Exchange Online.
El entorno Exchange Online se considera un SaaS (Software como servicio).
En el entorno de Office 365 y Exchange Online, no existe un servidor de correo "dedicado" para un inquilino de Office 365 en particular, sino una variedad de servidores de correo que sirven y representan a todos los inquilinos de Office 365.
Conector entrante de Exchange Online
Exchange Online utiliza un conector de entrada “dedicado” para cada uno de los inquilinos del dominio de Office 365 que están registrado en Office 365 y configurado para uso de correo, pero la configuración de este conector entrante no aparece en la interfaz de administración de administración de Exchange Online.
Conector saliente de Exchange Online
Lo único que sabemos es que con respecto a la infraestructura de correo saliente, Exchange Online utiliza EOP (Exchange Online Protection) como infraestructura para correo saliente + correo entrante.
El correo "saliente" para todos los inquilinos de Office 365 se entrega a través del conjunto de servidores EOP (Exchange Online Protection).
Una pregunta obvia que puede aparecer es:
P: ¿Puedo crear un conector de salida + ¿Conector entranter en el entorno de Exchange Online para mi inquilino?
A: La respuesta es “Sí”, podemos crear un conector de salida< personalizado. /span> + conector de entrada que servirá para - implementar un escenario de enrutamiento específico, un escenario de autenticación específico o, para configurar un canal de comunicación seguro usando TLS.
Más adelante en el artículo xx, revisaremos el tema de la creación y configuración de un conector saliente + conector entrante personalizado en el entorno basado en Exchange Online.
Infraestructura de Exchange Online | Conector de correo entrante | Las dos entidades de TLS oportunista y TLS forzado
En la sección anterior, declaramos que, de forma predeterminada, Exchange Online no incluye ningún conector que aparezca en la interfaz de administración de administración de Exchange Online, pero Exchange Online incluye:
- Un conector entrante que está "conectado" a un nombre de dominio de inquilino de Office 365 específico.
- “Conector entrante genérico” que no está asociado a un nombre de dominio específico. Este conector de entrada general está "adjunto" al nombre de host público: office365.com
Técnicamente hablando, un servidor de correo externo que necesita dirigirse al servidor de Exchange Online que representa un nombre de dominio específico (inquilinos de Office 365 que registran su nombre de dominio público en Office 365), puede dirigirse a la infraestructura de Exchange Online mediante dos métodos:
- Abordar el nombre de host que aparece en el registro MX
- Abordar un “nombre de host general”: smtp.office365.com
La principal diferencia entre las dos "entidades" de Exchange Online es la configuración de TLS.
- La entidad de Exchange Online que aparece en el registro MX está configurada para usar TLS oportunista.
- La entidad de Exchange Online representada por el nombre de host: office365.com está configurada para usar la opción de <.Forzar TLS
En otras palabras, cuando un servidor de correo accede al nombre de host: smtp.office365.com, Exchange Online "exige" que la comunicación se implemente como un canal de comunicación seguro utilizando el Protocolo TLS.
Dirigir Exchange Online utilizando el nombre de host que aparece en el registro MX
Se implementará una “comunicación de correo estándar”, en la que un servidor de correo externo intenta dirigirse al servidor de Exchange Online que representa un dominio específico, buscando el registro MX que representa un dominio específico.
En el entorno de Office 365 y Exchange Online, publicamos el registro MX utilizando un nombre de host representado por la infraestructura de Exchange Online.
Por ejemplo, el nombre de dominio o365pilot.com se registró en Office 365 y la infraestructura de correo está alojada en Exchange Online.
El nombre de host que aparece en el registro MX que "señala" el servidor de correo que representa este dominio se basa en la siguiente convención de nomenclatura.
En nuestro escenario específico, el nombre de host será: o365pilot-com.mail.protection.outlook.com
El nombre de host de Exchange Online que aparece en el registro MX está "vinculado" al Conector de recepción que admite la opción de TLS oportunista.
En un escenario en el que un servidor de correo externo se dirige al nombre de host de Exchange Online que representa un inquilino específico de Office 365 mediante el protocolo SMTP, Exchange Online intentará ofrecer el uso del protocolo TLS en su lugar.
- En el caso de que el servidor de correo externo (el servidor de origen) también admita la opción de TLS, el canal de comunicación se implementará mediante TLS.
- En el caso de que el servidor de correo externo (el servidor de origen) no admita la opción de TLS, el canal de comunicación se implementará mediante SMTP.
En el siguiente diagrama, podemos ver un ejemplo de un escenario de flujo de correo en el que el servidor de correo externo dirige el servidor Exchange Online, utilizando el nombre de host, que aparece en el registro MX.
El servidor de correo externo puede “elegir” entre utilizar el protocolo de correo no cifrado - SMTP o el protocolo de correo cifrado - TLS.
P: ¿Cómo sé que el nombre de host de Exchange Online que representa mi dominio admite TLS oportunista?
A: Intentaremos crear una sesión de telnet SMTP con el nombre de host de Exchange Online que representa al inquilino de Office 365.
En nuestro ejemplo, mi nombre de dominio público que estaba registrado en Office 365 es: o365info.com
El nombre de host que aparece en el registro MX para el nombre de dominio: o365info.com es:
o365info-com.mail. proteccion.outlook.com
¿Cuándo intentaré hacer telnet con este nombre de host usando el comando?
Telnet o365info-com.mail.protection.outlook.com 25
En la siguiente captura de pantalla, podemos ver que después de escribir el comando EHLO, el servidor Exchange Online responde con una lista de "opciones admitidas". Una de estas opciones es el comando - 250-STARTTLS
En esta etapa, no podemos estar seguros del soporte del host Force TLS o TLS oportunista
Para poder verificar si el servidor (Exchange Online) también admite la sesión "SMTP estándar", intentaremos crear una sesión SMTP estándar usando el siguiente comando:
Correo de:
En la siguiente captura de pantalla podemos ver que el servidor de Exchange Online responde con la “respuesta”: 250 2.1.0 Remitente OK
El significado es que podemos usar una sesión "SMTP estándar".
Dirigir Exchange Online utilizando el nombre de host smtp.office365.com
La entidad adicional de Exchange Online está representada por el nombre de host smtp.office365.com
Técnicamente hablando, la “smtp.office365.com entidad Exchange Online ” puede representar todos los principios de Office 365 alojados en la infraestructura de Exchange Online.
En otras palabras, en caso de que un servidor de correo necesite dirigirse al servidor de correo de Exchange Online que representa un inquilino específico de Office 365 (nombre de dominio público específico), el servidor de correo externo puede dirigirse al host smtp.office365 .com, en lugar de buscar el registro MX que representa los dominios particulares de Office 365.
El objetivo principal de la entidad “Exchange Online smtp.office365.com” es habilitar únicamente la comunicación por correo segura, es decir, Forzar TLS.
En otras palabras, la única forma de abordar la entidad smtp.office365.com de Exchange Online es mediante TLS.
Un ejemplo de un escenario en el que necesitamos abordar la entidad smtp.office365.com de Exchange Online es un escenario; en el que tenemos una aplicación habilitada para correo o un dispositivo habilitado para correo que necesita "usar" el servidor Exchange Online para enviar correo.
En el pasado, la única forma posible de implementar este tipo de escenario era configurando el dispositivo/aplicación habilitado para correo para dirigirse al nombre de host -
smtp.office365.com
El mayor obstáculo de este requisito fue que la mayoría de los dispositivos habilitados para correo no son compatibles con TLS.
Hoy en día, la solución es más sencilla, porque podemos configurar el dispositivo habilitado para correo para utilizar el nombre de host "estándar" de Exchange Online sin la necesidad de un requisito obligatorio para utilizar TLS.
Nota: Para habilitar el dispositivo/aplicación habilitado para correo para dirigirse al servidor Exchange Online mediante SMTP y enviar correo a un destinatario interno + externo, necesitaremos crear manualmente un conector entrante que identifique este cliente de correo. por su dirección IP pública.
En el siguiente diagrama, podemos ver un ejemplo de un flujo de correo que generalmente se implementa cuando un dispositivo o aplicación habilitado para correo se dirige al servidor Exchange Online mediante el nombre de host predefinido smtp.office365.com
P: ¿Cómo sé que el nombre de host de Exchange Online smtp.office365.com solo admite ¿Forzar TLS?
A: Intentaremos crear una sesión de telnet SMTP con el nombre de host de Exchange Online smtp.office365.com
¿Cuándo intentaré hacer telnet con este nombre de host usando el comando?
Telnet smtp.office365.com 25
En la siguiente captura de pantalla, podemos ver que después de escribir el comando EHLO, el servidor Exchange Online responde con una lista de "opciones admitidas". Una de estas opciones es el comando - 250-STARTTLS
En esta etapa, no podemos estar seguros del soporte del host Force TLS o TLS oportunista
Para poder verificar si el servidor (Exchange Online) también admite sesión “SMTP estándar”, usaremos el comando:
Correo de:
En la siguiente captura podemos ver que el servidor de Exchange Online responde con la “respuesta”:
530 5.7.57 SMTP; El cliente no fue autenticado para enviar correo anónimo durante MAIL FROM
El significado es que no podemos utilizar una sesión "SMTP estándar".
Nota: El cliente telnet cmd estándar no admite la opción de utilizar el protocolo TLS.
Artículo siguiente
El siguiente artículo (Configuración de la opción de Forzar TLS en el entorno local de Exchange | Parte 4#12) de la serie de artículos TLS está dedicado al tema de: Configuración de la opción de Forzar TLS en el entorno local de Exchange.