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.

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.

http://teams:5555: Konfigurieren Sie einen neuen DNS-Eintrag vom Typ "A" für die Webanwendung teams.

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
http://portal	vmlab\svcPortal10App
http://teams:5555	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

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

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.

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:

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:

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

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

1. Klicken Sie in der SharePoint-Zentraladministration auf Sicherheit.

2. Klicken Sie unter Allgemeine Sicherheit auf Verwaltete Konten konfigurieren.

3. 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.

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

1. Klicken Sie in der Zentraladministration auf Anwendungsverwaltung.

2. Klicken Sie im Abschnitt Webanwendungen auf Alternative Zugriffszuordnungen konfigurieren.

3. Wählen Sie in der Dropdownliste Alternative Zugriffszuordnungssammlung auswählen den Eintrag Alternative Zugriffszuordnungssammlung ändern aus.

4. Wählen Sie die Webanwendung "portal" aus.

5. Klicken Sie auf der oberen Symbolleiste auf Öffentliche URLs bearbeiten.

6. 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.

7. 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

1. Öffnen Sie den Internetinformationsdienste-Manager.

2. Wählen Sie die zu überprüfende IIS-Website aus.

3. Doppelklicken Sie in der Ansicht Features unter IIS auf Authentifizierung.

4. Windows-Authentifizierung muss aktiviert sein.

5. 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

1. Öffnen Sie den Internetinformationsdienste-Manager.

2. Wählen Sie die zu überprüfende IIS-Website aus.

3. Doppelklicken Sie in der Ansicht Features unter IIS auf Authentifizierung.

4. Windows-Authentifizierung muss aktiviert sein.

5. Klicken Sie auf Erweiterte Einstellungen.

6. 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:

1. 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.

2. 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)).

3. 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:

4. 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.

5. Stellen Sie sicher, dass unterInternetoptionen->Sicherheit->Intranetzone->Sites die Option Intranetnetzwerk automatisch ermitteln aktiviert ist.

6. 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:

1. Navigieren Sie zu den Websites, auf denen die Kerberos-Authentifizierung verwendet wird.

2. Führen Sie KerbTray.exe aus.

3. 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.

4. 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:

1. Laden Sie Fiddler (www.fiddlertool.com) auf den Clientcomputer herunter, und installieren Sie das Programm.

2. 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.

3. Starten Sie Fiddler.

4. Ö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:

1. Laden Sie NetMon 3.4 (Microsoft Network Monitor 3.4) herunter, und installieren Sie das Programm.

2. 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.

3. 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.

4. 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.

5. Öffnen Sie Internet Explorer, und wechseln Sie zur Webanwendung.

6. 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.

7. 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.

1. Melden Sie sich entweder vom Clientcomputer ab und anschließend wieder an, oder löschen Sie alle Kerberos-Tickets im Cache mithilfe von KerbTray.

2. Starten Sie eine neue NetMon-Erfassung auf dem Clientcomputer. NetMon muss mit Administratorberechtigungen gestartet werden.

3. Navigieren Sie zur durch SSL geschützten Webanwendung (in diesem Beispiel https://portal).

4. 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.

5. 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.

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.