Konfigurieren der Kerberos-Authentifizierung: Kernkonfiguration (SharePoint Server 2010)
Gilt für: SharePoint Server 2010
Letztes Änderungsdatum des Themas: 2017-01-18
Im ersten Szenario konfigurieren Sie zwei SharePoint Server 2010-Webanwendungen für die Verwendung des Kerberos-Protokolls zur Authentifizierung eingehender Clientanforderungen. Zu Demonstrationszwecken wird eine Anwendung zur Verwendung von Standardports (80/443) und die andere für die Verwendung eines nicht standardmäßigen Ports konfiguriert. Dieses Szenario bildet die Grundlage aller folgenden Szenarien, für die vorausgesetzt wird, dass die folgenden Aktivitäten ausgeführt wurden.
Wichtig
Ihre Webanwendungen müssen für die klassische Windows-Authentifizierung mithilfe der Kerberos-Authentifizierung konfiguriert werden, damit die Szenarien wie gewünscht funktionieren. In einigen Szenarien kann die anspruchs- bzw. forderungsbasierte Windows-Authentifizierung verwendet werden, die jedoch ggf. nicht die in den nachfolgenden Szenarien geschilderten Ergebnisse liefert.
Hinweis
Bei einer Installation unter Windows Server 2008 muss ggf. der folgende Hotfix für die Kerberos-Authentifizierung installiert werden:
Kerberos-Authentifizierung misslingt bei Verwenden des AES-Algorithmus auf einem Computer mit Windows Server 2008 oder Windows Vista mit dem Fehlercode 0X80090302 oder 0x8009030f (https://support.microsoft.com/kb/969083/de)
In diesem Szenario führen Sie die folgenden Schritte aus:
Konfigurieren zweier Webanwendungen mit Standardzonen, die das Kerberos-Protokoll für die Authentifizierung verwenden
Erstellen je einer Test-Websitesammlung in beiden Webanwendungen
Überprüfen der Internetinformationsdienste-Konfiguration der Webanwendung
Überprüfen, ob sich Clients bei der Webanwendung authentifizieren können, und Sicherstellen, dass das Kerberos-Protokoll für die Authentifizierung verwendet wird
Konfigurieren des Webparts RSS-Anzeige zum Anzeigen von RSS-Feeds in einer lokalen und einer Remotewebanwendung
Durchforsten beider Webanwendungen und Testen der Suche nach Inhalten in jeder Test-Websitesammlung
Checkliste für die Konfiguration
| Konfigurationsbereich | Beschreibung |
|---|---|
DNS |
Registrieren eines DNS-Eintrags vom Typ "A" für die virtuelle IP des Netzwerklastenausgleichs der Webanwendungen |
Active Directory |
Erstellen eines Dienstkontos für den Internetinformationsdienste-Anwendungspool (IIS) der Webanwendungen Registrieren von Dienstprinzipalnamen für die Webanwendungen für das Dienstkonto, das für den IIS-Anwendungspool der Webanwendungen erstellt wurde Konfigurieren der eingeschränkten Kerberos-Delegierung für Dienstkonten |
SharePoint-Webanwendung |
Erstellen verwalteter SharePoint Server-Konten Erstellen der SharePoint-Suchdienstanwendung Erstellen der SharePoint-Webanwendungen |
Internetinformationsdienste (IIS) |
Sicherstellen, dass die Kerberos-Authentifizierung aktiviert ist Sicherstellen, dass die Kernelmodusauthentifizierung deaktiviert ist Installieren von Zertifikaten für SSL |
Windows 7-Client |
Sicherstellen, dass sich Webanwendungs-URLs in der Zone Intranet bzw. einer Zone befinden, die für die automatische Authentifizierung mithilfe der integrierten Windows-Authentifizierung konfiguriert ist |
Firewallkonfiguration |
Öffnen von Firewallports zum Zulassen von eingehendem HTTP-Datenverkehr an Standard- und Nicht-Standardports Sicherstellen, dass sich Clients mit Kerberos-Ports in Active Directory verbinden können |
Testen der Browserauthentifizierung |
Überprüfen, ob die Authentifizierung im Browser ordnungsgemäß funktioniert Überprüfen von Anmeldeinformationen im Sicherheitsereignisprotokoll des Webservers Prüfen, ob die Kerberos-Authentifizierung ordnungsgemäß konfiguriert ist, mithilfe von Tools anderer Anbieter |
Testen von SharePoint Server-Suchindex und -abfrage |
Überprüfen des Browserzugriffs auf den Indexservern Hochladen von Beispielinhalten und Durchführen einer Durchforstung Testen der Suche |
Testen der Web-Front-End-Delegierung |
Konfigurieren von RSS-Feedquellen für jede Websitesammlung Hinzufügen von Webparts vom Typ RSS-Anzeige zur Homepage jeder Websitesammlung |
Schrittweise Konfigurationsanweisungen
Konfigurieren von DNS
Konfigurieren Sie DNS für die Webanwendungen in Ihrer Umgebung. In diesem Beispiel gibt es die beiden Webanwendungen (http://portal und http://teams:5555), die beide in dieselbe virtuelle IP-Adresse für den Netzwerklastenausgleich (192.168.24.140/24) aufgelöst werden.
Allgemeine Informationen zur DNS-Konfiguration finden Sie unter Verwalten von DNS-Einträgen.
SharePoint Server-Webanwendungen
http://portal: Konfigurieren Sie einen neuen DNS-Eintrag vom Typ "A" für die Webanwendung portal. In diesem Beispiel ist der Host portal für die Auflösung in die virtuelle IP-Adresse für den Lastenausgleich konfiguriert.
.jpg "Bild eines DNS-Eintrags")
http://teams:5555: Konfigurieren Sie einen neuen DNS-Eintrag vom Typ "A" für die Webanwendung teams.
.jpg "Bild eines DNS-Eintrags")
Hinweis
Sie müssen sicherstellen, dass die DNS-Einträge vom Typ "A" und keine CNAME-Aliase sind, damit die Kerberos-Authentifizierung in Umgebungen mit mehreren Webanwendungen erfolgreich funktioniert, die mit Hostheadern und gesonderten dedizierten Dienstkonten ausgeführt werden. Unter Bekannte Kerberos-Konfigurationsprobleme (SharePoint Server 2010) finden Sie eine Erklärung zum bekannten Problem bei der Verwendung von CNAME bei für Kerberos aktivierten Webanwendungen.
Konfigurieren von Active Directory
Als Nächstes konfigurieren Sie Active Directory-Konten für die Webanwendungen in Ihrer Umgebung. Es hat sich bewährt, jede Webanwendung für die Ausführung in ihrem eigenen IIS-Anwendungspool mit eigenem Sicherheitskontext (Anwendungspoolidentität) zu konfigurieren.
Dienstkonten der SharePoint-Webanwendungen
In unserem Beispiel gibt es zwei SharePoint Server-Webanwendungen, die in zwei gesonderten IIS-Anwendungspools mit eigenen ausgeführten Anwendungspoolidentitäten ausgeführt werden.
| Webanwendung (Standardzone) | IIS-Anwendungspoolidentität |
|---|---|
vmlab\svcPortal10App |
|
vmlab\ svcTeams10App |
Dienstprinzipalnamen
Konfigurieren Sie für jedes Dienstkonto eine Gruppe von Dienstprinzipalnamen, die den jeder Webanwendung zugewiesenen DNS-Hostnamen zugeordnet werden.
Mit SetSPN, einem Befehlszeilenprogamm von Windows Server 2008, können Sie einen neuen Dienstprinzipalnamen konfigurieren. Eine ausführliche Beschreibung von SetSPN finden Sie unter Setspn. Informationen zu Verbesserungen an SetSPN in Windows Server 2008 finden Sie in dem MSDN-Blogbeitrag Care, Share and Grow! : New features in SETSPN.EXE on Windows Server 2008.
Alle SharePoint Server-Webanwendungen befolgen ungeachtet der Portnummer das folgende Format für Dienstprinzipalnamen:
HTTP/<DNS-Hostname>
HTTP/<DNS-FQDN>
Beispiel:
HTTP/portal
HTTP/portal.vmlab.local
Registrieren Sie für Webanwendungen, die an Nicht-Standardports (anderen Ports als 80/443) ausgeführt werden, zusätzliche Dienstprinzipalnamen samt Portnummer:
HTTP/<DNS-Hostname>:<Port>
HTTP/<DNS-FQDN>:<Port>
Beispiel:
HTTP/teams:5555
HTTP/teams.vmlab.local:5555
Hinweis
Im Anhang finden Sie eine Erläuterung, warum empfohlen wird, Dienstprinzipalnamen mit und ohne Portnummer für HTTP-Dienste zu konfigurieren, die an Nicht-Standardports (80, 443) ausgeführt werden. Die technische ordnungsgemäße Vorgehensweise zum Verweisen auf einen HTTP-Dienst, der an einem Nicht-Standardport ausgeführt wird, ist das Einbeziehen der Portnummer in den Dienstprinzipalnamen, doch aufgrund bekannter im Anhang beschriebener Probleme, müssen auch Dienstprinzipalnamen ohne Portangabe konfiguriert werden. Das Verwenden der Dienstprinzipalnamen ohne Port für die Webanwendung teams bedeutet nicht, dass in unserem Beispiel auf Dienste über die Standardport (80, 443) zugegriffen wird.
In unserem Beispiel haben wir die folgenden Dienstprinzipalnamen für die beiden im vorherigen Schritt erstellten Konten konfiguriert:
| DNS-Host | IIS-Anwendungspoolidentität | Dienstprinzipalnamen |
|---|---|---|
Portal.vmlab.local |
vmlab\svcPortal10App |
HTTP/portal HTTP/portal.vmlab.local |
Teams.vmlab.local |
vmlab\ svcTeams10App |
HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
Zum Erstellen der Dienstprinzipalnamen wurden die folgenden Befehle ausgeführt:
SetSPN -S HTTP/Portal vmlab\svcportal10App
SetSPN -S HTTP/Portal.vmlab.local vmlab\svcportal10App
SetSPN -S HTTP/Teams vmlab\svcTeams10App
SetSPN -S HTTP/Teams.vmlab.local vmlab\ svcTeams10App
SetSPN -S HTTP/Teams:5555 vmlab\ svcTeams10App
SetSPN -S HTTP/Teams.vmlab.local:5555 vmlab\ svcTeams10App
Wichtig
Konfigurieren Sie Dienstprinzipalnamen nicht mit HTTPS, auch wenn die Webanwendung SSL verwendet.
In diesem Beispiel wurde der neue in Windows Server 2008 eingeführte Befehlszeilenparameter -S angegeben, der erst prüft, ob der Dienstprinzipalname vorhanden ist, ehe dieser für das Konto erstellt wird. Ist er bereits vorhanden, wird kein neuer Dienstprinzipalname erstellt und eine Fehlermeldung angezeigt.
Werden doppelte Dienstprinzipalnamen gefunden, müssen Sie das Problem beheben, indem Sie entweder einen anderen DNS-Namen für die Webanwendung wählen und dadurch den Dienstprinzipalnamen ändern oder den vorhandenen Dienstprinzipalnamen aus dem Konto entfernen, in dem er erkannt wurde.
Wichtig
Vergewissern Sie sich vor dem Löschen eines vorhandenen Dienstprinzipalnamens, dass dieser nicht mehr benötigt wird, da Sie andernfalls ggf. die Kerberos-Authentifizierung einer anderen Anwendung in der Umgebung außer Kraft setzen.
Dienstprinzipalnamen und SSL
Kerberos-Dienstprinzipalnamen werden häufig mit URLs für HTTP-Webanwendungen verwechselt, da die Syntax des Dienstprinzipalnamen- und URI-Formats sehr ähnlich ist. Doch wichtig ist es zu verstehen, dass es sich um zwei vollständig unterschiedliche und eigene Dinge handelt. Kerberos-Dienstprinzipalnamen dienen zum Bestimmen eines Diensts. Wenn der jeweilige Dienst eine HTTP-Anwendung ist, lautet das Dienstschema "HTTP" unabhängig davon, ob auf den Dienst über SSL zugegriffen wird oder nicht. Auch wenn Sie auf die Webanwendung über "https://beliebigeAnwendung" zugreifen sollten, dürfen Sie deshalb einen Dienstprinzipalnamen nicht mit HTTPS, z. B. "HTTPS/beliebigeAnwendung" konfigurieren.
Konfigurieren der eingeschränkten Delegierung von Kerberos für Computer und Dienstkonten
Je nach Szenario ist für bestimmte Funktionen in SharePoint Server 2010 die eingeschränkte Delegierung erforderlich. Wenn beispielsweise das Webpart RSS-Anzeige für die Anzeige eines RSS-Feeds aus einer authentifizierten Quelle konfiguriert ist, wird für die Nutzung des Quellfeeds eine Delegierung benötigt. In anderen Fällen muss die eingeschränkte Delegierung ggf. konfiguriert werden, um Dienstanwendungen (wie Excel Services) die Delegierung der Identität des Clients an Back-End-Systeme zu ermöglichen.
In diesem Szenario wird die eingeschränkte Kerberos-Delegierung konfiguriert, damit das Webpart RSS-Anzeige einen geschützten lokalen RSS-Feed und einen geschützten RSS-Remotefeed aus einer Remotewebanwendung lesen kann. In nachfolgenden Szenarien wird die eingeschränkte Kerberos-Delegierung für andere SharePoint Server 2010-Dienstanwendungen konfiguriert.
Das folgende Diagramm veranschaulicht, was in diesem Szenario konfiguriert wird:
.jpg "Szenariodiagramm")
Wir sehen zwei Webanwendungen mit je einer eigenen Websitesammlung sowie einer Webseite, die als Host zweier Webparts vom Typ RSS-Anzeige dient. Beide Webanwendungen haben eine einzelne Standardzone, die für die Kerberos-Authentifizierung konfiguriert ist, sodass für alle aus diesen Websites stammenden Feeds eine Authentifizierung erforderlich ist. In den beiden Websites ist eine RSS-Anzeige für das Lesen eines lokalen RSS-Feeds aus einer Liste und eine andere für das Lesen eines Authentifizierungsfeeds in der Remotewebsite konfiguriert.
Hierfür wird die eingeschränkte Kerberos-Delegierung so konfiguriert, dass die Delegierung zwischen den Dienstkonten des IIS-Anwendungspools zugelassen wird. Das folgende Diagramm zeigt die benötigten Pfade für die eingeschränkte Delegierung:
.jpg "Diagramm zur Anwendungspooldelegierung")
Wie bereits erwähnt, wird die Webanwendung anhand des Dienstnamens unter Verwendung des Dienstprinzipalnamens bestimmt, der der Identität des IIS-Anwendungspools zugewiesen ist. Die Anforderungen verarbeitenden Dienstkonten müssen so konfiguriert sein, dass die Clientidentität an die vorgesehenen Dienste delegiert wird. Die folgenden Pfade müssen für die eingeschränkte Delegierung konfiguriert werden:
| Prinzipaltyp | Prinzipalname | Erforderliche Stellvertretungen |
|---|---|---|
Benutzer |
svcPortal10App |
HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
Benutzer |
svcTeams10App |
HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
Hinweis
Es mag redundant erscheinen, eine Delegierung eines Diensts an sich selbst zu konfigurieren, z. B. die Delegierung des Dienstkontos portal an die Dienstanwendung portal, doch ist dies in Szenarien erforderlich, in denen der Dienst auf mehreren Servern ausgeführt wird. Dies ist für das Szenario erforderlich, bei dem ein Server ggf. eine Delegierung an einen anderen Server vornehmen muss, auf dem derselbe Dienst ausgeführt wird, z. B. ein Web-Front-End-Server, der eine Anforderung mit einer RSS-Anzeige verarbeitet, die die lokale Webanwendung als Datenquelle verwendet. Je nach Farmtopologie und -konfiguration ist es möglich, dass die RSS-Anforderung von einem anderen Server erfüllt wird, was für einen ordnungsgemäßen Betrieb die Delegierung erforderlich machen würde.
Die Delegierung kann mit dem Snap-In Active Directory-Benutzer und -Computer konfiguriert werden. Klicken Sie mit der rechten Maustaste auf die einzelnen Dienstkonten, und öffnen Sie das Eigenschaftendialogfeld. Im Dialogfeld wird eine Registerkarte für die Delegierung angezeigt (dies allerdings nur, wenn dem Objekt ein Dienstprinzipalname zugewiesen ist. Computer haben standardmäßig einen Dienstprinzipalnamen). Wählen Sie auf der Registerkarte erst Benutzer bei Delegierungen angegebener Dienste vertrauen und dann Beliebiges Authentifizierungsprotokoll verwenden aus.
Klicken Sie auf die Schaltfläche Hinzufügen, um die Dienste hinzuzufügen, für die der Benutzer (das Dienstkonto) eine Delegierung vornehmen darf. In unserem Fall wird eine Delegierung an einen HTTP-Dienst versucht, was bedeutet, dass nach dem Dienstkonto des IIS-Anwendungspools gesucht wird, dem der Dienstprinzipalname im vorherigen Schritt zugewiesen wurde.
Klicken Sie im Dialogfeld Benutzer oder Computer auswählen auf Benutzer und Computer, suchen Sie die Dienstkonten des IIS-Anwendungspools (in diesem Beispiel vmlab\svcPortal10App und vmlab\svcTeams10App), und klicken Sie dann auf OK.
Sie werden anschließend aufgefordert, die den Objekten zugewiesenen Dienste anhand des Dienstprinzipalnamens auszuwählen.
Klicken Sie im Dialogfeld Dienste hinzufügen auf Alle auswählen und dann auf OK. Wenn Sie zum Delegierungsdialogfeld zurückkehren, werden nicht alle ausgewählten Dienstprinzipalnamen angezeigt. Um alle anzuzeigen, aktivieren Sie links unten das Kontrollkästchen Erweitert.
Führen Sie diese Schritte für jedes Dienstkonto in der Umgebung durch, das die Delegierung benötigt. In diesem Beispiel ist dies die Dienstkontenliste.
Konfigurieren von SharePoint Server
Nachdem Active Directory und DNS konfiguriert wurden, kann die Webanwendung in Ihrer SharePoint Server 2010-Farm erstellt werden. In diesem Artikel wird an dieser Stelle vorausgesetzt, dass die Installation von SharePoint Server abgeschlossen ist und die Farmtopologie und unterstützende Infrastruktur (z. B. Lastenausgleich) konfiguriert sind. Weitere Informationen zum Installieren und Konfigurieren Ihrer SharePoint-Farm finden Sie unter Bereitstellung für SharePoint Server 2010.
Konfigurieren verwalteter Dienstkonten
Konfigurieren Sie vor dem Erstellen von Webanwendungen die in den vorherigen Schritten erstellten Dienstkonten in SharePoint Server als verwaltete Dienstkonten. Wenn Sie dies vorab tun, können Sie diesen Schritt überspringen, wenn Sie die Webanwendungen selbst erstellen.
So konfigurieren Sie ein verwaltetes Konto
Klicken Sie in der SharePoint-Zentraladministration auf Sicherheit.
Klicken Sie unter Allgemeine Sicherheit auf Verwaltete Konten konfigurieren.
Klicken Sie auf Verwaltetes Konto registrieren, und erstellen Sie für jedes Dienstkonto ein verwaltetes Konto. In diesem Beispiel wurden fünf verwaltete Dienstkonten erstellt:
Konto Zweck VMLAB\svcSP10Search
SharePoint-Suchdienstkonto
VMLAB\svcSearchAdmin
Dienstkonto für die SharePoint-Suchverwaltung
VMLAB\svcSearchQuery
Dienstkonto für die SharePoint-Suchabfrage
VMLAB\svcPortal10App
IIS-Anwendungspoolkonto für die Webanwendung portal
VMLAB\svcTeams10App
IIS-Anwendungspoolkonto für die Webanwendung teams
Hinweis
Verwaltete Konten in SharePoint Server 2010 entsprechen nicht verwalteten Dienstkonten im Active Directory von Windows Server 2008 R2.
Erstellen der SharePoint Server-Suchdienstanwendung
In diesem Beispiel wird die SharePoint Server-Suchdienstanwendung so konfiguriert, dass sichergestellt ist, dass die neu erstellte Webanwendung erfolgreich durchforstet und durchsucht werden kann. Erstellen Sie eine neue SharePoint Server-Suchdienstanwendung, und legen Sie den Such-, Abfrage- und Verwaltungsdienst auf dem Anwendungsserver ab (in diesem Beispiel vmSP10App01). Eine ausführliche Erläuterung der Konfiguration der Suchdienstanwendung finden Sie im englischsprachigen Blogbeitrag Step-by-Step: Provisioning the Search Service Application.
Hinweis
Die Installation aller Suchdienste auf einem einzelnen Anwendungsserver ist nur für Demonstrationszwecke gedacht. Eine vollständige Erläuterung der SharePoint Server 2010-Suchtopologieoptionen und empfohlenen Vorgehensweisen bietet dieser Artikel nicht.
Erstellen der Webanwendung
Wechseln Sie zur Zentraladministration, und wählen Sie im Abschnitt Anwendungsverwaltung die Option Webanwendungen verwalten aus. Klicken Sie auf der Symbolleiste auf Neu, und erstellen Sie Ihre Webanwendung. Vergewissern Sie sich, dass Folgendes konfiguriert ist:
Wählen Sie Klassischer Authentifizierungsmodus aus.
Konfigurieren Sie den Port und Hostheader für jede Webanwendung.
Wählen Sie Verhandeln als Authentifizierungsanbieter aus.
Wählen Sie unter Anwendungspool die Option Neuen Anwendungspool erstellen und dann das im vorherigen Schritt erstellte verwaltete Konto aus.
In diesem Beispiel wurden zwei Webanwendungen mit den folgenden Einstellungen erstellt:
| Einstellung | http://Webanwendung "Portal" | http://Webanwendung "Teams" |
|---|---|---|
Authentifizierung |
Klassischer Modus |
Klassischer Modus |
IIS-Website |
Name: SharePoint – Portal – 80 Port: 80 Hostheader: Portal |
Name: SharePoint – Teams – 5555 Port: 80 Hostheader: Teams |
Sicherheitskonfiguration |
Authentifizierungsanbieter: Verhandeln Anonymen Zugriff zulassen: Nein Secure Socket Layer verwenden: Nein |
Authentifizierungsanbieter: Verhandeln Anonymen Zugriff zulassen: Nein Secure Socket Layer verwenden: Nein |
Öffentliche URL |
http://Portal:80 |
http://Teams:5555 |
Anwendungspool |
Name: SharePoint – Portal80 Sicherheitskonto: vmlab\svcPortal10App |
Name: SharePoint – Teams5555 Sicherheitskonto: vmlab\svcTeams10App |
Beim Erstellen der neuen Webanwendung erstellen Sie auch eine neue Zone (die Standardzone), die für die Verwendung des Authentifizierungsanbieters Windows konfiguriert wird. Durch Auswählen der Webanwendung in deren Verwaltungsbereich und Klicken auf Authentifizierungsanbieter auf der Symbolleiste können Sie den Anbieter und seine Einstellungen für die Zone anzeigen. Im Dialogfeld mit den Authentifizierungsanbietern sind alle Zonen für die ausgewählte Webanwendung sowie der Authentifizierungsanbieter für jede Zone enthalten. Durch Auswählen der Zone werden die Authentifizierungsoptionen für die jeweilige Zone angezeigt.
Wenn Sie die Windows-Einstellungen falsch konfiguriert haben und NTLM beim Erstellen der Webanwendung ausgewählt haben, können Sie im Dialogfeld Authentifizierungsfeatures bearbeiten die Einstellung in Verhandeln ändern. Falls Klassischer Modus nicht als Authentifizierungsmodus ausgewählt wurde, müssen Sie entweder eine neue Zone erstellen, indem Sie die Webanwendung auf eine neue IIS-Website erweitern, oder die Webanwendung löschen und neu erstellen.
Erstellen von Websitesammlungen
Zum Testen, ob die Authentifizierung ordnungsgemäß funktioniert, müssen Sie in jeder Webanwendung mindestens eine Websitesammlung erstellen. Das Erstellen und Konfigurieren der Websitesammlung wirkt sich nicht auf die Funktionalität von Kerberos aus, weshalb Sie die Anleitungen zum Erstellen einer Websitesammlung unter Erstellen einer Websitesammlung (SharePoint Foundation 2010) befolgen können.
Für dieses Beispiel wurden zwei Websitesammlungen konfiguriert:
| Webanwendung | Pfad der Websitesammlung | Vorlage der Websitesammlung |
|---|---|---|
http://portal |
/ |
Veröffentlichungsportal |
http://teams:5555 |
/ |
Teamwebsite |
Erstellen alternativer Zugriffszuordnungen
Die Portalwebanwendung wird für die Verwendung von HTTPS und HTTP konfiguriert, um zu zeigen, wie die Delegierung bei durch SSL geschützten Diensten funktioniert. Zum Konfigurieren von SSL benötigt die Portwebanwendung für den HTTPS-Endpunkt eine zweite alternative SharePoint Server-Zugriffszuordnung.
So konfigurieren Sie alternative Zugriffszuordnungen
Klicken Sie in der Zentraladministration auf Anwendungsverwaltung.
Klicken Sie im Abschnitt Webanwendungen auf Alternative Zugriffszuordnungen konfigurieren.
Wählen Sie in der Dropdownliste Alternative Zugriffszuordnungssammlung auswählen den Eintrag Alternative Zugriffszuordnungssammlung ändern aus.
Wählen Sie die Webanwendung "portal" aus.
Klicken Sie auf der oberen Symbolleiste auf Öffentliche URLs bearbeiten.
Fügen Sie in einer freien Zone die HTTPS-URL der Webanwendung hinzu. Diese URL wird der Name auf dem SSL-Zertifikat, das Sie in den nächsten Schritten erstellen.
Klicken Sie auf Speichern.
Die HTTPS-URL sollte nun in der Zonenliste der Webanwendung enthalten sein.
IIS-Konfiguration
Installieren von SSL-Zertifikaten
Sie müssen auf jedem Server mit SharePoint Server, der als Host des Webanwendungsdiensts dient, für jede mit SSL arbeitende Webanwendung ein SSL-Zertifikat konfigurieren. Die Konfiguration eines SSL-Zertifikats und einer Zertifikatsvertrauensbeziehung wird ebenfalls in diesem Artikel nicht behandelt. Im Abschnitt "SSL-Konfiguration" in diesem Artikel finden Sie Verweise auf Informationen zum Konfigurieren von SSL-Zertifikaten in Internetinformationsdienste (IIS).
Sicherstellen, dass die Kerberos-Authentifizierung aktiviert ist
So überprüfen Sie, ob die Kerberos-Authentifizierung für die Website aktiviert ist
Öffnen Sie den Internetinformationsdienste-Manager.
Wählen Sie die zu überprüfende IIS-Website aus.
Doppelklicken Sie in der Ansicht Features unter IIS auf Authentifizierung.
Windows-Authentifizierung muss aktiviert sein.
Wählen Sie rechts unter Aktionen den Eintrag Anbieter aus. Vergewissern Sie sich, dass Verhandeln der oberste Listeneintrag ist.
Sicherstellen, dass die Kernelmodusauthentifizierung deaktiviert ist
Die Kernelmodusauthentifizierung wird von SharePoint Server 2010 nicht unterstützt. Für alle SharePoint Server-Webanwendungen muss die Kernelmodusauthentifizierung in den dazugehörigen IIS-Websites standardmäßig deaktiviert sein. Selbst in Fällen, in denen die Webanwendung für eine vorhandene IIS-Website konfiguriert wurde, deaktiviert SharePoint Server die Kernelmodusauthentifizierung, da eine neue Webanwendung in der vorhandenen IIS-Website bereitgestellt wird.
So prüfen Sie, ob die Kernelmodusauthentifizierung deaktiviert ist
Öffnen Sie den Internetinformationsdienste-Manager.
Wählen Sie die zu überprüfende IIS-Website aus.
Doppelklicken Sie in der Ansicht Features unter IIS auf Authentifizierung.
Windows-Authentifizierung muss aktiviert sein.
Klicken Sie auf Erweiterte Einstellungen.
Vergewissern Sie sich, dass die EAP- und Kernelmodusauthentifizierung deaktiviert sind.
Konfigurieren der Firewall
Stellen Sie vor dem Testen der Authentifizierung sicher, dass Clients an den konfigurierten HTTP-Ports auf die SharePoint Server-Webanwendungen zugreifen können. Stellen Sie ferner sicher, dass Clients sich bei Active Directory authentifizieren und über die Kerberos-Standardports Kerberos-Tickets vom Schlüsselverteilungscenter anfordern können.
Öffnen von Firewallports zum Zulassen von eingehendem HTTP-Datenverkehr an Standard- und Nicht-Standardports
In der Regel müssen Sie die Firewall auf jedem Front-End-Webserver für das Zulassen eingehender Anforderungen über die TCP-Ports 80 und 443 konfigurieren. Öffnen Sie für die Windows-Firewall den Abschnitt Erweiterte Sicherheit, und wechseln Sie zu den folgenden Regeln für eingehenden Datenverkehr:
WWW-Dienste (Eingehender HTTP-Datenverkehr)
WWW-Dienste (Eingehender HTTPS-Datenverkehr)
Vergewissern Sie sich, dass die entsprechenden Ports in Ihrer Umgebung geöffnet sind. In diesem Beispiel wird auf SharePoint Server über HTTP (Port 80) zugegriffen, weshalb diese Regel aktiviert wurde.
Darüber hinaus muss der in diesem Beispiel verwendete Nicht-Standardport (TCP 5555) geöffnet werden. Wenn Sie über an Nicht-Standardports ausgeführte Websites verfügen, müssen Sie benutzerdefinierte Regeln konfigurieren, die HTTP-Datenverkehr an diesen Ports zulassen.
Sicherstellen, dass sich Clients mit Kerberos-Ports in der Active Directory-Rolle verbinden können
Zum Verwenden der Kerberos-Authentifizierung müssen Clients TGTs (Ticket Granting Tickets) und Diensttickets über den UDP- oder TCP-Port 88 aus dem Schlüsselverteilungscenter abrufen. Wenn Sie die Active Directory-Rolle in Windows Server 2008 oder höher installieren, wird die Rolle standardmäßig mit den folgenden Regeln für eingehenden Datenverkehr konfigurieren, um diese Kommunikation standardmäßig zuzulassen:
Kerberos-Schlüsselverteilungscenter - PCR (TCP eingehend)
Kerberos-Schlüsselverteilungscenter - PCR (UDP eingehend)
Kerberos-Schlüsselverteilungscenter - TCP eingehend
Kerberos-Schlüsselverteilungscenter - UDP eingehend
Stellen Sie sicher, dass diese Regeln aktiviert sind und sich Clients über Port 88 mit dem Schlüsselverteilungscenter (Domänencontroller) verbinden können.
Testen der Browserauthentifizierung
Nach der Konfiguration von Active Directory, DNS und SharePoint Server können Sie nun testen, ob die Kerberos-Authentifizierung ordnungsgemäß konfiguriert ist, indem Sie im Browser zu Ihren Webanwendungen wechseln. Beim Testen im Browser müssen die folgenden Bedingungen erfüllt werden:
Der Testbenutzer ist bei einem Computer mit Windows XP, Vista oder Windows 7 angemeldet, der der Domäne beigetreten ist, in der SharePoint Server installiert ist, oder bei einer Domäne angemeldet, der von der SharePoint Server-Domäne vertraut wird.
Der Testbenutzer verwendet Internet Explorer 7.0 oder höher (Internet Explorer 6.0 wird von SharePoint Server 2010 nicht mehr unterstützt. Siehe Planen im Hinblick auf die Browserunterstützung (SharePoint Server 2010)).
Die integrierte Windows-Authentifizierung ist im Browser aktiviert. Vergewissern Sie sich, dass unter Internetoptionen auf der Registerkarte Erweitert im Abschnitt Sicherheit die Option Integrierte Windows-Authentifizierung aktivieren* aktiviert ist:
Das lokale Intranet ist für das automatische Anmelden von Clients konfiguriert. Wählen Sie in Internetoptionen auf der Registerkarte Sicherheit die Option Lokales Intranet aus, und klicken Sie auf die Schaltfläche Stufe anpassen. Führen Sie einen Bildlauf nach unten durch, und prüfen Sie, ob Automatisches Anmelden nur in der Intranetzone aktiviert ist.
Hinweis
Es ist möglich, die automatische Anmeldung für andere Zonen zu konfigurieren, doch in diesem Artikel werden die bewährten Methoden bei den Internet Explorer-Sicherheitszonen nicht behandelt. Zu Demonstrationszwecken wird für alle Tests die Intranetzone verwendet.
Stellen Sie sicher, dass unterInternetoptionen->Sicherheit->Intranetzone->Sites die Option Intranetnetzwerk automatisch ermitteln aktiviert ist.
Wenn Sie vollqualifizierte Domänennamen für den Zugriff auf die SharePoint Server-Webanwendungen verwendet, stellen Sie sicher, dass die vollqualifizierten Domänennamen in die Intranetzone einbezogen werden, entweder explizit oder durch Platzhalterinklusion (z. B. "*.vmlab.local").
Die einfachste Möglichkeit zum Bestimmen, ob die Kerberos-Authentifizierung verwendet wird, ist das Anmelden bei einer Testarbeitsstation und Navigieren zu der betreffenden Website. Wenn der Benutzer nicht zur Angabe von Anmeldeinformationen aufgefordert und die Website ordnungsgemäß angezeigt wird, können Sie davon ausgehen, dass die integrierte Windows-Authentifizierung funktioniert. Der nächste Schritt besteht im Bestimmen, ob das Protokoll Verhandeln zum Aushandeln der Kerberos-Authentifizierung als Authentifizierungsanbieter für die Anforderung verwendet wurde. Die kann auf folgende Weisen geschehen:
Sicherheitsprotokolle des Front-End-Webservers
Wenn die Kerberos-Authentifizierung ordnungsgemäß funktioniert, werden auf den Front-End-Webservern in den Sicherheitsereignisprotokollen Anmeldeereignisse mit der Ereignis-ID 4624 angezeigt. In den allgemeinen Informationen zu diesen Ereignissen sollten die auf dem Computer protokollierte Sicherheits-ID und der verwendete Anmeldeprozess enthalten sein, der Kerberos lauten muss.
KList
KList ist ein Befehlszeilenprogramm im Standardfunktionsumfang von Windows Server 2008 und Windows Server 2008 R2, mit dem Kerberos-Tickets auf einem bestimmten Computer aufgelistet und gelöscht werden können. Öffnen Sie zum Ausführen von KLIST in Windows Server 2008 eine Eingabeaufforderung, und geben Sie Klist ein.
Wenn Sie den Ticketcache löschen möchten, führen Sie KList mit dem optionalen Parameter purge aus: Klist purge
KerbTray
KerbTray ist ein kostenloses Hilfsprogramm im Funktionsumfang der Windows Server 2000 Resource Kit-Tools, das auf Clientcomputern zum Anzeigen des Kerberos-Ticketcaches verwendet werden kann. Es kann an unter Windows 2000 Resource Kit Tool: Kerbtray.exe heruntergeladen und anschließend installiert werden. Führen Sie nach der Installation die folgenden Schritte aus:
Navigieren Sie zu den Websites, auf denen die Kerberos-Authentifizierung verwendet wird.
Führen Sie KerbTray.exe aus.
Zeigen Sie den Kerberos-Ticketcache an, indem Sie auf der Taskleiste mit der rechten Maustaste auf das KerbTray-Symbol klicken und List Tickets auswählen.
Prüfen Sie, ob die Diensttickets für die Webanwendungen, die Sie authentifiziert haben, in der Liste der zwischengespeicherten Tickets enthalten sind. In diesem Beispiel sind wir zu den folgenden Websites navigiert, für die die folgenden Dienstprinzipalnamen registriert sind:
Website-URL Dienstprinzipalname http://portal
HTTP/Portal.vmlab.local
http://teams:5555
HTTP/Teams.vmlab.local
Fiddler
Fiddler ist ein kostenloses Analyseprogramm für HTTP-Datenverkehr, das an folgender Adresse heruntergeladen werden kann: http://www.fiddlertool.com/. In Fiddler können Sie das Aushandeln der Kerberos-Authentifizierung zwischen Client und Server verfolgen und in den HTTP-Headern jeder Anforderung die vom Client an den Server gesendeten Kerberos-Diensttickets erkennen. Führen Sie zum Überprüfen, ob die Kerberos-Authentifizierung ordnungsgemäß funktioniert, in Fiddler die folgenden Schritte aus:
Laden Sie Fiddler (www.fiddlertool.com) auf den Clientcomputer herunter, und installieren Sie das Programm.
Melden Sie sich vom Desktopcomputer ab und wieder an, um zwischengespeicherte Verbindungen mit dem Webserver zu löschen und den Browser zu zwingen, die Kerberos-Authentifizierung auszuhandeln und den Authentifizierungshandshake durchzuführen.
Starten Sie Fiddler.
Öffnen Sie Internet Explorer, und wechseln Sie zur Webanwendung (http://portal in unserem Beispiel).
In Fiddler können Sie die Anforderungen und Antworten an den SharePoint Server-Front-End-Webserver nachverfolgen.
Der erste HTTP 401-Befehl ist der Versuch des Browsers, die GET-Anforderung ohne Authentifizierung durchzuführen. Als Antwort sendet der Server die Meldung "HTTP 401 - Nicht autorisiert" zurück und gibt in der Antwort an, welche Authentifizierungsmethode unterstützt wird. In der nächsten Anforderung sendet der Client erneut die vorherige Anforderung, wobei jedoch dieses Mal das Dienstticket für die Webanwendung in den Headern der Anforderung mit gesendet wird. Bei erfolgreicher Authentifizierung sendet der Server die angeforderte Ressource zurück.
NetMon 3.4
NetMon 3.4 ist ein kostenlose Analyseprogramm von Netzwerkpaketen von, das aus dem Microsoft Download Center heruntergeladen werden kann: Microsoft Network Monitor 3.4.
In NetMon sehen Sie alle TCP-Anforderungen und -Antworten an das Schlüsselverteilungscenter und die SharePoint Server-Webserver und erhalten dadurch eine vollständige Sicht auf den Datenverkehr, der die komplette Authentifizierungsanforderung bildet. Führen Sie zum Überprüfen mit NetMon, ob die Kerberos-Authentifizierung funktioniert, die folgenden Schritte aus:
Laden Sie NetMon 3.4 (Microsoft Network Monitor 3.4) herunter, und installieren Sie das Programm.
Melden Sie sich vom Client ab und anschließend wieder an, um den Kerberos-Ticketcache zu löschen. Sie können den Ticketcache auch mithilfe von KerbTray löschen, indem Sie mit der rechten Maustaste auf KerbTray klicken und Purge Tickets auswählen.
Starten Sie NetMon im Administratormodus. Klicken Sie mit der rechten Maustaste auf die NetMon-Verknüpfung, und wählen Sie Als Administrator ausführen aus.
Starten Sie eine neue Erfassung für die Schnittstellen, die mit dem Active Directory-Domänencontroller in Ihrer Umgebung und den Front-End-Webservern verbunden sind.
Öffnen Sie Internet Explorer, und wechseln Sie zur Webanwendung.
Beenden Sie, sobald die Website angezeigt wird, die Erfassung, und fügen Sie einen Anzeigefilter hinzu, um die Frames für Kerberos-Authentifizierung und HTTP-Datenverkehr anzuzeigen.
Im Framesfenster werden sowohl der HTTP- als auch der Kerberos 5-Datenverkehr angezeigt.
Testen der Kerberos-Authentifizierung über SSL
Zum eindeutigen Bestimmen der Dienstprinzipalnamen, die angefordert werden, wenn ein Client auf eine durch SSL geschützte Ressource zugreift, können Sie mit einem Tool wie NetMon den Datenverkehr zwischen Client und Server erfassen und die Anforderungen von Kerberos-Diensttickets überprüfen.
Melden Sie sich entweder vom Clientcomputer ab und anschließend wieder an, oder löschen Sie alle Kerberos-Tickets im Cache mithilfe von KerbTray.
Starten Sie eine neue NetMon-Erfassung auf dem Clientcomputer. NetMon muss mit Administratorberechtigungen gestartet werden.
Navigieren Sie zur durch SSL geschützten Webanwendung (in diesem Beispiel https://portal).
Beenden Sie die NetMon-Erfassung, und untersuchen Sie den KerberosV5-Datenverkehr. Anweisungen zum Filter der Erfassungsanzeige finden Sie in den Anweisungen im Abschnitt NetMon 3.4 dieses Artikels.
Suchen Sie die TGS-Anforderung, die der Client sendet. In der Anforderung ist der angeforderte Dienstprinzipalname im Parameter "Sname" enthalten.
Beachten Sie, dass "Sname" HTTP/portal.vmlab.local und nicht HTTPS/portal.vmlab.local ist.
Testen von SharePoint Server-Suchindex und -abfrage
Überprüfen des Browserzugriffs auf den Indexservern
Stellen Sie vor einer Durchforstung sicher, dass der Indexserver auf die Webanwendungen zugreifen und sich ordnungsgemäß authentifizieren kann. Melden Sie sich beim Indexserver an, und öffnen Sie im Browser die Test-Websitesammlungen. Wenn die Websites ordnungsgemäß angezeigt und keine Authentifizierungsdialogfelder angezeigt werden, fahren Sie mit dem nächsten Schritt fort. Sollten beim Zugriff auf die Websites im Browser Probleme auftreten, kehren Sie zu den vorherigen Schritten zurück, um zu prüfen, ob alle Konfigurationsschritte ordnungsgemäß ausgeführt wurden.
Hochladen von Beispielinhalten und Durchführen einer Durchforstung
Laden Sie in jeder Websitesammlung ein Ausgangsdokument (das bei einer Suche leicht zu bestimmen ist) in eine Dokumentbibliothek hoch. Erstellen Sie hierzu beispielsweise ein Textdokument mit den Worten "Alpha, Beta, Gamma".
Wechseln Sie zur SharePoint-Zentraladministration, und beginnen Sie eine vollständige Durchforstung der Inhaltsquelle Lokale SharePoint-Websites (die standardmäßig die beiden Test-Websitesammlungen enthalten sollte).
Testen der Suche
Bei erfolgreicher Indizierung sollten der Index durchsuchbare Elemente und das Durchforstungsprotokoll keine Fehler enthalten.
Hinweis
Wenn Sie die Benutzerprofilanwendung konfiguriert haben und den Profilspeicher durchforsten, müssen Sie für die Benutzerprofilanwendung die entsprechenden Berechtigungen konfigurieren, um dem Inhaltszugriffskonto den Zugriff auf Profildaten zu ermöglichen. Wenn Sie nicht die Berechtigungen für die Benutzerprofilanwendung konfiguriert haben, enthalten die Durchforstungsprotokolle Fehler, die angeben, dass der Crawler nicht auf den Profildienst zugreifen konnten, da beim Versuch des Zugriffs auf den Dienst ein HTTP 401-Fehler aufgetreten ist. Dieser Fehler ist nicht auf Kerberos, sondern auf das Inhaltszugriffskonto zurückzuführen, das keine Berechtigungen zum Lesen der Profildaten hat.
Wechseln Sie als Nächstes zu den beiden Websitesammlungen, und führen Sie eine Suche nach dem Ausgangsdokument durch. Die Suchabfragen der beiden Websitesammlungen sollten das hochgeladene Ausgangsdokument zurückgeben.
Testen der Front-End-Webserverdelegierung
Als letzten Schritt in diesem Szenario wenden Sie das Webpart RSS-Anzeige auf jede Websitesammlung an, um sicherzustellen, dass die Delegierung sowohl lokal als auch remote funktioniert.
Konfigurieren von RSS-Feedquellen für jede Websitesammlung
Bei der Portalanwendung müssen Sie RSS-Feeds für die Websitesammlung aktivieren. Befolgen Sie zum Aktivieren von RSS-Feeds die Anweisungen unter Verwalten von RSS-Feeds auf Office.com.
Erstellen Sie nach der Aktivierung von RSS-Feeds eine neue benutzerdefinierte Liste, der Sie zu Testzwecken ein Element hinzufügen. Navigieren Sie zum Symbolleistenmenü Liste, und klicken Sie auf RSS-Feed, um den RSS-Feed anzuzeigen. Kopieren Sie die Feed-URL für die Verwendung in den folgenden Schritten.
Führen Sie diesen Schritt für jede Websitesammlung aus.
Hinzufügen von Webparts vom Typ "RSS-Anzeige" zur Homepage jeder Websitesammlung
Für die Anwendung portal müssen Sie die Websitesammlungs-Funktion Features von SharePoint Enterprise aktivieren, um das Webpart RSS-Anzeige verwenden zu können. Fügen Sie nach der Aktivierung zwei Webparts vom Typ RSS-Anzeige der Homepage hinzu. Konfigurieren Sie für das erste Webpart die Feed-URL so, dass sie auf den lokalen RSS-Feed zeigt, den Sie im vorherigen Schritt erstellt haben. Konfigurieren Sie für das zweite Webpart die Feed-URL so, dass sie auf die URL des Remote-Feeds zeigt. Im Anschluss sollten beide Webparts Inhalte aus dem lokalen und Remote-RSS-Feed anzeigen.