Coordenando URLs com AAM e DNS

Artigo original publicado em 25 de maio de 2011, quarta-feira

Mark Arend, Consultor Sênior, levantou várias questões boas sobre a coordenação de URLs com mapeamentos de acesso alternativo e DNS:

• Como você configura mapeamentos de acesso alternativo para URLs com nome único, como https://fabrikam?
• Como você coordena o acesso com balanceamento de carga a aplicativos Web que são estendidos com várias zonas, como https://partnerweb e https://remotepartnerweb.fabrikam.com?

Pode ser complicado configurar mapeamentos de acesso alternativo. Após alguma pesquisa e consultoria com nossos testadores astutos, Troy Starr e também Mark, eu criei o seguinte gráfico que lista as informações necessárias para criar ou modificar mapeamentos de acesso alternativo baseado na versão clássica de autenticação da amostra lógica de design da arquitetura.

Como você pode ver, as URLs com nome único (por exemplo, https://teams) podem ser configuradas para acesso à Intranet. Estas URLs são resolvidas pelo cliente por meio do acréscimo do sufixo DNS do cliente, como fabrikam.com, e em seguida, emissão de uma pesquisa de DNS em busca do nome com o sufixo. Por exemplo, quando um computador cliente no domínio fabrikam.com solicita https://teams, o computador envia uma solicitação ao DNS para https://teams.fabrikam.com.

Além de configurar mapeamentos de acesso alternativo, alguns trabalhos de DNS também são necessários. O DNS deve ser configurado com um registro para cada FQDN (nome de domínio totalmente qualificado). O registro aponta para o endereço IP de balanceamento de carga dos servidores Web que hospedam um site. Em uma implantação típica de produção, os servidores são configurados com endereços IP atribuídos estaticamente, bem como registros atribuídos estaticamente no DNS. 

Depois de receber o endereço IP virtual do balanceador de carga, o navegador cliente estabelece comunicação com um servidor Web front-end no farm e, em seguida, envia uma solicitação HTTP com a URL original com nome único, https://teams. O IIS e o SharePoint reconhecem isso como uma solicitação para a zona da Intranet, com base nas definições configuradas em mapeamentos de acesso alternativo. Se, em vez disso, o usuário tivesse solicitado https://teams.fabrikam.com, o processo seria o mesmo, exceto que o IIS e o SharePoint receberiam esse FQDN e, portanto, reconheceriam esta solicitação para a zona Padrão.

Em ambientes com múltiplos domínios, insira os registros CNAME do DNS nos domínios em que os sites não residem. Por exemplo, se o ambiente de rede Fabrikam inclui um segundo domínio chamado europe.fabrikam.com, os registros CNAME são inseridos para estes sites no domínio Europe. Para o site de intranet de Sites de Equipe (https://teams), um registro CNAME chamado equipes é adicionado ao domínio europe.fabrikam.com que aponta para teams.fabrikam.com. Então, quando o sufixo DNS de um cliente é anexado a solicitações de pesquisa de DNS, uma solicitação de https://teams a partir do domínio Europe emitirá uma pesquisa de DNS de teams.europe.fabrikam.com, e será direcionada pelo registro CNAME para teams.fabrikam.com.

Depois de aprender sobre como as URLs são resolvidas pelo navegador, eu percebi que https://fabrikam não é uma boa escolha para uma URL ilustrativa (https://fabrikam.fabrikam.com?). Consequentemente, atualizei a versão clássica de autenticação da amostra lógica de design da arquitetura com a URL de https://intranet. Você pode baixar a versão atualizada na página sobre amostras de design do SharePoint Server 2010: portal corporativo com autenticação clássica ou com autenticação baseada em declarações (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x416).

Finalmente, há um problema conhecido relacionado a alguns clientes Kerberos e à resolução de registros CNAME. Se o seu ambiente inclui a autenticação Kerberos, consulte o artigo sobre problemas conhecidos de configuração Kerberos (SharePoint Server 2010).

Esta é uma postagem de blog traduzida. Consulte o artigo original em Coordinating URLs with AAM and DNS