Los conceptos básicos del nombre de dominio, FQDN y dirección URL | Infraestructura de intercambio |Parte 09#36

El canal de comunicación entre el cliente Exchange y el servidor Exchange se basa en un concepto simple, en el que el cliente Exchange se dirige al servidor Exchange utilizando el nombre de host de Exchange o, si queremos ser más precisos, el FQDN del servidor Exchange.

La variedad de servicios que ofrece el servidor Exchange a su cliente Exchange solicitando servicios web Exchange y, terminando con servicios para el cliente de correo web como OWA, son implementados por el cliente Exchange que accede a este servicio Exchange mediante una dirección URL.

Con respecto a las relaciones que existen entre un servidor Exchange y un cliente Outlook, toda esta información se empaqueta y envía a un cliente Outlook a través de la respuesta de detección automática proporcionada por el servidor Exchange.

Como se mencionó en un artículo anterior, cada servidor Exchange público tiene dos identidades: la privada y la pública.

Cuando Exchange proporciona información sobre los servicios web de Exchange disponibles, la información se proporciona en dos "formatos" diferentes:

• Información relevante para el cliente interno de Outlook
• Información relevante para el cliente Outlook externo

La principal diferencia entre la información que se proporciona para el cliente Outlook interno y externo es la dirección URL de los servicios web de Exchange.

• La información relevante para el cliente interno de Outlook incluye la dirección URL de los servicios web de Exchange que utiliza el FQDN interno de Exchange.
• La información relevante para clientes externos de Outlook incluye la dirección URL de los servicios web de Exchange que utiliza el FQDN externo de Exchange.

Concepto de dirección URL y servicios web Exchange

Aunque aparentemente estamos familiarizados con el concepto de utilizar una dirección web (URL), me gustaría dedicar el siguiente apartado al tema Autodiscover y dirección URL porque este tema no es tan sencillo como parece.

En nuestro camino para convertirnos en un "profesional de detección automática", debemos estar familiarizados con

1. La estructura de la dirección URL de los servicios web de Exchange.
2. La otra parte que consta de la dirección URL de los servicios web.
3. La dirección URL diferente que Exchange proporciona para un cliente de correo interno frente a un cliente de correo externo.

Además, la pregunta que puede aparecer podría ser:

1. ¿Cómo configura el servidor Exchange CAS la dirección URL para los servicios web?
2. ¿Deberíamos “intervenir” con la configuración predeterminada de la dirección URL de los servicios web de Exchange?
3. ¿Cuáles son los escenarios en los que debemos implementar esta “Intervención”?
4. ¿Existe alguna práctica recomendada para la dirección URL de los servicios web de Exchange?

Y, como siempre, no existe una respuesta sencilla a esta pregunta.
En el artículo actual, nos centraremos en la "estructura física" de la dirección URL de los servicios web de Exchange.

La estructura de la dirección URL | Vista de alto nivel

Comencemos con una pregunta muy sencilla:
P. ¿Sabes qué significa URL?

A: Bueno… no los voy a aburrir con discusiones académicas, pero, para aquellos de ustedes que no sabían la respuesta, URL significa -localizador uniforme de recursos.

La mayoría de nosotros vinculamos asociativamente el término "URL" con términos como navegador, sitio web, etc.

Un "navegador" es sólo un ejemplo de un "cliente" que puede consumir servicios basados en web.

En realidad, existen muchos tipos de “clientes” que pueden consumir servicios basados en web.
Por ejemplo, Outlook es un cliente que depende en gran medida de los servicios web de Exchange.

La estructura de la dirección URL.

Una dirección URL es como un rompecabezas, formado por muchas partes.

La “mendicidad” de la dirección URL “declarará” el protocolo (el idioma) que utilizarán el cliente y el servidor. En un entorno basado en Exchange, los servicios web se proporcionan utilizando el protocolo HTTP y el protocolo HTTPS (la versión cifrada del protocolo HTTP).

La “parte media” de la dirección URL, incluye información sobre el host o el nombre del “elemento” que brindará el servicio web.

La mayoría de las veces, las convenciones de nomenclatura que utilizamos para "apuntar" al host que proporciona los servicios web específicos se basan en la convención de nomenclatura FQDN (nombre de dominio completo).

La "última parte" o la "parte derecha" de la dirección URL incluye la ruta de los servicios web específicos. La "ruta" no es una parte obligatoria de la dirección URL.

Usamos la opción de "camino" en caso de que el host en particular proporcione un par de servicios web, o queremos señalar al cliente a una carpeta o archivo específico.

Por ejemplo, el servidor Exchange CAS proporciona muchos tipos de servicios web. Cuando los clientes de Exchange necesitan un servicio web particular del servidor CAS de Exchange, los clientes de Exchange deberán dirigirse al servidor CAS de Exchange mediante una URL que incluya el nombre del servidor CAS de Exchange + la ruta del servicio web específico.

En este artículo, nos centraremos únicamente en la "parte media" (el nombre de host o el nombre FQDN) de la dirección URL de los servicios web de Exchange porque, en caso de que necesitemos configurar o ajustar la dirección URL de un servicio web de Exchange en particular, Actualizaremos o configuraremos la parte relacionada con el nombre de host de Exchange.

El escenario en el que actualizamos la parte "ruta" de la dirección URL de los servicios web de Exchange es muy poco común y no se recomienda.

Nombre de host versus nombre FQDN

Un nombre de host es un nombre lógico que utilizamos para dirigirnos a un “elemento” de red específico.
Podemos definir el término nombre de host como un “nombre único” o un “nombre de una sola palabra”.

El término FQDN significa Nombre de dominio completo.
Para mí, la palabra FQDN siempre suena extraña.

El término “Nombre de dominio completo” define la convención de nomenclatura, pero el término FQDN se relaciona con un “Nombre de host completo” versus el término “Host” que se califica con un solo nombre de host.

Un FQDN se crea utilizando la siguiente fórmula:

Para poder comprender mejor la diferencia entre el término nombre de host y el término nombre FQDN, podemos relacionarnos con una “dirección humana” estándar. "

Cuando nos referimos a alguien usando el nombre John, este es el equivalente al término nombre de host. El nombre "John" no se puede considerar como un identificador único.

En caso de que necesitemos enviar un paquete a John, necesitaremos usar una dirección que será un identificador único y nos permitirá estar seguros de que el paquete se envió al destinatario de destino requerido.

En este caso, utilizaremos la dirección "completa" o "completa" de John que incluye su apellido, dirección postal, ciudad, etc.

Podemos decir que la "Dirección completa" de John es idéntica al escenario en el que nos dirigimos a un host en particular utilizando su FQDN en el entorno de red.

Técnicamente, en una red interna, podemos dirigirnos a un "host" específico usando solo el nombre de host pero, la mayoría de las veces, el método preferido para dirigirnos a "servidores" o hosts que brindan servicios es usar el FQDN del host.

En un entorno de red pública, la única forma de dirigirse a los hosts es mediante su FQDN.

Nombre de dominio

Un nombre de dominio también es una convención de nomenclatura que se basa en una estructura específica.
Un nombre de dominio oficial se construye a partir del nombre de una organización y el sufijo del nombre de dominio.

Sufijo de dominio

Cada nombre de dominio tiene un sufijo (como cada viñeta tiene una dirección). El nombre de dominio podría clasificarse como privado o público.

Sufijo de nombre de dominio privado

Un sufijo de nombre de dominio privado basado en un sufijo no público (y sí, sé que la oración no es tan clara).
En otras palabras, un sufijo de nombre de dominio privado no se puede publicar en la red pública. En caso de que queramos utilizar un sufijo de nombre de dominio privado, técnicamente podemos inventar cualquier nombre que queramos.

Por ejemplo, una opción disponible para un sufijo de nombre de dominio privado podría ser blab la, y el nombre de dominio completo podría ser - o365info.blabla

Sufijo de nombres de dominio público.

Sufijo de nombre de dominio público basado en un sufijo público.
En el caso de que queramos utilizar un sufijo de nombre de dominio público, necesitaremos comprar el nombre de dominio de un proveedor público y hay una cantidad limitada de nombre de dominio público. sufijo entre el que podemos elegir.

Los hosts con el sufijo de nombre de dominio público pueden publicar y ser accesibles por hosts en una red externa (y también por hosts de la red interna\privada).

En el siguiente diagrama, podemos ver un ejemplo de un nombre de dominio con un sufijo de nombre de dominio privado: o365info.lcoal

Y un ejemplo adicional de un nombre de dominio público como: o365info.com

Nombre de dominio de Active Directory

Cada Active Directory debe tener un nombre de dominio.

El nombre de dominio de Active Directory defendido por la persona que instala el primer servidor DC. Los administradores de Active Directory pueden decidir qué tipo de dominio elegir como sufijo de nombre de dominio de Active Directory.

En caso de que el administrador prefiera utilizar un nombre de dominio privado para Active Directory, el sufijo del nombre de dominio común es - local

El sufijo “local” del nombre de dominio no se publica en la red pública.

En el siguiente diagrama podemos ver un ejemplo de las opciones que están disponibles para el Administrador de Active Directory.

El administrador de Active Directory puede optar por utilizar un “espacio de nombres interno” para Active Directory, como - o365info.lcoal o un “espacio de nombres externo”, como - o365info.com .
El sufijo “com ” es un sufijo de nombre de dominio público.

Nombre de dominio de Active Directory e infraestructura de Exchange

La infraestructura de Exchange está "integrada" o "entretejida" en la infraestructura de Active Directory.

La infraestructura de intercambio no puede “vivir” fuera de Active Directory o, en otras palabras; Active Directory sirve como plataforma para la infraestructura de Exchange, y la infraestructura de Exchange está "ligada" al límite del bosque de Active Directory.

FQDN predeterminado de cada servidor Exchange

El FQDN predeterminado de cada servidor Exchange creado a partir del nombre de host de Exchange + el nombre de dominio de Active Directory local.

En caso de que utilicemos un sufijo de nombre de dominio privado para el dominio de Active Directory, Exchange "heredará" el nombre de dominio de Active Directory y el resultado es que todos los FQDN de los servidores de Exchange tendrán el sufijo de nombre de dominio privado de Active Directory.

En teoría, no hay ningún "daño" en este escenario, pero el problema se produjo debido a la diferente naturaleza de la infraestructura de Active Directory frente a la infraestructura de Exchange.

Cuando nos relacionamos con la infraestructura de Active Directory, la suposición subyacente es que nunca querremos/necesitaremos exponer la infraestructura de Active Directory a la red pública ni permitir que el host externo acceda al Active Directory interno.

Cuando se relaciona con la infraestructura de Exchange, el concepto de "ocultar" el host interno o impedir que los hosts externos accedan a hosts privados no se puede implementar. La mayoría de las veces, necesitaremos “exponer” parte del servidor Exchange (servidor Exchange público) para que los hosts externos, como el cliente Exchange externo, puedan comunicarse con el servidor Exchange.

Para poder cumplir con el requisito de “publicar recursos de Exchange”, necesitaremos utilizar el nombre de dominio público para publicar el host requerido.

Por ejemplo, los clientes externos de Exchange se dirigirán al servidor público Exchange CAS mediante un FQDN como: mail.o365info.com

Las dos identidades del servidor CAS de Exchange orientado al público

En caso de que el servidor Exchange CAS sea un "servidor Exchange público" y Active Directory esté basado en un nombre de dominio privado, el resultado es:
El servidor Exchange CAS tendrá dos "identidades" diferentes.

1. Interno: identidad de “Directorio Activo”
2. Identidad pública

El término "identidad" describe el FQDN que utilizará el servidor CAS de Exchange.

• Cuando un cliente de Exchange necesita dirigirse a un servidor CAS de Exchange, el cliente de Exchange dirigirá la identidad pública o privada (FQDN) del servidor CAS de Exchange.
• Cuando los clientes de Exchange necesitan usar un servicio web de Exchange en particular, el cliente de Exchange usará una dirección URL que incluye la identidad pública o privada (FQDN) del servidor de Exchange que proporciona el servicio web de Exchange específico.

Intercambiar servicio web y dirección URL

Servidor Exchange, proporciona una variedad de servicios web a sus clientes Exchange.

La forma en que el servidor CAS de Exchange "expone" un servicio web de Exchange en particular es mediante el uso de una dirección URL. En otras palabras, los clientes de Exchange acceden al servicio web de Exchange mediante una dirección URL.

En esta sección, me gustaría centrarme en una parte muy específica de la dirección URL que utilizamos para los servicios web de Exchange: el FQDN.

En la sección anterior, analizamos un escenario en el que Active Directory se basa en un nombre de dominio privado, y también analizamos la necesidad de utilizar un nombre de dominio adicional: un nombre de dominio público, que utiliza el servidor Exchange público que necesita comunicarse. con clientes externos de Exchange.

En este escenario, necesitaremos implementar un escenario que describo como "dos identidades diferentes" que se asignarán al servidor público de Exchange. La identidad externa y la identidad interna.

Ejemplo 1: cliente Outlook que busca un servidor CAS de Exchange

Cuando el cliente Outlook intenta localizar el servidor Exchange CAS disponible, se implementará el siguiente proceso.

• Un cliente Outlook interno (cliente Outlook ubicado en la red interna de la empresa) se dirigirá al servidor CAS de Exchange utilizando su "FQDN privado".
• Un cliente Outlook externo (cliente Outlook ubicado en la red interna de la empresa) se dirigirá al servidor CAS de Exchange utilizando su "FQDN público".

Ejemplo 2: publicación de información sobre el servicio web Exchange

Cuando el servidor CAS de Exchange responde a una solicitud de detección automática, la respuesta de detección automática incluirá dos tipos de información sobre los servicios web de Exchange:

• Información para clientes internos de detección automática, que se basa en la dirección URL que incluye el FQDN privado del servidor de Exchange que proporciona el servicio web de Exchange en particular.
• Información para clientes externos de detección automática, que se basa en la dirección URL que incluye el FQDN público del servidor de Exchange que proporciona el servicio web de Exchange en particular.

Servicios web de Exchange y estructura de direcciones URL

Servidor Exchange, proporciona una variedad de servicios basados en web. Cada uno de los diferentes servicios web de Exchange está "representado" por una dirección URL dedicada.

A pesar de que utilizamos una URL dedicada de los diferentes servicios web de Exchange, la dirección URL que utilizamos se basa en una estructura básica que se utiliza en todas las direcciones URL de los servicios web de Exchange.

Una dirección URL de servicio web Exchange "estándar" incluirá cuatro partes:

1. Nombre del protocolo

La primera parte de la dirección URL es el nombre del protocolo.
Servicios web de Exchange implementados mediante el protocolo HTTP o HTTPS.
La mayoría de las veces, la comunicación entre el servidor Exchange y sus clientes se realizará utilizando el Protocolo HTTPS.

2. Nombre FQDN

El nombre FQDN es el "nombre de host completo" que incluye el nombre de host + el nombre de dominio.

En caso de que el servidor Exchange no esté expuesto a una red pública, el FQDN del servidor CAS de Exchange se crea a partir del "nombre de servidor correcto" (el nombre NetBIOS del servidor) + el nombre de dominio interno de Active Directory.

En caso de que el servidor Exchange CAS esté configurado como un "servidor Exchange público", el servidor Exchange CAS se "expuso" mediante el uso de un FQDN público y, además, puede tener y tendrá la mayoría de las veces un par de nombres FQDN.

La necesidad de más de un "FQDN público" depende de los servicios que proporciona el "servidor Exchange público".

3. Nombre de la carpeta

Para cada uno de los servicios web que proporciona Exchange, existe una "carpeta virtual dedicada".

Por ejemplo, el servicio de detección automática del servidor Exchange se implementa mediante una carpeta dedicada denominada Detección automática.

Cuando los clientes de Exchange necesiten obtener un servicio en particular, el cliente de Exchange necesitará conocer y utilizar la dirección URL que incluye un "nombre de carpeta" específico que representa los servicios específicos que necesita.

4. El nombre del archivo

La última parte de la dirección URL puede incluir un nombre de archivo. Por ejemplo, en el escenario de los servicios de detección automática, la dirección URL que utiliza el cliente de detección automática contiene el nombre del archivo particular que el cliente solicita al servidor.
El cliente de detección automática solicitará un archivo llamado - descubrimiento automático.xml

Ejemplo de dirección URL de detección automática interna o externa

Para poder demostrar el concepto de "identidad dual" del servidor CAS de Exchange, revisemos la dirección URL de detección automática que utilizan los clientes internos de Exchange frente a la dirección URL de detección automática que utilizan los clientes externos de Exchange.

Cartas de escenarios:

Una organización utiliza un nombre de dominio privado como nombre de dominio de Active Directory.
El nombre de dominio de Active Directory es - o365info.local

El nombre de dominio público organizador es - o365info.com

El nombre del servidor Exchange CAS es - exo1

En un escenario, el servidor CAS de Exchange atiende a clientes internos de Exchange y también ayuda a clientes públicos o externos de Exchange.

En el siguiente diagrama, podemos ver la estructura base de la dirección URL del servicio web Autodiscover.

Dirección URL de detección automática | clientes internos de Exchange

En nuestro ejemplo, el servidor Exchange CAS se registrará automáticamente en el SCP de Active Directory, utilizando el siguiente nombre de host: ex01.o365info.local

Si queremos ser más precisos, el servidor CAS de Exchange registra la dirección URL de detección automática en el SCP de Active Directory utilizando la siguiente URL:
https://ex01.o365info.local /autodiscover/autodiscover.xml

Cuando el cliente interno de Outlook inicia el proceso de detección automática, el cliente de Outlook obtendrá del Active Directory local la dirección URL del servicio de detección automática de Exchange y "extraerá" de la dirección URL el nombre de host del servidor CAS de Exchange: ex01.o365info.local y consulte el DNS interno para este nombre de host.
La “respuesta” de DNS incluirá la dirección IP interna\privada del servidor CAS de Exchange.

Dirección URL de detección automática | clientes externos de Exchange

En nuestro ejemplo, cuando un cliente de correo externo como Outlook necesita crear un nuevo perfil de correo de Outlook para John@o365info.com , Outlook “supone” que la dirección URL de detección automática es la siguiente: siga: https://autodiscover.o365info.com/autodiscover/autodiscover.xml

Para poder conectar el servidor Exchange público, Outlook "extraerá" el nombre FQDN del servidor Exchange de la dirección de detección automática pública.

En nuestro escenario: autodiscover.o365info.com

El cliente Outlook se dirigirá al servidor DNS público y enviará una consulta buscando información sobre la dirección IP pública de este host.

Intercambio de doble identidad | ¿Usando FQDN idéntico o diferente?

Una de las decisiones más básicas e importantes que tenemos como administrador de Exchange es la decisión sobre la infraestructura del espacio de nombres de Exchange.

Nuestra suposición subyacente es que parte de la infraestructura de Exchange se configurará como pública y, por esta razón, Exchange necesitará atender a clientes de Exchange internos y externos.

En otras palabras, el servidor Exchange público tendrá dos interfaces diferentes.

Opción 1: usar un espacio de nombres separado

En este caso, cada uno de los servidores Exchange de cara al público utilizará un espacio de nombres diferente para cada una de sus "identidades".

Para demostrar este concepto, usemos el siguiente escenario:

• El nombre de dominio interno de Active Directory es - o365info.local
• El nombre de dominio público de la organización es: o365info.com

Por ejemplo

• La "identidad interna" del servidor Exchange estará representada por el nombre del host: ex01.o365info.local
• La "identidad externa" del servidor Exchange estará representada por el nombre de host: mail.o365info.com y autodiscover.o365info.com

Un cliente interno de Exchange que necesitará dirigirse al servidor Exchange y buscar la infraestructura de detección automática se dirigirá al servidor Exchange utilizando el nombre de host: ex01.o365info.local

Un cliente de Exchange externo que necesitará conectarse al servidor de Exchange y buscar la infraestructura de detección automática se dirigirá al servidor de Exchange utilizando el nombre de host: autodiscover.o365info.com

Opción 2: usar un espacio de nombres unificado

En este caso, utilizaremos el espacio de nombres idéntico para cada una de las "identidades" del servidor Exchange.

Para demostrar este concepto, usemos el siguiente escenario:

• El nombre de dominio interno de Active Directory es - o365info.local
• El nombre de dominio público de la organización es: o365info.com

La principal diferencia es que en este escenario no usaremos el nombre de dominio local de Active Directory como parte del nombre de host de Exchange.

En el escenario que describo como un espacio de nombres unificado, el servidor Exchange se "publicará" para el cliente Exchange interno + externo utilizando el espacio de nombres de dominio público.

• La "identidad interna" del servidor Exchange estará representada por los nombres de host: mail.o365info.com y autodiscover.o365info.com
• La "identidad externa" del servidor Exchange estará representada por los nombres de host: mail.o365info.com y autodiscover.o365info.com

Un cliente Exchange interno que necesitará dirigirse al servidor Exchange y buscar la infraestructura de detección automática se dirigirá al servidor Exchange utilizando el nombre de host: autodiscover.o365info.com

Un cliente de Exchange externo que necesitará conectarse al servidor de Exchange y buscar la infraestructura de detección automática se dirigirá al servidor de Exchange utilizando el nombre de host: autodiscover.o365info.com

En el pasado, la “tendencia” era enfatizar la diferencia que existe entre los “entornos Exchange internos” versus el “entorno Exchange externo”. "

La razón de esta tendencia se basa en el supuesto de que el uso de un espacio de nombres separado es más seguro porque la "separación" protege la infraestructura interna de Exchange del acceso no deseado por parte de hosts externos.

Mi opinión es que la "separación lógica" en realidad no protege la infraestructura interna de Exchange porque, en realidad, la protección y la separación se implementarán mediante soluciones diferentes.

El uso del concepto de espacio de nombres separado complicará la vida del administrador de Exchange y confundirá a los usuarios.