Koordinieren von URLs mithilfe von AAM und DNS

  • Article

Veröffentlichung des Originalartikels: 25.05.2011

Mark Arend, Senior Consultant, stellte einige interessante Fragen im Zusammenhang mit der Koordination von URLs mithilfe von alternativen Zugriffszuordnungen (Alternate Access Mapping, AAM) und DNS:

  • Wie werden alternative Zugriffszuordnungen für URLs mit einem einzelnen Namen wie z. B. https://fabrikam konfiguriert?
  • Wie wird der Zugriff mit Lastenausgleich auf Webanwendungen koordiniert, die sich über mehrere Zonen erstrecken, wie z. B. https://partnerweb und https://remotepartnerweb.fabrikam.com?

Die Konfiguration von alternativen Zugriffszuordnungen kann knifflig sein. Nach einiger Recherche und Beratung mit unseren schlauen Testern, Troy Starr sowie in Zusammenarbeit mit Mark Arend habe ich das folgende Diagramm erstellt, in dem die notwendigen Informationen zum Erstellen oder Ändern von alternativen Zugriffszuordnungen auf der Grundlage der klassischen Authentifizierung des Entwurfsbeispiels der logischen Architektur aufgeführt sind.

Wie deutlich wird, können URLs mit einem einzelnen Namen (beispielsweise https://teams) für den Intranetzugriff konfiguriert werden.  Diese URLs werden vom Client durch Anfügen des DNS-Suffix des Clients aufgelöst (z. B. fabrikam.com), und ein DNS-Lookup wird nach dem Namen mit dem Suffix durchgeführt.  Wenn ein Clientcomputer in der Domäne fabrikam.com beispielsweise https://teams anfordert, wird vom Computer eine Anforderung für https://teams.fabrikam.com an DNS gesendet. 

Zusätzlich zur Konfiguration von alternativen Zugriffszuordnungen sind auch einige Schritte im Zusammenhang mit DNS erforderlich. Für jeden vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) muss DNS mit einem A-Datensatz konfiguriert werden. Der A-Datensatz zeigt auf die IP-Adresse mit Lastenausgleich für die Webserver, auf denen eine Website gehostet wird. Bei einer herkömmlichen Produktionsbereitstellung werden Server mit statisch zugewiesenen IP-Adressen sowie statisch zugewiesenen A-Datensätzen in DNS konfiguriert. 

Nach dem Empfangen der virtuellen IP-Adresse des Lastenausgleichsmoduls nimmt der Clientbrowser die Kommunikation mit einem Front-End-Webserver in der Farm auf und sendet dann eine HTTP-Anforderung mit der Original-URL mit einem einzelnen Namen https://teams).  IIS und SharePoint erkennen dies anhand der in alternativen Zugriffszuordnungen konfigurierten Einstellungen als eine Anforderung für die Intranetzone.  Wenn der Benutzer anstelle dessen https://teams.fabrikam.com anfordert, ist der Vorgang derselbe, außer dass IIS und SharePoint in diesem Fall den vollqualifizierten Domänennamen erhalten und diese Anforderung deshalb als Anforderung für die Standardzone erkannt wird.

In Umgebungen mit mehreren Domänen geben Sie CNAME-Datensätze für DNS in den Domänen ein, in denen sich die Websites nicht befinden. Wenn beispielsweise in der Netzwerkumgebung von Fabrikam eine zweite Domäne mit der Bezeichnung europe.fabrikam.com enthalten ist, werden CNAME-Datensätze für diese Websites in der Domäne Europe eingegeben. Für die Intranetwebsite Team Sites (https://teams) wird der Domäne europe.fabrikam.com ein CNAME-Datensatz namens teams hinzugefügt, der auf teams.fabrikam.com zeigt. Wenn dann der DNS-Suffix eines Clients an DNS-Lookupanforderungen angefügt wird, wird bei einer Anforderung für https://teams aus der Domäne Europe ein DNS-Lookup von teams.europe.fabrikam.com ausgeführt und durch den CNAME-Datensatz an teams.fabrikam.com geleitet.

Nachdem ich verstanden hatte, wie URLs vom Browser aufgelöst werden, wurde mir klar, dass https://fabrikam keine optimale Wahl für eine illustrative URL darstellt (https://fabrikam.fabrikam.com?). Folglich habe ich die klassische Authentifizierung des Entwurfsbeispiels der logischen Architektur durch die URL https://intranet aktualisiert. Die aktualisierte Version steht Ihnen als Download zur Verfügung unter SharePoint Server 2010-Entwurfsbeispiele: Unternehmensportal mit klassischer oder anspruchsbasierter Authentifizierung (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x407).

Schließlich liegt bei einigen Kerberos-Clients und der Auflösung von CNAME-Datensätzen ein bekanntes Problem vor. Wenn in Ihrer Umgebung die Kerberos-Authentifizierung verwendet wird, lesen Sie den Artikel unter Bekannte Probleme bei der Kerberos-Konfiguration (SharePoint Server 2010).

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Den Originalartikel finden Sie unter Coordinating URLs with AAM and DNS