Coordinar direcciones URL con AAM y DNS

  • Article

Artículo original publicado el miércoles, 25 de mayo de 2011

Mark Arend, consultor senior, planteó varias buenas preguntas acerca de la coordinación de direcciones URL con las asignaciones alternativas de acceso y DNS:

  • ¿Cómo se configuran las asignaciones alternativas de acceso para las direcciones URL de nombre único, como por ejemplo https://fabrikam?
  • ¿Cómo se coordina el acceso de carga equilibrada a las aplicaciones web que se extienden con varias zonas, como https://partnerweb y https://remotepartnerweb.fabrikam.com?

La configuración de asignaciones alternativas de acceso puede ser complicada. Después de investigar un poco y consultarlo con nuestros astutos evaluadores, Troy Starr, además de trabajar con Mark, elaboré el siguiente gráfico que muestra la información necesaria para crear o modificar asignaciones alternativas de acceso, según la versión clásica de autenticación del ejemplo de diseño de arquitectura lógica.

Como puede ver, las direcciones URL con un nombre único (por ejemplo, https://teams) se pueden configurar para acceso de intranet. Estas direcciones URL se resuelven mediante el cliente anexando el sufijo DNS del cliente, como fabrikam.com, y emitiendo una búsqueda DNS del nombre con el sufijo. Por ejemplo, cuando un equipo cliente en el dominio fabrikam.com solicita https://teams, el equipo envía una solicitud a DNS para https://teams.fabrikam.com.

Además de configurar asignaciones alternativas de acceso, también es necesario un poco de trabajo de DNS. El DNS debe configurarse con un registro A para cada nombre de dominio completo (FQDN). El registro A señala a la dirección IP de carga equilibrada para que los servidores web hospeden un sitio. En una implementación de producción típica, los servidores se configuran con direcciones IP asignadas estáticamente, así como registros A asignados estáticamente en DNS. 

Tras recibir la dirección IP virtual del equilibrador de carga, el explorador del cliente establece comunicación con un servidor web front-end en la granja de servidores y, a continuación, envía una solicitud HTTP con la dirección URL original de nombre único, https://teams. IIS y SharePoint reconocen esto como una solicitud para la zona de intranet, según las opciones configuradas en las asignaciones alternativas de acceso. Si en su lugar el usuario hubiera solicitado https://teams.fabrikam.com, el proceso sería el mismo excepto que IIS y SharePoint recibirían este FQDN en su lugar y, por lo tanto, reconocerían esta solicitud para la zona predeterminada.

En entornos con varios dominios, escriba registros CNAME para DNS en los dominios en los que no residen los sitios. Por ejemplo, si el entorno de red de Fabrikam incluye un segundo dominio denominado europe.fabrikam.com, se especifican registros CNAME para estos sitios en el dominio Europe. Para el sitio de intranet de sitios de grupo (https://teams), se agrega un registro CNAME denominado teams al dominio europe.fabrikam.com que señala a teams.fabrikam.com. A continuación, cuando se anexa el sufijo DNS de un cliente a las solicitudes de búsqueda DNS, una solicitud de https://teams desde el dominio Europe emite una búsqueda DNS de teams.europe.fabrikam.com y se redirige a teams.fabrikam.com mediante el registro CNAME.

Tras aprender cómo resuelve el explorador las direcciones URL, me di cuenta de que https://fabrikam no es una gran opción para una dirección URL ilustrativa (https://fabrikam.fabrikam.com?). En consecuencia, actualicé la versión clásica de autenticación del ejemplo de diseño de arquitectura lógica con la dirección URL de https://intranet en su lugar. Puede descargar la versión actualizada en la página de ejemplos de diseño de SharePoint Server 2010: portal corporativo con autenticación clásica o con autenticación basada en notificaciones (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0xC0A).

Por último, hay un problema conocido con algunos clientes de Kerberos y la resolución de registros CNAME. Si su entorno incluye autenticación Kerberos, vea el tema sobre problemas conocidos de configuración de Kerberos (SharePoint Server 2010).

Esta entrada de blog es una traducción. Puede consultar el artículo original en Coordinating URLs with AAM and DNS