Configuración de la opción Forzar TLS en el entorno local de Exchange |Parte 4#12
En el artículo actual, revisaremos el tema de Force TLS en un entorno basado en Exchange local.
En el entorno basado en Exchange local, podemos optar por implementar la opción de Forzar TLS usando dos opciones.
1. Seguridad del dominio
Esta opción define un conjunto de conectores de correo y ajustes de configuración que sirven para crear un canal de comunicación seguro, es decir, cifrado de datos y autenticación mutua, en un escenario en el que las dos partes utilizan la infraestructura de correo local de Exchange.
En otras palabras, no podemos utilizar la opción de Seguridad de Dominio en caso de que la infraestructura de correo del “otro lado” no esté basada en la arquitectura del servidor Exchange.
La opción de Seguridad de dominio (TLS mutua) se implementa activando una opción denominada - DomainSecureEnabled
Nota: La opción de Seguridad de dominio se puede utilizar en el servidor local Exchange 2010 y en versiones posteriores del servidor Exchange.
TlsAuthLevel
2. TlsAuthLevel
Para poder configurar la opción de Forzar TLS con una infraestructura de correo local que no sea Exchange, necesitaremos configurar un parámetro específico llamado -TlsAuthLevel.
El uso de la opción TlsAuthLevel nos permite definir una necesidad obligatoria para usar TLS y también incluir la opción para especificar el método exacto que queremos usar para identificar a la "otra parte" que participa en el flujo de correo.
Exchange local versus Exchange en línea
En cuanto al tema de Force TLS, existen un par de diferencias importantes entre Exchange on-Premises entorno y entorno basado en Exchange Online.
1. Exchange Online no admite la opción de Seguridad de Dominio futuro.
Aunque la arquitectura de Exchange Online se basa en la arquitectura de Exchange 2013, la infraestructura de correo de Exchange Online es diferente de la arquitectura local de Exchange.
En caso de que necesitemos implementar un escenario de Forzar TLS entre la infraestructura de correo local de Exchange y la infraestructura de correo de Exchange Online, necesitaremos utilizar la "otra opción" denominada: TlsAuthLevel.
2. Interfaz de gestión
En el entorno local de Exchange, la única forma de configurar la opción de Forzar TLS usando el parámetro TlsAuthLevel es mediante la interfaz de comandos de PowerShell.
En un entorno basado en Exchange Online, el proceso de configuración de Force TLS se implementa mediante la interfaz gráfica de administración web de Exchange Online.
La configuración de Force TLS se implementa mediante un asistente gráfico, que utilizamos para configurar todos los parámetros requeridos que necesitamos para Force TLS.
Exchange Online incluye la opción de establecer todas las configuraciones requeridas para Force TLS mediante el uso de una interfaz de comando de PowerShell, pero la mayoría de las veces usaremos la interfaz gráfica de administración web de Exchange Online.
Configurar los ajustes de TLS en el entorno local de Exchange y en el entorno de correo mixto | Los desafios
Antes de comenzar con la descripción de la configuración de Forzar TLS en un entorno basado en Exchange local, es importante que seremos conscientes de un par de “obstáculos” que fácilmente pueden llevarnos a la confusión y la desorientación.
- La diferencia entre la interfaz GUI de Exchange y Exchange PowerShell: la interfaz gráfica de Exchange no incluye todas las opciones que existen al usar Exchange PowerShell. Algunas de las opciones relacionadas con la configuración de TLS solo existen cuando se usa PowerShell.
- La diferencia entre las versiones de Exchange, interfaz GUI: en nuestro artículo, proporcionaremos ejemplos de la configuración TLS utilizando la interfaz del servidor local de Exchange 2010. La lógica que se implementa en Exchange 2013 local es similar, pero existen algunas diferencias entre las interfaces gráficas de las dos versiones de Exchange.
- La diferencia entre Exchange local y Exchange Online: desde un punto de vista técnico, Exchange Online utiliza una arquitectura y un concepto muy similares en comparación con un servidor Exchange 2013. Con respecto al tema de los conectores de correo y la configuración de TLS, la opción de administración de Exchange Online y los ajustes de configuración relacionados con el conector de correo de Exchange y la configuración de TLS son significativamente diferentes de la interfaz y las opciones de “Exchange local”.
- La configuración requerida que debe implementarse en Enviar + Conector de recepción y el parámetro diferente entre el Enviar + Conector de recepción.
Técnicamente En términos generales, las configuraciones de TLS no tienen el requisito obligatorio de configurarse en la cabina del conector Exchange, es decir, Exchange Enviar + Conector de recepción.
Sin embargo, muchas veces, la empresa El requisito de usar Force TLS dictará la necesidad de configurar TLS en la cabina del conector. Esta "necesidad" plantea otra dificultad porque las opciones y la interfaz del conector de envío local de Exchange frente al conector de recepción local de Exchange no son idénticas.
Configuración de la opción de forzar TLS en el entorno local de Exchange
En el artículo actual, revisaremos cómo configurar la opción de “Forzar TLS” en Exchange. 2010 en las instalaciones.
Solo un recordatorio rápido: de forma predeterminada, el servidor Exchange está configurado para usar la opción de TLS oportunista.
- Cada vez que ese servidor Exchange intente conectarse a otro servidor de correo, intentará establecer el canal de comunicación mediante TLS.
- Cada vez que el servidor de correo externo intenta comunicarse con el servidor Exchange, el servidor Exchange "ofrecerá" establecer el canal de comunicación mediante TLS.
De forma predeterminada, Office 365 envía correo mediante cifrado TLS, siempre que el servidor de destino también admita TLS. Si su organización asociada admite TLS, solo necesita crear un conector si desea imponer ciertas restricciones de seguridad; por ejemplo, siempre desea que se aplique TLS o requiere verificación de certificado cada vez que su socio envía correo a su organización.
La pregunta que puede aparecer en nuestra mente podría ser:
P: Si Exchange está configurado para usar la opción de TLS oportunista y siempre tratar de crear un vínculo de comunicación seguro, ¿por qué o cuándo debo usar la opción de Forzar TLS?
A: La respuesta a esta pregunta podría ser
1. La empresa debe asegurarse de que solo esté habilitada la comunicación TLS.
Necesidad de seguridad o un requisito normativo específico, que dictaminan la necesidad de verificar que el canal de comunicación entre nuestro servidor Exchange y el servidor de destino es un canal de comunicación cifrado que utiliza el protocolo TLS.
En otras palabras, no estamos dispuestos a correr el riesgo de que el enlace de comunicación con una organización particular o un servidor de correo específico se implemente mediante el uso de protocolos no cifrados como SMTP. . Es un escenario en blanco y negro, en el que el único que aceptamos crear el canal de comunicación por correo es mediante el uso del protocolo TLS.
2 La necesidad de identificar el “otro servidor de correo. ”
Además de la necesidad obligatoria de crear un canal de comunicación de correo seguro, queremos definir configuraciones de seguridad adicionales que se relacionarán con la sesión TLS con el servidor de correo de destino.
Por ejemplo, cada uno de los servidores de correo debe tener un certificado que se utilizará para cifrar los datos que fluyen en el canal de comunicación y puede usarse para la autenticación; cada servidor de correo puede "presentar" su certificado como una forma de probar su identidad legítima. .
En algunos escenarios, además de la necesidad obligatoria de cifrar el canal de comunicación mediante TLS, también necesitamos demostrar sin lugar a dudas la identidad del "otro servidor de correo" especificando un parámetro particular que debe aparecer en su certificado de servidor.
Por ejemplo, verifique que el servidor de correo de destino utilice un certificado público y verifique que su nombre de host aparezca en el certificado público.
Para poder cumplir con estos requisitos, necesitaremos utilizar la opción de Forzar TLS.
1. Configurar la opción de Seguridad de dominio (TLS mutua) en el entorno local de Exchange
Como se mencionó, en un entorno basado en Exchange, hay dos tipos de configuración de Force TLS utilizando conectores de correo.
- Seguridad de dominio (TLS mutua)
- TlsAuthLevel
En la sección actual, revisaremos brevemente la característica local de Exchange: Seguridad de dominio y en En la siguiente sección, revisaremos la opción de TlsAuthLevel
La opción de Seguridad de dominio es relevante solo para un escenario en el que las "dos partes" utilizan la infraestructura de correo local de Exchange.
La opción de Seguridad de dominio (Mutual TLS) se puede utilizar en la versión de servidor Exchange 2010 y 2013.
Una divulgación adecuada es que pude obtener información clara e informativa sobre los parámetros específicos que se implementan al usar la opción de Seguridad de dominio (TLS mutuo).
La solución de Seguridad de Dominio (Mutual TLS) se implementa en un escenario que se describe como “relación de socio ”. Dos organizaciones de Exchange diferentes que desean construir un canal de comunicación seguro entre ellas.
Las configuraciones requeridas para Seguridad de dominio (Mutual TLS) deben implementarse en cada uno de los “ lados” que están involucrados en las relaciones.
Cuando se utiliza la opción Seguridad de dominio (Mutual TLS), los clientes de Exchange como Outlook también están involucrados. en el proceso, y tienen la capacidad de "comprender" cuándo se envió una dirección de correo electrónico desde la "otra organización" que utiliza Seguridad de dominio (Mutual TLS) con “nuestra organización de Exchange”.
En el siguiente diagrama podemos ver un ejemplo de la Seguridad de Dominio (Mutual TLS) entre dos Organizaciones basadas en intercambio.
La "confianza" se crea entre la organización de Exchange denominada o365pilot.com y la organización de Exchange (otra organización) que está representada por el nombre de dominio público: gracias por compartir .org
No entraremos en los detalles específicos de la configuración requerida para usar la opción de Seguridad de dominio ( TLS mutuo)
Sin embargo, en general, para realizar la tarea de configurar la opción de Seguridad de Dominio (Mutual TLS) En el entorno local de Exchange, necesitaremos crear dos conectores de correo:
Conector de envío y Conector de recepciónr que se utilizará para atender el flujo de correo entrante y saliente con el “socio”.
Fase 1#2: configurar la opción de Habilitar seguridad de dominio |Conectores de envío y recepción
Cuando creamos el Conector de envío requerido, en la pestaña Red necesitaremos marcar la opción - Habilite la seguridad del dominio (autenticación mutua TLS).
Cuando creamos el Conector de recepción requerido, en la pestaña Red necesitaremos marcar la opción - Habilite la seguridad del dominio (autenticación mutua TLS).
Fase 2#2: uso del comando de PowerShell Set-TransportConfig
Necesitaremos usar dos comandos de PowerShell, que establecerán los parámetros requeridos en el conector de envío y Conector de recepción
En nuestro escenario, el comando de PowerShell que usaremos para configurar la Seguridad del dominio (Mutual TLS) con la “otra organización de Exchange” representada por el nombre de dominio thankyouforsharing.orges:
Set-TransportConfig -TLSSendDomainSecureList thankyouforsharing.orgEl siguiente comando de PowerShell configurará el Conector de recepción
Set-TransportConfig -TLSReceiveDomainSecureList o365info.comAdjunto algunas citas de un artículo de Microsoft, sobre el tema de - Seguridad de dominio (TLS mutua):
TLS mutua La autenticación TLS mutua difiere de TLS en que normalmente se implementa TLS. Normalmente, cuando se implementa TLS, se utiliza únicamente para proporcionar confidencialidad en forma de cifrado. No se produce ninguna autenticación entre el remitente y el receptor.
Además, a veces, cuando se implementa TLS, solo se autentica el servidor receptor. Esta implementación de TLS es típica de la implementación HTTP de TLS. Esta implementación,
donde solo el servidor receptor se autentica, es SSL.
Con la autenticación TLS mutua, cada servidor verifica la identidad del otro servidor validando un certificado proporcionado por ese otro servidor. En este escenario, donde se reciben mensajes de dominios externos a través de conexiones verificadas en un entorno de Exchange 2013, Microsoft Outlook muestra un icono de Dominio protegido.
Seguridad del dominio La seguridad del dominio es el conjunto de funciones, como la administración de certificados, la funcionalidad del conector y el comportamiento del cliente Outlook, que habilita TLS mutuo como una tecnología útil y manejable. La seguridad del dominio no se admite cuando el correo electrónico saliente se enruta a través de un servidor de acceso de cliente de Exchange 2013.
DominioSecureEnabled
El parámetro DomainSecureEnabled es parte del proceso para habilitar la autenticación mutua de Seguridad de la capa de transporte (TLS) para los dominios atendidos por este conector de envío. La autenticación TLS mutua funciona correctamente solo cuando se cumplen las siguientes condiciones:
El valor del parámetro DomainSecureEnabled debe ser $true.
El valor del parámetro DNSRoutingEnabled debe ser $true.
El valor del parámetro IgnoreStartTLS debe ser $false.
El carácter comodín (*) no se admite en dominios configurados para autenticación TLS mutua. El mismo dominio también debe estar definido en el conector de recepción correspondiente y en el atributo TLSReceiveDomainSecureList de la configuración de transporte.
validando un certificado proporcionado por ese otro servidor, de modo que los clientes no se incluyan en absoluto. Establecemos un canal SMTP seguro entre dos servidores Exchange, normalmente a través de Internet.
Los clientes de correo como Outlook y Outlook Web App sabrán que se ha establecido la seguridad del dominio. Se mostrará un icono verde con una marca de verificación en cada mensaje intercambiado entre servidores en los que se implemente la seguridad del dominio.
Seguridad de dominio se refiere al conjunto de funcionalidades de Microsoft Exchange Server 2010 y Microsoft Office Outlook 2007 que proporciona una alternativa de costo relativamente bajo a S/MIME u otras soluciones de seguridad a nivel de mensajes. El objetivo del conjunto de funciones de Seguridad de dominio es proporcionar a los administradores una forma de gestionar rutas de mensajes seguras a través de Internet con socios comerciales. Una vez configuradas estas rutas de mensajes seguras, los mensajes que han recorrido con éxito la ruta segura desde un remitente autenticado se muestran a los usuarios como Dominio protegido en la interfaz de Outlook y Microsoft Office Outlook Web App.
Domain Security utiliza autenticación mutua de Seguridad de la capa de transporte (TLS) para proporcionar autenticación y cifrado basados en sesiones. La autenticación TLS mutua difiere de TLS en la forma en que se implementa habitualmente. Normalmente, cuando se implementa TLS, el cliente verifica que la conexión se conecta de forma segura al servidor deseado validando el certificado del servidor. Esto se recibe como parte de la negociación TLS. En este escenario, el cliente autentica el servidor antes de que el cliente transmita datos. Sin embargo, el servidor no autentica la sesión con el cliente.
Con la autenticación TLS mutua, cada servidor verifica la conexión con el otro servidor validando un certificado proporcionado por ese otro servidor. En este escenario, donde se reciben mensajes de dominios externos a través de conexiones verificadas en un entorno de Exchange 2010, Outlook 2007 muestra un icono de Dominio protegido.
2. Configurar Force TLS en Exchange usando TlsAuthLevel
En esta sección, revisaremos la implementación de Force TLS en un entorno basado en Exchange local utilizando la opción de TlsAuthLevel.
Como se mencionó, el uso de "TlsAuthLevel" se implementará en un escenario en el que el "otro servidor de correo" no sea un servidor basado en Exchange o no sea un servidor basado en Exchange local.
Por ejemplo, en caso de que necesitemos configurar la opción de Forzar TLS entre nuestro Exchange on- Para el servidor local y el servidor Exchange Online, necesitaremos usar la opción TlsAuthLevel, porque a pesar de que Exchange Online se basa en la arquitectura del servidor Exchange, Exchange Online es diferente del servidor Exchange local.
La sección actual incluye dos partes.
- La configuración requerida para configurar la opción Forzar TLS para Exchange local Conector de envío.
- La configuración requerida para configurar la opción Forzar TLS para Exchange local Recibir conector.
1. Conector de envío local de Exchange | Configurar la opción de forzar TLS
En la sección actual, nos centraremos en la configuración requerida de Forzar TLS en un escenario en el que el "otro lado" no es un servidor Exchange local necesario.
En este escenario, necesitaremos usar un comando de PowerShell que nos ayudará a establecer los valores requeridos para el parámetro: TlsAuthLevel.
Cuando activamos el parámetro TlsAuthLevel, “Activamos” la opción de Forzar TLS.
A la “activación” del parámetro TlsAuthLevel le sigue una de tres opciones posibles que configuran la relación con el “otro servidor de correo”.
Podemos elegir entre tres opciones posibles como valor para el TlsAuthLevel
Opción 1: Solo cifrado
La opción de - EncryptionOnly es adecuada para un escenario en el que el servidor de correo de destino utiliza un certificado que no puede usarse para “identificar” el servidor de correo. Por ejemplo, una escena en la que el servidor de correo de destino utiliza un certificado autofirmado.
En este escenario, el certificado del servidor de correo de destino se utilizará únicamente para cifrar los datos que pasan a través del canal de comunicación.
En otras palabras, cuando configuramos la opción EncryptionOnly, el significado es que no necesitamos identificar el servidor de correo del otro lado comprobando su certificado de servidor. El enfoque principal está en la necesidad de cifrar el canal de comunicación mediante TLS.
Opción 2: Validación del certificado
La opción de - CertificateValidation es adecuada para un escenario en el que el servidor de correo de origen (servidor Exchange en nuestro escenario) necesita verificar la identidad del servidor de correo de destino.
El servidor de correo de destino puede probar su identidad proporcionando un certificado público creado por la CA pública (autoridad de certificación).
Opción 3: Validación de dominio
Se puede considerar la opción - DomainValidation es la opción más restrictiva.
En este caso, el requisito obligatorio incluirá los siguientes apartados:
- La necesidad de cifrar los datos que pasan por el canal de comunicación.
- La necesidad de identificar el servidor de destino. El servidor de correo de destino deberá proporcionar un certificado público legítimo creado por CA.
- El certificado que proporciona el servidor de destino debe incluir una de las siguientes opciones: el FQDN o el nombre de dominio que se configura mediante el parámetro adicionalTlsDomain
Cuando usemos la opción de DomainValidation también necesitaremos proporcionar el valor adicional de TlsDomain.
Al usar la opción de TlsDomain, necesitaremos "activar" el parámetro adicional llamado RequireTls
En el siguiente diagrama, podemos ver la variedad de opciones y combinaciones relacionadas con Forzar TLS.
Para poder demostrar la sintaxis de comando de PowerShell requerida que debemos usar cuando queremos configurar la opción de Forzar TLS , usemos el siguiente escenario:
Queremos implementar una configuración Force TLS con nuestro socio empresarial que utiliza el nombre de dominio público: < fuerte>contoso.com
En nuestro escenario, todos hemos creado un conector de envío que enruta el mensaje de correo electrónico enviado a el destinatario del dominio contoso.com
El nombre del conector de envío es: Contoso
Escenario 1: utilizar la opción Forzar TLS solo con el fin de cifrar el flujo de correo
En este escenario, no es necesario identificar el otro servidor de correo.
El nivel TlsAuthLevel se establecerá configurando el parámetro EncryptionOnly
La sintaxis del comando de PowerShell es:
Set-SendConnector -Identity Contoso -TlsAuthLevel EncryptionOnlyEscenario 2: cifrar el flujo de correo + solicitar un certificado de servidor válido del otro servidor de correo
En este escenario, necesitamos identificar el otro servidor de correo. El otro servidor de correo deberá proporcionar un certificado de servidor válido.
El nivel TlsAuthLevel se establecerá configurando el parámetro CertificateValidation
La sintaxis del comando de PowerShell es:
Set-SendConnector -Identity Contoso -TlsAuthLevel CertificateValidationEscenario 3: cifrar el flujo de correo + solicitar un certificado de servidor válido del otro servidor de correo + verificar que el certificado del servidor incluya un nombre de host específico
En este escenario, queremos usar la opción de Forzar TLS y además de la necesidad de cifrar la línea de comunicación, queremos poder identificar el servidor de correo de Contoso, verificar que utilice un certificado público confiable y Además, verifique que el certificado del servidor incluya el nombre de dominio: contoso.com.
El nivel TlsAuthLevel se establecerá configurando el parámetro DomainValidation
Al usar la opción de - DomainValidation, necesitaremos configurar dos parámetros adicionales
Parámetro TlsDomain: el parámetro TlsDomain se utiliza para definir el nombre de host específico o el nombre de dominio que debe incluirse en el certificado del servidor que el "otro servidor de correo" presentó como prueba de su identidad.
RequireTls $true
La sintaxis del comando de PowerShell es:
Set-SendConnector -Identity contoso3 -RequireTls $true -TlsAuthLevel DomainValidation -TlsDomain *.contoso.comAdjunto una cita de un artículo de Microsoft TechNet:
TlsAuthLevel
El parámetro TlsAuthLevel especifica el nivel de autenticación TLS que se utiliza para las conexiones TLS salientes establecidas por este conector de envío. Los valores válidos son:
EncryptionOnly: TLS se utiliza únicamente para cifrar el canal de comunicación. No se realizó autenticación de certificado.
CertificateValidation: TLS se utiliza para cifrar el canal y la validación de la cadena de certificados, y se realizan verificaciones de listas de revocación.
DomainValidation: además del cifrado de canal y la validación de certificados, el conector de envío también verifica que el FQDN del certificado de destino coincide con el dominio especificado en el parámetro TlsDomain. Si no se especifica ningún dominio en el parámetro TlsDomain, el FQDN en el certificado se compara con el dominio del destinatario.
No puede especificar un valor para este parámetro si el parámetro IgnoreSTARTTLS está establecido en $true o si el parámetro RequireTLS es establecido en $falso.
El parámetro TlsDomain especifica el nombre de dominio que utiliza el conector de envío para verificar el FQDN del certificado de destino al establecer una conexión segura TLS.
Este parámetro se usa solo si el parámetro TlsAuthLevel está establecido en DomainValidation.
Un valor para este parámetro es necesario si:
El parámetro TLSAuthLevel está establecido en DomainValidation.
El parámetro DNSRoutingEnabled está establecido en $false (conector de envío de host inteligente).
2. Conector de recepción local de Exchange | Configurar la opción de forzar TLS
Con respecto a la configuración requerida para implementar la opción Force TLS en el conector de recepción local de Exchange, necesitaremos usar una combinación de dos parámetros:
- Mecanismo de autenticación
- RequireTLS - este valor “activa” la opción de Forzar TLS
En la siguiente captura de pantalla, podemos ver un ejemplo de los parámetros predeterminados del conector de recepción local de Exchange.
Podemos ver que el parámetro AuthMechanism incluye un par de opciones, incluido TLS.
Además, podemos ver que el valor predeterminado del parámetro RequireTLS está establecido en False>.
En nuestro escenario, queremos implementar la opción de Forzar TLS con respecto al correo que nos envía un socio representado por el nombre de dominio: graciasporcompartir.org.
Ya hemos creado un conector de recepción en el servidor local de Exchange llamado - EX01 y el nombre del conector es -thankyouforsharing.org
Para poder configurar el conector de recepción local de Exchange para usar Force TLS, necesitaremos establecer el valor del parámetro RequireTLS en verdadero.
Los comandos de PowerShell que usaremos en nuestro escenario son:
Set-ReceiveConnector EX01\<strong><em>thankyouforsharing-receive</em></strong> -RequireTLS $trueAdjunto algunas citas del artículo de Microsoft:
El parámetro AuthMechanism especifica los mecanismos de autenticación anunciados y aceptados. Las opciones de autenticación son Ninguna, Tls, Integrada, BasicAuth, BasicAuthRequireTLS, ExchangeServer y ExternalAuthoritative. Puede ingresar varios valores para el parámetro AuthMechanism separando los valores con comas.
Si el parámetro RequireTLS está configurado en $true, el parámetro AuthMechanism debe estar configurado en TLS (Seguridad de la capa de transporte). Si configura el parámetro AuthMechanism en BasicAuthRequireTLS, también debe seleccionar BasicAuth y TLS.
El valor del parámetro AuthMechanism ExternalAuthoritative solo puede coexistir con el valor Tls. Si configura el parámetro AuthMechanism en ExternalAuthoritative, el parámetro PermissionGroups también debe tener el valor
Artículo siguiente
El siguiente artículo (Forzar TLS | Entorno de Exchange Online versus entorno local de Exchange | Parte 5#12) de la serie de artículos TLS, está dedicado al tema de: las diferencias que existen entre el entorno basado en Exchange local y el Entorno basado en Exchange Online con respecto a los conectores de correo y la configuración de TLS y una descripción de los caracteres del escenario que usaremos en los próximos artículos de la serie de artículos TLS que nos ayudarán a demostrar el flujo TLS opcional entre los entornos basados en Exchange on-Premises y Exchange Online. .