Siete escenarios principales de flujo de detección automática | Parte 25#36
En el siguiente artículo, revisaremos siete flujos principales de detección automática comunes en un entorno diferente.
La revisión es una revisión de alto nivel y no un examen detallado que aborda cada uno de los pasos y procesos específicos que están involucrados.
El propósito: en la continuación de la serie actual de artículos, del artículo 29 al 34, entraremos en detalles muy específicos del flujo de detección automática mediante el uso de diferentes herramientas como ExRCA, prueba de conectividad de Outlook y más.
Antes de profundizar en los detalles, es importante que podamos obtener una "vista desde arriba" de los diferentes flujos de detección automática y sus personajes principales.
La lógica básica del flujo de detección automática.
El mecanismo de detección automática incluye tres partes principales:
- Localización del punto final de detección automática
- Obtener la información de detección automática requerida
- Uso de la información de detección automática
En el presente artículo nos referimos a las dos primeras partes:
1. Localización del punto final de detección automática
2. Obtener la información\datos de detección automática.
El flujo de detección automática se basa en la capacidad del cliente de detección automática.
- Localice un posible punto final de detección automática.
- Aborde este posible punto final de detección automática.
- Complete todo, si se cumplen los pasos requeridos relacionados con el proceso de detección automática, como la autenticación mutua y más.
- Obtenga del punto final de detección automática la información de detección automática requerida.
La detección automática se refiere a la "ruta" que el cliente de detección automática (punto A) debe pasar para llegar al punto B (punto final de detección automática).
Cuando nos enfrentamos a un proceso de solución de problemas relacionado con la detección automática, lo primero que debemos hacer es comprender claramente la ruta de detección automática.
Además, necesitaremos saber cuál es la "función" de cada componente que participa en la ruta de detección automática y verificar que cada uno de los componentes involucrados esté configurado correctamente con la configuración requerida.
Sólo después de que sepamos cuál es la "ruta de detección automática" por la que se suponía que "pasaría" el cliente de detección automática y cuáles son los componentes o nodos que participan en este proceso, podremos "identificar" la causa particular de el problema o iniciar el proceso de eliminación de los diferentes componentes que intervienen en el flujo de Autodiscover.
El flujo de detección automática involucra componentes y cartas.
En la siguiente sección, revisaremos siete escenarios diferentes de "flujo de detección automática" y señalaremos los estatutos específicos de cada escenario.
Escenario 1: entorno de Active Directory | Servidor local de Exchange único
El servidor Exchange On-Premise que tiene la función CAS se registró automáticamente en el SCP del Active Directory On-Premise (otros escenarios opcionales es una escena en la que estamos registrando el servidor Exchange CAS en el SCP de Active Directory usando un nombre de host diferente ).
El cliente de detección automática que necesita encontrar el punto final de detección automática (servidor Exchange) accede a Active Directory mediante una consulta LDAP y solicita la URL específica que necesita usar para tratar con el punto final de detección automática requerido (la URL de detección automática que lo "conducirá" al servidor interno Exchange CAS).
Active Directory "responde" a la consulta del cliente de detección automática y le envía la dirección URL de detección automática requerida.
El cliente de detección automática se dirige al servidor CAS de Exchange utilizando la dirección URL que obtuvo.
Nota: Técnicamente, hay un componente adicional involucrado en este escenario, como el servidor DNS local.
Escenario 2: entorno de Active Directory | Múltiples servidores Exchange locales
Este escenario todavía está relacionado con el proceso de detección automática en una red de organización local o privada.
El proceso de encontrar el punto final de detección automática requerido en función de la capacidad del cliente para consultar el Active Directory local y obtener una lista de los puntos finales de detección automática disponibles (servidores CAS de Exchange locales).
Cuando Active Directory responda con una lista de puntos finales de detección automática disponibles, el cliente de detección automática deberá elegir el punto final de detección automática de la lista de forma aleatoria o mediante un proceso que se describe como: Afinidad de sitio.
El término “Afinidad de sitio ” describe un proceso en el que el cliente de detección automática preferirá dirigirse al servidor Exchange que tiene el mismo valor de nombre de sitio de detección automática que él.
Escenario 3: cliente de detección automática | Acceso a la red externa
En el siguiente escenario, un cliente de correo externo necesita acceso al buzón de su organización y, para obtener el acceso requerido, deberá ubicar y conectar un servidor público Exchange CAS.
El cliente de detección automática no puede utilizar una consulta LDAP porque el servidor Active Directory de la organización no está "expuesto" al host de la red pública.
Por este motivo, el cliente de detección automática deberá consultar un servidor DNS público en busca de un host opcional que proporcione servicios de detección automática (punto final de detección automática).
La suposición subyacente es que el registro DNS requerido ya se creó y actualizó en un servidor DNS público que está disponible para un cliente ubicado en una red pública.
La diferencia significativa adicional es la necesidad de "disponibilidad pública" del servidor Exchange que se supone debe servir a los clientes Exchange externos.
El servidor Exchange deberá configurarse con nombre público, IP pública y certificado público.
El servidor Firewall o Proxy de la organización deberá configurarse con la configuración requerida que permitirá a los clientes externos "acceder" al servidor Exchange que sirve como punto final de detección automática para clientes externos.
Escenario 4: infraestructura de Exchange Online | Sólo nube | Cliente de correo externo
Este es un escenario clásico de “nube de Office 365”.
En este escenario, la infraestructura de correo de la organización no está alojada "internamente" ni en las instalaciones, sino que se basa en una suscripción a Office 365 y utiliza la infraestructura de Exchange Online como servicios de correo.
El acceso a la "infraestructura de correo en la nube" puede ser implementado por clientes de correo ubicados en la red pública o por clientes ubicados en la red privada/interna de la organización.
En el siguiente diagrama podemos ver una descripción del flujo de Autodiscover para un cliente de correo, que se ubica en una red pública y busca un Autodiscover Endpoint que se encuentra “en la nube” (Exchange Online).
El cliente de detección automática intentará buscar información sobre el punto final de detección automática dirigiéndose al servidor DNS público y preguntándole sobre un nombre de host de detección automática en particular.
La suposición subyacente es que el registro DNS requerido que señalará al cliente a la “descubrimiento automático en la nube” Endpoint” ya ha sido configurado.
Después de que el cliente de detección automática obtenga la IP necesaria (la IP que se asignó al punto final de detección automática en la nube), ese cliente de detección automática intentará conectarse al punto final de detección automática en la nube.
Nota: El diagrama proporcionado simplifica el "proceso real" solo para permitirnos obtener una comprensión general de la lógica del flujo de detección automática.
En realidad, el proceso es un poco más complicado porque, en el entorno de Office 365, el cliente de detección automática será redirigido a un punto final de detección automática adicional hasta que llegue al destino requerido.
Escenario 5: infraestructura de Exchange Online | Sólo nube | Cliente de correo interno
El siguiente escenario es similar al escenario anterior, pero con una diferencia principal: el cliente de correo (el cliente de detección automática) está ubicado dentro de la red de la organización y necesita conectarse a su buzón de Exchange Online.
En nuestro escenario particular, la organización no utiliza la infraestructura local de Exchange.
Cuando el escritorio de un usuario está configurado como "unido a un dominio" y los usuarios (y su escritorio) están ubicados en la red interna\privada, el cliente de detección automática, como Outlook, "programa" para iniciar la búsqueda del punto final de detección automática requerido conectando el servidor local On- Active Directory local mediante una consulta LDAP.
Debido a que no existe una "infraestructura local de Exchange", no hay información en el Directorio activo local y el Directorio activo local no puede proporcionar una "respuesta" al cliente de detección automática.
En este caso, el cliente comenzará a utilizar el segundo método de detección automática que se basa en una consulta DNS que busca la dirección IP del punto final de detección automática (el cliente "sabe" cuál es el nombre del punto final de detección automática).
Debido a que el cliente de detección automática se encuentra en la red interna\privada, el cliente de detección automática intentará conectarse al servidor DNS local.
La suposición subyacente es que el “DNS local” del servidor tiene acceso a la red pública y que puede “buscar” para el cliente de detección automática la dirección IP requerida del “punto final de detección automática en la nube”.
Cuando el cliente de detección automática interno obtenga la dirección IP necesaria, intentará conectarse al “punto final de detección automática en la nube”.
Escenario 6: Cliente de red interna | Infraestructura local de Exchange | Buzón de Exchange en línea
Un “escenario de nube” más complicado es un escenario en el que
- Un cliente tiene un buzón de Exchange Online
- El cliente de correo está ubicado en una red interna\privada
- La organización utiliza la infraestructura local de Exchange.
En nuestro escenario, el cliente de correo que se encuentra en la red interna de la organización no desea conectarse al "buzón local de Exchange", sino que desea conectarse a un buzón de Exchange Online que está ubicado "fuera" de la organización. red interna.
Aunque el "nodo final" está ubicado fuera de la red de la organización y la suposición lógica es que el cliente de detección automática accederá directamente al "punto final de detección automática en la nube", la realidad es diferente.
Cuando el escritorio de un usuario está configurado como "unido a un dominio" y los usuarios (y su escritorio) están ubicados en la red interna\privada, el cliente de detección automática como Outlook o "programado" para iniciar la búsqueda del punto final de detección automática requerido conectando el local en -Premise Active Directory mediante una consulta LDAP.
Active Directory "responde" a la consulta del cliente de detección automática y le envía la dirección URL de detección automática requerida.
El cliente de detección automática se dirige al servidor CAS de Exchange utilizando la dirección URL que obtuvo.
Debido a que el servidor local de Exchange no es "responsable" del dominio que se registró en la nube (infraestructura de Exchange Online), el servidor local de Exchange El servidor local responde con una respuesta negativa.
El cliente de detección automática "entiende" que ahora necesita utilizar un método de detección automática adicional.
En este caso, el cliente comenzará a utilizar el segundo método de detección automática, que se basa en una consulta DNS que busca la dirección IP del punto final de detección automática (el cliente "sabe" cuál es el nombre del punto final de detección automática).
Debido a que el cliente de detección automática está ubicado en la red interna\privada, el cliente intentará conectarse al servidor DNS local.
La suposición subyacente es que el “DNS local” del servidor tiene acceso a la red pública y que puede “buscar” para el cliente la dirección IP requerida del “punto final de detección automática en la nube”.
Cuando el cliente interno obtenga la dirección IP requerida, intentará conectarse al "punto final de detección automática de la nube".
Escenario 7: configuración híbrida
El proceso de detección automática en un entorno híbrido podría describirse como complicado debido a la "forma" en que el cliente de detección automática encuentra su "punto final de detección automática requerido".
En nuestro escenario, el usuario de una organización desea conectarse a su buzón, pero su buzón migró a la "nube" (Exchange Online).
Los servidores Exchange On-Premise “ven” el buzón migrado del usuario como un buzón remoto.
Técnicamente, Exchange On-Premise es el "propietario" del buzón del usuario. Cuando el usuario intenta conectarse a su buzón ubicado físicamente en la "nube" (Exchange Online), Exchange On-Premise es razonable para "redirigir" al destinatario a su buzón en la nube.
La redirección se implementa proporcionando al destinatario la Dirección de correo electrónico adicional que tiene y que utiliza el nombre de dominio del espacio compartido que se emplea en el entorno híbrido:
El concepto de "entorno híbrido" se basa en una estructura lógica en la que la
"infraestructura local" sirve como punto focal o "punto de partida" para los clientes de Exchange.
En caso de que el buzón del usuario esté ubicado en Exchange On-Premise, el proceso de detección automática (y todo el resto del proceso de detección automática) se implementa exactamente como cualquier escenario estándar de cliente/servidor de Exchange On-Premise.
En caso de que el buzón del cliente esté ubicado en la “nube” (Exchange Online), el proceso de detección automática es muy diferente.
El cliente de detección automática iniciará el proceso dirigiéndose al servidor local de Exchange On-Premise, pero el cliente de detección automática será "redirigido" o "señalado" a su dirección de correo electrónico en la nube (Exchange Online) y desde ese punto, el cliente de detección automática proceso implementado como un "proceso estándar de detección automática en la nube", en el que el cliente de detección automática intenta localizar y conectar su "punto final de detección automática en la nube".
Para demostrar la "ruta de detección automática" que se implementó en un entorno híbrido, utilicemos el siguiente escenario.
- El nombre de dominio local de Active Directory local es: o365info.local
- El nombre de dominio de la organización pública es - o365info.com
- El nombre de dominio de Office 365 híbrido es: mail.o365info.com
- Dirección de correo electrónico del usuario/destinatario: Bob@o365info.com
El buzón de Bob está ubicado en la "nube" (Exchange Online). El término técnico es "buzón remoto".
El buzón de Bob se "movió" a la infraestructura de correo en la nube (Exchange Online) y al servidor Exchange On-Premise, se relaciona con el buzón de Bob como "buzón remoto".
El objeto de “buzón remoto” sirve como “puntero” al buzón de la nube de Bob.
La tarea: a Bob le gustaría configurar un nuevo perfil de correo de Outlook que le permitirá conectarse a su buzón de correo "en la nube".
Paso 1: Outlook conecta el Active Directory local y solicita una lista de posibles puntos finales de detección automática (servidores Exchange CAS).
Paso 2: Active Directory “responde” con una lista de servidores Exchange disponibles (punto final de detección automática).
En nuestro ejemplo, Active Directory proporciona al cliente la siguiente dirección URL:
Https://ex01.o365info.local/Autodiscover/Autodiscover.xml
Nota: técnicamente hay un paso adicional en el que Outlook conecta el servidor DNS local buscando el Dirección IP del host: ex01.o365info.local
En nuestro ejemplo, asumimos que este paso se completa correctamente y que Outlook "sabe" cómo llegar al punto final de detección automática interno (ex01.o365info.local).
Paso 3: el cliente de detección automática (Bob) intentará comunicarse con el servidor CAS de Exchange ex01.o365info.local asumiendo que este es “su CAS de Exchange”. servidor”.
Paso 4: el servidor local de Exchange busca el buzón de Bob y "ve" el buzón de Bob configurado como "buzón remoto".
Los servidores de Exchange buscan un valor almacenado en la propiedad de un destinatario denominada -
Dirección de correo electrónico de enrutamiento y “ver” que la dirección de correo electrónico de la “nube” (Exchange Online) de Bob sea - Bob @o365info.mail.onmicrosoft.com
El servidor Exchange "informa" a Bob que debe utilizar una "nueva dirección de correo electrónico": Bob@o365info.com
Paso 5: los clientes de Outlook acceden al servidor DNS local y solicitan la dirección IP del “punto final de detección automática remoto”. Outlook primero intentará obtener la dirección IP del nombre de dominio raíz (en nuestro ejemplo o365info.mail.onmicrosoft.com) y si el DNS no incluye la IP requerida, Outlook intentará buscar la siguiente convención de nombres Autodiscover.
(en nuestro ejemplo Autodiscover.o365info.mail. enmicrosoft.com).
Paso 6: el DNS local accede a “sus recursos” y encuentra para su cliente de detección automática la dirección IP requerida.
(La dirección IP pública que está “asignada” al punto final de detección automática que presenta el Exchange Servicios en línea).
Paso 7: Outlook intentará verificar si el “punto final de detección automática remoto” escucha o abre usando el puerto 443 y, si la respuesta es “Sí”, Outlook enviará un requisito para el archivo Autodiscover.xml requerido.
Nota: Esta descripción del flujo de trabajo es solo una descripción muy general. En realidad, el "primer punto final de detección automática en la nube" es solo una "caja negra" lógica que responderá a la solicitud de Outlook con una redirección HTTP.
El cliente Outlook intentará solicitar el Autodiscover.xml desde el “punto final de detección automática adicional” y será redirigido nuevamente hasta que llegue al “punto final de detección automática final”.
