Escenarios de detección automática en entorno empresarial | Parte 16#36
La infraestructura local de Exchange se diseñó para satisfacer las necesidades de una pequeña empresa y, al mismo tiempo, satisfacer las necesidades de una empresa que necesita brindar servicios de correo a miles o incluso decenas de miles de usuarios.
Los principales personajes del entorno empresarial son:
- El uso de múltiples servidores Exchange en múltiples sitios de Active Directory.
- La necesidad de implementar soluciones de equilibrio de carga y alta disponibilidad para la infraestructura de Exchange.
En el artículo anterior (Flujo de detección automática en un entorno basado en Active Directory | Parte 15#36), revisamos los conceptos básicos del canal de comunicación entre un cliente de detección automática como Outlook y un servidor CAS de Exchange específico.
En el artículo actual, me gustaría “pasar” al escenario más avanzado o complejo que es común en el entorno empresarial.
El Autodiscover es una “criatura muy flexible” que fue diseñada para una infraestructura simple y, al mismo tiempo, para una infraestructura compleja y compuesta.
En el siguiente artículo, “probaremos” solo una parte de los posibles escenarios locales de Exchange en un entorno empresarial, para que podamos comprender mejor la forma en que se implementan los servicios de detección automática en múltiples entornos de servidores Active Directory y Exchange. .
Nota: En el contexto de la infraestructura de detección automática, cuando se utiliza el término "múltiples servidores Exchange", el significado es: múltiples servidores Exchange que tienen la función CAS (servidor de acceso de cliente).
En En la infraestructura de Exchange, el servidor de Exchange que desempeña la función CAS es responsable de proporcionar al cliente (como Outlook) servicios de detección automática.
El conocimiento sobre el "comportamiento" de los servicios de detección automática, en una infraestructura y entornos de Exchange diferentes, puede ayudarnos en un escenario de solución de problemas de detección automática.
Escenario 1: varios servidores Exchange CAS en el mismo sitio de Active Directory
El escenario de múltiples servidores Exchange CAS en el mismo sitio de Active Directory es un escenario popular en una organización grande o empresarial, que utiliza una infraestructura de Exchange, que puede atender a una gran cantidad de clientes de Exchange al mismo tiempo y puede proporcionar respuestas para temas como - Alta disponibilidad y optimización del rendimiento.
Técnicamente hablando, no hay limitación en la cantidad de servidores Exchange CAS que podemos usar en un sitio de Active Directory en particular.
Además, no necesitamos hacer ni configurar nada para que este servidor Exchange CAS esté disponible para el cliente Exchange porque el registro de los servidores Exchange CAS en el SCP de Active Directory se implementó automáticamente.
Cada vez que un cliente de detección automática consulte el SCP de Active Directory para obtener información sobre el punto final de detección automática disponible (servidores CAS de Exchange), la respuesta incluirá la URL y el FQDN para cada uno de los servidores CAS de Exchange.
En el diagrama, podemos ver que cuando el cliente de detección automática consulta Active Directory, el cliente de detección automática obtiene dos nombres de "punto final de detección automática opcional". "
En caso de que todos los puntos finales de detección automática "pertenezcan" al mismo sitio de Active Directory, el cliente de detección automática simplemente elegirá aleatoriamente un nombre de punto final de detección automática (servidor Exchange CAS) de la lista e intentará dirigirse a él.
En caso de que el punto final de detección automática no responda, el punto final de detección automática "pasará" al siguiente host en la lista al que obtuvo una respuesta de la consulta de Active Directory.
El método descrito en el que el cliente de detección automática simplemente "selecciona" un nombre de servidor Exchange de una lista no requiere equilibrio de carga.
El tema de la implementación de una solución de equilibrio de carga para servidores Exchange CAS ha cambiado radicalmente en la arquitectura Exchange 2013 frente a la arquitectura Exchange 2010.
No entraremos en los detalles específicos del “mundo del equilibrio de carga y la alta disponibilidad” en el entorno Exchange, sino que nos contentaremos con una explicación muy simple.
La implementación de una solución de alta disponibilidad en un entorno Exchange implementada mediante el uso de un nombre de servidor Exchange lógico que sirve como representante de dos o más servidores "Exchange físicos".
Al implementar una solución de equilibrio de carga y alta disponibilidad en un entorno Exchange, no utilizaremos la opción predeterminada en la que los servidores CAS de Exchange se registran automáticamente en el SCP de Active Directory, sino que registraremos manualmente el nombre si el lógico entidad que representa los servidores CAS de Exchange existentes.
Cada vez que un cliente de detección automática consulte el Active Directory local para obtener el nombre (URL) de Autodiscover Endpoint, la respuesta incluirá la dirección URL que utiliza el FQDN de la entidad lógica, como el FQDN que eligió para el equilibrador de carga que " representan "los servidores Exchange CAS existentes en el sitio.
En otras palabras, el cliente de detección automática no conectará un punto final de detección automática directamente, sino que conectará la entidad lógica (como el equilibrio de carga) que "reenviará" su solicitud a un servidor CAS de Exchange en particular.
Nota: En otros tipos de implementación, como la operación por turnos de DNS, el cliente de detección automática se dirige al servidor CAS de Exchange directamente sin un intermediario, como un equilibrador de carga.
Escenario 2: varios servidores CAS de Exchange en varios sitios de Active Directory | Sitio de Active Directory sin un servidor Exchange CAS local
En el siguiente escenario, nos basaremos en la siguiente infraestructura de Active Directory y Exchange:
Una empresa tiene tres sitios físicos: un sitio en Nueva York, un sitio en Los Ángeles y un sitio de la empresa de hilos en Bangkok.
La infraestructura de Exchange se implementa de la siguiente manera:
- Exchange CAS server name
Sitio de Active Directory local
- ex01.o365info.local
Nueva York
- ex01.o365info.local
Bangkok
- N/A
LA
El sitio de Los Ángeles no incluye una infraestructura de Exchange.
Todos los buzones de correo del “usuario de Los Ángeles” ubicados en el servidor Exchange en el sitio de Nueva York.
La pregunta principal es: en caso de que los “usuarios del sitio de Los Ángeles” necesiten conectar su buzón de correo de Exchange (con la mediación del servidor CAS de Exchange), ¿con qué servidor CAS de Exchange deben contactar?
A primera vista, la respuesta parece bastante evidente: los usuarios de Los Ángeles probablemente se dirigirán al servidor Exchange CAS en el sitio de Nueva York porque el "servidor Exchange CAS de Nueva York" está geográficamente más cerca de ellos que el servidor Exchange CAS en el sitio de Bangkok. .
Bueno, en realidad la respuesta no es tan simple.
Técnicamente hablando, el cliente de Exchange no sabe quién es el "servidor CAS de Exchange correcto". La única forma disponible para el cliente de Exchange es consultar su Active Directory local.
En nuestro escenario, la respuesta incluye una lista de dos nombres de servidores Exchange CAS:
- ex01.o365info.local el servidor CAS de New York Exchange
- ex03.o365info.local el servidor CAS de Bangkok Exchange
Lo que sucederá gravemente es que el cliente de Exchange de Los Ángeles seleccionará aleatoriamente los nombres de los servidores Exchange CAS de la lista.
Estadísticamente, el 50 % de las solicitudes de conexión apuntarán al servidor CAS de New York Exchange (ex03.o365info.local) y el otro 50 % de las solicitudes de conexión apuntarán al Servidor CAS de Bangkok Exchange (ex03.o365info.local).
La suposición subyacente es que nos gustaría evitar este escenario porque no tiene sentido que los usuarios de Los Ángeles se conectaran a su buzón de correo a través del servidor CAS de Bangkok Exchange ubicado en el "otro lado del mundo".
La buena noticia es que existe una solución para este "problema" llamada Site Affinity.
La opción de Afinidad de sitio nos permite “marcar” un servidor Exchange CAS en particular como servidor preferido para uno o más sitios de Active Directory.
En nuestro escenario, el servidor CAS de Exchange de Nueva York se registró automáticamente como servidor CAS de Exchange para el sitio de Nueva York.
En nuestro escenario, nos gustaría "decirle" al cliente de Los Angles Exchange que debería preferir el servidor CAS de New York Exchange (ex01.o365info.local).
Para implementar este requisito, podemos "vincular" o "adjuntar" un nombre de sitio de Active Directory adicional al servidor CAS de New York Exchange.
La implementación de este "enlace" en el que definimos el servidor CAS de Exchange de Nueva York como un tamiz que considera el servidor CAS de Exchange preferido para los usuarios de Los Ángeles se implementó mediante la edición de valores de Exchange específicos que están registrados en Active Directory denominados - Palabra clave
Después de completar esta tarea, a partir de este día en adelante, cada vez que el cliente Exchange del sitio de Los Ángeles consulte en Active Directory los servidores Exchange CAS disponibles, porque el servidor Exchange CAS de Nueva York (ex01.o365info. local) tiene la palabra clave que incluye el nombre de su sitio (LA), preferirán conectarse a este servidor Exchange CAS en particular.
Escenario 3: Cliente de correo interno que busca servicios de detección automática "externos"
En la siguiente sección, revisaremos un escenario en el que el usuario de una organización que está conectado a la red privada/local de la empresa intenta crear un nuevo perfil de correo de Outlook para conectarse al buzón de Exchange Online ubicado en una red pública.
Un ejemplo popular podría ser: usuarios de Office 365 cuyo buzón de correo estaba alojado en Exchange Online.
La organización utiliza una infraestructura local de Exchange, pero, en nuestro escenario, el usuario particular necesita conectarse a la "infraestructura externa de Exchange" (Exchange Online) y no a la infraestructura local de Exchange.
Tenga en cuenta que en nuestro escenario, el usuario utiliza el escritorio de una organización, que puede acceder al Active Directory local.
La suposición subyacente del cliente Outlook es que el Active Directory local puede proporcionar la información requerida sobre los nombres de los puntos finales de detección automática (URL si queremos ser más precisos) de los puntos finales de detección automática disponibles.
Técnicamente, el cliente de Outlook no sabe que el buzón de correo que desea conectar no está alojado en un servidor local de Exchange.
Para que el ejemplo sea real, usemos el siguiente escenario:
- El nombre de dominio de Active Directory es -o365info.lcoal
- El nombre de dominio SMTP público es - o365info.com
- La organización tiene dos sitios Active Directory\ Exchange: el sitio de Nueva York y el sitio de Los Ángeles. Cada uno de los sitios de Active Directory incluye el servidor Exchange CAS.
- El nombre en el servidor Exchange CAS en el sitio de Nueva York es - ex01.o365info.com
- El nombre en el servidor Exchange CAS en el sitio de Los Ángeles es: ex02o365info.com
- La dirección de correo electrónico de un usuario de dominio alojado en el servidor externo de Exchange Online es: Bob@Ihaveaverysmallbrain.com
- Bob está ubicado en el sitio de la empresa en Nueva York.
Fase 1: conexión del Active Directory local
El cliente Outlook se conecta al Active Directory local y solicita una lista de servidores Exchange locales disponibles.
Tenga en cuenta que no existe ninguna “relación” o conexión entre el nombre de dominio de Active Directory local y el nombre de dominio SMTP de correo electrónico.
Active Directory envía al cliente de detección automática una lista de objetos SCP registrados (servidores Exchange CAS).
En nuestro ejemplo, la lista incluye nombres de dos servidores Exchange:
ex01.o365info.local y ex03.o365info.local (número 1 en el diagrama).
Fase 2: conexión a cada uno de los servidores CAS de Exchange locales
El primer punto final de detección automática al que el cliente Outlook intentará conectarse es el servidor Exchange CAS que se encuentra en el mismo sitio de Active Directory.
Lo "extraño" es que el cliente de detección automática (Outlook) logrará encontrar y comunicar el servidor local de Exchange ex01.o365info.local
Cuando el cliente de detección automática intenta obtener la información de detección automática requerida (la respuesta autodiscover.xml), el servidor CAS de Exchange envía una "respuesta negativa" porque el servidor CAS de Exchange (ex01.o365info.local) no es responsable o, si queremos ser más precisos, no tiene autoridad para el dominio Bob@Ihaveaverysmallbrain.com (número 2 en el diagrama ).
Nota: el proceso de comunicación de detección automática se completará correctamente porque el servidor CAS de Exchange: ex01.o365info.local tiene un certificado que incluye el FQDN especificado, el cliente de detección automática podría proporcionar las credenciales de usuario requeridas. , etc.
A pesar de que todos los pasos básicos de detección automática se completaron con éxito, el proceso no se puede completar porque ex01.o365info.local no es responsable (autorizado) del espacio de nombres - Tengo un cerebro muy pequeño.com
El logaritmo de detección automática se basa en el método en el que, cuando el "primer punto final de detección automática" de la lista no puede proporcionar la información requerida, el cliente de detección automática "se mueve" al siguiente nombre de la lista (si dicho nombre existe).
En nuestro escenario, el punto final de detección automática proporcionado por Active Directory incluye el nombre adicional: ex03.o365info.local
El cliente de correo de Outlook supone que este es el "punto final de detección automática correcto" que proporcionará la información de detección automática requerida.
Outlook se dirige al servidor CAS de Exchange ex03.o365info.local y nuevamente, se supone que Outlook encontrará la dirección IP interna de ex03.o365info. local, logra completar el proceso de autenticación mutua, pero el proceso no se puede completar exitosamente porque ex03.o365info.local tampoco es responsable ni tiene autoridad sobre el nombre de dominio - Ihaveaverysmallbrain.com (número 3 en el diagrama).
Fase 3: búsqueda del punto final de detección automática mediante el nombre de dominio SMTP
Esta es la fase en la que el cliente de detección automática comprende que no puede seguir utilizando el “método de detección automática de Active Directory”.
El "siguiente método de detección automática" se implementa "extrayendo" el nombre de dominio SMTP de la dirección de correo electrónico del destinatario y conectando un servidor DNS buscando la dirección IP del "nombre de host". "
En nuestro escenario, Outlook extraerá el nombre de dominio: Ihaveaverysmallbrain.com y solicitará a un servidor DNS la IP de este dominio.
En caso de que el servidor DNS tenga una dirección IP asignada al nombre de dominio, el servidor DNS proporciona al cliente (Outlook) la dirección IP (número 4 en el diagrama).
Fase 4: conexión al servidor Exchange “externo”
Outlook intenta conectarse al punto final de detección automática mediante la siguiente URL: Https://Ihaveaverysmallbrain.com/Autodiscover/Autodiscover.xml
El cliente Outlook consultará el servidor DNS. Dado que todas las configuraciones requeridas se aplicaron de antemano, el DNS proporcionará una respuesta que incluye la dirección IP de la infraestructura de Exchange Online.
El cliente de detección automática puede completar el proceso con el “servidor CAS de Exchange externo”.
El cliente Outlook abordará Exchange Online, complementará el proceso de autenticación mutua y enviará una solicitud de información de detección automática.
Exchange Online envía a Outlook (el cliente de detección automática) la información de detección automática requerida.
El cliente Outlook utiliza la información incluida en el archivo Autodiscover.xml para crear un nuevo perfil de correo Outlook y permite al usuario conectarse a su buzón de Exchange Online "remoto" o "externo".