Flujo de detección automática en un entorno local de Exchange | entorno no Active Directory| Parte 1#3 | Parte 26#36

El cliente de detección automática utiliza un método de detección automática diferente para ubicar el punto final de detección automática en un entorno basado en Active Directory local frente a un entorno que no sea de Active Directory. El cliente de detección automática verifica si está ubicado en un entorno de Active Directory o no. Si decide que se encuentra en un entorno que no es Active Directory, el cliente de detección automática comienza a activar un sofisticado algoritmo de verificación creado para encontrar y conectar el punto final de detección automática requerido.

El artículo actual y los dos siguientes están dedicados a revisar el proceso de detección automática que se implementó en un entorno que no es Active Directory.

El término entorno de directorio no activo

El término "entorno no Active Directory" describe uno de los siguientes escenarios:
1. Escritorio de usuario que no está unido a un dominio.
2. Escritorio del usuario que no está ubicado en la red interna de la organización.

Cuando el cliente de detección automática reconoce que opera en un "entorno no de Active Directory", el cliente de detección automática "salta" la fase en la que se dirige al Directorio activo local y comienza a realizar el proceso de detección automática buscando el nombre de host del punto final de detección automática que considera como un derivado de la dirección de correo electrónico.

Localización del host del punto final de detección automática | Active Directory versus ninguno: entorno de Active Directory

Antes de entrar en los detalles del proceso de detección automática que se implementó en un entorno que no es Active Directory, es importante comprender la diferencia significativa del método de detección automática que se realizó en cada uno de estos entornos.

En un entorno de Active Directory, el cliente de detección automática no conoce el nombre del punto final de detección automática y, en cambio, se relaciona con Active Directory como una fuente confiable de infraestructura que puede proporcionarle los "nombres" de los puntos finales de detección automática disponibles (servidores CAS de Exchange). .

En un entorno que no es Active Directory, la "parte que falta" es Active Directory.

En lugar de dirigirse a Active Directory para obtener información sobre los nombres del punto final de detección automática, el cliente de detección automática deberá utilizar otro método.

El método de detección automática que utiliza el cliente de detección automática según el siguiente flujo:

1. El punto final de detección automática "adivina" o "genera" la dirección URL de un punto final de detección automática potencial en función del dominio SMTP que obtiene de la dirección de correo electrónico del destinatario.

2. En caso de que el cliente de detección automática logre localizar y comunicarse con el "punto final de detección automática potencial" pero el "host de destino" no pueda proporcionarle la información requerida, el cliente de detección automática solicitará una redirección a otro punto final de detección automática potencial.

3. En caso de que el posible punto final de detección automática del "paso 1" no pueda proporcionar la información de detección automática requerida + no pueda proporcionar una redirección a un posible punto final de detección automática, el cliente de detección automática intentará consultar el DNS en busca del registro SRV que incluirá el nombre de host de un posible punto final de detección automática.

Preste atención al hecho de que en un entorno que no sea de Active Directory; El cliente de detección automática puede considerarse "cliente ciego" porque no existe una "fuente de información formal" que pueda proporcionarle el nombre de host específico (la URL si queremos ser más precisos) del posible punto final de detección automática.

El posible escenario en el que el cliente de detección automática no puede utilizar el método de detección automática de Active Directory.

Los cuatro escenarios posibles en los que el cliente no puede utilizar el método de detección automática basado en una consulta LDAP y Active Directory local son:

1. El escritorio no está unido a un dominio.
Como su nombre lo indica, este escenario puede estar relacionado con una de las siguientes opciones:

• El escritorio de un usuario que no está configurado como miembro del dominio (unido al dominio)
• El escritorio de un usuario que se configura como miembro del dominio (unido al dominio), pero el usuario inicia sesión localmente en su escritorio y no en el "perfil de dominio".

2. El escritorio está unido a un dominio pero no hay opción para comunicarse con Active Directory

Un ejemplo podría ser un usuario a quien su computadora portátil se considera un dominio unido, pero el usuario de la organización está trabajando desde casa o desde una red pública.

En ese caso, a pesar de que el escritorio es un “Dominio unido”, el intento de comunicación con Active Directory fallará porque, de forma predeterminada, Active Directory considera recursos internos o protegidos y no está expuesto al acceso del host. de la red pública.

3. El escritorio está unido a un dominio; existe una opción para comunicarse con Active Directory, pero el dominio SMTP que busca el cliente no "pertenece" al servidor local de Exchange (Exchange no tiene autoridad para el nombre de dominio específico).

¡¡Vaya!! ¡Este es un nombre muy largo para el título de un escenario!

Un ejemplo de esta situación podría ser un usuario que desee crear un nuevo perfil de correo de Outlook utilizando la dirección de correo electrónico de un destinatario.

La parte del dominio SMTP de la dirección de correo electrónico del destinatario no "pertenece" a los dominios de la organización (el dominio que Exchange considera autorizado para ellos).

En esa situación, aunque el dominio no forma parte de la infraestructura local de Exchange, el cliente de detección automática solicitará una lista de servidores Exchange CAS disponibles desde Active Directory e intentará comunicarse con cada uno de los servidores Exchange CAS en la lista buscando el servidor requerido. Descubrir información automáticamente.

Solo después de que el cliente de detección automática agote todos los "puntos finales de detección automática internos" posibles, el cliente de detección automática se "entregará" y comenzará a utilizar un método de detección automática adicional.

4. No hay disponible un servidor local de Exchange.

Los estatutos de este escenario son:

• El escritorio del usuario está unido a un dominio.
• El cliente de detección automática logra consultar el Active Directory local y obtiene una lista de posibles puntos finales de detección automática.
• El cliente de detección automática intenta comunicarse con el punto final de detección automática (servidor CAS de Exchange), pero el servidor CAS de Exchange no está disponible (no responde, etc.).

En este caso, el cliente de detección automática se “rendirá” y comenzará a utilizar un método de detección automática adicional.

El viaje del tesoro perdido: archivo Autodiscover.xml

Para simplificar el concepto de proceso de detección automática, utilicemos la siguiente metáfora:

El proceso de Autodescubrimiento es muy similar a “la búsqueda del tesoro perdido”.

Alguien nos habló de un tesoro muy precioso.
Queremos mucho este tesoro y sabemos que “en algún lugar” hay una persona que guarda este precioso tesoro.

¡Todo lo que necesitamos es un "mapa" que pueda llevarnos a la persona que guarda nuestro preciado tesoro!

Volvamos al “mundo real” e intentemos comprender qué proceso representa cada una de estas figuras imaginarias.

1. El “buscador. ”

El "buscador" podría ser cualquier cliente de detección automática. En nuestro escenario, el cliente de detección automática es Outlook que necesita una configuración para crear un nuevo perfil de correo de Outlook.

2. El tesoro perdido - Información de descubrimiento automático

El ascenso del “viaje de descubrimiento automático” es muy simple: encuentre la información de descubrimiento automático (el tesoro perdido).

3. La fuente. ”

El "elemento" que guarda nuestro preciado tesoro es el servidor Exchange CAS o, si queremos usar el término formal, potencial punto final de detección automática.

Técnicamente hablando, utilizamos el término "potencial" porque, en realidad, cuando el cliente de detección automática se dirige a un host en particular, no sabe si el host (el punto final de detección automática potencial) responde a su solicitud de comunicación. En caso de que el anfitrión responda, no podemos estar seguros de que ese anfitrión en particular sea el “correcto”.

Por esta razón utilizamos el término “potencial”. El host al que se dirige el cliente de detección automática tiene el potencial de ser el "punto final de detección automática correcto" pero, al mismo tiempo, el cliente de detección automática necesitará saber cómo lidiar con un escenario en el que el host no sea el "punto final de detección automática correcto". "

4. El mapa. ”

En nuestra historia, el "mapa" debería llevarnos a la persona que guarda nuestro tesoro más deseado.
En el mundo de detección automática, el "mapa" se implementa como una dirección web (URL).

Si queremos ser más precisos, el cliente (Outlook) ya tiene la mayor parte del mapa, la única parte que falta en el “mapa” es el nombre del Autodiscover Endpoint, que “contiene” la información (conserva nuestro preciado tesoro).

URL de detección automática (el mapa del tesoro perdido)

Continuando con nuestra metáfora, el "mapa" (la dirección) del tesoro perdido, también conocido como información de detección automática, se implementa mediante el uso de una dirección URL.

Veamos la estructura de la dirección URL de detección automática, para que podamos comprender mejor el método de detección automática que utiliza el cliente de detección automática en un entorno que no es Active Directory.

La dirección URL de detección automática incluye las siguientes partes:

• El nombre del protocolo (HTTPS o HTTP)
• El nombre de host del punto final de detección automática
• La ruta que incluye el nombre de la carpeta (Autodiscover) y el nombre del archivo requerido (autodiscover.xml o autodiscover.svc)

El cliente de detección automática sabe cuál es la estructura de la dirección URL que debe usar para dirigirse al punto final de detección automática.

El protocolo de comunicación predeterminado es HTTPS (otra opción es HTTP en un escenario de solicitudes de redirección).

Tenga en cuenta que el cliente de detección automática no conoce el nombre del FQDN del punto final de detección automática.

En la siguiente sección, aprenderemos cómo el cliente de detección automática resuelve este problema, pero es importante enfatizar que en un entorno que no es Active Directory, el cliente de detección automática no puede saber "de antemano" el nombre de host del punto final de detección automática.

La ruta predeterminada de la URL de detección automática según la siguiente convención de nomenclatura.

La ruta predeterminada de los servicios de detección automática es:

/Autodiscover/autodiscover.xml

En el siguiente diagrama podemos ver la presentación del concepto de “dirección URL de detección automática conocida”.

El cliente de detección automática "conoce" la mayoría de las "partes" de la dirección URL de detección automática.
La única "parte que falta" es el nombre de host del punto final de detección automática.

¡El gran misterio revelado! Generando el nombre de host del punto final de detección automática

Cuando un cliente de detección automática utiliza el “método de detección automática de Active Directory”, el cliente de detección automática confía en Active Directory como fuente de información sobre el punto final de detección automática disponible.

Pero en caso de que el cliente de detección automática no pueda utilizar Active Directory como "fuente de información", ¿cómo puede el cliente de detección automática saber cuál es el nombre del punto final de detección automática? ¿Existe más de un posible punto final de detección automática?

¡Estoy emocionado!

¡Hoy vamos a desvelar el gran secreto que sólo unas pocas personas en todo el mundo conocen!

La forma que utiliza el cliente de detección automática para "encontrar" el nombre de host del punto final de detección automática tal vez no sea el "gran secreto que sólo unas pocas personas en todo el mundo conocen". Sin embargo, sigue siendo un proceso apasionante con el que algunos de nosotros no estamos familiarizados.

• La misión es: crear un nuevo perfil de correo de Outlook.
• El nombre del agente es - Bob
• La ubicación: Bob está ubicado en una red pública y, por este motivo, no puede acceder al Directorio Activo de la organización.
• Los obstáculos: cómo encontrar el servidor Exchange CAS (el punto final de detección automática) que permitirá a Bob conectarse a su buzón de correo + proporciona toda la información necesaria para crear el perfil de correo de Outlook Anywhere.

El método secreto que utiliza el cliente de detección automática se basa en un pequeño truco.
Como se mencionó anteriormente, la dirección URL del punto final de detección automática se basa en una convención de nomenclatura predefinida.
Para el cliente de detección automática que necesita encontrar su punto final de detección automática, la única parte que falta es el nombre de host del punto final de detección automática.

El truco que utiliza el cliente de detección automática en función de la dirección de correo electrónico del destinatario. Cada dirección de correo electrónico oficial consta de dos partes:

1. La "parte izquierda" es el alias del destinatario o el nombre del destinatario.
2. La “Parte izquierda”, esta parte representa el nombre de dominio o el nombre de dominio SMTP de la organización de la empresa a la que pertenece el usuario.

Los clientes de detección automática saben cómo utilizar la "parte correcta" de la dirección de correo electrónico "tomando" el nombre de dominio SMTP y es para "Completar la parte que falta del rompecabezas". "

En nuestro escenario, cuando Bob inicie el asistente de Outlook, Bob deberá proporcionar su dirección de correo electrónico: Bob@o365info.com

El cliente de detección automática (Outlook), toma el nombre de dominio de la dirección de correo electrónico y "ponga el nombre" en la URL de detección automática.

En nuestro ejemplo, Outlook comenzará el viaje conectando el servidor DNS y solicitará la dirección IP del host denominado: o365info.com

En caso de que el servidor DNS pueda proporcionar una dirección IP, Outlook (cliente de detección automática) se relacionará con el host como un posible punto final de detección automática.

La suposición principal de Outlook es que este host, o365info.com, es un posible punto final de detección automática, es decir, un servidor o elemento CAS de Exchange que puede proporcionarle la información de detección automática necesaria para crear el correo de Outlook en cualquier lugar. perfil.

La mayoría de las veces, el método en el que la detección automática se relaciona con el nombre de dominio SMTP es el nombre de host del posible punto final de detección automática, no producirá los resultados requeridos porque en un entorno moderno, el "nombre de dominio raíz" se asigna de manera útil a la empresa pública. sitio web.

Hoy en día, podemos “llegar” a la mayoría de los sitios web públicos sin utilizar la convención de nomenclatura formal, como - www. pero, en su lugar, utilizamos solo el nombre de dominio.

Supongamos que en nuestro escenario, Outlook logra encontrar la dirección IP de un host llamado - o365info.com, pero “este host” no es el punto final de detección automática requerido (servidor Exchange CAS). ) sino simplemente un sitio web simple.

En esa situación, el cliente de detección automática utiliza una nueva convención de nomenclatura, pero esta vez; Outlook intentará abordar el punto final de detección automática utilizando el siguiente nombre de host: autodiscover.o365info.com

El nombre de host: Detección automática es un nombre preservado.

Cada organización que desee señalar a los clientes de detección automática a su punto final de detección automática debe crear bajo el nombre de dominio en la zona DNS un registro A, que incluya el nombre de host: detección automática y asignado a la dirección IP del servidor CAS de Exchange que opera como punto final de detección automática.

P: ¿Este es el final del viaje de detección automática? ¿Podemos asumir que la historia tiene un buen final?

A: Sí y no

Este podría ser el final del viaje de detección automática en caso de que el host: autodiscover.o365info.com sea el "verdadero" y este sea el "servidor Exchange CAS adecuado" que puede habilite Outlook para conectarse al buzón de correo del usuario + proporcione todos los ajustes de configuración necesarios para crear un nuevo perfil de correo de Outlook en cualquier lugar.

Otros escenarios posibles son que el host que Outlook considera como un "punto final de detección automática potencial" no sea el host que pueda "finalizar el proceso". ”
Por ejemplo, existe una opción en la que Outlook encuentra la dirección IP de un host llamado autodiscover.o365info.com, pero el “host” no responde a la solicitud HTTPS que envía Outlook. (El proceso de detección automática basado en el protocolo HTTPS).

En este caso, Outlook "comprende" que esta no es "la última estación" en su viaje de detección automática.

Si el punto final de detección automática no respondió a la solicitud de comunicación HTTPS, el cliente de detección automática todavía tiene "cierta creencia" de que el host aún puede ayudarlo de otra manera.

Redirección HTTP

Debido al destino, el host no admite la comunicación HTTPS, el cliente de detección automática "entiende" que este no es el elemento que puede proporcionarle la información de detección automática requerida.

En lugar de "ceder", el cliente Outlook se dirigirá al host que no admite HTTPS y le preguntará si conoce un posible punto final de detección automática.

El punto final de detección automática se dirige al host mediante el protocolo HTTP en lugar de HTTPS.

En caso de que el host responda a la solicitud HTTP, el cliente de detección automática asume que puede pedir ayuda.

El cliente de detección automática intentará solicitar al host información sobre el nombre del punto final de detección automática.

Entonces… ¿este es el final?

¡La respuesta no es esa!

En caso de que el host cuya dirección del cliente de detección automática no admita HTTP o no pueda proporcionar el nombre de un posible punto final de detección automática, el cliente de detección automática utilizará el “último método, él lleva su saco”. "

Este método de detección automática se basa en un registro DNS especial denominado registro SRV.

La singularidad de un registro DNS SRV es que este tipo de registro permite al cliente DNS consultar DNS sobre el nombre de host para proporcionar un servicio particular con Outlook que necesita conocer el nombre de host. En otras palabras, cuando se utiliza la consulta SRV para buscar un servicio en particular, el DNS responde con el nombre del host que proporciona ese servicio en particular.

En caso de que la organización publique en el DNS un registro SRV que incluya el nombre de host del servidor Exchange CAS (punto final de detección automática) que puede proporcionar servicios de detección automática, el cliente de detección automática utilizará el nombre y se relacionará con el host como un punto final de detección automática potencial.