Flujo de detección automática en un entorno local de Exchange | entorno no Active Directory| Parte 2#3 | Parte 27#36
En el artículo actual, revisamos el algoritmo de detección automática que utiliza el cliente de detección automática
en un “entorno que no es Active Directory”. ”
Autodiscover Toolbox ofrece una variedad de métodos que el cliente de detección automática puede utilizar cuando intenta localizar su punto final de detección automática.
La esencia del viaje de detección automática
El objetivo principal del “viaje de detección automática” que implementa el cliente de detección automática es encontrar su punto final de detección automática.
Técnicamente hablando, existen muchos tipos de escenarios en los que el cliente de detección automática inicializará el proceso de detección automática y diferentes tipos de clientes de detección automática.
Por esta razón, necesitaremos centrarnos en ejemplos específicos de la variedad de escenarios posibles.
Para demostrar el proceso de detección automática en un entorno que no es Active Directory, revisaremos la situación de un cliente que necesita crear un nuevo perfil de correo de Outlook, en un entorno que se describe como entorno que no es Active Directory.
- De forma predeterminada, el cliente de detección automática intentará localizar su punto final de detección automática consultando el DNS para obtener un nombre de host específico (dominio raíz) que obtiene de la dirección de correo electrónico del destinatario.
- En caso de que el cliente Autodiscover no logre completar el proceso con el host, intentará usar un nombre de host diferente usando la convención de nomenclatura Autodiscover + nombre de dominio.
- En caso de que el cliente Autodiscover no logre completar el proceso con el host, intentará solicitar una instrucción de "redirección" al host requerido.
- En caso de que el cliente de detección automática no logre completar el proceso con el host, consultará el servidor DNS en busca de un registro SRV que incluya el nombre de host del punto final de detección automática requerido.
En el siguiente diagrama, podemos ver el flujo del algoritmo de detección automática para el cual el cliente de detección automática está "programado".
¿Tienes la sensación de que el diseño es complicado y, al mirar el gráfico, empiezas a sentir un ligero dolor de cabeza?
Bueno, estoy de acuerdo, pero al mismo tiempo debo informarles que esta es una “versión minimizada” del flujo de trabajo de detección automática.
Al ahogar el diagrama, omití muchas "partes", como el proceso de autenticación mutua y otras partes para hacer que el diagrama sea digerible.
Por ejemplo, con respecto al mecanismo de seguridad que se implementó como parte del proceso de detección automática, la descripción del flujo de detección automática que se proporciona en la siguiente sección incluye una referencia muy general a la falla de seguridad que se implementó.
Si desea leer información más detallada sobre el tema de la seguridad en el entorno de detección automática, lea el artículo - Proceso de detección automática e infraestructura de seguridad de Exchange | Parte 20#36
Flujo de trabajo de detección automática en un entorno que no es Active Directory | Escenarios opcionales
Para demostrar algunos de los escenarios opcionales de detección automática en un entorno que no es Active Directory, utilicemos la siguiente infraestructura organizativa:
El nombre de dominio público de la organización es - o365info.com
La empresa tiene un sitio web público que se publica utilizando el nombre de host - o365info .com
Un usuario externo llamado Bob que tiene la dirección de correo electrónico: Bob@o365info.com necesita crear un nuevo perfil de correo de Outlook para conectarse a su buzón alojado en Exchange On-Premise. servidor.
Nota: El método de detección automática implementado no puede basarse en el método de detección automática de Active Directory porque el cliente de detección automática está ubicado en una red pública externa y no tiene acceso al Directorio Activo de la organización.
Escenario 1: sitio web de la empresa que utiliza el nombre de dominio público | sin soporte HTTPS
El cliente de detección automática (Outlook en nuestro ejemplo) tomará la "parte derecha" de la dirección de correo electrónico del destinatario y se relacionará con el nombre de dominio SMTP como el nombre de host de un posible punto final de detección automática.
El cliente de detección automática se comunicará con un servidor DNS y consultará al DNS sobre una dirección IP de un host llamado: o365info.com
En nuestro escenario, el DNS tiene una IP que está "asignada" a este nombre de host.
Tenga en cuenta que esta dirección IP apuntará al sitio web público de la empresa que no es un punto final de detección automática, ¡pero el cliente de detección automática no lo sabe!
El cliente de detección automática utiliza la dirección IP que obtiene del servidor DNS e intenta verificar si el punto final de detección automática potencial admite la comunicación mediante el protocolo HTTPS.
En este escenario particular, el sitio web de la empresa no admite HTTPS (no tiene un certificado público).
Cuando falla la prueba de comunicación HTTPS con el host o365info.com, el cliente de detección automática "comprende" que necesitará "pasar" al método de detección automática adicional.
El cliente de detección automática inicia una nueva sesión, pero esta vez; El cliente de detección automática ahora intentará buscar un punto final de detección automática potencial utilizando el nombre de host: autodiscover.o365info.com
En nuestro escenario, se creó un registro A utilizando el nombre de host: detección automática y la dirección IP que se asignó a este nombre de host apunta al servidor local de Exchange.
El cliente de detección automática comprueba si el host autodiscover.o365info.com admite HTTPS.
El punto final de detección automática (servidor CAS de Exchange público) aprueba que pueda comunicarse mediante el protocolo HTTPS.
El cliente de detección automática solicitará al punto final de detección automática (servidor CAS de Exchange público) que demuestre su identidad proporcionando un certificado público.
En caso de que el certificado del servidor se verifique correctamente, el cliente de detección automática enviará sus credenciales de usuario al punto final de detección automática.
El último paso es el paso en el que el cliente de detección automática solicita al punto final de detección automática la información de detección automática necesaria para crear un nuevo perfil de Outlook en cualquier lugar.
Escenario 2: sitio web de la empresa que utiliza el nombre de dominio público | Soporte HTTPS
El siguiente escenario es un poco confuso porque esta vez tratamos con un sitio web público que está asignado al "nombre de dominio raíz" + admite HTTPS.
Este escenario hará que el cliente de detección automática "crea" que ha encontrado su punto final de detección automática, pero en realidad, el host con el que intenta comunicarse no es el host requerido.
El cliente de detección automática se pondrá en contacto con el servidor DNS buscando el nombre de host: o365info.com
Después de obtener la dirección IP, el cliente de detección automática intenta verificar si el host (el posible punto final de detección automática) admite la comunicación HTTPS.
En nuestro escenario, el sitio web de la empresa admite la comunicación HTTPS y tiene un certificado público.
La suposición subyacente del punto final de detección automática es que este es el "host adecuado" y ahora; el cliente de detección automática generará una solicitud de información de detección automática.
La solicitud será aceptada por el host- o365info.com pero este host no es un punto final de detección automática y no No “entiendo” el significado de - “solicitud de información de detección automática”.
El cliente de detección automática sabe que intenta comunicarse con el "host incorrecto" y el siguiente paso es: avanzar hacia los siguientes métodos de detección automática en los que el cliente de detección automática intentará buscar el punto final de detección automática utilizando un nombre de host diferente: autodiscover.o365info.com
Escenario 3: redirección HTTP
En este escenario, nos “desviaremos” de nuestro escenario original que se basa en la infraestructura local de Exchange en favor de un escenario que es común en un entorno como Office 365 y Exchange Online.
En este escenario, el buzón de correo del usuario se aloja en el servidor de Exchange Online.
La infraestructura de la nube no publica nombres de host utilizando la "supuesta convención de nomenclatura", sino cuando el cliente de detección automática "piensa" que obtuvo su posible punto final de detección automática. , el host lo redirige a la infraestructura de detección automática de Office 365 para continuar con el proceso de detección automática.
En el siguiente diagrama, podemos ver que el cliente de detección automática obtiene del servidor DNS la dirección IP de - autodiscover.o365info.com
Cuando intenta comprobar si el punto final de detección automática potencial (autodiscover.o365info.com) admite conexiones HTTPS, obtiene una respuesta negativa.
El cliente de detección automática "pasará" al siguiente método de detección automática en el que intenta solicitar información del posible punto final de detección automática sobre un "nuevo nombre" del punto final de detección automática.
Este método se describe como una redirección HTTP porque el host redirige al cliente de detección automática a un "punto final potencial de detección automática adicional".
En el siguiente diagrama, podemos ver que el cliente de detección automática se dirige al host autodiscover.o365info.com utilizando el protocolo HTTP en lugar de utilizar el protocolo HTTPS estándar.
Debido a que el host de Office 365 es "consciente" del proceso en el que necesita redirigir el cliente de detección automática a otro posible punto final de detección automática, el host de Office 365 envía el nombre de host: autodiscover.outlook.com en la respuesta de redirección.
El cliente de detección automática intentará ahora comunicarse con el “nuevo punto final de detección automática llamado- Autodiscover-s.outlook.com utilizando el protocolo HTTPS (he abandonado el proceso de resolución de nombres DNS).
En el entorno de Office 365, el flujo de detección automática no finalizará en este punto, pero por el momento detendré nuestro escenario en esta fase.
El cliente de detección automática verifica si el "nuevo punto final de detección automática" puede comunicarse mediante HTTPS. Si la respuesta es “sí”, el proceso de detección automática continuará desde este punto.
Escenario 4: búsqueda de un registro SRV de detección automática
El siguiente escenario describe un método de detección automática único que se basa en un registro DNS especial, el registro SRV.
El uso del método SRV Autodiscover permite implementar el método Autodiscover en un entorno que no es Active Directory que es muy similar al proceso Autodiscover en un entorno Active Directory.
Hasta ahora, el proceso de detección automática que utiliza el cliente de detección automática se basa en un método en el que el cliente de detección automática "genera" o adivina el nombre del punto final de detección automática utilizando la "parte derecha" de la dirección de correo electrónico del destinatario (el nombre de dominio SMTP).
En un escenario en el que una organización particular posee varios dominios públicos, el departamento de TI debe configurar el registro DNS requerido para cada uno de los dominios y también agregar el nombre del host de detección automática para cada uno de los dominios al certificado público del servidor.
Al usar la opción del registro SRV, no se puede "apuntar" un cliente de correo que usa un nombre de dominio SMTP diferente a un "punto único de autoridad", es decir, un punto final de detección automática que puede servir al cliente diferente.
Por ejemplo, el registro DNS SRV puede señalar a un destinatario del dominio - o365info.com + el dominio o365info.org al un punto final de detección automática denominado: mail3.otherdomain.com
Es importante enfatizar que el método de detección automática SRV es el "último método de detección automática de la lista".
Solo si el cliente de detección automática agota todos los métodos de detección automática, que revisamos en los escenarios anteriores, intentará utilizar el método de detección automática SRV.
Podría haber un par de escenas que "llevarán" al cliente de detección automática a utilizar el método de detección automática SRV.
En este escenario, el cliente de detección automática intenta consultar al servidor DNS la dirección IP de los hosts: o365info.com y autodiscover.o365info.com
El registro A para este host no se agregó al DNS deliberadamente.
La intención era "obligar" al cliente de detección automática a "conmutar por recuperación" al método de detección automática SRV.
El siguiente paso del cliente de detección automática es consultar el DNS para obtener un registro SRV de detección automática.
En nuestro ejemplo, el registro SRV se creó y se configuró con el host denominado: mail3.otherdomain.com
El cliente de detección automática intentará obtener la dirección IP del host: mail3.otherdomain.com
Cuando Autodiscover encuentre el host, intentará verificar que el host pueda comunicarse mediante HTTPS, etc.
Otro escenario posible es un ejemplo en el que el cliente de detección automática encuentra información sobre un posible punto final de detección automática llamado autodiscover.o365info.com
El "problema" es que este host no responde a una solicitud de comunicación HTTPS y, además, no puede relacionarse con la aplicación de redirección HTTP para el cliente de detección automática.
En este caso, el cliente de detección automática "volverá" al método de detección automática para intentar consultar al servidor DNS sobre un registro SRV.
