Flujo de detección automática en un entorno de Office 365 | Parte 1#3 | Parte 29#36

El flujo de detección automática en un entorno basado en Office 365 puede considerarse un proceso fascinante porque el cliente de detección automática localiza su punto final de detección automática, que incluye muchos giros y vueltas.

Flujo de detección automática en un entorno de Office 365 | la serie de artículos

El artículo actual es el primero de una serie de tres artículos dedicados a describir en detalle el flujo de detección automática en un entorno que podemos describir como "solo nube".

Los artículos adicionales de la serie son:

• Flujo de detección automática en un entorno de Office 365 | Parte 2#3 | Parte 30#36
• Flujo de detección automática en un entorno de Office 365 | Parte 3#3 | Parte 31#36

El primer artículo está dedicado a presentar la lógica y los componentes involucrados en el flujo de detección automática que se implementa en un entorno basado en Office 365.

En los dos artículos siguientes, revisaremos el flujo de detección automática que se implementa en un entorno basado en Office 365 mediante la herramienta basada en web de Microsoft, Microsoft Remote Connectivity Analyzer (ExRCA).

Puede leer más información sobre cómo utilizar la herramienta Microsoft Remote Connectivity Analyzer (ExRCA) en el artículo - Microsoft Remote Connectivity Analyzer (ExRCA) | Herramientas de solución de problemas de detección automática | Parte 2#4 | Parte 22#36

Los caracteres especiales del flujo de detección automática en un entorno basado en Office 365

El flujo de detección automática que se implementa en un entorno basado en Office 365 es muy diferente del flujo de detección automática "estándar" implementado en el entorno local de Exchange.

Las características clave del flujo de detección automática en el entorno basado en Office 365 son:

• El flujo de detección automática, incluido de forma estructurada, el evento de error. En palabras simples, el cliente de detección automática se dirigirá al punto final de detección automática que no existe o no puede proporcionar la información de detección automática requerida.
• El flujo de detección automática se basará en un par de nodos y "saltos" hasta que el cliente de detección automática llegue a su destino final, es decir, el punto final de detección automática que puede proporcionar la información de detección automática requerida.
• Algunos de los nodos que incluyen el flujo de detección automática no proporcionarán la "información de detección automática estándar", sino que proporcionarán un mensaje de redirección de detección automática que "enrutará" el cliente de detección automática a puntos finales de detección automática adicionales.

¿Esta información suena grande y no tan clara?

Si la respuesta es “Sí”, ¡bienvenido al club!

Exchange Online y el “entorno solo en la nube”

En el entorno de Exchange Online, el proceso de detección automática se implementa de una manera diferente al proceso de detección automática "estándar" que se implementa en el entorno local de Exchange.

En el entorno local de Exchange, el cliente de detección automática buscará un punto final de detección automática que represente un dominio en particular.

Por ejemplo, en un escenario en el que un usuario cuya dirección de correo electrónico es: Bob@o365info.com intenta crear un nuevo perfil de correo de Outlook; El proceso de detección automática se implementa de la siguiente manera:

Autodiscover Endpoint consultará DNS en busca de un host llamado: o365info.com. En caso de que el cliente de detección automática no logre conectar el nombre de host especificado, el punto final de detección automática pasará al paso 2, en el que el cliente de detección automática intenta localizar un punto final de detección automática potencial utilizando el nombre de host -
autodiscover.o365info.com

La suposición subyacente es que en un entorno basado en Exchange local, la organización asigna un servidor CAS de Exchange público que servirá como representante del nombre de dominio: o365info.com y el FQDN -autodiscover.o365info.com asignado a este servidor Exchange público.

Cuando el cliente de detección automática logra localizar el punto final de detección automática, el cliente de detección automática solicitará al punto final de detección automática "probar su identidad" proporcionando un certificado de servidor público.

El punto final de detección automática proporcionará el certificado requerido y el cliente de detección automática verificará que el certificado del servidor incluya el nombre de dominio: o365info.com (en un escenario de certificado comodín) o el nombre de host: autodiscover.o365info.com.

En el entorno de Exchange Online, el escenario descrito no se puede implementar por una razón muy simple:

En realidad, la “infraestructura de la nube” (Office 365 y Exchange Online) no puede asignar un certificado público dedicado para cada uno de los inquilinos de Office 365 y para cada uno de los dominios públicos registrados en Office 365.

En Exchange Online, un servidor Exchange particular (o conjunto de servidores Exchange Online) puede representar cien o mil dominios diferentes al mismo tiempo.

¡El concepto en el que Autodiscover Endpoint (el servidor Exchange) proporciona un certificado público que incluye una referencia al dominio del cliente en particular no se puede implementar!

Entonces, la gran pregunta es: ¿cómo solucionamos el problema que permitirá a los clientes de detección automática acceder a su buzón de Exchange Online?

Y la respuesta es: "redirección".

Método de redirección de DNS mediante un registro CNAME

El entorno de Office 365 y Exchange Online tiene un carácter diferente al entorno local de Exchange.
Por este motivo, es importante que estemos familiarizados con la lógica central de la infraestructura de Office 365.

Office 365 (que utiliza Exchange Online como infraestructura de correo) es un SaaS (software como servicio).
Cada uno de los suscriptores de Office 365 se describe como un “inquilino”; que contrata un espacio privado en el “Gran Edificio” de Office 365.

En el entorno local de Exchange, la organización utiliza un servidor Exchange público dedicado, que actúa como "representante" del nombre de dominio público de la organización.

El “entorno de nube” (Office 365) no puede proporcionar este tipo de “servidor Exchange dedicado” que representará el nombre de dominio particular del inquilino de Office 365.

Por ejemplo, en caso de que necesitemos crear un nuevo perfil de correo de Outlook para un destinatario con la dirección de correo electrónico - Bob@o365info.com, el cliente de detección automática (Outlook), siempre iniciará el proceso de detección automática buscando un host llamado: o365info.com
y, si no puede encontrar o comunicarse con este host, intentará buscar el punto final de detección automática. nombrado - autodiscover.o365info.com

La verdadera respuesta es que en el entorno de Office 365, no existe un “servidor real” llamado - autodiscover.o365info.com que tenga un certificado público que incluya una referencia al nombre de dominio - < abarca clase="highlight4i">o365info.com

En teoría, el proceso de detección automática debería fallar.

La respuesta a este problema es: la suplantación.

La solución es dejar que el cliente de Autodiscover "piense" que se está comunicando con un host en particular mientras, en la práctica, se comunica con otro elemento que se "presenta" como el elemento que el cliente de Autodiscover cree que es.

¿Suena como una conspiración?
Sí, un poco

En un "entorno solo en la nube" (infraestructura de correo alojada completamente en la nube), el suscriptor de Office 365 debe actualizar su DNS público agregando un nuevo registro CNAME.

Los registros DNS que hacen la "magia" son un registro CNAME simple que se creó para volver a detectar solicitudes de clientes de detección automática a un "elemento" de Office 365 que se hará pasar por el "host real" que están buscando.

Detección automática y registro DNS CNAME (redirección DNS)

El “truco” del registro CNAME se implementa de la siguiente manera:

En el servidor DNS público que aloja el nombre de dominio público de la organización, creamos un nuevo registro CNAME que redirige las solicitudes del nombre de host (descubrimiento automático) a un nombre de host diferente u otro.

El nombre de host al que se redirigirán las solicitudes de detección automática: autodiscover.o365info.com

Por ejemplo, en el servidor DNS público que aloja el nombre de dominio - o365info.com , agregaremos un nuevo registro CNAME que hará que el servidor DNS proporcione la dirección IP del Aloje autodiscover.outlook.com en cada cliente DNS que solicitará la dirección IP de autodiscover.outlook.com

Por ejemplo, cuando un cliente de detección automática intenta comunicarse con un host llamado autodiscover.o365info.com, la dirección IP que se devolverá al cliente de detección automática desde el DNS "conducirá ” el cliente de detección automática a los hosts de Office 365 denominados - autodiscover.outlook.com.

¿Quién es autodiscover.outlook.com?

El autodiscover.outlook.com es un "elemento de Office 365" que sirve como un "enrutador lógico" entre los clientes de detección automática y la infraestructura de Exchange Online.

El flujo de detección automática de los usuarios de Office 365 (usuarios cuyo buzón de correo está alojado en Exchange Online) comienza comunicándose con los hosts de Office 365 denominados -
autodiscover.outlook.com

El componente “autodiscover.outlook.com” aceptará las solicitudes del cliente de detección automática, pero, en lugar de demostrar la información de detección automática requerida, el host autodiscover .outlook.com, envíe como respuesta un "mensaje de redirección" para "conducir" el cliente de detección automática a otros puntos finales de detección automática de Office 365.

autodiscover.o365info.com un único host o componentes lógicos. En teoría, los objetos de Office 365 que redirigen Autodiscover Endpoint a su servidor Exchange Online requerido son un único host llamado autodiscover.o365info.com.

En realidad, autodiscover.outlook.com es solo un objeto lógico representado por docenas o incluso cientos de servidores repartidos por todo el mundo.

Cuando un cliente de detección automática intenta obtener la dirección IP del nombre de host: autodiscover.outlook.com, la respuesta (la dirección IP + nombre de host) que obtendrá el cliente de detección automática depende de su ubicación geográfica.

Por ejemplo, un cliente de detección automática ubicado físicamente en Europa obtendrá información precisa que es diferente de un cliente de detección automática ubicado físicamente en los EE. UU.

Podemos ver una demostración de este proceso usando un simple comando ping.
En la siguiente captura de pantalla, podemos ver el resultado de un comando ping al host llamado - autodiscover.o365info. es

La "respuesta" que obtenemos del servidor DNS nos dirige a un host diferente llamado-
autodiscover-emeaeast.outlook.com

En caso de que se pregunte por qué vemos el nombre de host:
autodiscover-emeaeast.outlook.com en lugar del nombre de host del que hablamos: autodiscover.outlook.com, la respuesta es que probablemente se deba a que la infraestructura DNS de Office 365 se basa en un “GeoDNS”.

Al utilizar la opción de GeoDNS, el servidor DNS reconoce la dirección IP del cliente DNS y concluye cuál es la ubicación geográfica del cliente DNS.

Con base en esta información, los servidores DNS brindan una respuesta (dirección IP y nombre de host) que es adecuada para la ubicación geográfica del cliente DNS.
En nuestro ejemplo, mi ubicación física se considera "EMEA" (Europa, Medio Oriente y África), y por esta razón, el componente de detección automática de Office 365 que se utiliza es un host ubicado físicamente en EMEA.

Método de redirección HTTP y HTTPS

Un método de redireccionamiento adicional que se implementa en el entorno de Office 365 para los servicios de detección automática son los métodos: redireccionamiento HTTP y redireccionamiento HTTPS.

En la sección anterior, mencionamos que el cliente de detección automática que consulta el servidor DNS sobre el posible punto final de detección automática será “redirigido” a otro nombre de host
(autodiscover.outlook.com).

El cliente de Autodiscover “piensa” que este es el “elemento” que podría proporcionarle la información requerida, pero esta “suposición” es errónea.

Cuando el cliente de detección automática intenta conectarse al punto final de detección automática denominado: autodiscover.outlook.com, el resultado final será una redirección adicional, que se implementa mediante el protocolo HTTP a < u>punto final de detección automática adicional.

Si cree que este es el "fin de la historia", ¡se sentirá decepcionado!
(O, para ser más precisos, el cliente de detección automática se sentirá decepcionado).

Después de la fase de la redirección HTTP, cuando el cliente de detección automática intenta abordar el "nuevo host" (el posible punto final de detección automática), el resultado es una redirección adicional, pero esta vez, la redirección El método se basa en el protocolo HTTPS.

El “viaje” de detección automática del cliente de detección automática en un entorno de Office 365

Describí el flujo de trabajo de Detección automática del cliente de Detección automática en Office 365 como un "Viaje", porque, como en los cuentos de hadas, donde el Príncipe pasa por muchas dificultades para llegar a Princesa, el cliente de Detección automática también tendrá que pasar por muchos obstáculos.

Nota: no entraremos en muchos detalles sobre cada uno de los “pasos” que el cliente de detección automática debe seguir porque, en el próximo artículo Flujo de detección automática en un entorno de Office 365 | Parte 2#3 | Parte 30#36, revisamos minuciosamente cada uno de estos pasos.

En el siguiente diagrama, podemos ver una "vista de alto nivel" de los "elementos" que el cliente de detección automática encontrará en su camino.

Tengo que colocar el servidor DNS en la parte superior del diagrama porque, cada vez que el cliente de detección automática redirige al "siguiente salto", el cliente de detección automática deberá crear una consulta de DNS solicitando la dirección IP del nombre de host que aparece en el mensaje de redirección.

Revisión adicional del proceso de detección automática en el entorno de Office 365

El proceso en el que el punto final de detección automática "funciona" para proporcionar al cliente de detección automática la información requerida (la respuesta de detección automática) se puede realizar solo si se aplican dos reglas:

Regla 1: Autenticación mutua
El servidor debe demostrar su identidad al cliente de detección automática para que el cliente de detección automática pueda estar seguro de que el servidor (punto final de detección automática) es una "fuente confiable de información".

El cliente de detección automática debe demostrar su identidad al punto final de detección automática proporcionando sus credenciales de usuario.

Regla 2: Canal de comunicación seguro

Los datos que se transfirieron en el canal de comunicación entre el punto final de detección automática y el cliente de detección automática deben estar cifrados.

Necesitamos conocer estas "reglas obligatorias" para poder comprender el "extraño flujo de detección automática" en el entorno de Office 365.

En la siguiente sección, respondo a la pregunta de: "¿cuál es la necesidad de implementar una infraestructura de detección automática tan complicada en el entorno de Office 365?".

Fase 1

Como se mencionó anteriormente, en nuestro escenario, el cliente de detección automática busca un host llamado: autodiscover.o365info.com

La respuesta del DNS proporcionará al cliente de detección automática la dirección IP del host autodiscover.outlook.com

El cliente de detección automática intentará comunicarse (mediante HTTPS) con este host.

El host, autodiscover.outlook.com, no puede comunicarse mediante HTTPS porque no es el punto final de detección automática "real" y no tiene un certificado de servidor que incluya el nombre del host. - autodiscover.o365info.com

Debido a que la prueba de comunicación HTTPS falla, el cliente de detección automática creará una nueva solicitud HTTP solicitando una "redirección" al punto final de detección automática requerido, que puede proporcionar los servicios de detección automática necesarios mediante el protocolo HTTPS.

La “respuesta de redirección HTTP” de autodiscover.outlook.com
incluye el nombre del punto final de detección automática denominado: autodiscover-s.outlook. es

Fase 2

El cliente de detección automática intenta comunicar el “nuevo punto final de detección automática” (autodiscover-s.outlook.com) mediante el protocolo HTTPS.

La buena noticia es que el host autodiscover.outlook.com puede comunicarse mediante HTTPS, pero la noticia menos buena es que autodiscover.outlook. com el certificado público incluye una “autorización” solo para los nombres de host que pertenecen al dominio “outlook.com”.

El cliente de detección automática espera encontrar en el certificado del servidor el nombre de host: autodiscover.o365info.com y esta expectativa no puede cumplirse porque, en el entorno de Office 365, no existe ningún mecanismo que proporcione un certificado público dedicado para cada uno de los nombres de dominio público del inquilino de Office 365.

Entonces ahora tenemos un "problema".

El cliente de detección automática no puede completar el proceso porque no puede encontrar el nombre de host autodiscover.o365info.com en el certificado del servidor y técnicamente el proceso de detección automática debería fallar.

Y la buena noticia es que el método de detección automática tiene un “truco” llamado -redirección HTTPS.

El punto final de detección automática: autodiscover.outlook.com no puede cumplir con las condiciones del cliente de detección automática, sino porque
autodiscover.outlook.com puede probar su identidad proporcionando al cliente su certificado, el cliente de detección automática puede “confiar” en el host
autodiscover.outlook.com y relacionarse con él como un servidor confiable. Fuente de información.

La información que autodiscover.outlook.com proporciona al cliente de detección automática no es la información de detección automática (los ajustes de configuración de detección automática), sino que la información incluye una redirección a un punto final de detección automática adicional.

El "punto final de detección automática adicional" es el servidor CAS de Exchange Online que podrá proporcionar al cliente de detección automática la información de detección automática requerida.

En nuestro escenario específico, la información proporcionada por autodiscover.outlook.com (el mensaje de redirección XML) incluye el nombre del siguiente host: pod5149.outlook.com

Nota: el nombre del servidor CAS de Exchange Online en nuestro escenario es: pod51049.outlook.com
Técnicamente, el nombre puede cambiarse y se cambiará en función de muchos factores, como los centros de datos de Office 365. en el que está alojado el inquilino de Office 365, los servidores CAS de Exchange Online disponibles, etc.

Fase 3

El cliente de detección automática está dispuesto a aceptar la información de redirección e intentar comunicarse con el punto final de detección automática: pod51049.outlook.com

La buena noticia es que ahora se puede completar el proceso de detección automática.

El certificado público que proporciona pod51049.outlook.com es un certificado comodín que incluye una "autorización" para todos los nombres de host "bajo" outlook.com nombre de dominio.

El cliente de detección automática obtendrá el certificado pod51049.outlook.com, validará que el certificado fue proporcionado por una CA confiable, verificará el nombre de host o el nombre de dominio (en nuestro escenario outlook.com) aparece en el certificado público.

Esta es una "señal" para el cliente de detección automática de que ahora puede proporcionar su identidad de forma segura al "servidor" proporcionando las credenciales de usuario de Office 365.

Después de completar el proceso de autenticación mutua, se crea un enlace de comunicación seguro y el “servidor” (pod5149.outlook.com) proporciona al cliente de detección automática el autodiscover.xml deseado. archivo.

El próximo artículo de la serie de artículos actual.

Flujo de detección automática en un entorno de Office 365 | Parte 2#3 | Parte 30#36