Flujo de detección automática en un entorno híbrido de Exchange | Parte 2#3 | Parte 33#36

El artículo actual y el siguiente estarán dedicados a una revisión detallada del flujo de detección automática, que se implementa en el entorno híbrido de Exchange, 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 híbrido de Exchange | la serie de artículos

El artículo actual es el segundo de una serie de tres artículos.
Los artículos adicionales de la serie son:

• Flujo de detección automática en un entorno híbrido de Exchange | Parte 1#3 | Parte 32#36
• Flujo de detección automática en un entorno híbrido de Exchange | Parte 3#3 | Parte 34#36

Un usuario en un entorno híbrido cuyo buzón estaba migrando a la nube obtiene un nuevo escritorio, hace doble clic en el ícono de Outlook, Outlook tose y tiembla y después de un par de segundos, el usuario se conecta a su buzón.

Suena simple, ¿no?

En realidad, este "proceso simple" en el que el usuario crea un nuevo perfil de correo de Outlook y se conecta automáticamente a su "buzón de correo en la nube", se basa en un proceso de detección automática muy inteligente y sofisticado.

La razón para describir el flujo de detección automática híbrida de Exchange como "complicado" es porque, para el destinatario de Exchange cuyo buzón estaba alojado en la infraestructura de Exchange Online, el flujo de detección automática en un entorno híbrido de Exchange se implementó dos veces:

La primera vez que se utiliza la infraestructura local de Exchange y la segunda vez, después de que el cliente de Exchange recibe un mensaje de redirección, el flujo de detección automática se realiza en la infraestructura de Exchange Online.

La magia del viaje de detección automática en el entorno híbrido de Exchange

En el artículo actual y en el siguiente (Flujo de detección automática en un entorno híbrido de Exchange | Parte 3#3 | Parte 34#36), revisaremos en detalle cada uno de los muchos pasos que se incluyen en el recorrido de detección automática en un entorno híbrido.

Intenté separar cada uno de estos pasos y obtuve un resultado de 30 partes diferentes.

El número "30 ", es solo un número arbitrario porque el "viaje de detección automática" puede ser se sumergió incluso a más partes o menos partes. El número de “partes” depende de muchas variables.

Entonces, si tiene el coraje necesario, únase a nuestro largo pero fascinante viaje para revivir el flujo de detección automática en un entorno híbrido de Exchange.

Esta es tu última oportunidad. Después de esto, no hay vuelta atrás. Tomas la pastilla azul: la historia termina; Te despiertas en tu cama y crees lo que quieras creer. Tomas la pastilla roja, te quedas en el País de las Maravillas y te muestro hasta qué punto llega la madriguera del conejo. Recuerda: todo lo que te ofrezco es la verdad, nada más.

Citado de la matriz parte 1#3

Descripción del escenario

Para poder demostrar el proceso de detección automática en un entorno híbrido, utilizaremos el siguiente escenario:

Una organización denominada o365info.com utiliza una configuración híbrida de Exchange, que incluye una combinación de buzones de correo Exchange locales y buzones de correo en la nube (Exchange Online).

En nuestro escenario, un usuario llamado Alice que utiliza la siguiente dirección de correo electrónico: Alice@o365info.com, necesita crear un nuevo perfil de correo de Outlook.

El buzón de Alice migró a la nube (Exchange Online).

El largo viaje del descubrimiento automático en un entorno híbrido

En el entorno híbrido, Exchange On-Premise continúa sirviendo como "punto focal" para los servicios de detección automática.

A pesar de que el buzón de Alice está almacenado físicamente en Exchange Online, el proceso de detección automática comenzará con el entorno local de Exchange.

El cliente Exchange (Alice en nuestro escenario) intentará conectarse a su servidor Exchange On-Premise y en caso de que el buzón del usuario esté “en la nube”, Exchange On-Premise es el elemento que redirigirá al cliente de correo a su “ buzón de correo en la nube” proporcionándole su “dirección de correo electrónico en la nube”.

Antes de entrar en detalles, es importante que podamos ver el "panorama general" o los nodos principales que aparecerán en nuestro viaje de detección automática en el entorno híbrido.

En el siguiente diagrama, podemos ver que el cliente de detección automática deberá pasar por muchos nodos en su viaje de detección automática hasta llegar a su destino final, el punto final de detección automática que le proporcionará la información de detección automática requerida.

Uso del analizador de conectividad remota de Microsoft: el prefijo

Para poder ilustrar cada uno de los pasos de detección automática que intervienen en el flujo de detección automática, utilizaremos una combinación de diagramas y una captura de pantalla del resultado del analizador de conectividad remota de Microsoft.

En nuestro escenario, utilizaremos la prueba ExRCA denominada: Pruebas de conectividad de Outlook de Microsoft Office y elegiremos Detección automática de Outlook . prueba.

1. El “entorno” de la Bolsa | Intercambio local

En nuestro escenario, examinamos el flujo de detección automática de un destinatario cuyo buzón estaba alojado en la infraestructura de Exchange Online.

En teoría, deberíamos haber elegido la pestaña "Office 365 " de ExRCA porque el buzón del destinatario está ubicado físicamente en la infraestructura de Exchange Online.

En el entorno híbrido de Exchange, Exchange local actúa como un "punto focal de detección automática". El flujo de detección automática debe comenzar dirigiéndose al servicio local de Exchange y, según el "mensaje de redirección" que se proporcionará al cliente de detección automática, continuar el flujo de detección automática dirigiéndose a la infraestructura de Exchange Online.

Por este motivo elegiremos la pestaña Exchange Server.

2. Credenciales de inicio de sesión

En un escenario en el que queremos probar un proceso de detección automática, para el buzón de usuario alojado en Exchange Online, tendremos que usar la convención de nomenclatura UPN (nombre principal de usuario). Aunque el proceso comienza con Exchange On-Premise, que permite utilizar la convención de nomenclatura de inicio de sesión estándar de Active Directory, como: o365info\Alice

La razón es que, en la primera fase de detección automática; el usuario se identifica ante Exchange On-Premise pero, en los siguientes pasos, el cliente de detección automática deberá identificarse ante el servidor Exchange Online que utiliza la convención de nomenclatura UPN de Office 365, como: Alice @o365info.com

3. Las dos infraestructuras de Exchange diferentes

Antes de profundizar en los pasos específicos de detección automática que se implementaron en un entorno híbrido de Exchange, comencemos por el final, mirando un ejemplo de prueba ExRCA que se completó.

En la siguiente captura de pantalla, podemos ver que la prueba de detección automática se completó con éxito.

El informe resumido muestra información sobre dos entornos de Exchange diferentes:

• Entorno local de Exchange
• Entorno de intercambio en línea

Uso del analizador de conectividad remota de Microsoft: descripción detallada

En la siguiente sección y en el próximo artículo, revisaremos en detalle cada uno de los “30 pasos” que se implementan en un flujo de detección automática en un entorno híbrido de Exchange.

Paso 1/30: Intentando resolver el nombre de host o365info.com

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" de la E 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: Alice@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 organización en particular, del servidor público y de la infraestructura de servicios.
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/30: Analizando los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

El paso de resolución de nombres DNS, en el que la detección automática consulta el servidor DNS para obtener la dirección IP del host: o365info.com, se completa con éxito.

El servidor DNS responde con una lista de direcciones IP públicas.

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/30: Prueba del puerto TCP 443 en el host o365info.com

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 tiene éxito. El "servidor" aprueba que pueda comunicarse mediante HTTPS.

Sólo un rápido recordatorio

• Caso 1: el hecho de que el "host de destino" admita el protocolo HTTPS no significa necesariamente que el host sea un servidor Exchange que pueda proporcionar los servicios de detección automática necesarios.
• Caso 2: incluso en el caso de que el “host de destino” admita el protocolo HTTPS + el “host de destino” sea un servidor Exchange válido; no significa que pueda proporcionar información de detección automática al cliente de detección automática.

Paso 2/30: Analizar los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

El cliente Autodiscover intenta verificar si el “host de destino” admite el protocolo HTTPS y la respuesta es “sí”.

Probando el puerto TCP 443 en el host o365info.com para garantizar que esté escuchando y abierto. El puerto se abrió correctamente.

Paso 3/30: Intentar obtener el certificado SSL del servidor remoto o365info.com

Las “relaciones” de detección automática entre el cliente de detección automática y el punto final de detección automática se basan en un “concepto de confianza”.

La primera fase es el paso en el que el cliente de detección automática deberá confiar en el punto final de detección automática y, en la segunda fase, el punto final de detección automática también deberá “confiar” en el cliente de detección automática.

La "confianza" comienza con el paso en el que el Autodiscover Endpoint debe demostrar su identidad.

Para poder verificar la identidad del Autodiscover Endpoint, el cliente de Autodiscover solicitará al Autodiscover Endpoint que le envíe su certificado público.

Paso 3/30: Analizar los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

• El cliente de detección automática solicita al punto final de detección automática que le envíe su certificado.
• El punto final de detección automática envía su certificado.
• El cliente de detección automática aceptó correctamente el certificado.

El Analizador de conectividad de Microsoft está intentando obtener el certificado SSL del servidor remoto o365info.com en el puerto 443.
El Analizador de conectividad de Microsoft obtuvo con éxito el certificado SSL remoto.

Detalles adicionales

En la siguiente sección, podemos ver el contenido del certificado público del servidor que se envió al cliente de detección automática.

Asunto del certificado remoto: CN=ssl2000.cloudflare.com, O=”CloudFlare, Inc.”, L=San Francisco, S=CA, C=US, Emisor: CN=Validación de organización GlobalSign CA - G2, O= GlobalSign nv-sa, C=BE.

Paso 4/30: Probar el certificado SSL de o365info.com para asegurarse de que sea válido.

El cliente de detección automática deberá implementar tres pruebas de verificación diferentes para poder “aprobar” el certificado del servidor.
(En caso de que una de las tres pruebas diferentes falle, el certificado no se considerará válido).

La primera prueba, realidades del - ”Nombre de host”. El cliente de detección automática comprobará si el certificado incluye el nombre de host del punto final de detección automática.
En nuestro escenario, el cliente de detección automática intentará buscar el nombre de host: o365info.com

En nuestro ejemplo, el resultado es "fallo" porque el certificado proporcionado por el servidor no contiene el nombre de host: o365info.com

Paso 4/30: Analizando los datos de la prueba de conectividad ExRCA

En la página de resultados del Analizador de conectividad remota de Microsoft, podemos ver información sobre el hecho de que el certificado del servidor no incluye el nombre de host requerido.

El nombre de host o365info.com no coincide con ningún nombre encontrado en el certificado del servidor CN=ssl2000.cloudflare.com, O=”CloudFlare, Inc.”, L=San Francisco, S=CA, C=US.

Paso 5/30: Intentar resolver el nombre de host autodiscover.o365info.com

Debido a que el intento de comunicación con el posible punto final de detección automática utilizó el nombre de host. Debido a que el intento de comunicación falló, el cliente de detección automática pasará al siguiente método, en el que el cliente de detección automática buscará un punto final de detección automática potencial utilizando el siguiente esquema de nombres: Detección automática +
En nuestro escenario, la dirección de correo electrónico del destinatario es: Alice@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

En nuestro escenario, el nombre de host autodiscover.o365info.com está asignado "al servidor local de Exchange.

Paso 5/30: Analizando los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

Intentando resolver el nombre de host autodiscover.o365info.com en DNS. El nombre del host se resolvió correctamente. Direcciones IP devueltas: 212.25.80.239

Paso 6/30: 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 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 tiene éxito. El "servidor" aprueba que pueda comunicarse mediante HTTPS.

Paso 6/30: Analizar los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

Intentando resolver el nombre de host autodiscover.o365info.com en DNS. El nombre del host se resolvió correctamente. Direcciones IP devueltas: 212.25.80.239

Paso 7/30: Intentar obtener el certificado SSL del servidor remoto autodiscover.o365info.com

Para poder verificar la identidad del Autodiscover Endpoint, el cliente de Autodiscover solicitará al Autodiscover Endpoint que le envíe su certificado público.

Paso 30/7: Analizar los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

• El cliente de detección automática solicita al punto final de detección automática que le envíe su certificado.
• El punto final de detección automática envía su certificado.
• El cliente de detección automática aceptó correctamente el certificado.

El Analizador de conectividad de Microsoft está intentando obtener el certificado SSL del servidor remoto autodiscover.o365info.com en el puerto 443.
El Analizador de conectividad de Microsoft obtuvo con éxito el certificado SSL remoto.

En la siguiente sección, podemos ver el contenido del certificado público del servidor que se envió al cliente de detección automática.

Asunto del certificado remoto: CN=mail.o365info.com, OU=Control de dominio validado, O=mail.o365info.com, Emisor: SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificados .godaddy.com/repository, O=”GoDaddy.com, Inc.”, L=Scottsdale, S=Arizona, C=EE.UU.

En nuestro escenario podemos ver que el certificado del servidor fue proporcionado por GoDaddy.com.

Paso 30/8: Probar el certificado SSL de autodiscover.o365info.com para asegurarse de que sea válido.

La prueba de validación de certificados que realiza el cliente Autodiscover incluye tres partes distintas.

1. Validar el nombre del certificado
El cliente de detección automática, dirija el posible punto final de detección automática utilizando el nombre de host: autodiscover.o365info.com

Para poder saber si esta es la fuente de información válida o confiable, el cliente de detección automática verificará si el certificado incluye el nombre de host especificado:
autodiscover.o365info.com o el nombre de dominio: *.o365info.com en un escenario de certificado comodín.

2. Validar la confianza del certificado
El certificado público que proporciona el servidor fue proporcionado por una CA (autoridad certificadora). El cliente de detección automática también deberá validar el certificado de CA que proporciona su certificado al servidor (punto final de detección automática).

3. Verifique que la fecha del certificado sea válida.
El cliente de detección automática deberá verificar que la fecha del certificado del servidor sea válida.

En caso de que desee leer información más detallada sobre el tema de Autodiscover, mecanismo de seguridad y certificados, lea el artículo: Proceso de Autodiscover e infraestructura de seguridad de Exchange | Parte 20#36

Paso 30/8: Analizando los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

1. Validar el nombre del certificado
El cliente de detección automática, verifique que el certificado del servidor incluya el FQDN del servidor o el nombre de dominio del servidor.

Validando el nombre del certificado. El nombre del certificado se validó correctamente. El nombre de host autodiscover.o365info.com se encontró en la entrada Nombre alternativo del sujeto del certificado.

2. Validar la confianza del certificado

• El cliente de detección automática verifica la cadena de confianza que aparece en el certificado del servidor.
• El cliente de detección automática logra verificar con éxito la cadena de confianza.

El Analizador de conectividad de Microsoft está intentando crear cadenas de certificados para el certificado CN=mail.o365info.com, OU=Control de dominio validado, O=mail.o365info.com. Se construyeron exitosamente una o más cadenas de certificados.

3. Verifique que la fecha del certificado sea válida.

El cliente de detección automática verifica que el certificado del servidor aún sea válido y no haya caducado.
En nuestro ejemplo, la prueba se completó exitosamente, lo que significa que el certificado del servidor es válido.

Fecha de validación aprobada. El certificado no ha caducado. El certificado es válido. No antes=26/01/2013 23:22:11, No después=26/01/2015 23:22:11

Paso 9/30: Verificar la configuración de IIS para la autenticación del certificado del cliente

El "canal de confianza" entre el cliente de detección automática y el punto final de detección automática se basa en la capacidad de cada parte para demostrar su identidad.

En la sección anterior, el cliente de detección automática logró verificar la identidad del servidor con éxito.
Ahora, llegamos a la segunda parte, en la que el cliente de detección automática deberá demostrar su identidad al servidor para obtener la información de detección automática requerida.

El cliente de detección automática, verifique si el host de destino (el punto final de detección automática) necesita un certificado de cliente. (Un certificado de cliente, es un método en el que el cliente puede acreditar su identidad).

El uso de un certificado de cliente es muy raro y, la mayoría de las veces, la forma que el cliente utiliza para "probar su identidad" es proporcionando las credenciales de un usuario.

Paso 30/9: Analizando los datos de la prueba de conectividad ExRCA

En la página de resultados del Analizador de conectividad remota de Microsoft, podemos ver que

• El cliente de detección automática pregunta al servidor si se requiere un certificado de cliente.
• El servidor responde que no necesita un certificado del lado del cliente.

Comprobación de la configuración de IIS para la autenticación del certificado del cliente. No se detectó la autenticación del certificado del cliente. Aceptar/Requerir certificados de cliente no está configurado.

Paso 10/30: Proporcionar credenciales de usuario al punto final de detección automática

Después de la validación del certificado, la prueba se completó con éxito y el cliente de detección automática puede "confiar" en el host de destino; el cliente de detección automática también deberá demostrar su identidad.
El cliente de detección automática se identificará proporcionando las credenciales de un usuario. ”
(Nombre de usuario + contraseña).

Paso 30/10: Analizando los datos de la prueba de conectividad ExRCA

Paso 30/11: Intentar enviar una solicitud POST de detección automática a una posible URL de detección automática: https://autodiscover.o365info.com/autodiscover/autodiscover.xml

El cliente de detección automática intentará enviar una solicitud POST de detección automática al punto final de detección automática para obtener la información de detección automática requerida.

En nuestro escenario, el punto final de detección automática es un servidor público local de Exchange.

Si recuerda, el buzón de Alice está alojado en el servidor Exchange Online.
Exchange On-Premise se relaciona con el buzón de Alice como un "buzón remoto".

Debido a que Exchange local es para el "propietario" del buzón de Alice, la respuesta de Exchange local incluirá una redirección a la infraestructura "real" de Exchange que aloja el buzón de Alice: la infraestructura de Exchange Online.

Exchange local "informa" al usuario (Alice) que debe realizar el proceso de detección automática utilizando una dirección de correo electrónico nueva o actualizada.

En nuestro escenario, Exchange On-Premise informa a Alice que su “dirección de correo electrónico real” es: Alice@o365info2.onmicrosoft.com

Entorno híbrido y Office 365 “Nombre de dominio híbrido”

Antes de continuar con la descripción del proceso de detección automática, es importante comprender el concepto de dirección de correo electrónico en un entorno híbrido.

En nuestro escenario específico, el espacio de nombres de dominio SMTP que se utiliza para "representar" a los destinatarios de Exchange Online es: o365info2.mail.onmicrosoft.com

Este "nombre de dominio" no es un nombre de dominio real que se utilizará para el proceso de detección automática, sino simplemente un "puntero lógico" que "conducirá" a los destinatarios de Exchange Online a la infraestructura de detección automática de Exchange Online.

Cuando el cliente de detección automática intenta buscar un host llamado - o365info2.onmicrosoft.com, el proceso fallará porque se supone que el nombre de host no debe publicarse.

En el siguiente diagrama, podemos ver que la respuesta de detección automática local de Exchange incluye un mensaje de redirección.

Exchange local informa a Alice que su dirección de correo electrónico "real" es-
Alice@o365info2.mail.onmicrosoft.com

Paso 30/11: Analizando los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

• El cliente de detección automática se dirige al punto final de detección automática solicitando información de detección automática.
• La respuesta de Autodiscover Endpoint incluye un mensaje de redirección que incluye "otra" dirección de correo electrónico.

El Analizador de conectividad de Microsoft está intentando recuperar una respuesta de detección automática XML de la URL https://autodiscover.o365info.com:443/Autodiscover/Autodiscover.xml para el usuario alice@o365info.com. La respuesta XML de detección automática se recuperó correctamente.
Redirección de dominio de detección automática
redirectAddr
Alice@o365info2.mail.onmicrosoft.com

Paso 30/12: Intentando resolver el nombre de host o365info2.mail.onmicrosoft.com

Ahora, el flujo de detección automática se "mueve" del entorno local de Exchange al "entorno de nube" (Office 365 y Exchange Online).

El cliente de detección automática "entiende" que necesita reiniciar el proceso de detección automática nuevamente. El proceso de detección automática se basará en la “nueva dirección de correo electrónico” que se entregó a Alice: Alice@o365info2.mail.onmicrosoft.com

Como ya sabemos, el cliente de detección automática "extraerá" la "parte derecha" de la dirección de correo electrónico del destinatario
e intentará iniciar una consulta DNS buscando este nombre de host.

El cliente de detección automática se dirigirá a un servidor DNS y buscará la dirección IP del host denominado: o365info2.mail.onmicrosoft.com

La solicitud de información fracasará porque, en realidad, no existe tal host.

Paso 30/12: Analizando los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

• El cliente de detección automática se dirige al servidor DNS buscando la dirección IP del host: mail.onmicrosoft.com
• La respuesta de DNS es que no tiene ninguna información sobre el nombre de host específico.

Intentando resolver el nombre de host o365info2.mail.onmicrosoft.com en DNS. No se pudo resolver el nombre del host. El host o365info2.mail.onmicrosoft.com no se pudo resolver en DNS InfoNoRecords.

Paso 13/30: Intentar resolver el nombre de host autodiscover.o365info2.mail.onmicrosoft.com

En caso de que el cliente de detección automática no pueda encontrar su punto final de detección automática utilizando la "convención de nomenclatura de dominio", el cliente de detección automática intentará buscar el punto final de detección automática utilizando el FQDN utilizando el siguiente esquema de nomenclatura: Autodiscover +< Nombre de dominio SMTP de correo electrónico>

En nuestro escenario, el resultado de esta "fórmula" es un host con nombre:
autodiscover.o365info2.mail.onmicrosoft.com

El cliente de detección automática se dirigirá a un servidor DNS y buscará la dirección IP del host denominado -autodiscover.o365info2.mail.onmicrosoft.com

La “respuesta” del servidor DNS incluye una lista de direcciones IP. El motivo de las "múltiples direcciones IP" es que en Office 365 utilizamos un "nombre de host lógico" que, en realidad, se puede "asignar a" muchos servidores físicos.

Paso 13/30: Analizando los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

La respuesta de DNS incluye una lista de direcciones IP que están "asignadas" al host denominado: autodiscover.o365info2.mail.onmicrosoft.com

Intentando resolver el nombre de host autodiscover.o365info2.mail.onmicrosoft.com en DNS. El nombre del host se resolvió correctamente. Direcciones IP devueltas: 157.56.244.217, 157.56.236.89, 157.56.232.9, 157.56.234.137

Paso 14/30: Probar el puerto TCP 443 en el host autodiscover.o365info2.mail.onmicrosoft.com para asegurarse de que esté escuchando y abierto

Cliente de detección automática, intente verificar si puede continuar el proceso de detección automática con el host autodiscover.o365info2.mail.onmicrosoft.com verificando si el host de destino puede comunicarse mediante el protocolo HTTPS.

El resultado de la “prueba HTTPS” es -fallo.
Este es un resultado esperado, porque el host autodiscover.o365info2.mail.onmicrosoft.com no es un " servidor Exchange real”.

Paso 14/30: Analizando los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

El cliente de detección automática intenta comprobar si el host: autodiscover.o365info2.mail.onmicrosoft.com puede comunicarse mediante el protocolo HTTPS. El resultado es que el host específico no escucha el puerto 443 (el protocolo HTTPS predeterminado).

Probando el puerto TCP 443 en el host autodiscover.o365info2.mail.onmicrosoft.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 15/30: intentar contactar con el servicio de detección automática utilizando el método de redireccionamiento HTTP

El algoritmo del cliente de detección automática se basa en el siguiente concepto: en caso de que el punto final de detección automática potencial no pueda responder a una solicitud HTTPS, el cliente de detección automática no está dispuesto a "rendirse" y, en cambio, se da por vencido; el cliente de detección automática probará otro método en el que se dirige al posible punto final de detección automática utilizando el protocolo HTTP y solicita instrucciones para: "Cómo llegar a su punto final de detección automática".

El cliente de detección automática comprueba si el host autodiscover.o365info2.mail.onmicrosoft.com puede comunicarse mediante el protocolo HTTP.

Paso 15/30: Analizando los datos de la prueba de conectividad ExRCA

En la página de resultados de Microsoft Remote Connectivity Analyzer, podemos ver la siguiente información:

El cliente de detección automática intenta comprobar si el host: autodiscover.o365info2.mail.onmicrosoft.com puede comunicarse mediante el protocolo HTTP. El resultado es que el host específico escucha el puerto 80 (el protocolo HTTP predeterminado).

Probando el puerto TCP 80 en el host autodiscover.o365info2.mail.onmicrosoft.com para garantizar que esté escuchando y abierto. El puerto se abrió correctamente.

La continuación del flujo de detección automática en un entorno híbrido de Exchange aparece en el siguiente artículo: Flujo de detección automática en un entorno híbrido de Exchange | Parte 3#3 | Parte 34#36