Flujo de detección automática en un entorno local de Exchange | entorno no Active Directory| Parte 3#3 | Parte 28#36
El artículo actual es la continuación del artículo anterior, en el que revisamos el flujo de detección automática implementado en el flujo de detección automática en un entorno que no es Active Directory. En este artículo, inspeccionaremos el flujo de detección automática utilizando la herramienta web de Microsoft, Microsoft Remote Connectivity Analyzer (MRCA).
Para revisar cada uno de los pasos y cada una de las partes que incluyen un paso de Autodiscover en particular, utilizaremos la poderosa herramienta Microsoft Remote Connectivity Analyzer.
El Analizador de conectividad remota de Microsoft (MRCA) incluye muchas pestañas y opciones. En nuestro escenario específico, queremos probar la infraestructura local de Exchange. Para implementar la prueba requerida, elegiremos la pestaña del servidor Exchange, prueba de conectividad de Microsoft Office Outlook y la opción de Detección automática de Outlook.
En caso de que necesite obtener más detalles sobre la herramienta web Microsoft Remote Connectivity Analyzer, puede leer 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
Descripción del escenario
Para demostrar el flujo de trabajo de detección automática que se implementa en un "entorno que no es Active Directory" cuando se utiliza una infraestructura local de Exchange, utilicemos el siguiente escenario:
John es un usuario de una organización que necesita acceder a su buzón alojado en el servidor local de Exchange.
John está ubicado físicamente en una red pública y, por este motivo, no puede utilizar el proceso de detección automática que se implementa en un entorno de Active Directory.
La dirección de correo electrónico de John es: john@o365info.com
La tarea de John es crear un nuevo perfil de correo de Outlook que le permitirá conectar su buzón. El perfil de Outlook se basa en el servicio Outlook Anywhere.
Tenga en cuenta que la empresa tiene un sitio web público que se publica utilizando el host llamado o365info.com
Análisis del proceso de detección automática mediante MRCA
Antes de profundizar en los detalles, comencemos con una vista de alto nivel de los resultados de la prueba de detección automática.
En la siguiente captura de pantalla, podemos ver que los procesos de detección automática se completan exitosamente.
Al observar la estructura de informes de resultados de detección automática, podemos ver que la “primera parte” falló (no se completó correctamente), pero la segunda parte (B sección) completado exitosamente.
Nota: El flujo de detección automática "contendrá" un par de "pasos fallidos" el 99% de las veces, pero aun así finaliza como un proceso exitoso.
La segunda parte (sección B) incluye la descripción de "alto nivel" de cada uno de los cinco pasos de detección automática que se implementaron y documentaron en el informe de resultados (revisaremos en detalle cada uno de estos pasos en la siguiente sección).
Analizando el proceso de detección automática | Pasos descritos en detalle.
Paso 1/9: 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" de la dirección de correo electrónico del destinatario que incluye el nombre de dominio SMTP.
En nuestro escenario, la dirección de correo electrónico del destinatario es: john@o365info. es
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 en particular.
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á "asignado" a la IP pública del sitio web.
En nuestro escenario, el 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 IP pública dirección asignada a un servidor web estándar.
Paso 1/9: Analizar los datos de la prueba de conectividad MRCA
En la página de resultados de MRCA, podemos ver la siguiente información:
Los resultados de las pruebas MRCA comienzan con un mensaje de error que indica que el intento de conexión al host denominado 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 trabajo 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 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/9: 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 está listado en el puerto 443 (HTTPS).
En nuestro escenario, la prueba de comunicación HTTPS falla porque el "host de destino" no admite la comunicación HTTPS.
Paso 2/9: Analizar los datos de la prueba de conectividad MRCA
En la página de resultados de MRCA, podemos ver la siguiente información sobre la prueba del puerto TCP 443 en el host o365info.com:
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/9: intentar resolver el nombre de host autodiscover.o365info.com en DNS
Debido a que falla el intento de comunicación con el posible punto final de detección automática utilizando el nombre de host o365info.com, el cliente de detección automática pasa 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 nomenclatura: descubrimiento automático +
En nuestro escenario, la dirección de correo electrónico del destinatario es: john@o365info.com
En función de esta dirección de correo electrónico específica, el cliente de detección automática creará una consulta DNS buscando para una dirección IP de un host llamado - autodiscover.o365info.com
Paso 3/9: Analizar los datos de la prueba de conectividad MRCA
En la página de resultados de MRCA, podemos ver la siguiente información sobre el intento de resolver el nombre de host o365info.com:
Intentando resolver el nombre de host autodiscover.o365info.com en DNS.
El nombre de host se resolvió correctamente. Direcciones IP devueltas: 212.25.80.239
Paso 4/9: 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 está listado en el puerto 443 (HTTPS).
En nuestro escenario, la prueba de comunicación HTTPS fue exitosa, lo que significa que el host de destino (el punto final de detección automática) admite la comunicación HTTPS.
Paso 4/9: Analizar los datos de la prueba de conectividad MRCA
En la página de resultados de MRCA, podemos ver la siguiente información sobre la prueba del puerto TCP 443 en el host autodiscover.o365info.com :
Probando el puerto TCP 443 en el host autodiscover.o365info.com para garantizar que esté escuchando y abierto. El puerto se abrió correctamente.
Paso 5/9: Solicitar al posible punto final de detección automática que proporcione un certificado de servidor público
El cliente de detección automática "asume" que el host de destino es un "punto final de detección automática potencial", que puede proporcionarle la información de detección automática requerida.
Antes de que el cliente de detección automática solicite la información requerida, deberá completar con éxito un par de pasos.
El cliente de detección automática necesita "estar seguro" de que el host de destino es confiable y confiable.
Para poder confiar en el posible punto final de detección automática, el cliente de detección automática solicitará al servidor que demuestre su identidad proporcionando un certificado público válido.
Paso 5/9: Analizar los datos de la prueba de conectividad MRCA
En la página de resultados de MRCA, podemos ver la siguiente información sobre el paso en el que el cliente de detección automática solicita que el posible punto final de detección automática proporcione un certificado público de servidor:
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.
Paso 6/9: Probar el certificado SSL para asegurarse de que sea válido
La prueba de validación de certificados que realiza el cliente Autodiscover incluye tres partes diferentes.
1. Validación del nombre del certificado
El cliente de detección automática aborda el posible punto final de detección automática mediante el nombre de host: autodiscover.o365info.com
Para poder saber que este es el "host real", el cliente de detección automática comprobará si el certificado incluye el nombre de host especificado (autodiscover.o365info.com )
Nota: Esta descripción es relevante para un escenario en el que el servidor utiliza un certificado SAN.
En caso de que el posible punto final de detección automática utilice un certificado comodín, el cliente validará solo el nombre de dominio (en En nuestro escenario, el nombre de dominio que el cliente validará es - o365info.com).
2. Validar el certificado confía en
El certificado público que proporciona el servidor, creado por una CA (autoridad de certificación).
El cliente de detección automática también necesitará validar el certificado de CA que proporciona al servidor su certificado.
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.
Nota: En caso de que desee leer información más detallada sobre el tema de detección automática, mecanismo de seguridad y certificados, lea el artículo: Proceso de detección automática e infraestructura de seguridad de Exchange | Parte 20#36
Paso 6/9: Analizar los datos de la prueba de conectividad MRCA
1. Validando el nombre del certificado
En la página de resultados de MRCA, podemos ver la siguiente información sobre la prueba de validación para el nombre del punto final de detección automática:
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. Validando la confianza del certificado
En la página de resultados de MRCA, podemos ver la siguiente información sobre la prueba de validación para el certificado de confianza:
Se está validando la confianza del certificado. El certificado es confiable y todos los certificados están presentes en la cadena. 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 correctamente una o más cadenas de certificados.
3. Verifique que la fecha del certificado sea válida
En la página de resultados de MRCA, podemos ver la siguiente información sobre la prueba de validación de los datos del certificado:
Probar la fecha del certificado para confirmar que es válido. Validación de fecha 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 7/9: Verificar la configuración de IIS para la autenticación del certificado del cliente
El cliente de detección automática comprueba 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 demostrar su identidad proporcionando un certificado.
El uso del certificado de cliente es muy raro y la mayoría de las veces, la forma que utiliza el cliente para "probar su identidad" es proporcionando credenciales de usuario.
Paso 7/9: Analizar los datos de la prueba de conectividad MRCA
En la página de resultados de MRCA, podemos ver la siguiente información sobre la prueba de autenticación del certificado 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 8/9: Proporcionar credenciales de usuario
Una vez que la prueba de validación del certificado se haya completado con éxito y el cliente de detección automática pueda "confiar" en el host de destino, el cliente de detección automática también deberá demostrar su identidad.
El cliente Autodiscover se identificará proporcionando las credenciales de usuario” (Nombre de usuario + contraseña).
Nota: La parte de "proporcionar credenciales de usuario" no aparece en los resultados de MRCA.
Paso 9/9: intentar enviar una solicitud POST de detección automática a posibles URL de detección automática
Este es el último paso en el viaje de detección automática.
Después de una compilación exitosa de todos los pasos, el cliente de detección automática completa su misión: obtener el archivo de detección automática.
El punto final de detección automática generará la respuesta de detección automática que se "personalizó" para el cliente de detección automática particular que requiere la información (John en nuestro escenario).
Paso 9/9: Analizar los datos de la prueba de conectividad MRCA
En la página de resultados de MRCA, podemos ver la siguiente información sobre la respuesta de detección automática que envió el servidor Exchange CAS al cliente:
Intentando enviar una solicitud POST de detección automática a posibles URL de detección automática.
El Analizador de conectividad de Microsoft recuperó con éxito la configuración de detección automática enviando una POST de detección automática.
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 john@o365info.com. La respuesta XML de detección automática se recuperó correctamente.
El proveedor de Exchange de detección automática
El servidor Exchange CAS incluye un par de proveedores de Outlook.
La detección automática incluirá una sección dedicada para cada uno de estos proveedores.
En nuestro ejemplo, tomamos una captura de pantalla de la parte que incluye la información del proveedor EXCH:
Si necesita información más detallada sobre el proveedor de detección automática del servidor CAS de Exchange, lea el artículo: El contenido de la respuesta del servidor de detección automática | Parte 11#36
En la siguiente captura de pantalla, podemos ver que la respuesta de detección automática incluye el "privado" o el "nombre oculto" del servidor Exchange CAS que proporciona los servicios de detección automática:
La respuesta de detección automática incluye información detallada sobre cada uno de los servicios web de Exchange disponibles.
En el siguiente ejemplo podemos ver la información sobre los servicios disponibles:
Y sobre los servicios de Respuesta automática (Fuera de la oficina):
