Flujo de detección automática en un entorno de Office 365 | Parte 2#3 | Parte 30#36
El artículo actual y el próximo estarán dedicados a una revisión detallada del flujo de detección automática; que se implementó en un entorno basado en Office 365 mediante el uso de la herramienta basada en web de Microsoft, Microsoft Remote Connectivity Analyzer (ExRCA).
Flujo de detección automática en un entorno basado en Office 365 | la serie de artículos
- Flujo de detección automática en un entorno de Office 365 | Parte 1#3 | Parte 29#36
- 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 entorno de detección automática en Office 365 incluye muchos pasos.
Intenté separar cada uno de estos pasos y obtuve un resultado de 20 partes diferentes.
El número "20 ", es solo un número arbitrario porque el "Viaje de detección automática" se puede sumergir incluso en más partes o menos. partes.
El número de "partes" depende de muchas variables, pero las observaciones importantes del "viaje de descubrimiento automático" son:
- El proceso de detección automática es un mecanismo muy “inteligente” e inteligente, que logra sobrevivir en un entorno complejo y complicado.
- Hay muchas “partes móviles” y muchos caminos disponibles para el viaje de detección automática.
- Parte del proceso de detección automática incluye "fallos integrados". Estos “fracasos” son normales y esperados. Lo que importa es el significado de los "resultados finales": si el cliente de detección automática logró completar el viaje de detección automática con éxito o no.
El viaje de descubrimiento automático
En las siguientes secciones, profundizaremos en el "capó de detección automática" y observaremos cada paso y proceso que intervienen en un proceso de detección automática en el entorno de Office 365 y Exchange Online.
Antes de comenzar, definamos los factores que intervienen en el proceso.
1. El cliente de detección automática
El cliente es la entidad que necesita la información requerida del punto final de detección automática. El cliente de detección automática podría ser un cliente de correo como Outlook, dispositivos móviles (cliente ActiveSync), etc.
En este artículo, el cliente de detección automática es ExRCA (la herramienta de diagnóstico web de Microsoft).
Usamos la excelente capacidad de ExRCA para mostrar un informe muy detallado que describe de manera muy clara y precisa los pasos que se implementaron en el proceso de detección automática.
Nota: Aunque ExRCA proporciona información muy detallada, algunos de los "pasos de detección automática" no se mencionan en el informe de resultados de ExRCA. Por ejemplo, el proceso en el que el cliente de detección automática proporciona sus credenciales al punto final de detección automática no aparece en el informe ExRCA.
En este escenario, agregué mi descripción\explicación aunque no podemos ver "evidencia" de este proceso de detección automática en el informe ExRCA.
2. El punto final de detección automática
El término "Punto final de detección automática" se relaciona con cada uno de los nodos o hosts que participarán en el proceso de detección automática.
Pronto veremos que el cliente de detección automática cumplirá con un par de "elementos".
(La suposición predeterminada del cliente de detección automática es que cada uno de estos "elementos" es el punto final de detección automática requerido (punto final de detección automática potencial).
En realidad, solo el último nodo es el "punto final de detección automática de la verdad". El resto de hosts que participan en el proceso de detección automática en un entorno de Office 365 sirven como "enrutadores lógicos" que guiarán y redirigirán al cliente de detección automática a su destino.
3. El propósito del Viaje
El único propósito del viaje de detección automática es muy simple: obtener una respuesta de detección automática que incluya la configuración requerida para un nuevo perfil de correo de Outlook + infraestructura sobre los servicios web de Exchange existentes.
El largo viaje de detección automática en el entorno de Office 365 y Exchange Online
En las siguientes secciones, entraremos en detalles muy específicos de cada paso que se incluye en el proceso de detección automática en el entorno de Office 365.
El viaje es bastante largo y necesitaremos tener algo de paciencia para poder acompañar al cliente Autodiscover en el viaje.
Antes de entrar en detalles, es importante que podamos ver el "panorama general" o los nodos principales que participarán en el viaje de detección automática en Office 365 y el entorno Exchange Online.
En el siguiente diagrama, podemos ver que el cliente de Autodiscover tendrá que pasar por muchos nodos en su viaje, antes de poder completar el viaje de Autodiscover y llegar a su "destino final" (número 4 en El diagrama).
Descripción del escenario
Para poder demostrar el proceso de detección automática en un "entorno solo de nube", utilizamos el siguiente escenario:
Una organización denominada o365info.com utiliza Office 365 y Exchange Online como infraestructura de correo. Todos los buzones de correo del usuario están alojados en la infraestructura de Exchange Online.
En nuestro escenario, un usuario llamado - Bob que utiliza la siguiente dirección de correo electrónico -Bob@o365info.com, necesita crear un nuevo perfil de correo de Outlook.
El cliente de detección automática comenzará su viaje de detección automática buscando un punto final de detección automática llamado o365info.com
El punto final de detección automática utiliza este nombre de host específico porque el algoritmo de detección automática se basa en un método en el que el cliente de detección automática "toma" el nombre de dominio SMTP de las direcciones de correo electrónico del destinatario (o365info.com ).
Uso del analizador de conectividad remota de Microsoft: el prefijo
Para poder ilustrar cada una de las partes de Autodiscover, utilizaremos una combinación de diagrama y una captura de pantalla del resultado del analizador de conectividad remota de Microsoft.
En nuestro escenario, nos gustaría revisar el proceso de detección automática de un usuario cuyo buzón está alojado en Exchange Online. Por tal motivo elegiremos las pestañas de Office 365 y luego; Elegiremos la opción de prueba de - Outlook Autodiscover.
En las siguientes capturas de pantalla, podemos ver los resultados del proceso de detección automática de Outlook para el buzón de correo de Bob alojado en Exchange Online.
En esta vista de "alto nivel" de los resultados de la prueba de detección automática, podemos ver claramente la "estructura" del proceso de detección automática que se implementa en el entorno de Office 365.
(El proceso de detección automática se implementa de una manera diferente a un “proceso de detección automática estándar” de un cliente externo que intenta acceder a la infraestructura local de Exchange).
Los dos primeros pasos, en los que el cliente de detección automática intenta acceder al "punto final de detección automática estándar" utilizando los nombres de host: o365info.com y
autodiscover.o365info.com falló (número 1 y 2 en la captura de pantalla).
El “proceso de detección automática real” en un entorno de Office 365 comienza solo después de la fase de redirección HTTP implementada por el elemento denominado - autodiscover.o365info.com (número 3 en la captura de pantalla).
Cuando observamos el proceso de detección automática que se implementa en el entorno de Office 365, podemos ver que el cliente de detección automática será redirigido a elementos adicionales de Office 365 denominados: Autodiscover-s.outlook.com (número 4 en la captura de pantalla).
Cuando el cliente de detección automática llegue a los elementos de Office 365 denominados
Autodiscover-s.outlook.com, será redirigido nuevamente a su "destino final", el servidor CAS de Exchange Online. quién "conectará" el cliente de correo a su buzón, le proporcionará la información de detección automática requerida, etc.
Analizando el proceso de detección automática | Pasos descritos en detalle
Paso 1/20: Intentar resolver el nombre de host o365info.com en DNS
De forma predeterminada, el cliente de detección automática intentará localizar un "punto final de detección automática potencial" utilizando un nombre de host que fue "extraído" de la dirección de correo electrónico del destinatario.
El cliente de detección automática utilizará la "parte derecha" del correo electrónico del destinatario. dirección de correo electrónico que incluye el nombre de dominio SMTP.
En nuestro escenario, la dirección de correo electrónico del destinatario es: Bob@o365info.com
Basado en esta dirección de correo electrónico específica; el cliente de detección automática creará una consulta DNS buscando una dirección IP de un host llamado - o365info.com
La "respuesta" del servidor DNS depende de la infraestructura de servicios y servidores públicos de la organización específica.
Por ejemplo, la mayoría de las organizaciones tienen un sitio web público y, la mayoría de las veces, el nombre de dominio público está "mapeado". a la IP pública del sitio web.
En nuestro escenario, el servidor DNS responde con una dirección IP pública del nombre de host solicitado. La IP proporcionada por el servidor DNS no "pertenece" a un servidor Exchange (punto final de detección automática), sino que esta dirección IP pública se asigna a un servidor web estándar.
Paso 1/20: Analizando los datos de la prueba de conectividad ExRCA
En la página de resultados de ExRCA, podemos ver la siguiente información:
Los resultados de la prueba ExRCA comienzan con un mensaje de error que indica que el intento de conexión al nombre de host: o365info.com falló.
Intentando probar una posible URL de detección automática https://o365info.com:443/Autodiscover/Autodiscover.xml
la prueba de esta posible URL de detección automática falló.
(Obtendremos más detalles sobre el motivo del fallo en la siguiente sección)
Tenga en cuenta que cuando observamos los detalles del flujo de detección automática realizado por el cliente de detección automática, podemos ver que algunos de los pasos se completaron correctamente.
Por ejemplo, el paso de resolución de nombres, en el que el cliente de detección automática solicita al servidor DNS la dirección IP del host o365info.com se completa correctamente.
Intentando resolver el nombre de host o365info.com en DNS. El nombre del host se resolvió correctamente. Direcciones IP devueltas: 104.28.12.85, 104.28.13.85
Paso 2/20: Probar el puerto TCP 443 en el host o365info.com para asegurarse de que esté escuchando y abierto.
El cliente de detección automática se dirige al posible punto final de detección automática utilizando la dirección IP que obtuvo en el paso anterior.
El cliente de detección automática intentará verificar si el posible punto final de detección automática puede comunicarse mediante el protocolo HTTPS (puerto 443).
En nuestro escenario, la prueba de comunicación HTTPS falla porque el "host de destino" no admite la comunicación HTTPS.
Paso 2/20: Analizar los datos de la prueba de conectividad ExRCA
En la página de resultados de ExRCA, podemos ver la siguiente información sobre el proceso en el que el cliente de detección automática intenta verificar si el host de destino
(o365info.com ) puede comunicarse usando Puerto TCP 443
El puerto especificado está bloqueado, no escucha o no produce la respuesta esperada. Se produjo un error de red al comunicarse con el host remoto.
Paso 3/20: Intentar resolver el nombre de host autodiscover.o365info.com en DNS
Debido a que el intento de comunicación con el posible punto final de detección automática utilizando el nombre de host o365info.com mediante HTTPS falla, el cliente de detección automática pasará al siguiente método, en el que el cliente de detección automática buscará un posible punto final de detección automática utilizando el siguiente esquema de nomenclatura: descubrimiento automático +
En nuestro escenario, la dirección de correo electrónico del destinatario es: Bob@o365info.com
Basado en esta dirección de correo electrónico específica; el cliente de detección automática creará una consulta DNS buscando una dirección IP de un host llamado - autodiscover.o365info.com
La respuesta del servidor DNS incluye un rango de direcciones IP entre las que el cliente de detección automática puede elegir.
En nuestro escenario, el DNS público incluye el registro CNAME requerido que "redirecciona" la consulta del cliente de detección automática al rango de direcciones IP asignado al nombre de host: Autodiscover.outlook.com
En nuestro escenario, el DNS proporciona el siguiente rango de direcciones IP: 157.56.236.89, 157.56.232.9, 157.56.234.137, 157.56.244.217.
(Las “entidades de Office 365” denominadas - autodiscover.outlook.com, sirve como un "enrutador lógico" que redirigirá al cliente al "siguiente salto" en el recorrido de detección automática).
Paso 3/20: Analizar los datos de la prueba de conectividad ExRCA
En la página de resultados de ExRCA, podemos ver la siguiente información sobre el intento de resolver el nombre del host autodiscover.o365info.com
El nombre del host se resolvió correctamente. Direcciones IP devueltas: 157.56.236.89, 157.56.234.137, 157.56.232.9, 157.56.244.217
Paso 4/20: Probar el puerto TCP 443 en el host autodiscover.o365info.com para asegurarse de que esté escuchando y abierto.
El cliente de detección automática se dirige al posible punto final de detección automática e intenta verificar si el posible punto final de detección automática aparece en el puerto 443 (HTTPS).
En nuestro escenario, la prueba de comunicación HTTPS falla.
Aunque el resultado del fallo aparece como un “problema”, en un entorno Office 365 este es el resultado esperado.
En nuestro escenario, el cliente de detección automática "piensa" que está hablando con el host llamado autodiscover.o365info.com y que este host debería poder iniciar una sesión HTTPS presentando su certificado público.
En realidad, el host cuya dirección del cliente de detección automática es autodiscover.outlook.com que se creó solo para servir como enrutador lógico, que redirigirá al cliente de detección automática al siguiente salto. .
El propósito de estos “componentes de Office 365” (autodiscover.outlook.com) es simplemente enviar un “mensaje de enrutamiento” al cliente de detección automática.
El cliente de detección automática está "programado" para utilizar y redirigir HTTP una solicitud en caso de que el punto final de detección automática potencial no pueda comunicarse mediante HTTPS.
En nuestro ejemplo, debido a que el posible punto final de detección automática no puede comunicarse mediante HTTPS, el cliente de detección automática "retrocederá" e intentará comunicarse con el punto final de detección automática mediante el protocolo HTTP, intentando solicitar al punto final de detección automática una redirección que incluya la dirección de " otro punto final de detección automática”.
Paso 4/20: Analizar los datos de la prueba de conectividad ExRCA
En la página de resultados de ExRCA, podemos ver que la prueba de comunicación HTTPS con el “punto final de detección automática de destino” (autodiscover.outlook.com) falla.
Probando el puerto TCP 443 en el host autodiscover.o365info.com para garantizar que esté escuchando y abierto. El puerto especificado está bloqueado, no escucha o no produce la respuesta esperada. Se produjo un error de red al comunicarse con el host remoto.
Paso 5/20: intentar contactar con el servicio de detección automática utilizando el método de redireccionamiento HTTP.
Debido a que el host de destino no respondió a la solicitud de comunicación HTTPS, el cliente de detección automática intenta un método de consulta de detección automática adicional que se describe como -
solicitud de redireccionamiento HTTP.
La verificación del cliente de detección automática del host de destino aparece en la comunicación a través de HTTP (puerto 80).
En nuestro escenario, el host de destino responde a la solicitud de comunicación HTTP.
La respuesta "positiva" del host de destino le "dice" al cliente de detección automática que probablemente este sea un elemento que puede ayudarlo al proporcionarle el nombre de un host adicional que actúa como punto final de detección automática.
En el siguiente paso, veremos cómo el cliente de detección automática enviará una consulta HTTP que incluye una solicitud de un "nombre de host y URL alternativos" que pueda proporcionar los servicios de detección automática necesarios.
Paso 5/20: Analizar los datos de la prueba de conectividad ExRCA
En la página de resultados de ExRCA, podemos ver la siguiente información sobre el intento de contactar con el servicio de detección automática utilizando el método de redirección HTTP:
Se contactó con éxito con el servicio de detección automática mediante HTTP método de redirección.
Paso 6/20: comprobar el host autodiscover.o365info.com en busca de una redirección HTTP al servicio de detección automática.
Como se mencionó anteriormente, el host: autodiscover.outlook.com sirve como un "enrutador lógico" que redirige a los clientes de detección automática en un entorno de Office 365 al "siguiente salto" en la detección automática. fluir.
El cliente de detección automática envía una solicitud de redirección HTTP y el punto final de detección automática (autodiscover.outlook.com) responde con una respuesta que incluye la URL de detección automática del "host de destino".
En nuestro escenario, la respuesta de redirección HTTP incluye la siguiente dirección URL: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
Paso 6/20: Analizar los datos de la prueba de conectividad ExRCA
En la página de resultados de ExRCA, podemos ver la siguiente información
La respuesta de redirección (HTTP 301/302) se recibió correctamente. URL de redireccionamiento: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
Continuaremos revisando el flujo de detección automática en un entorno basado en Office 365 en el próximo artículo: Flujo de detección automática en un entorno de Office 365 | Parte 3#3 | Parte 31#36