Coordination d’adresses URL avec AAM et DNS

  • Article

Article d’origine publié le mercredi 25 mai 2011

Mark Arend, consultant confirmé, a posé plusieurs bonnes questions sur la coordination d’adresses URL avec des mappages d’accès de substitution et DNS :

  • Comment procédez-vous pour configurer des mappages d’accès de substitution pour des adresses URL à nom unique, telles que https://fabrikam ?
  • Comment coordonnez-vous un accès à équilibre de charge à des applications Web qui sont étendues avec plusieurs zones, telles que https://partnerweb et https://remotepartnerweb.fabrikam.com ?

Configurer des mappages d’accès de substitution peut être complexe. Après avoir effectué des recherches et consulté notre astucieux testeur, Troy Starr, puis travaillé avec Mark, j’ai établi le tableau suivant répertoriant les informations nécessaires pour créer ou modifier des mappages d’accès de substitution basés sur la version d’authentification classique de l’exemple de conception d’architecture logique.

Comme vous pouvez le voir, les URL à nom unique (par exemple, https://teams) peuvent être configurées pour un accès intranet. Ces URL sont résolues par le client en ajoutant le suffixe DNS du client, tel que fabrikam.com, et en émettant une recherche DNS pour le nom avec le suffixe. Par exemple, lorsqu’un ordinateur client dans le domaine fabrikam.com demande https://teams, l’ordinateur envoie une demande à DNS pour https://teams.fabrikam.com. 

Outre la configuration de mappages d’accès de substitution, un travail DNS est également nécessaire. DNS doit être configuré avec un enregistrement A pour chaque nom de domaine complet (FQDN). L’enregistrement A pointe vers l’adresse IP avec équilibrage de la charge réseau pour les serveurs Web hébergeant un site. Dans un déploiement de production classique, les serveurs sont configurés avec des adresses IP statiques, ainsi que des enregistrements A affectés de façon statique dans DNS. 

Après réception de l’adresse IP virtuelle de l’équilibreur de charge, le navigateur client établit une communication avec un serveur Web frontal dans la batterie de serveurs, puis envoie une demande HTTP avec l’URL à nom unique d’origine, https://teams. IIS et SharePoint reconnaissent ceci comme une demande pour la zone intranet, en fonction des paramètres configurés dans les mappages d’accès de substitution. Si l’utilisateur demande plutôt https://teams.fabrikam.com, le processus serait le même sauf qu’IIS et SharePoint recevraient ce FQDN à la place, et reconnaîtraient donc cette demande pour la zone par défaut.

Dans des environnements à plusieurs domaines, entrez des enregistrements CNAME pour DNS dans les domaines où les sites ne résident pas. Par exemple, si l’environnement réseau de Fabrikam inclut un deuxième domaine nommé europe.fabrikam.com, les enregistrements CNAME sont entrés pour ces sites dans le domaine Europe. Pour les sites intranet Team Sites (https://teams), un enregistrement CNAME nommé teams est ajouté au domaine europe.fabrikam.com qui pointe vers teams.fabrikam.com. Ensuite, lorsqu’un suffixe DNS d’un client est ajouté à des demandes de recherche DNS, une demande pour https://teams à partir du domaine Europe émet la recherche DNS de teams.europe.fabrikam.com, et est dirigée par l’enregistrement CNAME vers teams.fabrikam.com.

Après avoir découvert comment les URL sont résolues par le navigateur, je me suis rendu compte que https://fabrikam ne représente pas le choix idéal pour une URL illustrative (https://fabrikam.fabrikam.com?). Par conséquent, j’ai mis à jour la version d’authentification classique de l’exemple de conception d’architecture logique avec l’URL https://intranet. Vous pouvez télécharger la version mise à jour dans la page    Exemples de conception SharePoint Server 2010 : portail d’entreprise avec authentification classique ou avec authentification basées sur les revendications (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x40C).

Enfin, il existe un problème connu pour certains clients Kerberos et la résolution d’enregistrements CNAME. Si votre environnement inclut une authentification Kerberos, consultez Problèmes connus de la configuration Kerberos (SharePoint Server 2010) (éventuellement en anglais).

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Coordinating URLs with AAM and DNS