Desmitificación del objeto de matriz CAS: parte 1

Artículo original publicado el sábado 24 de marzo de 2012

Desde su lanzamiento en 2009, el interés mostrado por Exchange 2010 ha sido increíble. Al trabajar codo con codo con los clientes en el aprendizaje y la formación para migrar a Exchange 2010, nos dimos cuenta de que existían algunos conceptos erróneos comunes. Uno de estos conceptos erróneos está relacionado con el objeto de matriz Client Access Server, también denominado objeto de matriz CAS. Scott Schnoll, redactor técnico y bloguero asiduo me sugirió la idea de plasmar en papel... quiero decir... plasmar con el teclado esta tendencia errónea durante una sesión interna de grupo de distribución de Microsoft, así que me he decidido a publicar esta entrada.

No voy a abordar todos los aspectos técnicos del objeto de matriz CAS en esta entrada. De eso ya se ha encargado bien Nagesh Magadev en una entrada anterior: Exploración del servicio de acceso de cliente de RPC de Exchange 2010

La lista siguiente muestra un conjunto de conceptos que a menudo los clientes no tienen en cuenta a la hora de abordar el objeto de matriz CAS y que trataremos de desmitificar. En la parte 1 se abordarán los tres primeros elementos, mientras que los tres restantes se tratarán en la parte 2.

1. El objeto de matriz CAS no equilibra la carga del tráfico.
2. El objeto de matriz CAS no presta servicios de Detección automática, OWA, ECP, EWS, IMAP, POP o SMTP.
3. No es necesario que el FQDN del objeto de matriz CAS forme parte de su certificado SSL.
4. Los clientes externos no deben poder resolver los objetos de matriz CAS a través del DNS.
5. El objeto de matriz CAS no debe configurarse ni modificarse tras crear las bases de datos de los buzones de Exchange 2010 y mover los buzones a las bases de datos.
6. Es necesario configurar el objeto de matriz CAS incluso si solo dispone de un CAS o de un único servidor de múltiples roles.

¿Parece un poco confuso, verdad? Vamos a intentar explicarlo todo de la mejor forma posible yendo punto por punto. En este artículo podrán comprobar que se usan algunos nombres de servidor, por lo que antes les mostraré en qué estoy trabajando en mi laboratorio.

Ahora vayamos con los detalles.

1. El objeto de matriz CAS no equilibra la carga del tráfico.

El objeto de matriz CAS no realiza ninguna tarea de equilibrado de cargas de trabajo. Se trata de un objeto de Active Directory que se usa para automatizar determinadas funciones de Exchange. La documentación de Exchange 2010 recomienda el uso de equilibradores de carga (LB) para equilibrar la carga del tráfico de CAS; por lo que es necesario explicar realmente por qué el objeto de matriz no realiza ninguna tarea de equilibrado de cargas de trabajo.

En realidad, cuando se usa un equilibrador de cargas, estamos equilibrado el tráfico de un grupo de CAS o, mejor dicho, una matriz de CAS, pero no del objeto de matriz CAS propiamente dicho. La diferencia es sutil, pero muy clara. Quizás los nombres no sean lo suficientemente claros como para evitar la confusión en torno a esta cuestión.

La razón principal, y probablemente la única, es que el objeto de matriz CAS existe para llenar automáticamente el atributo RpcClientAccessServer de las nuevas bases de datos de buzones de Exchange 2010 creadas en el mismo sitio de Active Directory (que el objeto de matriz CAS).

El atributo RpcClientAccessServer se usa para indicar a los clientes Outlook cuál es el nombre de servidor del perfil durante el proceso de creación del perfil. No hay más. La cuestión es bastante simple: una vez que se crea el objeto de matriz CAS, este se convierte en un simple objeto de Active Directory y no se realiza ninguna tarea de equilibrado de cargas en este punto.

Todo lo demás ya son cuestiones adicionales. Cada uno decide si desea:

• Crear un registro ‘A’ en DNS que permita a la máquina cliente resolver el nombre de host en una dirección IP. Esta dirección IP probablemente sea la IP virtual (VIP) del LB accesible solo para los clientes internos. Esta VIP es donde Outlook o cualquier otra aplicación MAPI/RPC se conectará para obtener acceso a los recursos del buzón de Exchange 2010.
• Configurar la solución de equilibrado para que pase el tráfico al grupo de servidores CAS mediante la VIP.

Los CAS en realidad no son conscientes de que se estén realizando tareas de equilibrado de cargas.

La información que se muestra tras crear un objeto de matriz CAS mediante el cmdlet New-ClientAccessArray cmdlet o al visualizar un objeto de matriz CAS preexistente mediante el cmdlet Get-ClientAccessArray también puede inducir a error.

En el ejemplo siguiente voy a crear en mi laboratorio un nuevo objeto de matriz CAS con el nombre CASArray-A, el FQDN outlook.lab.local y con el sitio Active Directory denominado Site-A.

Figura 1: Creación de una matriz de acceso cliente

En primer lugar, puede verse que los valores de los campos FQDN y Nombre no coinciden porque el Nombre es un nombre para mostrar, es decir, se trata de un nombre puramente superficial. Puede ser cualquier nombre que indique para qué se va a usar el objeto de matriz CAS. El FQDN es el registro que debe crearse en el DNS, ya que, de lo contrario, los demás clientes no podrán resolverlo en una dirección IP para establecer la conexión, Es necesario recordar que solo puede haber un objeto de matriz CAS por sitio de Active Directory.

Pero... ¿por qué se llena la propiedad Members con dos CAS inmediatamente después de la creación? ¿No se supone que no había equilibrio de cargas de trabajo en este punto? Parece que lo que acabo de explicar no es del todo cierto, ¿verdad?

Para ser sinceros, la propiedad Members se presta a la confusión. Si no se repasan bien los pasos necesarios para crear un objeto de matriz CAS, seguro que pensamos que ya hemos terminado: hemos creado un objeto de matriz CAS y dos CAS se han unido a la matriz automáticamente. A estas horas, seguro que han ido a tomar algo o a robarle algunas galletas a este tipo. Pues me temo que todavía no podemos irnos...

Debido al hecho de que hemos asociado el objeto de matriz CAS al sitio de Active Directory denominado Site-A, el cmdlet simplemente buscará todos los servidores de acceso de cliente registrados como residentes en el Site-A y los mostrará en la columna Members. Me gusta pedir a los clientes que piensen en esta columna como en una columna de miembros potenciales o como dice mi compañero Kamal Abburi, otro PFE aquí en Microsoft, como en la columna Members de CAS del sitio. Estos servidores de acceso de cliente pueden agregarse como nodos de la solución de equilibrio de cargas porque todos residen en el mismo sitio de Active Directory. Sin embargo, no se realizará ningún tipo de equilibrado de carga hasta que el equilibrador no esté configurado.

¿Cómo han podido saber los cmdlets en qué sitio se encuentra el CAS? Me alegro de que os planteéis esta pregunta, porque esto nos llevará a hablar de nuestro gran amigo AdsiEdit.msc y a analizar la partición Configuration de Active Directory para averiguar dónde está el truco.

Figura 2: El atributo msExchServerSite del servidor de Exchange 2010 contiene el sitio de Active Directory en el que reside el servidor.

Todos los servidores Exchange tienen un atributo msExchServerSite que contiene información sobre el sitio de Active Directory en el que residen. Por si alguno de vosotros se lo está preguntando, diré que sí, este atributo se actualiza de forma dinámica al mover el servidor Exchange al nuevo sitio. Asimismo, el servicio de topología de directorio de Active Directory de Microsoft Exchange puede iniciar y actualizar varios parámetros. No obstante, el atributo AutoDiscoverSiteScope (parte de Get/Set-ClientAccessServer) no se actualiza de forma dinámica, lo que puede dar lugar a resultados extraños de autodetección hasta que no se solucione este problema, dependiendo del diseño de su sitio, servidor y cliente.

2. El objeto de matriz CAS no presta servicios OWA, ECP, EWS, de Detección automática, IMAP, SMTP o POP

Volvamos un momento a ver cuál es el cometido real de un objeto de matriz CAS. Este objeto llena el atributo RpcClientAccessServer de la base de datos del buzón de Exchange 2010, que, a continuación, se usa para indicar Outlook dónde debe conectarse cuando usa RPC (mediante TCP). Para los clientes de Outlook Anywhere (HTTPS), indica dónde debe conectarse el tráfico saliente del proxy RPC a través de HTTP en nombre del cliente para tener acceso a sus buzones de correo.

¿A qué servicios trata de conectarse el cliente de Outlook cuando usa RPC (a través de TCP)?

En primer lugar, Outlook se conecta al objeto de matriz CAS en TCP/135 para comunicarse con el Asignador de extremos RPC y detectar los puertos TCP a los que escuchan los dos servicios siguientes:

1. Acceso de cliente RPC de Microsoft Exchange (MSExchangeRPC)
2. Libreta de direcciones de Microsoft Exchange (MSExchangeAB)

Esto es todo en cuanto a l modo RPC (mediante TCP).

Los clientes de Outlook Anywhere (RPC mediante HTTP) se conectan al componente proxy RPC a través de HTTP en TCP/443 en CAS mediante la resolución del nombre de host externo de Outlook Anywhere, o lo que el perfil de Outlook denomina como servidor proxy.

Como nota interesante para a quien pueda interesar, diré que Outlook agrega automáticamente la cadena /rpc/rpcproxy.dll al nombre de servidor especificado, que es lo que necesita para establecer la conexión. Si los usuarios tuviesen que escribir estos nombres como en tiempos de Outlook 2003, ¿os hacéis una idea de cuántos no lo escribirían o lo harían de forma incorrecta?

Figura 3: Especificación de la URL del proxy RPC en Outlook 2003

El tráfico se envía del proxy RPC a través de HTTP al extremo MAPI/RPC correspondiente a través de una lista de puertos TCP codificados, en lugar de asignados dinámicamente. Entre los puertos se incluyen TCP 6001, TCP 6002 y TCP 6004. Por ello, el nombre de host externo de Outlook Anywhere no es el mismo FQDN que el del objeto de matriz CAS. Más adelante os explicaré por qué.

El cliente también puede establecer conexiones HTTPS a servicios como, por ejemplo, de Detección automática, descargas OAB, EWS, POP o IMAP, aunque estos servicios están definidos por métodos totalmente distintos como las URL de directorio virtual o mediante el valor AutoDiscoverServiceInternalUri. El objeto de matriz CAS no presta ninguno de estos servicios adicionales, puesto que ninguno de ellos usa RPC, aunque probablemente se conecten al mismo servidor. El FQDN del objeto de matriz CAS puede compartir la misma VIP que el resto de URL de servicio, aunque se recomienda que el FQDN del no sea el mismo que el de las URL de los otros servicios si se está usando un DNS dividido. Más adelante ofreceremos información sobre esta última recomendación.

3. No es necesario que el FQDN del objeto de matriz CAS forme parte de la lista de nombres del certificado SSL

Este es un concepto erróneo muy común debido al elemento descrito anteriormente. Los certificados SSL descritos en este artículo solo se usan para establecer una sesión HTTP protegida mediante SSL. Puesto que RPC (mediante TCP) no es una sesión HTTP, no estará bajo la protección de SSL, por lo que no es necesario incluir el FQDN del objeto de matriz CAS en la lista de nombres de asuntos del certificado SSL. Veamos esta cuestión más de cerca.

A continuación se muestra a Outlook 2010 en modo MAPI/RPC con conexión a un objeto de matriz CAS de Exchange 2010.

Figura 4: Conexiones de Outlook 2010 RPC (mediante TCP) al CAS de Exchange 2010

Aquí podemos ver que se ha creado un directorio y dos conexiones de correo. En los resultados de netstat (que aparecen antes de la captura de pantalla) podemos ver que la máquina ha creado una conexión de asignador de extremos (TCP 135) al objeto de matriz CAS, además de conexiones a TCP 59531 y TCP 59532, que representan los puertos TCP asignados estadísticamente a los servicios MSExchangRPC y MSExchangeAB respectivamente en este laboratorio.

En el servidor, es posible ver los servicios que están escuchando con el comando netstat –n –b.

Figura 5: Los servicios de Outlook necesitan establecer la conexión con RPC (mediante TCP).

Tal como se esperaba, indica que no se ha establecido contacto con ninguno de los servicios a través de HTTP (TCP 443). Por esta razón es por la que no es necesario que el FQDN del objeto de matriz CAS figure en el certificado SSL.

Como puede verse a continuación, la manera en que Outlook muestra las conexiones cuando está en modo HTTPS puede llevar a creer que es necesario que el FQDN de la matriz CAS figure en el certificado SSL.

Figura 6: Conexiones de Outlook Anywhere.

Aquí podemos ver que Outlook 2010 había establecido dos conexiones de correo y una conexión de Carpeta pública cuando se tomó esta captura de pantalla. Asimismo, también podemos constatar que estamos usando HTTPS. Desde Outlook, parece que estamos conectados a outlook.lab.local y E2K10-MLT-01.lab.local, aunque al volver a usar netstat podemos comprobar que en realidad estamos conectados al proxy HTTP mediante RPC que se encuentra en webmail.lab.local en TCP/443 (HTTPS). Outlook mostrará siempre a qué servidor se ha conectado para los datos en sí mismos o mediante el proxy HTTP mediante RPC. Si os estáis preguntando por qué aparecen 6 conexiones en netstat en lugar de tres, es porque HTTP es un protocolo dúplex medio, por lo que es necesario establecer un canal RPC_DATA_IN y RPC_DATA_OUT para cada conexión de Outlook.

Seguro que también os estáis planteando que, de forma predeterminada, Outlook 2007 y 2010 cifran las sesiones RPC y que, por lo tanto, necesitamos que el nombre figure en el certificado. Pues bien queridos amigos, la respuesta es que no, ya que la configuración de cifrado que se muestra a continuación usa el cifrado RPC, que nada tiene que ver con SSL. Recuerden que la comunicación se produce a través de RPC y no mediante HTTPS.

Figura 7: En la conexión a través de RPC (mediante TCP), Outlook usa el cifrado RPC.

Simple, ¿verdad? Imagínense que un objeto de matriz CAS se topase con una entidad de certificación y esta le dijera: “¡Oye, tú me necesitas! Vamos, puedo venderte un certificado comodín a muy buen precio.” El objeto de matriz CAS respondería “¡Tranquilidad, puedo arreglármelas sin problemas!” y seguro que utilizaría el CA como cascanueces. Todo ello, si se han seguido las recomendaciones de usar un FQDN para el objeto de matriz CAS distinto de los FQDN de los otros servicios. Pronto les explicaré por qué...

Espero que la parte 1 de este artículo haya resultado útil para esclarecer los malos entendidos más comunes relacionados con los objetos de matriz CAS. También espero volver a veros en la parte 2, ya que abordaremos los tres conceptos erróneos restantes que giran en torno a los objetos de matriz CAS.

Brian Day
Ingeniero de campo principal, Mensajería

Esta es una entrada de blog localizada. Puede consultar el artículo original en Demystifying the CAS Array Object - Part 1