¿Debo utilizar un único espacio de nombres para la infraestructura de Exchange? | Parte 1#2 | Parte 17#36
El artículo actual está dedicado al tema interesante y no tan claro: el espacio de nombres de la infraestructura de Exchange.
La arquitectura del servidor Exchange nos permite utilizar una interfaz diferente con clientes Exchange internos frente a clientes Exchange externos basados en varios espacios de nombres.
Las principales preguntas que intentaré responder en este artículo son:
- ¿Es bueno o malo utilizar un espacio de nombres diferente?
- ¿Cuáles son los caracteres del entorno Exchange que se basa en dos espacios de nombres diferentes?
Al leer el título del artículo, el resultado son muchas preguntas que pueden surgir:
- ¿Cuál es el significado de “esquema de nombres públicos” o “espacio de nombres únicos” para la infraestructura de Exchange?
- ¿Por qué necesito utilizar un único esquema de nomenclatura pública?
- ¿Cómo está configurada mi infraestructura Exchange actual?
Creo que es importante dedicar tiempo porque muy pronto todos los administradores de Exchange tendrán que abordar el tema de usar UN esquema de nombres públicos para la infraestructura de Exchange.
Relacionando las preguntas anteriores
P1 - ¿Cuál es el significado del esquema de denominación pública para la infraestructura de intercambio?
P2: ¿Por qué necesito utilizar UN esquema de nomenclatura pública?
No podemos responder a esta pregunta con una respuesta breve pero, a pesar de ese obstáculo, intentaré responder a esta pregunta en breve y, para obtener una respuesta más detallada y completa; necesitarás leer el resto del artículo.
Los objetos de infraestructura de Exchange se "direccionan" mediante nombres de host y direcciones URL.
La comunicación entre el cliente de Exchange y la comunicación entre los servidores de Exchange se implementa dirigiéndose a un servidor de Exchange en particular utilizando su nombre de host.
El servidor Exchange CAS publica servicios web de Exchange para sus clientes proporcionándoles una dirección URL que incluye el nombre del host.
Arquitectura de intercambio | Convenciones de espacios de nombres anteriores versus modernas
Arquitectura del servidor Exchange Incluye capacidad integrada para implementar una interfaz diferente con clientes Exchange internos y externos.
La Realización de las diferentes interfaces basadas en tres elementos principales
- Protocolo de comunicación
- Protocolo de autenticación
- Espacio de nombres
Arquitectura de servidor Exchange anterior versus arquitectura Exchange moderna | Interfaz con clientes internos de Exchange frente a clientes externos de Exchange.
En versiones anteriores del servidor Exchange, como Exchange 2003, 2007 y 2010, la convención típica era configurar el servidor Exchange para usar una interfaz diferente con clientes Exchange internos versus clientes Exchange externos.
La idea principal detrás de esta configuración fue que la red interna tiene necesidades y caracteres diferentes en comparación con la red externa y, por esta razón, existe la necesidad de configurar Exchange para usar una configuración diferente al interactuar con clientes de Exchange internos versus clientes de Exchange externos.
En un entorno Exchange moderno como Exchange 2013, la diferenciación entre los dos entornos (red interna versus pública) disminuye y desaparece.
En otras palabras, a pesar de que una arquitectura Exchange 2013 incluye la capacidad de implementar una interfaz diferente con clientes Exchange internos versus clientes Exchange externos, la mayoría de las veces, la práctica estándar es usar una interfaz idéntica con clientes Exchange internos versus clientes Exchange 2013. clientes externos de Exchange.
Por ejemplo:
En versiones anteriores del servidor Exchange (Exchange 2003, 2007, 2010), una configuración común era utilizar un protocolo de comunicación diferente y un espacio de nombres diferente con los clientes Exchange internos frente a los clientes Exchange externos.
- La interfaz con el cliente Outlook interno se implementó utilizando el protocolo RPC y el espacio de nombres interno basado en un nombre de dominio interno como el sufijo de dominio "local".
- La interfaz con clientes externos de Outlook se implementó utilizando el protocolo RPC/HTTPS (Outlook Anywhere) y un espacio de nombres público basado en un nombre de dominio público como el sufijo de dominio “com”.
Nota: La definición de Exchange Server 2010 como parte de la "versión anterior del servidor Exchange" no es una "definición científica". Muchas veces, las organizaciones implementaron la infraestructura de Exchange 2010 basándose en las características de los entornos de correo modernos.
La convención estándar, que dicta la necesidad de diferenciar y separar la interfaz de Exchange con clientes internos de Exchange frente a los clientes externos de Exchange, cambió con el tiempo a una nueva convención que se basa en una "simplificación del concepto" en la que la interfaz de Exchange con clientes internos de Exchange frente a Clientes Exchange externos configurados como una interfaz idéntica.
Por ejemplo, en un entorno Exchange 2013, el único protocolo de comunicación disponible con el cliente Outlook es Outlook Anywhere (RPC\HTTPS o MAPI\HTTPS).
En otras palabras, no podemos establecer un protocolo de comunicación diferente para el cliente Outlook interno y el cliente Outlook externo.
Con respecto al tema del "espacio de nombres", teóricamente, Exchange 2013 nos permite usar la opción de "espacio de nombres interno" para el cliente Outlook interno frente al espacio de nombres externo para un cliente Outlook externo, pero la mayoría de las veces no implementaremos esta opción.
Otro elemento que se relaciona con la "nueva tendencia" en la que "cancelamos" la diferente interfaz de Exchange con clientes internos de Exchange versus clientes externos de Exchange se debe a que, en la actualidad, el certificado público no puede ni admitirá nombres de host que incluyan nombres no sufijo de nombre de dominio público o público.
En otras palabras, incluso en el caso de que decidamos continuar usando el espacio de nombres interno y externo de Exchange cuando necesitemos renovar nuestro certificado público, no podemos solicitar incluir el nombre de host interno como parte del certificado.
Nota: puede leer más información sobre el nuevo estándar de certificado público en el artículo - Certificado SAN público | Soporte obsoleto en el nombre del servidor interno | Parte 19#36
Infraestructura de Exchange existente basada en espacios de nombres internos y externos
En la sección anterior, mencionamos que el entorno moderno de Exchange avanza hacia la consolidación o unificación de la interfaz de Exchange con clientes internos de Exchange frente a clientes externos de Exchange.
Sin embargo, en realidad, hay muchas organizaciones que todavía utilizan la convención reciente en la que implementamos dos interfaces de Exchange diferentes con clientes de Exchange internos frente a clientes de Exchange externos.
En las siguientes secciones, revisaremos algunos ejemplos de este tipo de infraestructura en las que utilizamos dos interfaces Exchange diferentes, los caracteres de este entorno y el flujo que implementa entre el servidor Exchange y su cliente.
Al leer la información, podría sentir que mi opinión es que la organización que utiliza la "separación" de la interfaz de Exchange debería trabajar para unificar esta interfaz de Exchange en una interfaz global.
El próximo artículo - Infraestructura de intercambio | Implementación de un esquema de espacio de nombres de dominio único | Parte 2#2 | La Parte 18#36, Tratará la parte "cómo hacer" en un escenario en el que decidimos utilizar un único espacio de nombres con clientes internos de Exchange frente a clientes externos de Exchange.
Infraestructura de Exchange: nombres de host y FQDN
La mayoría de las veces, cuando utilizamos el término "Nombre de host", nos referimos a otro término: FQDN.
El FQDN es el nombre “completo” o “completo” de un host que incluye dos partes:
1. El nombre de host
Con respecto al tema de Nombres de host, cada vez que instalemos un nuevo servidor, necesitaremos proporcionarle al servidor un nombre único que podamos considerar como el nombre de host del servidor.
Si queremos ser más precisos, en un entorno basado en Microsoft, el nombre del host del servidor Exchange es un nombre NetBIOS.
Nota: Muchas veces, “adjuntaremos” nombres de host adicionales al servidor Exchange mediante el uso de la infraestructura DNS, pero analizaremos este tema más adelante.
2. El nombre de dominio
De forma predeterminada, la infraestructura de Exchange hereda su nombre de dominio del nombre de dominio de Active Directory.
En caso de que Active Directory se haya configurado con un nombre de dominio privado, la infraestructura de Exchange también utilizará el sufijo del nombre de dominio privado.
En un escenario en el que utilizamos un "espacio de nombres dual", es decir, un espacio de nombres privado y un espacio de nombres público, los clientes de Exchange internos abordarán los recursos de Exchange utilizando el FQDN interno de los servidores de Exchange y la dirección URL de Exchange que incluye el nombre de dominio interno o privado.
Los clientes externos de Exchange no pueden abordar ni acceder a los recursos de Exchange utilizando el "esquema de nombres privados" y, por esta razón, necesitaremos crear una infraestructura de espacio de nombres adicional, que utilizarán los clientes de correo "públicos" o externos de Exchange.
La posible matriz de escenarios de espacio de nombres
Para organizar las cosas en un formato claro, revisemos la posible "combinación" de espacios de nombres.
Los personajes de este escenario que repasaremos son los siguientes:
Escenario 1: espacio de nombres privado de Active Directory | Intercambiar espacio de nombres dual
En este escenario, Active Directory se basa en un espacio de nombres privado como o365info.local
La infraestructura del espacio de nombres de Exchange se basa en una infraestructura de espacio de nombres dual.
- Los clientes internos de Exchange abordarán los recursos de Exchange utilizando el espacio de nombres interno\privado: o365info.local
- Los clientes externos de Exchange abordarán los recursos de Exchange utilizando el espacio de nombres interno\privado: o365info.com
Escenario 2: espacio de nombres privado de Active Directory | Intercambiar espacio de nombres único
En este escenario, Active Directory se basa en un espacio de nombres privado como: o365info.local
La infraestructura del espacio de nombres de Exchange se basa en un único significado de infraestructura de espacio de nombres: el espacio de nombres privado y el público serán idénticos.
En este escenario, necesitaremos cambiar el FQDN predeterminado de los servidores Exchange que, de forma predeterminada, utilizan el nombre de dominio privado de Active Directory (o365info.com)
- Los clientes internos de Exchange abordarán los recursos de Exchange utilizando el espacio de nombres interno\privado: o365info.com
- Los clientes externos de Exchange abordarán los recursos de Exchange utilizando el espacio de nombres interno\privado: o365info.com
Escenario 3: espacio de nombres públicos de Active Directory | Intercambiar espacio de nombres único
En este escenario, Active Directory se basa en un espacio de nombres público como o365info.com
La infraestructura del espacio de nombres de Exchange se basa en una única infraestructura de espacio de nombres, es decir, el espacio de nombres público y privado serán idénticos.
En este escenario, no necesitaremos cambiar el FQDN predeterminado de los servidores Exchange que, de forma predeterminada, utilizan el nombre de dominio público de Active Directory (o365info.com).
- Los clientes internos de Exchange abordarán los recursos de Exchange utilizando el espacio de nombres interno\privado: o365info.com
- Los clientes externos de Exchange abordarán los recursos de Exchange utilizando el espacio de nombres interno\privado: o365info.com
P: ¿Por qué debería evitar utilizar la opción “Exchange dual namespace”?
R: La versión corta de la respuesta a esa pregunta es, por dos razones principales:
1. No hay nombres de servidores internos en los certificados SAN posteriores a 2015
En caso de que utilicemos la infraestructura del esquema de nombres duales de Exchange, el certificado público de Exchange deberá incluir el nombre de host interno (host que usa el nombre de dominio privado de Active Directory) y el nombre de host público.
Este tipo de configuración ya no será compatible desde el 1 de noviembre de 2015.
Nota - Si necesita leer más información sobre este tema, lea el artículo - Certificado SAN público | Soporte obsoleto en el nombre del servidor interno | Parte 19#36
2. Porque es el “camino correcto”
La “versión corta” de la respuesta es que usar la opción de infraestructura de esquema de nombres duales de Exchange en lugar de usar UN esquema de nombres públicos para la infraestructura de Exchange no es la “forma correcta”.
La razón para utilizar un espacio de nombres dual se debe a razones históricas que ya no son válidas o relevantes para el entorno moderno.
El uso de la opción de infraestructura de esquema de nomenclatura dual de Exchange complica las cosas, dificulta que el cliente de Exchange memorice dos convenciones de nomenclatura diferentes, dificulta la solución de "problemas de Exchange" y mucho más.
Microsoft Active Directory y nombre de dominio privado
Active Directory local” está representado por un nombre de dominio.
El nombre de dominio que utilizamos como nombre de dominio de Active Directory puede considerarse como “nombre de dominio privado” o “nombre de dominio público”.
Técnicamente hablando, al Directorio Activo “no le importa” si usamos un nombre de dominio privado o un nombre de dominio público.
Como se mencionó, la infraestructura predeterminada del espacio de nombres de dominio de Exchange se basa en la infraestructura de nombres de dominio de Active Directory.
Muchas organizaciones utilizan un nombre de dominio privado para Active Directory si el resultado es que la infraestructura de Exchange tendrá que utilizar dos infraestructuras de nombres de dominio.
P1: ¿Cuál es el significado de un nombre de dominio privado?
R2: La "implementación técnica" de un nombre de dominio privado es mediante el uso de un nombre de dominio que utiliza "local" como sufijo.
El sufijo de dominio "local" es un sufijo preservado y no existe la opción de comprar un nombre de dominio con el sufijo "local".
El término "nombre de dominio público" se utiliza en el caso de que hayamos comprado el nombre de dominio de un proveedor público como GoDaddy, etc.
P2: ¿Por qué Active Directory utiliza un nombre de dominio privado?
R2: En los viejos tiempos, el concepto general era que usar un nombre de dominio privado para Active Directory era el método preferido porque era una buena práctica de seguridad.
Mi opinión siempre fue que esto es sólo un mambo jumbo del personal de seguridad porque nunca logré entender la razón de esta suposición y nadie nunca pudo darme una explicación real para esta suposición.
Esta “teoría” de utilizar un nombre de dominio privado para el nombre de dominio de Active Directory se basa en una suposición errónea. La idea era que el uso de un "nombre de dominio privado" es requerido u obligatorio para proteger la red de origen privada de los riesgos y peligros que existen en la "red pública" que dañarán los recursos de la organización privada.
Utilizo el término "mambo jumbo" para describir la teoría de "usar un nombre de dominio privado" para proteger los recursos internos de la red porque simplemente no es cierto.
Los recursos internos utilizan un esquema de IP privado (Asignación de direcciones para Internet privadas). Por este motivo, no existe ninguna opción para que los recursos internos se comuniquen directamente con los "recursos externos" que utilizan una dirección IP pública.
La única forma posible es a través de “un intermediario”, como un Firewall, que protege la red interna y se basa en una regla de Firewall que “expone” hosts (servidores) de red específicos en función de lo que el administrador quiere/necesita exponer a la red pública.
Si queremos buscar una explicación psicológica adicional para la "teoría de la conspiración del dominio privado de Active Directory", es que en los viejos tiempos, la suposición subyacente era que la red de la organización es un lugar aislado que nunca debería necesitar exponerse a una "red externa". o usuario externo que reside en la red pública.
Esta suposición parece un poco radical hoy en día porque, ahora lo común es lo contrario: la mayoría de los usuarios de la organización utilizan una red pública y deben tener acceso a "recursos de red internos", como el servidor Exchange CAS cada hora.
El síndrome del señor chacal y el señor Hyde
Entonces, ¿cuál es mi punto?
Mi punto es que debido a que muchas o incluso la mayoría de las organizaciones obedecen a esta “suposición de error de dominio privado”, los resultados son bastante confusos.
Una organización que utiliza el esquema de nombres de dominio privado de Active Directory tendrá que administrar dos infraestructuras de nombres separadas.
El “esquema de nombres privados” será utilizado únicamente por el cliente de la red interna y el esquema de nombres públicos será utilizado únicamente por el cliente público.
¡Incluso puedo comparar este escenario con el de una persona que sufre la enfermedad de doble personalidad!
La tendencia de utilizar un nombre de dominio privado en paralelo al uso de un nombre de dominio “externo\público” está llegando a su fin porque el nuevo estándar o certificado público ya no admite el uso de nombres de host que tengan un nombre de dominio privado como como sufijo del nombre de dominio local.
La infraestructura pública de Exchange frente a la infraestructura privada de Active Directory.
Como se mencionó, a diferencia de Active Directory, atiende solo a clientes internos y no "se expone" al cliente público, el carácter si la infraestructura de Exchange es lo contrario.
- La infraestructura de Exchange tendrá que “exponerse” a clientes externos de Exchange ubicados en una red pública.
- La infraestructura de la red pública debe utilizar nombres de host públicos.
En el siguiente diagrama, podemos ver un ejemplo de los "dos mundos" en los que debe operar el servidor público Exchange CAS.
P: En caso de que Active Directory utilice un nombre de dominio privado, ¿cómo atiende Exchange a los clientes externos?
R: Hay dos “soluciones” posibles:
Opción 1: mantener dos esquemas de nombres de dominio diferentes
En este escenario, la infraestructura de Exchange también utilizará el espacio de nombres de dominio privado de Active Directory para comunicarse con los clientes internos de Exchange.
La infraestructura de Exchange utilizará el esquema de nombres de dominio público para comunicarse con un cliente de correo externo.
En este escenario, la infraestructura de Exchange está "vinculada" a dos nombres de dominio diferentes al mismo tiempo.
Por ejemplo, en una escena en la que usamos un servidor Exchange CAS que también brindará servicio para clientes de correo externos (servidor Exchange CAS público), un cliente Exchange interno se dirigirá al servidor Exchange CAS usando el host llamado ex01.o365info.local
El cliente Exchange externo se dirigirá al servidor CAS de Exchange público utilizando el host denominado: mail.o365info.com
Opción 2: infraestructura de Exchange utilizando un "esquema de nombre de dominio unificado"
En este escenario, la infraestructura de Exchange utilizará únicamente un esquema de nombre de dominio público empleado por clientes de correo internos y externos.
La infraestructura de Exchange estará “adjunta” o “vinculada” únicamente al nombre de dominio público y no al nombre de dominio privado de Active Directory.
Por ejemplo, en un escenario en el que usamos un servidor Exchange CAS que también brindará servicio para clientes de correo externos (servidor Exchange CAS público), un cliente Exchange interno se dirigirá al servidor Exchange CAS usando el nombre de host: mail.o365info.com
El cliente Exchange externo se dirigirá al servidor CAS de Exchange público utilizando el host denominado: mail.o365info.com
Mantenga dos escenarios de esquemas de nombres de dominio diferentes con más detalles
En la sección anterior, proporcionamos una revisión de alto nivel de los posibles "escenarios de espacio de nombres de Exchange".
En la siguiente sección, continuaremos revisando el escenario de la situación "Mantener dos esquemas de espacios de nombres de dominio diferentes" con más detalle.
En caso de que se pregunte sobre el segundo escenario de infraestructura de Exchange utilizando un "esquema de nombre de dominio unificado", tendrá que tener paciencia porque he deducido un artículo diferente para este tipo de escenario.
Las cartas de nuestro escenario son las siguientes:
- El nombre de dominio privado interno es -o365info.local
- El nombre de dominio público que tiene la empresa y que se utiliza para publicar hosts en la red externa es - o365info.com
- De forma predeterminada, cada uno de los hosts internos en Active Directory tendrá un nombre de host o, si queremos ser más precisos, un FQDN que se base en la siguiente convención de nomenclatura:
.o365info.local - Todos los "hosts internos" se registran automáticamente en el servidor DNS de Active Directory bajo el dominio denominado - o365info.local
- El servidor Exchange de la empresa sirve como "servidor Exchange público", que proporciona servicios a clientes de correo externos.
En este caso, los clientes de correo externos se dirigirán al servidor Exchange público utilizando el "esquema de nombre de dominio público", en nuestro escenario - o365info.com - El nombre público del servidor Exchange público es mail.o365info.com y el nombre adicional, que se utiliza para el servicio de detección automática para un cliente de correo externo: autodiscover.o365info.com
- El mismo servidor Exchange se publica en la red interna utilizando el FQDN interno: o365info.com
En nuestro escenario, necesitaremos construir dos infraestructuras separadas: una infraestructura para los usuarios internos de la empresa que utilizan la red interna de la empresa y una infraestructura pública adicional, que será utilizada por los usuarios externos de la empresa que se encuentran en la red pública.
La descripción de la infraestructura de Exchange Interno.
En esta parte, revisamos los estatutos y el flujo de trabajo del "entorno de red interna" que está disponible sólo para clientes internos.
1. SCP de Active Directory
La infraestructura de detección automática en el “entorno interno de Active Directory” se implementa de la siguiente manera:
El cliente interno de Exchange consultará en Active Directory los nombres de los servidores Exchange CAS existentes. El servidor Exchange CAS "sabe" cómo registrarse automáticamente en el SCP de Active Directory.
De forma predeterminada, el servidor CAS de Exchange se registrará en el punto de conexión del servicio Active Directory (SCP) utilizando el FQDN -exo1.o365info.local
2. DNS interno
El DNS interno de Active Directory configurado como autoridad para el nombre de dominio privado de Active Directory: o365info.com
De forma predeterminada, DNS de Active Directory admite la función DDNS (DNS dinámico) y los hosts autenticados, como nuestro servidor Exchange, pueden registrarse automáticamente.
En nuestro escenario, el servidor interno Exchange CAS se registra automáticamente en la zona DNS: o365info.local
El FQDN del servidor CAS de Exchange es: exo1.o365info.local
La dirección IP privada del servidor Exchange CAS es - 192.168.1.5
3. Certificado de servidor
En un entorno Exchange, el certificado del servidor es un componente obligatorio. Debido a que el servidor Exchange CAS también debería estar disponible para el cliente de correo externo, el certificado adquirido es un certificado público que incluye los siguientes nombres de host:
- o365info.local: el nombre que utiliza el servidor Exchange para su cliente de correo interno para todo tipo de comunicaciones y servicios.
- o365info.com: el nombre “externo” o público del servidor CAS de Exchange orientado al público que está “asignado” para los servicios de detección automática. El cliente de correo externo utilizará este nombre para localizar su servidor Exchange CAS (punto final de detección automática).
- o365info.com: el nombre “externo” o público del servidor CAS de Exchange público que el cliente de correo externo utiliza para acceder y comunicarse con su servidor Exchange.
Cuando un cliente interno de Exchange necesita acceder a su buzón, necesita encontrar y comunicar su servidor CAS de Exchange. En la red interna, la ruta de comunicación entre el cliente de Exchange y el servidor CAS de Exchange se basa en el siguiente flujo de trabajo:
1. El cliente de correo se conecta al Active Directory (SCP) local y solicita una lista de servidores Exchange CAS disponibles.
En nuestro escenario, Active Directory responde con una respuesta como:
https://exo1.o365info.local/autodiscver/autodiscover.xml
2. El cliente de correo conecta el servidor DNS local y solicita la dirección IP de
exo1.o365info.local (la respuesta DNS incluirá la dirección IP privada: 192.168. 1.5)
3. El cliente de correo se conecta al servidor CAS de Exchange local, verifica que pueda comunicarse mediante HTTPS y solicita el certificado del servidor.
Cuando el servidor Exchange CAS proporciona su certificado al cliente de correo, el cliente de correo comprobará y verificará solo un nombre de host: exo1.o365info.local
El cliente interno de Exchange “ ignorar” el resto de nombres de host que aparecen en el certificado.
La razón de esto es que el cliente de Exchange "reconoce" o se relaciona con el servidor CAS interno de Exchange, utilizando solo el nombre de host: exo1.o365info.local
Al cliente de correo “no le importan” los nombres de host adicionales que existen en el certificado que proporciona el servidor público Exchange CAS (mail.o365info.com y o365info.com).
La descripción de la infraestructura de Exchange externa\pública
La infraestructura de correo que utiliza el cliente de correo externo tiene un carácter muy diferente.
La infraestructura de correo exterior incluirá las siguientes “partes” y componentes:
1. IP pública
Se debe adquirir y asignar una dirección IP pública al servidor CAS de Exchange, que actúa como un "servidor CAS de Exchange público". La mayoría de las veces, esta dirección IP pública se asignará al servidor Firewall de la empresa, quien reenviará las solicitudes del cliente de correo externo a la dirección IP interna del servidor CAS de Exchange.
2. Servidor DNS público\externo
Todo servidor CAS de Exchange público tendrá al menos dos nombres de host públicos.
Estos "nombres públicos" (FQDN) deberán registrarse en el servidor DNS público que aloja la empresa. nombre de dominio público.
En nuestro escenario, necesitaremos registrar en la zona o365info.com (nombre de dominio) los siguientes nombres de host: correo y detección automática
3. Certificado del servidor público Exchange
El certificado del servidor Exchange CAS deberá incluir los dos nombres públicos que “representan” el servidor público Exchange CAS (autodiscover.o365info.com y mail.o365info.com)
Cuando un cliente externo de Exchange necesita acceder a su buzón, se implementa el siguiente flujo:
- Bloqueo de la IP pública del punto final de detección automática
El cliente de correo conecta el DNS público buscando la dirección IP de - mail.o365info.com (en la realidad, el cliente de correo iniciará el proceso de detección automática buscando el nombre del host -o365info.com y solo si no puede encontrar o conectarse a este host, creará una consulta NDS buscando el FQDN del punto final de detección automática).
- Cliente de correo y servidor público Exchange CAS
El cliente de Exchange, conéctese al servidor CAS de Exchange público y verifique que pueda comunicarse mediante HTTPS.
En caso de que el servidor admita la comunicación HTTPS, el cliente de correo solicita el certificado del servidor.
Cuando el servidor público Exchange CAS proporciona su certificado al cliente de correo, el cliente de correo comprobará y verificará solo dos nombres de host:
autodiscover.o365info.com y mail.o365info.com
La razón de esto es que el cliente de Exchange "reconoce" o se relaciona con el servidor CAS de Exchange público utilizando solo los nombres de host: autodiscover.o365info.com y mail.o365info.com
Al cliente de correo "no le importan" los nombres de host adicionales, existen en el certificado que proporciona el servidor público Exchange CAS (ex01.o365info.lcoal)
