Konfigurieren der Kerberos-Authentifizierung für ...download.microsoft.com/download/4/5/E/45E08010-776… · Web viewIn diesem Dokument wird das Konzept der Identität in Microsoft

Konfigurieren der Kerberos-Authentifizierung für SharePoint 2010-ProdukteMicrosoft Corporation

Veröffentlichung: Juli 2010

Aktualisiert: April 2012

Autor: Tom Wisnowski. Mitwirkende: Philippe-Joseph Arida, Luca Bandinelli, Kevin Donovan, Pej Javaheri , Denny Lee, Cephas Lin, Dave Manning, Carl Rabeler, Prash Shirolkar, Norm Warren, Josh Zimmerman. ([email protected])

Zusammenfassung

In diesem Dokument wird das Konzept der Identität in Microsoft SharePoint 2010-Produkten erklärt. Die vorliegenden Informationen helfen Ihnen außerdem, zu verstehen, welche wichtige Rolle die Kerberos-Authentifizierung in Authentifizierungs- und Delegierungsszenarien spielt und in welchen Situationen Kerberos-Authentifizierung in Lösungsentwürfen verwendet werden sollte oder benötigt wird. Als Beispiele für entsprechende Szenarien dienen u. a. Business Intelligence-Implementierungen, die den Zugriff auf externe Datenquellen wie etwa SQL Server schützen. In diesem Dokument wird auch die durchgehende Konfiguration der Kerberos-Authentifizierung in einer Umgebung erläutert, einschließlich Szenarien, in denen verschiedene Dienstanwendungen in Microsoft SharePoint Server verwendet werden. Zusätzliche Tools und Ressourcen werden beschrieben, die Ihnen beim Testen und Validieren der Kerberos-Konfiguration helfen.

1

Dieses Dokument wird wie besehen bereitgestellt. Die in diesem Dokument enthaltenen Informationen und Ansichten, einschließlich URLs und Verweise auf Internetwebsites, können ohne vorherige Ankündigung geändert werden. Das Risiko der Nutzung liegt bei Ihnen.

Einige Beispiele sind frei erfunden, soweit nichts anderes angegeben ist. Jede Ähnlichkeit mit der Realität ist rein zufällig.

Mit diesem Dokument werden keine Rechte an geistigem Eigentum an einem Microsoft-Produkt auf Sie übertragen. Sie sind berechtigt, dieses Dokument zu kopieren und für eigene interne Referenzzwecke zu nutzen.

© 2010 Microsoft Corporation. Alle Rechte vorbehalten.

Microsoft, Active Directory, Excel, Internet Explorer, Outlook, PerformancePoint, SharePoint, Windows und Windows PowerShell sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern.

Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus der Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren.

2

Inhaltsverzeichnis

Konfigurieren der Kerberos-Authentifizierung für SharePoint 2010-Produkte..................7

Kerberos-Authentifizierung für Microsoft SharePoint 2010-Produkte (Übersicht)............8Wer sollte diese Artikel zur Kerberos-Authentifizierung lesen?.....................................9Vom Anfang bis zum Ende..........................................................................................9Upgrade von Office SharePoint Server 2007...............................................................9Schrittweise exemplarische Vorgehensweise............................................................10Vorhandene Umgebung mit SharePoint 2010-Produkten.........................................11

Identitätsszenarien in SharePoint 2010-Produkten......................................................11Eingehende Identität.................................................................................................12Identität in einer SharePoint 2010-Produkte-Umgebung..........................................16Ausgehende Identität................................................................................................17Delegierung über Domänen- und Gesamtstrukturgrenzen hinaus...........................20

Einführung in Ansprüche..............................................................................................21Einführung in das Kerberos-Protokoll...........................................................................21Vorteile des Kerberos-Protokolls..................................................................................21Kerberos-Delegierung, eingeschränkte Delegierung und Protokollübergang...............22Änderungen bei der Kerberos-Authentifizierung in Windows 2008 R2 und Windows 7..................................................................................................................................24

Änderungen bei der Kerberos-Konfiguration in SharePoint 2010-Produkten..............24Überlegungen beim Upgrade von Office SharePoint Server 2007................................25

Konfigurieren der Kerberos-Authentifizierung: Schritt-für-Schritt-Anleitung (SharePoint Server 2010).................................................................................................................26Umgebung und Farmtopologie.....................................................................................26Spezifikation der Umgebung.....................................................................................28

Spezifikation der Webanwendung................................................................................29SSL-Konfiguration......................................................................................................31Lastenausgleich.........................................................................................................32

SQL--Aliasing.................................................................................................................32

3

SharePoint Server Services und Dienstkonten..............................................................33Dienstidentität für den Forderungen an den Windows-Tokendienst (C2WTS).............34Tipps zum Durcharbeiten der Szenarien.......................................................................35

Konfigurieren der Kerberos-Authentifizierung: Kernkonfiguration (SharePoint Server 2010)............................................................................................................................37Checkliste für die Konfiguration...................................................................................38Schrittweise Konfigurationsanweisungen.....................................................................40Konfigurieren von DNS..............................................................................................40Konfigurieren von Active Directory...........................................................................41Konfigurieren von SharePoint Server........................................................................52IIS-Konfiguration.......................................................................................................60Konfigurieren der Firewall.........................................................................................63Testen der Browserauthentifizierung........................................................................65Testen der Kerberos-Authentifizierung über SSL......................................................79Testen von SharePoint Server-Suchindex und -abfrage............................................80Testen der Front-End-Webserverdelegierung...........................................................83

Kerberos-Authentifizierung für SQL OLTP (SharePoint Server 2010)...............................86Checkliste für die Konfiguration...................................................................................87Details der Szenarioumgebung.....................................................................................88Schrittweise Konfigurationsanweisungen.....................................................................88Konfigurieren von DNS..............................................................................................88Konfigurieren von Active Directory...........................................................................89Überprüfen der SQL Server-Kerberos-Konfiguration.................................................90Erstellen einer SQL Server-Testdatenbank sowie einer Testtabelle..........................92

Kerberos-Authentifizierung für SQL Server Analysis Services (SharePoint Server 2010)..94Checkliste für die Konfiguration...................................................................................94Schrittweise Konfigurationsanweisungen.....................................................................95Konfigurieren von Active Directory...........................................................................95Überprüfen der SQL Server-Kerberos-Konfiguration.................................................96

Identitätsdelegierung für SQL Server Reporting Services (SharePoint Server 2010)........99Voraussetzungen für dieses Szenario.........................................................................100Checkliste für die Konfiguration.................................................................................100

4

Details der Szenarioumgebung...................................................................................101Domänenübergreifende Kerberos-Delegierung.........................................................101Schrittweise Konfigurationsanweisungen...................................................................102Konfigurieren von DNS............................................................................................102Active Directory-Verzeichnisdienst.........................................................................103SQL Server Reporting Services................................................................................110Konfigurieren von SharePoint Server......................................................................112Überprüfen der Konfiguration.................................................................................115

SSL-Konfiguration für Reporting Services...................................................................127

Identitätsdelegierung für Excel Services (SharePoint Server 2010)...............................130Voraussetzungen für dieses Szenario.........................................................................130Checkliste für die Konfiguration.................................................................................130Details der Szenarioumgebung...............................................................................132Logische SharePoint Server-Authentifizierung........................................................133

Schrittweise Konfigurationsanweisungen...................................................................134Active Directory-Konfiguration................................................................................134SharePoint Server-Konfiguration.............................................................................140Überprüfen der eingeschränkten Excel Services-Delegierung.................................152

Identitätsdelegierung für PowerPivot für SharePoint 2010 (SharePoint Server 2010). .158Szenarien, in denen die Kerberos-Authentifizierung erforderlich ist..........................159Voraussetzungen für dieses Szenario.........................................................................161Konfigurationsanweisungen.......................................................................................161

Identitätsdelegierung für Visio Services (SharePoint Server 2010)................................162Voraussetzungen für dieses Szenario.........................................................................162Checkliste für die Konfiguration.................................................................................162Details der Szenarioumgebung...................................................................................164Pfade der eingeschränkten Kerberos-Delegierung..................................................164Logische SharePoint Server-Authentifizierung........................................................164

Schrittweise Konfigurationsanweisungen...................................................................165Active Directory-Konfiguration................................................................................165SharePoint Server-Konfiguration.............................................................................171Überprüfen der eingeschränkten Delegierung für den Visio-Grafikdienst..............179

5

Identitätsdelegierung für PerformancePoint Services (SharePoint Server 2010)...........191Voraussetzungen für dieses Szenario.........................................................................191Checkliste für die Konfiguration.................................................................................192Details der Szenarioumgebung...................................................................................193Pfade der eingeschränkten Kerberos-Delegierung..................................................193Logische SharePoint Server-Authentifizierung........................................................194

Schrittweise Konfigurationsanweisungen...................................................................195Active Directory-Konfiguration................................................................................195SharePoint Server-Konfiguration.............................................................................201Überprüfen der eingeschränkten PerformancePoint Services-Delegierung............215

Identitätsdelegierung für Business Connectivity Services (SharePoint Server 2010).....222Voraussetzungen für dieses Szenario.........................................................................223Checkliste für die Konfiguration.................................................................................223Details der Szenarioumgebung...................................................................................224Schrittweise Konfigurationsanweisungen...................................................................224Active Directory-Konfiguration................................................................................224SharePoint Server-Konfiguration.............................................................................230Überprüfung............................................................................................................232

Bekannte Kerberos-Konfigurationsprobleme (SharePoint Server 2010)........................247Kerberos-Authentifizierung und Nicht-Standardports................................................247Kerberos-Authentifizierung und DNS CNAMEs...........................................................249Kerberos- und Kernelmodusauthentifizierung...........................................................250Kerberos- und sitzungsbasierte Authentifizierung.....................................................251Kerberos-Authentifizierung und Probleme mit doppelten/fehlenden Dienstprinzipalnamen.............................................................................................252

Maximale Größe des Kerberos-Tokens.......................................................................253Hotfixes für die Kerberos-Authentifizierung für Windows Server 2008 und Windows Vista........................................................................................................................253

Zurücksetzen des C2WTS-Kontos (SharePoint Server 2010)..........................................254Lösung........................................................................................................................254

6

Bekannte Kerberos-Konfigurationsprobleme (SharePoint Server 2010)

Konfigurieren der Kerberos-Authentifizierung für SharePoint 2010-ProdukteVeröffentlichung: 15.07.10

In diesem Dokument wird das Konzept der Identität in Microsoft SharePoint 2010-Produkten erklärt. Die vorliegenden Informationen helfen Ihnen außerdem, zu verstehen, welche wichtige Rolle die Kerberos-Authentifizierung in Authentifizierungs- und Delegierungsszenarien spielt und in welchen Situationen Kerberos-Authentifizierung in Lösungsentwürfen verwendet werden sollte oder benötigt wird. Als Beispiele für entsprechende Szenarien dienen u. a. Business Intelligence-Implementierungen, die den Zugriff auf externe Datenquellen wie etwa SQL Server schützen.

In diesem Dokument wird auch die durchgehende Konfiguration der Kerberos-Authentifizierung in einer Umgebung erläutert, einschließlich Szenarien, in denen verschiedene Dienstanwendungen in Microsoft SharePoint Server verwendet werden. Zusätzliche Tools und Ressourcen werden beschrieben, die Ihnen beim Testen und Validieren der Kerberos-Konfiguration helfen. In den Abschnitten „Schrittweise Konfiguration“ in diesem Dokument werden die folgenden Szenarien für SharePoint Server 2010 behandelt.

Szenario 1: Kernkonfiguration

Szenario 2: Kerberos-Authentifizierung für SQL OLTP

Szenario 3: Szenario 3: Identitätsdelegierung für SQL Analysis Services

Szenario 4: Identitätsdelegierung für SQL Reporting Services

Szenario 5: Identitätsdelegierung für Excel Services

Szenario 6: Identitätsdelegierung für PowerPivot für SharePoint 2010

Szenario 7: Identitätsdelegierung für Visio Services

Szenario 8: Identitätsdelegierung für PerformancePoint Services

Szenario 9: Identitätsdelegierung für Business Connectivity Services7

Konfigurieren der Kerberos-Authentifizierung für SharePoint 2010-Produkte

Dieselben Information zur Konfiguration der Kerberos-Authentifizierung für SharePoint 2010-Produkte finden Sie in der TechNet-Bibliothek in Form einer Artikelgruppe, die hier beginnt: Kerberos-Authentifizierung für Microsoft SharePoint 2010-Produkte (Übersicht) .

Kerberos-Authentifizierung für Microsoft SharePoint 2010-Produkte (Übersicht)Veröffentlichung: 02.12.10

In Microsoft SharePoint 2010-Produkten gibt es wichtige Verbesserungen beim Verwalten der Identität in der Plattform. Sie müssen unbedingt wissen, wie sich diese Änderungen auf den Lösungsentwurf und die Plattformkonfiguration auswirken, um Szenarien zu ermöglichen, in denen die Benutzeridentität an integrierte Systeme delegiert werden muss. Das Kerberos 5-Protokoll spielt eine wichtige Rolle, um die Delegierung zu ermöglichen, und ist für diese Szenarien möglicherweise notwendig.

In dieser Artikelfolge finden Sie Informationen zu folgenden Themen:

Grundlegendes zum Identitätskonzept in SharePoint 2010-Produkten

Informationen zur wichtigen Rolle der Kerberos-Authentifizierung in Authentifizierungs- und Delegierungsszenarien

Identifizieren der Situationen, in denen die Kerberos-Authentifizierung in Lösungsentwürfen verwendet werden sollte oder benötigt wird

Durchgängiges Konfigurieren der Kerberos-Authentifizierung in einer Umgebung, einschließlich Szenarien, in denen verschiedene Dienstanwendungen in SharePoint Server verwendet werden

Testen und Überprüfen, ob die Kerberos-Authentifizierung ordnungsgemäß konfiguriert ist und erwartungsgemäß ausgeführt wird

Suchen nach zusätzlichen Tools und Ressourcen zum Konfigurieren der Kerberos-Authentifizierung in Ihrer Umgebung

Diese Artikelfolge ist in zwei Hauptabschnitte unterteilt:

Diese Übersicht über die Kerberos-Authentifizierung in SharePoint 2010-Produkten

8


Dieser Artikel enthält konzeptionelle Informationen zum Verwalten der Identität in SharePoint 2010, zum Kerberos-Protokoll sowie zur wichtigen Rolle der Kerberos-Authentifizierung in SharePoint 2010-Lösungen.

Schritt-für-Schritt-Anleitung für die Konfiguration

In dieser Artikelfolge werden die erforderlichen Schritte zum Konfigurieren der Kerberos-Authentifizierung und -Delegierung in verschiedenen SharePoint-Lösungsszenarien behandelt.

Wer sollte diese Artikel zur Kerberos-Authentifizierung lesen?Identität und Delegierung nehmen in SharePoint 2010-Produkten einen wichtigen Platz ein und weisen viele Facetten und Bedeutungen auf. In dieser Artikelfolge werden die konzeptionellen und technischen Aspekte dieses Themas erläutert, wobei die Anforderungen verschiedener Zielgruppen berücksichtigt werden:

Vom Anfang bis zum Ende„Ich möchte alles über Identität und die Kerberos-Authentifizierung in SharePoint 2010-Produkten wissen“

Wenn Sie sich gerade erst mit den SharePoint 2010-Produkten, der Kerberos-Authentifizierung und der anspruchsbasierten Authentifizierung vertraut machen, sollten Sie den ersten Abschnitt dieses Dokuments lesen. Hier werden die grundlegenden Konzepte der Identität und Delegierung behandelt und die anspruchsbasierte Authentifizierung und die Kerberos-Authentifizierung vorgestellt. Folgen Sie unbedingt den Links zu externen Artikeln und zusätzlichen Informationen, um sich gründlich zu informieren, bevor Sie mit den Artikeln zur schrittweisen Konfiguration fortfahren.

Upgrade von Office SharePoint Server 2007„Ich möchte wissen, was sich seit der Version 2007 geändert hat und worauf ich mich beim Upgrade auf die Version 2010 vorbereiten sollte“

Wenn Sie über eine vorhandene Microsoft Office SharePoint Server 2007-Umgebung verfügen, für die bereits die Kerberos-Authentifizierung und Kerberos-Delegierung konfiguriert ist, sollten Sie die folgenden Abschnitte lesen:

9


Identitätsszenarien in SharePoint 2010-Produkten

Einführung in Ansprüche

Änderungen bei der Kerberos-Authentifizierung in Windows 2008 R2 und Windows 7

Änderungen bei der Kerberos-Konfiguration in SharePoint 2010-Produkten

Überlegungen beim Upgrade von Office SharePoint Server 2007

Falls Sie zusätzliche Fragen zur Konfigurationsdelegierung für ein bestimmtes Feature oder Szenario haben, sollten Sie die Artikel zur schrittweisen Konfiguration lesen, insbesondere die Konfigurationsprüflisten. Dadurch können Sie sicherstellen, dass Ihre Umgebung nach dem Upgrade ordnungsgemäß konfiguriert ist.

Schrittweise exemplarische Vorgehensweise„Ich wünsche ausführliche schrittweise Anleitungen zum Konfigurieren der Kerberos-Delegierung in SharePoint Server und entsprechenden SharePoint Server-Dienstanwendungen“

In den Artikeln zur schrittweisen Konfiguration werden mehrere Szenarien mit SharePoint 2010-Produkten behandelt, für die die Verwendung der Kerberos-Delegierung konfiguriert werden kann. Jedes Szenario wird ausführlich erörtert, einschließlich einer Konfigurationsprüfliste und schrittweiser Anleitungen, damit Sie die Kerberos-Authentifizierung in Ihrer Umgebung erfolgreich konfigurieren können. Die folgenden Szenarien werden behandelt:



Szenario 3: Kerberos-Authentifizierung für SQL Server Analysis Services

Szenario 4: Identitätsdelegierung für SQL Server Reporting Services


Szenario 6: Identitätsdelegierung für PowerPivot für SharePoint 2010

Szenario 7: Identitätsdelegierung für Visio Services

Szenario 8: Identitätsdelegierung für PerformancePoint Services

Szenario 9: Identitätsdelegierung für Business Connectivity Services

10


Lesen Sie das erste Kernkonfigurationsszenario unbedingt gründlich durch, da alle nachfolgenden Szenarien darauf aufbauen.

Hinweis

Die Szenarien enthalten SetSPN-Befehle, die Sie in diesem Dokument kopieren und in einem Eingabeaufforderungsfenster einfügen können. Diese Befehle enthalten Bindestriche. In Microsoft Word gibt es ein AutoFormat-Feature, mit dem Bindestriche normalerweise in Gedankenstriche konvertiert werden. Falls dieses Feature in Word aktiviert ist und Sie dann einen Vorgang zum Kopieren und Einfügen ausführen, werden die Befehle nicht ordnungsgemäß ausgeführt. Ändern Sie die Gedankenstriche in Bindestriche, um diesen Fehler zu beheben. Zum Deaktivieren des AutoFormat-Features in Word klicken Sie im Menü Datei auf Optionen, klicken Sie auf die Registerkarte Dokumentprüfung, und öffnen Sie dann das Dialogfeld AutoKorrektur.

Vorhandene Umgebung mit SharePoint 2010-Produkten„Ich verfüge über eine vorhandene Umgebung mit SharePoint 2010-Produkten, und die Kerberos-Authentifizierung wird nicht ordnungsgemäß ausgeführt. Wie kann ich die Konfiguration überprüfen und debuggen?“

In den Artikeln unter Schrittweise Konfiguration finden Sie mehrere Prüflisten zum Auswählen Ihrer Umgebung in verschiedenen Szenarien. Beachten Sie insbesondere Szenario 1, Kernkonfiguration, in dem grundlegende Tools und Techniken zum Selektieren der Kerberos-Konfiguration behandelt werden.

Identitätsszenarien in SharePoint 2010-ProduktenWenn Sie sich mit dem Konzept der Identität im Zusammenhang mit der Authentifizierung in SharePoint Server-Produkten vertraut machen, können Sie sich in den folgenden drei wichtigen Szenarien anschauen, wie die Identität von der Plattform behandelt wird: eingehende Authentifizierung, Authentifizierung innerhalb und zwischen Farmen sowie ausgehende Authentifizierung.

11


Eingehende IdentitätIm Szenario für die eingehende Authentifizierung wird veranschaulicht, wie ein Client die Identität gegenüber der Plattform präsentiert oder anders ausgedrückt für die Webanwendung oder den Webdienst authentifiziert wird. SharePoint Server autorisiert mithilfe der Identität des Clients dessen Zugriff auf mit SharePoint Server gesicherte Ressourcen, wie beispielsweise Webseiten, Dokumente usw.

SharePoint Server 2010-Produkte unterstützen zwei Modi zum Authentifizieren eines Clients für die Plattform, nämlich den klassischen Modus und den anspruchsbasierten Modus.

Klassischer ModusDer klassische Modus ermöglicht die typischen IIS-Authentifizierungsmethoden (Internetinformationsdienste, Internet Information Services), mit denen Sie möglicherweise bereits aus früheren Versionen von SharePoint Server vertraut sind. Wenn für eine SharePoint Server 2010-Webanwendung die Verwendung des klassischen Modus konfiguriert ist, können Sie die folgenden IIS-Authentifizierungsmethoden verwenden:

Integrierte Windows-Authentifizierung

Mit der integrierten Windows-Authentifizierung können Windows-Clients nahtlos mit SharePoint Server authentifiziert werden, ohne dass Anmeldeinformationen (Benutzername/Kennwort) manuell bereitgestellt werden müssen. Benutzer, die über das Internet Explorer auf SharePoint Server zugreifen, authentifizieren sich anhand der Anmeldeinformationen, unter denen der Internet Explorer-Prozess ausgeführt wird.

12


Dies sind standardmäßig die Anmeldeinformationen, mit denen sich der Benutzer am Desktop angemeldet hat. Dienste oder Anwendungen, die im integrierten Windows-Authentifizierungsmodus auf SharePoint Server zugreifen, versuchen sich mit den Anmeldeinformationen des ausgeführten Threads anzumelden, der standardmäßig der Identität des Prozesses entspricht.

NTLM

Der NT-LAN-Manager (NTLM) ist der Standardprotokolltyp, wenn die integrierte Windows-Authentifizierung ausgewählt ist. Dieses Protokoll nutzt eine dreiteilige Abfrage/Rückmeldung-Sequenz zum Authentifizieren von Clients. Weitere Informationen zu NTLM finden Sie unter Microsoft NTLM (http://go.microsoft.com/fwlink/?LinkId=196643&clcid=0x407).

Vorteile

Dieses Protokoll ist einfach zu konfigurieren und erfordert in der Regel keine zusätzliche Konfiguration der Infrastruktur oder Umgebung.

Es kann verwendet werden, wenn der Client nicht der Domäne angehört oder wenn er sich nicht in einer Domäne befindet, die für die Domäne, in der sich SharePoint Server befindet, vertrauenswürdig ist.

Nachteile:

SharePoint Server muss den Domänencontroller jedes Mal kontaktieren, wenn eine Clientauthentifizierungsantwort überprüft werden muss, wodurch der Datenverkehr auf den Domänencontrollern zunimmt.

Die Delegierung von Clientanmeldeinformationen an die Back-End-Systeme ist nicht zulässig, was auch als Doppel-Hop-Regel bezeichnet wird. Es handelt sich hierbei um ein geschütztes Protokoll.

Es handelt sich hierbei um ein geschütztes Protokoll.

Die Serverauthentifizierung wird nicht unterstützt.

Es gilt als nicht so sicher wie die Kerberos-Authentifizierung.

Kerberos-Protokoll

Bei Kerberos handelt es sich um ein sichereres Protokoll, das das Authentifizierungs-Ticketing unterstützt. Ein Kerberos-Authentifizierungsserver erteilt ein Ticket als Antwort auf eine Authentifizierungsanforderung eines Clientcomputers, falls die Anforderung

13

http://go.microsoft.com/fwlink/?linkid=196643&clcid=0x407


gültige Benutzeranmeldeinformationen und einen gültigen Dienstprinzipalnamen (Service Principal Name, SPN) enthält. Der Clientcomputer verwendet das Ticket für den Zugriff auf Netzwerkressourcen. Damit Kerberos-Authentifizierung unterstützt wird, müssen der Client- und der Servercomputer über eine vertrauenswürdige Verbindung zum Schlüsselverteilungscenter (Key Distribution Center, KDC) der Domäne verfügen. Das KDC verteilt freigegebene geheime Schlüssel, um die Verschlüsselung zu ermöglichen. Darüber hinaus müssen Client- und Servercomputer auf Active Directory-Verzeichnisdienste (Active Directory Domain Services, AD DS) zugreifen können. Für AD DS ist die Gesamtstruktur-Stammdomäne das Zentrum für Kerberos-Authentifizierungsverweise. Weitere Informationen zum Kerberos-Protokoll finden Sie unter Funktionsweise des Kerberos 5-Authentifizierungsprotokolls (http://go.microsoft.com/fwlink/?LinkId=196644&clcid=0x407) und Microsoft Kerberos. (http://go.microsoft.com/fwlink/?LinkId=196645&clcid=0x407)

Vorteile

Sicherstes Protokoll für die integrierte Windows-Authentifizierung

Ermöglicht die Delegierung von Clientanmeldeinformationen

Unterstützt die gegenseitige Authentifizierung von Clients und Servern

Erzeugt weniger Datenverkehr auf den Domänencontrollern

Offenes Protokoll, das von vielen Plattformen und Herstellern unterstützt wird

Nachteile:

Erfordert die zusätzliche Konfiguration von Infrastruktur und Umgebung

Die Clients müssen mit dem KDC (Active Directory-Domänencontroller in Windows-Umgebungen) über den TCP/UDP-Port 88 (Kerberos) bzw. den TCP/UDP-Port 464 (Kerberos – Kennwort ändern – Windows) verbunden sein

Andere Methoden

Neben der NTLM- und Kerberos-Authentifizierung unterstützt SharePoint Server weitere IIS-Authentifizierungsmethoden wie beispielsweise die Standardauthentifizierung, die Digestauthentifizierung und die zertifikatbasierte Authentifizierung, die in diesem Dokument nicht behandelt werden. Weitere Informationen zur Funktionsweise dieser Protokolle finden Sie unter In IIS 6.0 unterstützte Authentifizierungsmethoden (IIS 6.0) (http://go.microsoft.com/fwlink/?linkid=196646&clcid=0x407).

14





Anspruchsbasierte AuthentifizierungDie Unterstützung der anspruchsbasierten Authentifizierung ist ein neues Feature in SharePoint 2010-Produkten und basiert auf Windows Identity Foundation (WIF). Bei einem Anspruchsmodell akzeptiert SharePoint Server einen oder mehrere Ansprüche zu einem authentifizierenden Client, um den Client zu identifizieren und autorisieren. Die Ansprüche liegen als SAML-Token vor und stellen Fakten zu dem Client dar, die von einer vertrauenswürdigen Zertifizierungsstelle präsentiert werden. Beispielsweise könnte in einem Anspruch Folgendes angegeben sein: „Paul ist Mitglied der Gruppe „Organisations-Admins“ für die Domäne „Contoso.com“. Wenn dieser Anspruch von einem Anbieter stammt, dem SharePoint Server vertraut, könnte die Plattform anhand dieser Informationen Paul authentifizieren und ihm den Zugriff auf SharePoint Server-Ressourcen erlauben. Weitere Informationen zur anspruchsbasierten Authentifizierung finden Sie unter Handbuch zur anspruchsbasierten Identitäts- und Zugriffssteuerung (http://go.microsoft.com/fwlink/?linkid=187911&clcid=0x407).

Von SharePoint 2010-Produkten werden für die eingehende Authentifizierung die folgenden Ansprüche unterstützt: Windows-Ansprüche, formularbasierte Authentifizierungsansprüche sowie SAML-Ansprüche.

Windows-Ansprüche

Im Windows-Anspruchsmodus wird der Client von SharePoint Server mithilfe der standardmäßigen integrierten Windows-Authentifizierung (NTLM/Kerberos) authentifiziert, und anschließend wird die resultierende Windows-Identität in eine Anspruchsidentität umgewandelt.

Formularbasierte Authentifizierungsansprüche

Im formularbasierten Authentifizierungsanspruchsmodus wird der Client von SharePoint Server an eine Anmeldeseite umgeleitet, auf der die standardmäßigen ASP.NET-Anmeldesteuerelemente gehostet werden. Auf dieser Seite wird der Client mithilfe der ASP.NET-Mitgliedschafts- und Rollenanbieter authentifiziert, ähnlich wie bei der formularbasierten Authentifizierung in Office SharePoint Server 2007. Nachdem das Identitätsobjekt, das den Benutzer repräsentiert, erstellt wurde, wird diese Identität von SharePoint Server in ein Anspruchsidentitätsobjekt umgewandelt.

SAML-Ansprüche

Im SAML-Anspruchsmodus akzeptiert SharePoint Server SAML-Token von einem vertrauenswürdigen externen Sicherheitstokenanbieter (Security Token Provider, STS). Wenn sich der Benutzer anzumelden versucht, wird er an einen externen

15



Anspruchsanbieter (z. B. den Windows Live ID-Anspruchsanbieter) umgeleitet, der den Benutzer authentifiziert und ein SAML-Token erstellt. SharePoint Server akzeptiert und verarbeitet dieses Token, wobei die Ansprüche erweitert werden und ein Anspruchsidentitätsobjekt für den Benutzer erstellt wird.

Weitere Informationen zur anspruchsbasierten Authentifizierung in SharePoint 2010-Produkten finden Sie unter Anspruchsbasierte Identität in SharePoint.

Hinweis zur eingehenden Anspruchsauthentifizierung und zu C2WTSFür einige Dienstanwendungen müssen Sie C2WTS (Claims to Windows Token Service, Forderungen an den Windows-Tokendienst) von Windows Identity Foundation (WIF) verwenden, um Ansprüche innerhalb der Farm in Windows-Anmeldeinformationen für die ausgehende Authentifizierung zu transformieren. Es ist wichtig zu wissen, dass C2WTS nur ausgeführt wird, wenn als eingehende Authentifizierungsmethode entweder der klassische Authentifizierungsmodus oder die anspruchsbasierte Windows-Authentifizierung verwendet wird. Wenn die anspruchsbasierte Authentifizierung konfiguriert ist, benötigt C2WTS nur Windows-Ansprüche; von der Webanwendung können nicht mehrere Anspruchsformen in der Webanwendung verwendet werden, da andernfalls C2WTS nicht ausgeführt wird.

Identität in einer SharePoint 2010-Produkte-UmgebungSharePoint 2010-Umgebungen verwenden die anspruchsbasierte Authentifizierung für die Kommunikation innerhalb und zwischen Farmen für die meisten SharePoint-Dienstanwendungen und integrierten SharePoint-Produkte unabhängig vom verwendeten eingehenden Authentifizierungsmechanismus. Dies bedeutet, dass selbst bei Verwendung der klassischen Authentifizierung zum Authentifizieren mit einer bestimmten Webanwendung die eingehende Identität von SharePoint-Produkten in eine anspruchsbasierte Identität konvertiert wird, um die Authentifizierung mit SharePoint-Dienstanwendungen und -Produkten zu ermöglichen, von denen Ansprüche unterstützt werden. Durch die Standardisierung des Anspruchsmodells für die Kommunikation innerhalb und zwischen Farmen wird die Plattform von den verwendeten eingehenden Protokollen unabhängig.

16



Hinweis:

Einige in SharePoint Server integrierte Produkte, wie beispielsweise SQL Server Reporting Services, unterstützen keine Ansprüche und nutzen die Architektur der anspruchsbasierten Authentifizierung zwischen Farmen nicht. SharePoint Server nutzt möglicherweise auch die klassische Kerberos-Delegierung und Ansprüche in anderen Szenarien. Beispielsweise, wenn für das RSS-Anzeige-Webpart die Verwendung eines authentifizierten Feeds konfiguriert ist. Bestimmen Sie anhand der Dokumentation des jeweiligen Produkts oder der jeweiligen Dienstanwendung, ob die anspruchsbasierte Authentifizierung und die Identitätsdelegierung unterstützt werden.

Ausgehende IdentitätDie ausgehende Identität in SharePoint 2010-Produkten repräsentiert jene Szenarien, in denen Dienste innerhalb der Farm bei externen Branchensystemen und -diensten authentifiziert werden müssen. In Abhängigkeit vom jeweiligen Szenario kann die Authentifizierung in einem von zwei grundlegenden Modellen ausgeführt werden:

Vertrauenswürdiges SubsystemBeim vertrauenswürdigen Subsystem führt der Front-End-Dienst die Authentifizierung und Autorisierung des Clients aus und führt anschließend die Authentifizierung bei zusätzlichen Back-End-Diensten aus, ohne die Clientidentität an das Back-End-System zu übergeben. Das Back-End-System vertraut dem Front-End-Dienst bei der Durchführung der Authentifizierung und Autorisierung in seinem Namen. Die gängigste Methode zum Implementieren dieses Modells ist das Authentifizieren beim externen System mithilfe eines freigegebenen Dienstkontos:

17


In SharePoint Server gibt es für die Implementierung dieses Modells verschiedene Methoden:

Mithilfe der IIS-Anwendungspoolidentität – gewöhnlich wird dabei Code in der Webanwendung ausgeführt, mit dem die Berechtigungen erhöht werden, während ein externes System aufgerufen wird. Andere Methoden wie beispielsweise RevertToSelf können ebenfalls die Anwendungspoolidentität zum Authentifizieren bei externen Systemen verwenden.

Mithilfe eines Dienstkontos – gewöhnlich werden dabei Anmeldeinformationen der Anwendung im Secure Store Service gespeichert, die dann zum Authentifizieren bei einem externen System verwendet werden. Eine weitere Methode ist das Speichern der Anmeldeinformationen des Dienstkontos auf andere Weise, wie beispielsweise als eingebettete Verbindungszeichenfolgen.

Anonyme Authentifizierung – hierbei erfordert das externe System keine Authentifizierung. Deshalb muss der SharePoint Server-Front-End-Dienst keine Identität an das Back-End-System übergeben.

DelegierungBeim Delegierungsmodell authentifiziert der Front-End-Dienst zunächst den Client und nimmt dann mithilfe der Identität des Clients eine Authentifizierung bei einem anderen Back-End-System vor, das eine eigene Authentifizierung und Autorisierung durchführt:

18


In SharePoint 2010-Produkten gibt es für die Implementierung dieses Modells verschiedene Methoden:

Kerberos-Delegierung – wenn sich der Client mithilfe der Kerberos-Authentifizierung beim Front-End-Dienst authentifiziert, kann mit der Kerberos-Delegierung die Identität des Clients an das Back-End-System übergeben werden.

Hinweis:

Derzeit erlauben die meisten in SharePoint Server enthaltenen Dienstanwendungen die ausgehende Anspruchsauthentifizierung nicht, jedoch wird dies in Zukunft von dieser Plattform unterstützt werden. Darüber hinaus unterstützen viele gängige Branchensysteme heutzutage nicht die eingehende Anspruchsauthentifizierung. Dies bedeutet, dass die ausgehende Anspruchsauthentifizierung möglicherweise nicht verwendet werden kann oder zusätzliche Entwicklungsarbeit erfordert, damit sie ordnungsgemäß ausgeführt wird.

Ansprüche – mit der anspruchsbasierten Authentifizierung können die Ansprüche des Clients zwischen Diensten übergeben werden, vorausgesetzt es besteht eine Vertrauensstellung zwischen den beiden Diensten, und beide Dienste unterstützen Ansprüche.

Delegierung über Domänen- und Gesamtstrukturgrenzen hinausFür die Szenarien in dieser Artikelfolge zur Kerberos-Authentifizierung müssen sich der SharePoint Server-Dienst und externe Datenquellen in derselben Windows-Domäne

19


befinden, um die eingeschränkte Kerberos-Delegierung zu ermöglichen. Das Kerberos-Protokoll unterstützt zwei Delegierungsarten, nämlich die Standarddelegierung (uneingeschränkt) und die eingeschränkte Delegierung. Die Kerberos-Standarddelegierung ist über Domänengrenzen in einer einzelnen Gesamtstruktur hinweg möglich, was jedoch bei einer Gesamtstrukturgrenze unabhängig von der Vertrauensstellung nicht der Fall ist. Die eingeschränkte Kerberos-Delegierung ist über Domänen- oder Gesamtstrukturgrenzen hinweg für kein Szenario möglich.

Für einige SharePoint Server-Dienste kann die Verwendung der Kerberos-Standarddelegierung konfiguriert werden, aber für andere Dienste muss die eingeschränkte Delegierung verwendet werden. Jeder Dienst, der auf C2WTS (Claims to Windows Token Service, Forderungen an den Windows-Tokendienst) basiert, muss die eingeschränkte Kerberos-Delegierung verwenden, damit C2WTS mithilfe des Kerberos-Protokollübergangs Ansprüche in Windows-Anmeldeinformationen transformieren kann.

Für die folgenden Dienstanwendungen und Produkte sind C2WTS und die eingeschränkte Kerberos-Delegierung erforderlich:

Excel Services

PerformancePoint-Dienste

Visio Services

Die folgenden Dienstanwendungen und Produkte sind von diesen Anforderungen nicht betroffen, weshalb bei Bedarf die Standarddelegierung verwendet werden kann:

Business Data Connectivity-Dienst und Microsoft Business Connectivity Services

InfoPath Forms Services

Access Services

Microsoft SQL Server Reporting Services (SSRS)

Microsoft Project Server 2010

Die folgende Dienstanwendung erlaubt die Delegierung von Clientanmeldeinformationen nicht und ist deshalb von diesen Anforderungen nicht betroffen:

Microsoft SQL Server PowerPivot für Microsoft SharePoint

20


Einführung in AnsprücheEine Einführung in die Konzepte von Ansprüchen und in die anspruchsbasierte Authentifizierung finden Sie unter Einführung in Ansprüche (http://go.microsoft.com/fwlink/?linkid=196648&clcid=0x407) und Anspruchsbasierte Identität in SharePoint (http://go.microsoft.com/fwlink/?linkid=196647&clcid=0x407).

Einführung in das Kerberos-ProtokollEine Übersicht über die Funktionsweise des Kerberos-Protokolls finden Sie unter Microsoft Kerberos (Windows) (http://go.microsoft.com/fwlink/?linkid=196645&clcid=0x407), Erläuterungen zu Kerberos (http://go.microsoft.com/fwlink/?linkid=196649&clcid=0x407) und Ask the Directory Services Team: Kerberos for the Busy Admin (http://go.microsoft.com/fwlink/?linkid=196650&clcid=0x407).

Vorteile des Kerberos-ProtokollsBevor wir uns mit den Details der Konfiguration von SharePoint Server (oder einer beliebigen Webanwendung) für die Verwendung des Kerberos-Protokolls befassen, betrachten wir erst einmal das Kerberos-Protokoll und dessen Verwendung.

In der Regel gibt es drei Hauptgründe für die Verwendung des Kerberos-Protokolls:

1. Delegierung von Clientanmeldeinformationen – Mit dem Kerberos-Protokoll kann die Identität eines Clients von einem Dienst angenommen werden, damit dieser Dienst die Identität an andere Netzwerkdienste im Namen des Clients übergeben kann. Bei NTLM ist diese Delegierung nicht zulässig. (Diese Begrenzung in NTLM wird als „Doppel-Hop-Regel“ bezeichnet). Die anspruchsbasierte Authentifizierung, wie die Kerberos-Authentifizierung, kann zum Delegieren von Clientanmeldeinformationen verwendet werden, aber die Back-End-Anwendung muss Ansprüche unterstützen.

2. Sicherheit – Aufgrund von Features wie beispielsweise AES-Verschlüsselung, gegenseitiger Authentifizierung, Unterstützung von Datenintegrität und Datenschutz ist das Kerberos-Protokoll sicherer als sein NTLM-Pendant.

3. Potenziell bessere Leistung – Die Kerberos-Authentifizierung erfordert im Vergleich zu NTLM weniger Datenverkehr auf den Domänencontrollern (in Abhängigkeit von der PAC-Verifizierung, siehe Microsoft Open Specification Support Team Blog: Understanding Microsoft Kerberos PAC Validation). Falls die PAC-Verifizierung deaktiviert oder nicht erforderlich ist, muss der Dienst, der den Client authentifiziert, keinen Remoteprozeduraufruf für den Domänencontroller ausführen

21











(siehe Verzögerte Benutzerauthentifizierung bei der Ausführung eines Serverprogramms mit hohem Datenverkehrsaufkommen auf einem Domänenmitglied in Windows 2000 oder Windows Server 2003). Die Kerberos-Authentifizierung erfordert außerdem im Vergleich zu NTLM weniger Datenverkehr zwischen Client und Server. Clients können im Vergleich zum typischen dreistufigen Handshake von NTLM in zwei Anforderungen/Antworten bei Webservern authentifiziert werden. Diese Verbesserung macht sich jedoch in der Regel in Netzwerken mit geringen Wartezeiten auf Transaktionsbasis nicht bemerkbar, jedoch sehr wohl beim allgemeinen Durchsatz des Systems. Beachten Sie, dass viele Umgebungsfaktoren die Authentifizierungsleistung beeinflussen können. Deshalb sollten Sie die Leistung von Kerberos-Authentifizierung und NTLM in Ihrer eigenen Umgebung testen, bevor Sie sich für eine Methode entscheiden.

Dies ist eine unvollständige Liste der Vorteile des Kerberos-Protokolls. Es gibt andere Gründe, wie beispielsweise die gegenseitige Authentifizierung, die plattformübergreifende Interoperabilität und die transitive domänenübergreifende Vertrauensstellung. In den meisten Fällen sind jedoch die Delegierung und die Sicherheit die wichtigsten Gründe für die Verwendung des Kerberos-Protokolls.

Kerberos-Delegierung, eingeschränkte Delegierung und ProtokollübergangDas Kerberos 5-Protokoll in der Windows-Plattform unterstützt zwei Typen von Identitätsdelegierung, nämlich die Standarddelegierung (uneingeschränkt) und die eingeschränkte Delegierung:

Typ Vorteile Nachteile

Standarddelegierung Ist über Domänengrenzen in einer einzelnen Gesamtstruktur hinweg möglich.

Erfordert weniger Konfiguration als die eingeschränkte Delegierung.

Der Protokollübergang wird nicht unterstützt.

Sicher. Wenn die Sicherheit des Front-End-Diensts gefährdet ist, kann die Clientidentität an einen beliebigen Dienst in der Gesamtstruktur delegiert werden, der die Kerberos-Authentifizierung akzeptiert.

22





Typ Vorteile Nachteile

Eingeschränkte Delegierung

Ein anderes als das eingehende Kerberos-Authentifizierungsprotokoll kann in das Kerberos-Protokoll transformiert werden (Beispiel: NTLM zu Kerberos, anspruchsbasierte Authentifizierung zu Kerberos)

Sicherer. Identitäten können nur an den angegebenen Dienst delegiert werden.

Ist nicht über Domänengrenzen hinweg möglich.

Erfordert zusätzliche Setupkonfiguration.

Von Kerberos-aktivierten Diensten kann die Identität mehrfach über mehrere Dienste und mehrere Hops delegiert werden. Wenn eine Identität zwischen Diensten übertragen wird, kann die Delegierungsmethode von der Standarddelegierung in die eingeschränkte Delegierung geändert werden, aber nicht umgekehrt. Dies ist ein wichtiges Entwurfsdesign: wenn ein Back-End-Dienst die Standarddelegierung erfordert (z. B. zum Delegieren über eine Domänengrenze hinweg), müssen alle Dienste vor dem Back-End-Dienst die Standarddelegierung verwenden. Falls ein Front-End-Dienst die eingeschränkte Delegierung verwendet, kann das eingeschränkte Token vom Back-End-Dienst nicht in ein uneingeschränktes Token geändert werden, um eine Domänengrenze zu überwinden.

Mit dem Protokollübergang kann ein Kerberos-aktivierter Authentifizierungsdienst (Front-End-Dienst) eine andere als eine Kerberos-Identität in eine Kerberos-Identität konvertieren, die an andere Kerberos-aktivierte Dienste delegiert werden kann (Back-End-Dienst). Für den Protokollübergang ist die eingeschränkte Kerberos-Delegierung erforderlich, weshalb Identitäten mit Protokollübergang keine Domänengrenzen überwinden können. In Abhängigkeit von den Benutzerrechten des Front-End-Diensts kann das vom Protokollübergang zurückgegebene Kerberos-Ticket ein Identifikationstoken oder ein Identitätswechseltoken sein. Weitere Informationen zur eingeschränkten Delegierung und zum Protokollübergang finden Sie in den folgenden Artikeln:

Kerberos-Protokollübergang und eingeschränkte Delegierung (http://technet.microsoft.com/de-de/library/cc739587(WS.10).aspx)

23

http://technet.microsoft.com/de-de/library/cc739587(WS.10).aspx


Technischer Zusatz zum Protokollübergang mit eingeschränkter Delegierung (http://msdn.microsoft.com/de-de/library/ff650469.aspx)

Eingeschränkte Kerberos-Delegierung erfordert möglicherweise den Protokollübergang in Szenarien mit mehreren Hops (http://support.microsoft.com/kb/2005838/de-de)

Falls die Kerberos-Delegierung erforderlich ist, sollte als allgemeine bewährte Methode nach Möglichkeit die eingeschränkte Delegierung verwendet werden. Falls die Delegierung über Domänengrenzen hinweg erforderlich ist, muss für alle Dienste im Delegierungspfad die Standarddelegierung verwendet werden.

Änderungen bei der Kerberos-Authentifizierung in Windows 2008 R2 und Windows 7In Windows Server 2008 R2 und Windows 7 wurden neue Features für die Kerberos-Authentifizierung eingeführt. Eine Übersicht über die Änderungen finden Sie unter Änderungen bei der Kerberos-Authentifizierung (http://go.microsoft.com/fwlink/?linkid=196655&clcid=0x407) und Verbesserungen bei Kerberos (http://go.microsoft.com/fwlink/?LinkId=196656&clcid=0x407). Darüber hinaus sollten Sie sich mit der Kernelmodusauthentifizierung von IIS 7.0 vertraut machen (Einstellungen für die Kernelmodusauthentifizierung von IIS 7.0, (http://go.microsoft.com/fwlink/?linkid=196657&clcid=0x407)) auch wenn sie in SharePoint Server-Farmen nicht unterstützt wird.

Änderungen bei der Kerberos-Konfiguration in SharePoint 2010-ProduktenDie meisten grundlegenden Konzepte zum Konfigurieren der Kerberos-Authentifizierung in SharePoint 2010-Produkten sind unverändert. Sie müssen auch weiterhin Dienstprinzipalnamen (Service Principal Names, SPNs) konfigurieren, und Sie müssen auch weiterhin Delegierungseinstellungen für Computer- und Dienstkonten konfigurieren. Es gibt jedoch einige Änderungen, die Sie beachten sollten:

Eingeschränkte Delegierung – ist für Dienste erforderlich, die C2WTS (Claims to Windows Token Service, Forderungen an den Windows-Tokendienst) verwenden. Die eingeschränkte Delegierung ist erforderlich, damit vom Protokollübergang Ansprüche in Windows-Token konvertiert werden können.

24




http://support.microsoft.com/kb/2005838/de-de


http://msdn.microsoft.com/de-de/library/ff650469.aspx


Dienstanwendungen – In Office SharePoint Server 2007 waren für die SSP-Dienste spezielle Änderungen bei Dienstprinzipalnamen und bei der Serverregistrierung erforderlich, um die Delegierung zu ermöglichen. In SharePoint 2010-Produkten werden von Dienstanwendungen die anspruchsbasierte Authentifizierung und C2WTS verwendet, weshalb diese Änderungen nicht mehr nötig sind.

Windows Identity Foundation (WIF) – Der Forderungen an den Windows-Tokendienst (Claims to Windows Token Service, C2WTS) von WIF ist ein neuer Dienst, der von SharePoint 2010-Produkten für Delegierungsszenarien zum Konvertieren von Ansprüchen in Windows-Token verwendet wird.

Überlegungen beim Upgrade von Office SharePoint Server 2007Beim Upgrade einer Office SharePoint Server 2007-Farm auf SharePoint Server 2010 sollten Sie die folgenden Aspekte beachten:

Falls für Webanwendungen die URLs geändert werden, müssen Sie die Dienstprinzipalnamen entsprechend den DNS-Namen aktualisieren.

Löschen Sie die SSP-Dienstprinzipalnamen, da sie in SharePoint Server 2010 nicht mehr benötigt werden.

Starten Sie C2WTS (Claims to Windows Token Service, Forderungen an den Windows-Tokendienst) auf den Servern, auf denen Dienstanwendungen ausgeführt werden, für die eine Delegierung erforderlich ist (z. B. Excel Services, Visio Graphics Service).

Konfigurieren Sie für die eingeschränkte Kerberos-Delegierung Beliebiges Authentifizierungsprotokoll verwenden, um die eingeschränkte Kerberos-Delegierung mit C2WTS zu erlauben.

Stellen Sie sicher, dass die Kernelmodusauthentifizierung in IIS deaktiviert ist.

25


Konfigurieren der Kerberos-Authentifizierung: Schritt-für-Schritt-Anleitung (SharePoint Server 2010)Veröffentlichung: 02.12.10

In den folgenden Szenarioartikeln bauen wir eine SharePoint Server 2010-Umgebung auf, um zu demonstrieren, wie in einer Reihe von Szenarien, die in Unternehmen häufig vorkommen, die Delegierung konfiguriert wird. Bei den exemplarischen Vorgehensweisen wird davon ausgegangen, dass Sie eine horizontal skalierte SharePoint-Farm ähnlich der im folgenden Abschnitt beschriebenen Farm erstellen.

Hinweis:

Einige Konfigurationsschritte können variieren oder sind u. U. in bestimmten Farmtopologien nicht anwendbar. Beispielsweise unterstützt eine Installation mit einem einzelnen Server nicht den Forderungen-zu-Windows-Tokens-Dienst (C2WTS) in Windows Identity Foundation, sodass Szenarien mit Delegierung von Forderungen an Windows-Tokens in dieser Farmkonfiguration nicht möglich sind.

Umgebung und FarmtopologieDas folgende Diagramm veranschaulicht die Farmtopologie, die beim Konfigurieren der Szenarien in den folgenden Abschnitten verwendet wurde. Die Farmtopologie wurde mit Lastenausgleich konfiguriert und zwischen mehreren Ebenen horizontal skaliert, um zu demonstrieren, wie die Identitätsdelegierung in Szenarien mit mehreren Servern und in Szenarien mit mehreren Schritten funktioniert.

26


Hinweis:

Die Farmkonfiguration in den Demos ist nicht als Referenzarchitektur oder als Modell für das Entwerfen einer Topologie für Produktionsumgebungen gedacht. Beispielsweise werden in der Demo-Topologie alle SharePoint Server 2010-Dienstanwendungen auf einem einzigen Server ausgeführt, sodass für diese Dienste eine einzige Fehlerquelle vorhanden ist. Weitere Informationen zum Entwerfen und Erstellen einer SharePoint Server-Produktionsumgebung finden Sie unter SharePoint Server 2010 – physische und logische Architektur und Topologien für SharePoint Server 2010.

27





Hinweis:

Bei den exemplarischen Vorgehensweisen für die Szenarien wird davon ausgegangen, dass sich alle Computer, auf denen SharePoint Server ausgeführt wird, und die im unten beschriebenen Szenario verwendeten Datenquellen in einer einzigen Domäne befinden. Eine Erklärung und eine exemplarische Vorgehensweise zur Konfiguration mit mehreren Domänen bzw. mit mehreren Gesamtstrukturen ist nicht Gegenstand dieses Dokuments.

Spezifikation der UmgebungAlle Computer in der Demo-Umgebung werden als virtualisierte Computer unter Windows Server 2008 R2 Hyper-V ausgeführt. Die Computer gehören einer einzigen Windows-Domäne an, vmlab.local, die in den Funktionsebenen für Windows Server 2008-Gesamtstrukturen und -Domänen ausgeführt werden.

Clientcomputer

Windows 7 Professional, 64-Bit

SharePoint Server-Front-End-Webs

Windows Server 2008 R2 Enterprise, 64-Bit

Dienste:

Webanwendungsdienst

Lastenausgleich mit Windows NLB

SharePoint Server-Anwendungsserver


Microsoft SharePoint Server 2010 (RTM)

Dienste:

WIF-Forderungen-zu-Windows-Tokens-Dienst

Verwalteter Metadatendienst

SharePoint-Index

SharePoint-Abfrage

28


Excel Services

Visio-Grafikdienst

Business Connectivity Services

PerformancePoint-Dienste

SQL-Dienste


Microsoft SQL Server 2008 R2 Enterprise, 64-Bit

Aktiv-Passiv-Konfiguration

SQL Server-Dienste:

SQL Data Engine

SQL Server Analysis Services

SQL Agent

SQL-Browser

SQL Reporting Server

Windows Server 2008 R2 Enterprise, 64-Bit (RTM)

Microsoft SQL 2008 R2 Enterprise, 64-Bit (RTM)

Microsoft SharePoint Server 2010 (RTM)

Lastenausgleich mit Windows NLB

Reporting Services im integrierten SharePoint-Modus

Reporting Services im Modus für horizontale Skalierung

Spezifikation der WebanwendungIn den Szenarien in der exemplarischen Vorgehensweise wird Bezug genommen auf eine Reihe von SharePoint Server 2010-Webanwendungen, die Sie in Szenario 1 konfigurieren werden. Für die folgenden Webanwendungen wird mithilfe von Windows NLB ein Lastenausgleich zwischen den zwei SharePoint Server-Web-Front-Ends in der Demo-Umgebung durchgeführt:

29


http://sp10CA Die Webanwendung der Zentraladministration für die Farm. In Szenario 1 wird die Konfiguration dieser Webanwendung nicht Schritt für Schritt erklärt.

http://portal und https://portal Die Webanwendung mit dem Demo-Veröffentlichungsportal. Anhand dieser Webanwendung wird gezeigt, wie Sie die Delegierung für Webanwendungen konfigurieren, die auf Standardports (HTTP 80, HTTPS 443) ausgeführt werden.

http://teams:5555 Die Webanwendung mit der Demo-Teamwebsite. Anhand dieser Webanwendung wird die Konfiguration der Delegierung für Webanwendungen gezeigt, die auf nicht standardmäßigen Ports ausgeführt werden, im aktuellen Beispiel Port 5555.

30


SSL-KonfigurationIn einigen der Szenarien mit exemplarischen Vorgehensweisen wird SSL verwendet, um zu veranschaulichen, wie die Delegierung mit HTTPS konfiguriert wird. Es wird davon ausgegangen, dass die verwendeten Zertifikate von einer (internen oder öffentlichen) vertrauenswürdigen Stammzertifizierungsstelle stammen oder dass Sie alle Computer so

31


konfiguriert haben, dass den verwendeten Zertifikaten vertraut wird. Nicht erklärt wird in diesem Dokument, wie Sie die Vertrauensstellung für Zertifikate ordnungsgemäß konfigurieren oder wie Sie Probleme im Zusammenhang mit der Installation von SSL-Zertifikaten beheben. Wir empfehlen dringend, die einschlägige Dokumentation über diese Themen zu lesen und die SSL-Konfiguration zu testen, bevor Sie die eingeschränkte Kerberos-Delegierung mit SSL-geschützten Diensten konfigurieren. Weitere Informationen finden Sie unter:

Active Directory-Zertifikatdienste (Übersicht) (http://go.microsoft.com/fwlink/?LinkId=196660&clcid=0x407)

Schrittweise Anleitung zu den Windows Server Active Directory-Zertifikatdiensten (http://go.microsoft.com/fwlink/?LinkId=196661&clcid=0x407)

Konfigurieren von Serverzertifikaten in IIS 7 (http://go.microsoft.com/fwlink/?LinkId=196662&clcid=0x407)

Einrichten von SSL für IIS 7: Konfigurieren der Sicherheit : Installieren und Konfigurieren von IIS 7 (http://go.microsoft.com/fwlink/?LinkID=193447&clcid=0x407)

Hinzufügen einer Bindung zu einer Site (IIS 7) (http://go.microsoft.com/fwlink/?LinkId=196663&clcid=0x407)

Konfigurieren eines Hostheaders für eine Website (IIS 7) (http://go.microsoft.com/fwlink/?LinkId=196664&clcid=0x407) – (Verwenden von SSL mit Hostheadern)

Erstellen eines selbstsignierten Serverzertifikats in IIS 7 (http://go.microsoft.com/fwlink/?LinkId=196665&clcid=0x407)

LastenausgleichDer Lastenausgleich in den SharePoint Server-Front-End-Web und auf Servern mit SQL Server Reporting Services wurde mithilfe von Windows Server 2008-Netzwerklastenausgleich (Network Load Balancing, NLB) implementiert. Die Konfiguration von NLB und bewährte Methoden für NLB werden in diesem Dokument nicht behandelt. Weitere Informationen zu NLB finden Sie unter Netzwerklastenausgleich (Übersicht).

SQL--AliasingDie Farm wurde unter Verwendung eines SQL-Client-Alias zum Herstellen einer Verbindung zum SQL-Cluster erstellt. Dies ist eine bewährte Methode und dient zur Veranschaulichung der Kerberos-Authentifizierung bei Verwendung von SQL-Aliasing.

32











In Szenario 2 wird davon ausgegangen, dass die Umgebung auf diese Weise konfiguriert wurde. Die Verwendung von SQL-Aliasen ist jedoch keine Bedingung, um die unten beschriebenen Szenarien auszuführen. Weitere Informationen zum Konfigurieren von SQL-Aliasen finden Sie unter Vorgehensweise: Erstellen eines Serveralias für die Verwendung durch einen Client (SQL Server-Konfigurations-Manager).

SharePoint Server Services und DienstkontenIn den nachfolgenden Szenarien wird ein Modell der geringsten Rechte implementiert, bei dem jeder Dienst in der SharePoint-Farm für seine Dienstidentität ein eigenes, eindeutiges Active Directory-Konto nutzt. Dieses Modell hat Vor- und Nachteile:

Vorteile:

Der Administrator kann die Berechtigungen jedes Diensts präzise steuern Dazu zählen Domänen-, lokale und allgemeine Berechtigungen, Delegierungsrechte und andere Einstellungen.

Bessere Überwachung und Nachverfolgbarkeit Dadurch, dass jeder Dienst eine eigene Identität hat, kann der Administrator Netzwerk- und Systemaktivitäten basierend auf der in den Überwachungsdateien erfassten Identität zum jeweiligen Dienst zurückverfolgen. Wenn beispielsweise ein Überwachungsprotokoll eines Servers Anmeldeaktivitäten für ein bestimmtes Konto zeigt, kann mithilfe dieses Kontos die Aktivität zu einem bestimmten Dienst zurückverfolgt werden.

Mehr Sicherheit Durch Arbeiten mit eigenen Konten für jeden Dienst kann ein Administrator sicherstellen, dass bei Gefährdung der Sicherheit eines Kontos der potenzielle Schaden begrenzt ist, da nur der Dienst betroffen ist, der dieses gefährdete Konto verwendet. Sollte jemals die Sicherheit eines Kontos gefährdet sein, muss eine ganzheitliche Sicherheitsprüfung der gesamten Umgebung erfolgen, um zum Beseitigen des Sicherheitsproblems die geeignetste Lösung zu finden.

Nachteile:

33




Höhere Komplexität bei der Kontoverwaltung Durch die höhere Anzahl von Dienstkonten erhöht sich der Aufwand der Active Directory-Konfiguration und die Anzahl der zu erzwingenden Verwaltungsrichtlinien für Kennwörter.

Zusätzliche Konfiguration Wie die nachfolgende schrittweise Anleitung zeigt, müssen SharePoint Server-Administratoren, nachdem sie sich für das Arbeiten mit dem Modell der geringsten Rechte entschlossen haben, weitere Schritte ausführen, um die Umgebung ordnungsgemäß zu konfigurieren.

Erhöhte Verwaltungskomplexität Die Wahrscheinlichkeit von Konfigurationsfehlern steigt mit der Zunahme der Komplexität der Umgebung. Wenn Sie mit mehreren Konten arbeiten, besteht die Möglichkeit, dass bestimmte Dienste falsch konfiguriert werden, was zu Funktionsstörungen führen kann, die dann behoben werden müssen.

Beachten Sie, dass das Arbeiten mit gesonderten Dienstkonten keine Anforderung von SharePoint Server, sondern eine allgemeine Empfehlung für Produktionsumgebungen ist. In den Schritten im Rest dieses Dokuments wird erklärt, wie SharePoint Server konfiguriert wird, wenn Sie mit gesonderten Konten arbeiten. Einige dieser Schritte treffen ggf. nicht zu, wenn Sie mit gemeinsam genutzten Konten arbeiten.

Dienstidentität für den Forderungen an den Windows-Tokendienst (C2WTS)Die nachfolgenden Schritte gehen von einem Sicherheitsmodell der geringsten Rechte aus und sehen für jeden SharePoint Server-Dienst ein eigenes Dienstkonto vor. Der Forderungen an den Windows-Tokendienst (C2WTS) ist zum Erfüllen dieser Vorgabe für die Nutzung eines gesonderten Active Directory-Kontos anstatt des standardmäßigen lokalen Systemkontos konfiguriert. Wenn Sie mit einem eindeutigen Konto arbeiten, können die dem Forderungen an den Windows-Tokendienst (C2WTS) gewährten Delegierungsrechte getrennt von anderen Diensten auf dem Server verwalten, die auch das lokale Systemkonto verwenden. Dies ist keine Produktanforderung, sondern eine empfohlene Vorgehensweise.

34


Tipps zum Durcharbeiten der SzenarienDie unten beschriebenen Szenarien leiten Sie durch die verschiedenen Aktivitäten, die Sie zum Konfigurieren der Kerberos-Delegierung für verschiedene Funktionen der SharePoint Server-Plattform ausführen müssen. Beachten Sie beim Durcharbeiten der einzelnen Abschnitte Folgendes:

Bei allen Szenarien wird davon ausgegangen, dass Sie die Webanwendungen für klassische eingehende Authentifizierung (Kerberos) konfiguriert haben. Einige der Szenarien erfordern die klassische Authentifizierung, d. h. sie funktionieren nicht wie hier dokumentiert, wenn eingehende Forderungsauthentifizierung verwendet wird.

Stellen Sie zuerst sicher, dass die SharePoint Server-Dienste ohne Delegierung funktionieren, um sicherzugehen, dass die Dienstanwendungen korrekt konfiguriert sind, bevor Sie komplexere Konfigurationen mit Delegierung angehen.

Führen Sie jeden Schritt sorgfältig durch, und überspringen Sie keinen Schritt.

Führen Sie Szenario 1 durch, und arbeiten Sie mit den im Szenario genannten Tools zum Debuggen, da Sie diese in anderen Szenarien für die Ursachenanalyse bei Konfigurationsproblemen verwenden können.

Arbeiten Sie unbedingt auch Szenario 2 durch. Sie brauchen einen Computer mit SQL Server, der für Kerberos-Authentifizierung konfiguriert ist. Die Testdatenbank, die Sie in diesem Szenario erstellen, werden Sie für einige der späteren Szenarien benötigen.

Überprüfen Sie in jedem Szenario stets mithilfe von SetSPN -X und SetSPN -Q die Konfiguration der Dienstprinzipalnamen. Weitere Informationen hierzu finden Sie im Anhang.

Überprüfen Sie unbedingt die Serverereignisprotokolle und die ULS-Protokolle, wenn Sie mit dem Debuggen eines Konfigurationsproblems beginnen. In diesen Protokollen finden Sie meist gute Hinweise auf die Ursachen möglicher Probleme.

Aktivieren Sie die Diagnoseprotokollierung für SharePoint Foundation->Anspruchsauthentifizierung und jegliche Dienstanwendungen, die zu untersuchen sind, falls ein Problem auftritt.

Denken Sie daran, dass sich die Zwischenspeicherung für Dienstanwendungen auf jedes Szenario auswirken kann. Wenn Sie Änderungen an der Konfiguration vornehmen, aber keine Veränderung im Verhalten der Plattform feststellen können, starten Sie den Anwendungspool oder den Windows-Dienst des Dienstes neu. Wird das Problem dadurch behoben, hilft manchmal ein Neustart des Systems.

35


Bedenken Sie, dass Kerberos-Tickets nach der Anforderung zwischengespeichert werden. Wenn Sie ein Tool wie NetMon verwenden, um TGT- und TGS-Anforderungen anzuzeigen, müssen Sie u. U. den Ticketcache leeren, wenn der erwartete Anforderungsdatenverkehr nicht zu sehen ist. In Szenario 1, Konfigurieren der Kerberos-Authentifizierung: Kernkonfiguration (SharePoint Server 2010), wird erklärt, wie Sie diesen Schritt mithilfe der Hilfsprogramme KLIST und KerbTray ausführen.

Führen Sie NetMon unbedingt mit administrativen Berechtigungen aus, um Kerberos-Datenverkehr zu erfassen.

Bei komplexen Debuggingszenarien empfiehlt es sich u. U., die WIF-Ablaufverfolgung für den Forderungen an den Windows-Tokendienst (C2WTS) sowie für die SharePoint-Dienstanwendungen (WCF-Dienste) zu aktivieren. Weitere Informationen finden Sie in folgenden Artikeln:

WIF-Ablaufverfolgung

Vorgehensweise: Aktivieren der Ablaufverfolgung

Konfigurieren der Ablaufverfolgung

36



http://go.microsoft.com/fwlink/?LinkId=196691&clcid=0x407


Konfigurieren der Kerberos-Authentifizierung: Kernkonfiguration (SharePoint Server 2010)Veröffentlichung: 02.12.10

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 (http://support.microsoft.com/kb/969083/de-de)

In diesem Szenario führen Sie die folgenden Aufgaben aus:

Konfigurieren zweier Webanwendungen mit Standardzonen, die das Kerberos-Protokoll für die Authentifizierung verwenden

37





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

IIS Sicherstellen, dass die Kerberos-Authentifizierung aktiviert ist

38


Konfigurationsbereich Beschreibung

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

39


Schrittweise Konfigurationsanweisungen

Konfigurieren von DNSKonfigurieren 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-Webanwendungenhttp://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“.

40




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 DirectoryAls 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-WebanwendungenIn unserem Beispiel gibt es zwei SharePoint Server-Webanwendungen, die in zwei gesonderten IIS-Anwendungspools mit eigenen ausgeführten Anwendungspoolidentitäten ausgeführt werden.

41


Webanwendung (Standardzone) IIS-Anwendungspoolidentität

http://portal vmlab\svcPortal10App

http://teams:5555 vmlab\ svcTeams10App

Dienstprinzipalnamen (SPNs)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 im 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-HOST Name>

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

42





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 43


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

44


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 DienstkontenJe 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:

45


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:

46


Prinzipaltyp Prinzipalname Erforderliche Stellvertretungen

User svcPortal10App HTTP/Portal

HTTP/Portal.vmlab.local

HTTP/Teams


HTTP/Teams:5555


User svcTeams10App HTTP/Portal

HTTP/Portal.vmlab.local

HTTP/Teams


HTTP/Teams:5555


47


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.

48


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.

49


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.

50


Klicken Sie im Dialogfeld Dienste hinzufügen auf Alles markieren 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.

51


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 ServerNachdem Active Directory und DNS konfiguriert wurden, kann die Webanwendung in Ihrer SharePoint Server 2010-Farm erstellt werden. In diesem Artikel wird an dieser

52


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

53



Konto Zweck

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-SuchdienstanwendungIn 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 WebanwendungWechseln Sie zur Zentraladministration, und wählen Sie im Abschnitt Anwendungsverwaltung die Option Webanwendungen verwalten aus. Klicken Sie auf

54



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 Aushandeln 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: Aushandeln

Anonymen Zugriff zulassen: Nein

Secure Socket Layer verwenden: Nein

Authentifizierungsanbieter: Aushandeln

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

55


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.

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.

56


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

57


Erstellen von WebsitesammlungenZum 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 ZugriffszuordnungenDie 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.

58




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.

59


7. Klicken Sie auf Speichern.

Die HTTPS-URL sollte nun in der Zonenliste der Webanwendung enthalten sein.

IIS-Konfiguration

Installieren von SSL-ZertifikatenSie 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.

60


4. Windows-Authentifizierung muss aktiviert sein.

5. Wählen Sie rechts unter Aktionen den Eintrag Anbieter aus. Vergewissern Sie sich, dass Negotiate der oberste Listeneintrag ist.

61


Sicherstellen, dass die Kernelmodusauthentifizierung deaktiviert istDie 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.

62


Konfigurieren der FirewallStellen 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-StandardportsIn 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:

63


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

64


Testen der BrowserauthentifizierungNach 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

65




Bildlauf nach unten durch, und prüfen Sie, ob Automatisches Anmelden nur in der Intranetzone aktiviert ist.

Führen Sie einen Bildlauf nach unten durch, und prüfen Sie, ob Automatisches Anmelden nur in der Intranetzone aktiviert ist.

66


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 unter Internetoptionen->Sicherheit->Intranetzone->Sites die Option Intranetnetzwerk automatisch ermitteln aktiviert ist.

67


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

68


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-WebserversWenn die Kerberos-Authentifizierung ordnungsgemäß funktioniert, werden auf den Front-End-Webservern in den Sicherheitsereignisprotokollen Anmeldeereignisse mit der Ereignis-ID 4624 angezeigt.

69


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.

70


KListKList 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

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

71




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

72


73


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

74




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.

75


Im Inspektorfenster von Fiddler sehen Sie in der Ansicht „Auth“ auch das Kerberos-Ticket in der Anforderung und die Kerberos-Antwort:

76


Bei erfolgreicher Authentifizierung sendet der Server die angeforderte Ressource zurück.

NetMon 3.4NetMon 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

77




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.

78



a. Die ersten beiden Frames sind die ursprüngliche Anforderung und Antwort, wobei der Client und der Server die Verwendung von Kerberos für die Authentifizierung aushandeln.

b. Die folgenden Kerberos 5-Frames sind die Clientanforderungen des Ticket Granting Tickets für den Bereich „VMLAL.Local“ und der Kerberos-Diensttickets für den Dienstprinzipalnamen (SPN) „HTTP/portal.VMLAB.local“.

c. Die letzten HTTP-Frames gehören schließlich zum Client, der die Diensttickets verwendet, um sich beim Webserver zu authentifizieren, und zum Server, der den Client erfolgreich authentifiziert und die Antwort zurückgibt.

Testen der Kerberos-Authentifizierung über SSLZum 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 Forderungen an den Windows-Tokendienst (C2WTS)).

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.

79


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

80


Hochladen von Beispielinhalten und Durchführen einer DurchforstungLaden 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 SucheBei erfolgreicher Indizierung sollten der Index durchsuchbare Elemente und das Durchforstungsprotokoll keine Fehler enthalten.

81


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.

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.

82


Testen der Front-End-WebserverdelegierungAls 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 WebsitesammlungBei 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.

83




Führen Sie diesen Schritt für jede Websitesammlung aus.

84


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.

85


Kerberos-Authentifizierung für SQL OLTP (SharePoint Server 2010)Veröffentlichung: 02.12.10

In diesem Szenario wird das Konfigurieren der Kerberos-Authentifizierung für den SQL Server-Cluster in der Beispielumgebung veranschaulicht. Im Anschluss wird die Authentifizierung von SharePoint Server-Diensten beim Cluster mit dem Kerberos-Protokoll überprüft.

In diesem Szenario führen Sie folgende Schritte aus:

Konfigurieren eines bestehenden SQL Server 2008 R2-Clusters für die Kerberos-Authentifizierung

Sicherstellen, dass der Client sich mithilfe von Kerberos-Authentifizierung beim Cluster authentifizieren kann

Erstellen einer Testdatenbank und von Beispieldaten für spätere Szenarien

86


Hinweis:

Es ist nicht erforderlich, die Kerberos-Authentifizierung für SQL Server für zentrale Datendienste von SharePoint Server (beispielsweise Verbindungen zu Plattformdatenbanken) zu verwenden. Die Beispielumgebung verfügt lediglich über einen SQL Server-Cluster, auf dem zusätzliche Beispieldatenbanken für spätere Szenarien gehostet werden. Damit die Delegierung in diesen Szenarien ordnungsgemäß funktioniert, müssen vom SQL Server-Cluster mit Kerberos authentifizierte Verbindungen akzeptiert werden.

Hinweis:



Checkliste für die Konfiguration


Konfigurieren von DNS DNS (A)-Hosteinträge für die IP-Adresse des SQL Server-Clusters erstellen

Konfigurieren von Active Directory

Dienstprinzipalnamen (SPN) für den SQL Server-Dienst erstellen

Überprüfen der SQL Server-Kerberos-Konfiguration

SQL-Verbindungsmetadaten mit SQL Server Management Studio abfragen, um die Verwendung des Kerberos-Authentifizierungsprotokolls sicherzustellen

87





Details der Szenarioumgebung

In diesem Szenario wird eine SharePoint Server-Farm veranschaulicht, die für Verwendung eines SQL-Alias in einer Verbindung mit einem SQL Server-Cluster konfiguriert wurde, der für die Verwendung der Kerberos-Authentifizierung konfiguriert ist.


Konfigurieren von DNSKonfigurieren Sie das DNS für den SQL Server-Cluster in Ihrer Umgebung. Konfigurieren Sie das DNS für den SQL Server-Cluster in Ihrer Umgebung. In diesem Beispiel wird ein SQL Server-Cluster (MySqlCluster.vmlab.local) verwendet, der auf Port 1433 unter der Cluster-IP-Adresse 192.168.8.135/4 ausgeführt wird. Der Cluster ist Aktiv/Passiv, und das SQL Server-Datenbankmodul wird in der Standardinstanz des ersten Knotens ausgeführt.


In diesem Beispiel wurde ein DNS (A)-Eintrag für den SQL Server-Cluster konfiguriert.

88




Hinweis:

Da SQL Server-SPNs einen Instanzennamen enthalten (wenn die zweite benannte Instanz auf dem gleichen Computer verwendet wird), kann der DNS-Host für den Cluster rein technisch als CNAME-Alias registriert und so das in Anhang A, Bekannte Kerberos-Konfigurationsprobleme (SharePoint Server 2010), beschriebene CNAME-Problem vermieden werden. Wenn Sie CNAME-Einträge verwenden möchten, sollten Sie mithilfe des DNS (A)-Eintragshostnamens für die CNAME-Aliase einen SPN registrieren.

Konfigurieren von Active DirectoryDamit die Kerberos-Authentifizierung für Clients von SQL Server verwendet werden kann, müssen Sie einen Dienstprinzipalnamen (SPN) für das Dienstkonto registrieren, mit dem SQL Server ausgeführt wird. Dienstprinzipalnamen für das SQL Server-Datenbankmodul weisen bei Konfigurationen, die die Standardinstanz anstelle der benannten SQL Server-Instanz verwenden, folgendes Format auf:

89


MSSQLSvc/<FQDN>:Port

Weitere Informationen zum Registrieren von Dienstprinzipalnamen für SQL Server 2008 finden Sie unter Registrieren eines Dienstprinzipalnamens.

Im Beispiel wurde der SQL Server-SPN im Dienstkonto des SQL Server-Datenbankmoduls (vmlab\svcSQL) mit dem folgenden SetSPN-Befehl konfiguriert:

SetSPN -S MSSQLSVC/MySQLCluster.vmlab.local:1433 vmlab\svcSQL

Benannte SQL Server-InstanzenWenn Sie anstelle der Standardinstanz benannte SQL Server-Instanzen verwenden, müssen Sie Dienstprinzipalnamen speziell für die SQL Server-Instanz und für den SQL Server-Browser-Dienst registrieren. Weitere Informationen zum Konfigurieren der Kerberos-Authentifizierung für benannte Instanzen finden Sie unter:

Registrieren eines Dienstprinzipalnamens

Ein SPN für den SQL Server-Browser-Dienst ist erforderlich, wenn Sie eine Verbindung zu einer benannten Instanz von SQL Server Analysis Services oder SQL Server herstellen

SQL-AliaseEine bewährte Vorgehensweise beim Erstellen einer Farm besteht darin, SQL-Aliase für Verbindungen zum SQL Server-Computer zu verwenden. Das Kerberos-Format des SPN bleibt bei der Verwendung von SQL-Aliasen unverändert. Sie verwenden auch weiterhin den registrierten DNS-Hostnamen (A-Eintrag) im SPN für SQL Server. Wenn Sie beispielsweise den Alias „SPFARMSQL“ für „MySQLCluster.vmlab.local“ registrieren, lautet der SPN für die Verbindung mit SPFarmSQL weiterhin „MSSQLSVC/MySQLCluster.vmlab.local:1433“.

Überprüfen der SQL Server-Kerberos-KonfigurationNachdem das DNS und die Dienstprinzipalnamen konfiguriert wurden, können Sie die Computer mit SharePoint Server neu starten und überprüfen, ob die Authentifizierung der SharePoint Server-Dienste für SQL Server jetzt mit dem Kerberos-Protokoll durchgeführt wird.

90







So überprüfen Sie die Clusterkonfiguration

1. Starten Sie die Computer mit SharePoint Server neu – Dadurch werden alle Dienste neu gestartet und gezwungen, das Herstellen der Verbindung sowie die Authentifizierung unter Verwendung des Kerberos-Protokolls zu wiederholen.

2. Öffnen Sie SQL Server Management Studio, und führen Sie folgende Abfrage aus:

Select s.session_id,s.login_name,s.host_name,c.auth_scheme

fromsys.dm_exec_connections cinner joinsys.dm_exec_sessions son c.session_id = s.session_id

Die Abfrage gibt Metadaten zu den einzelnen Verbindungen und Sitzungen zurück. Mithilfe der Sitzungsdaten können die Verbindungsquelle sowie das Authentifizierungsschema für die Verbindung identifiziert werden.

3. Vergewissern Sie sich, dass die SharePoint Server-Dienste mit dem Kerberos-Protokoll authentifiziert werden.

4. Wenn die Kerberos-Authentifizierung ordnungsgemäß konfiguriert wurde, finden Sie in der Spalte auth_scheme der Abfrage den Eintrag Kerberos.

91


Erstellen einer SQL Server-Testdatenbank sowie einer TesttabelleUm die Delegierung für die verschiedenen SharePoint Server-Dienstanwendungen zu testen, die in den Szenarien in diesem Dokument behandelt werden, müssen Sie eine Testdatenquelle konfigurieren, auf die die Dienste zugreifen können. Zum Abschluss dieses Szenarios konfigurieren Sie die Testdatenbank „Test“ und die Testtabelle „Sales“ für die spätere Verwendung.

1. Erstellen Sie in SQL Server Management Studio die neue Datenbank „Test“ mit den Standardeinstellungen.

2. Erstellen Sie in der Datenbank „Test“ eine neue Tabelle mit dem folgenden Schema:

Spaltenname Datentyp NULL-Werte zulassen

Region nvarchar(10) Nein

Jahr nvarchar(4) Nein

Betrag money Nein

RowId int Nein

3. Speichern Sie die Tabelle unter dem Namen „Sales“.

4. Füllen Sie die Tabelle in Management Studio mit den Testdaten. Die Daten selbst spielen keine Rolle und wirken sich nicht auf die Funktion späterer Szenarien aus. Es werden nur wenige Datenzeilen benötigt. In der Beispielumgebung wurde die Tabelle mit den folgenden Daten aufgefüllt:

92


93


Kerberos-Authentifizierung für SQL Server Analysis Services (SharePoint Server 2010)Veröffentlichung: 02.12.10

In diesem Szenario führen Sie die folgenden Aufgaben aus:

Konfigurieren der Analysis Services-Instanzen im Servercluster mit SQL Server 2008 R2 für die Verwendung von Kerberos-Authentifizierung

Sicherstellen, dass der Client sich mithilfe von Kerberos-Authentifizierung beim Cluster authentifizieren kann

Das Aktivieren der Kerberos-Authentifizierung für SQL Server Analysis Services ist ähnlich wie bei SQL Server.

Hinweis:




Konfigurieren von Active Directory

Dienstprinzipalnamen (Service Principal Names, SPNs) für die Analysis Services-Instanz erstellen

SQL-Kerberos-Konfiguration überprüfen

Verbindung mit der Analysis Services-Instanz in Excel 2010 herstellen

94






Konfigurieren von Active DirectoryDamit die Kerberos-Authentifizierung für Clients von SQL Server Analysis Services verwendet werden kann, müssen Sie einen Dienstprinzipalnamen (SPN) für das Dienstkonto registrieren, mit dem SQL Server ausgeführt wird. Der Dienstprinzipalname für eine standardmäßige Analysis Services-Instanz hat das folgende Format:

MSOLAPSvc.3/<FQDN>

Wenn Sie eine benannte Instanz von Analysis Services verwenden, denken Sie daran, dass Sie nach dem Doppelpunkt keinen Port angeben können. Wenn Sie dies tun, wird er als Teil des Host- oder Domänennamens interpretiert. Sie müssen stattdessen den tatsächlichen Namen der Instanz verwenden, damit alle Funktionen ordnungsgemäß arbeiten.

MSOLAPSvc.3/<FQDN>:Instanzname

Weitere Informationen zum Registrieren von Dienstprinzipalnamen für SQL Server 2008 finden Sie unter http://support.microsoft.com/kb/917409/de-de.

Bei diesem Szenario wird von einer standardmäßigen Analysis Services-Instanz ausgegangen. Wir konfigurieren den Dienstprinzipalnamen für Analysis Services auf dem Analysis Services-Dienstkonto (vmlab\svcSQLAS) mit dem folgenden SetSPN-Befehl:

SetSPN -S MSOLAPSvc.3/MySQLCluster.vmlab.local vmlab\svcSQLAS

Benannte SQL Server-InstanzenWenn Sie anstelle der Standardinstanz benannte SQL Server-Instanzen verwenden, müssen Sie Dienstprinzipalnamen speziell für die SQL Server-Instanz und für den SQL Server-Browser-Dienst registrieren. Weitere Informationen zum Konfigurieren der Kerberos-Authentifizierung für benannte Instanzen finden Sie unter:

Registrieren eines Dienstprinzipalnamens

Ein SPN für den SQL Server-Browser-Dienst ist erforderlich, wenn Sie eine Verbindung zu einer benannten Instanz von SQL Server Analysis Services oder SQL Server herstellen

95







Überprüfen der SQL Server-Kerberos-KonfigurationNachdem Sie den Dienstprinzipalnamen konfiguriert haben, überprüfen Sie die Kerberos-Verbindung zum Cluster mithilfe von Excel 2010.

1. Öffnen Sie Excel 2010 auf dem Clientcomputer mithilfe eines Domänenkontos, das Zugriff auf mindestens eine Datenbank in der Analysis Services-Instanz hat. Öffnen Sie außerdem eine Datenverbindung zur Analysis Services-Instanz, indem Sie auf die Registerkarte Daten, dann auf Aus anderen Quellen und anschließend auf Von Analysis Services klicken.

2. Geben Sie im Datenverbindungs-Assistent im Feld Servername den Befehl MySQLCluster ein, und klicken Sie auf Weiter. Wenn die Kerberos-Authentifizierung funktioniert, sehen Sie jetzt alle Datenbanken, die Sie entsprechend Ihrer Berechtigungen bereits sehen dürfen.

96


Hinweis:

Wenn Sie die AdventureWorks 2008 R2-Beispieldatenbanken verwenden möchten, laden Sie sie von der Website Microsoft SQL Server-Community-Projekte und -Beispiele herunter, und befolgen Sie die Installationsanweisungen.

3. Öffnen Sie die Ereignisanzeige auf dem Datenbankserver (vmsql2k8r2-01). Im Sicherheitsprotokoll sollten Sie jetzt einen Eintrag für die erfolgreiche Überwachung sehen, ähnlich dem Eintrag in den Überprüfungsschritten für Szenario 2, Kerberos-Authentifizierung für SQL OLTP (SharePoint Server 2010).

97



98


Identitätsdelegierung für SQL Server Reporting Services (SharePoint Server 2010)Veröffentlichung: 02.12.10

In diesem Szenario konfigurieren Sie zwei Server mit SQL Server Reporting Services (SSRS) mit Lastenausgleich in einer horizontal skalierten Konfiguration, die im integrierten SharePoint-Modus ausgeführt wird. Die Server sind so konfiguriert, dass sie Kerberos-Authentifizierung akzeptieren und delegieren die Authentifizierung an einen Back-End-Servercluster mit SQL Server.

Die SharePoint Server-Farm und die Reporting Services-Datenquelle befinden sich beide in der gleichen Domäne. Daher konfigurieren wir in diesem Szenario eingeschränkte Kerberos-Delegierung, um die Identitätsdelegierung an die Back-End-Datenquelle zu ermöglichen. Wenn Sie sich bei Datenquellen in anderen Domänen in der gleichen Gesamtstruktur authentifizieren müssen, müssen Sie einfache (nicht eingeschränkte) Kerberos-Delegierung konfigurieren. Denken Sie daran, dass Reporting Services den Forderungen-zu-Windows-Tokens-Dienst (C2WTS) nicht nutzt und daher einfache Delegierung verwenden kann.

Hinweis:



99





Voraussetzungen für dieses Szenario Szenario 1: Kernkonfiguration


(Optional) Szenario 3: Kerberos-Authentifizierung für SQL Server Analysis Services



Active Directory Erstellen eines SSRS-Dienstkontos

Eingeschränkte Kerberos-Delegierung konfigurieren

SQL Server Reporting Services

SSRS im Modus für horizontale Skalierung mit Lastenausgleich installieren und konfigurieren

Web.Config ändern

Ändern von „ReportingServer.config“

Konfigurieren von SharePoint Server

Integration von Reporting Services konfigurieren

Der Integration einen Berichtsserver hinzufügen

Festlegen von Standardwerten für Server

Überprüfen der Konfiguration

Erstellen einer Dokumentbibliothek für Berichte

Websitesammlungseinstellungen für Reporting Services konfigurieren

Einen Testbericht in SQL Server Business Intelligence Development Studio erstellen und veröffentlichen

Anzeigen des Testberichts in Internet Explorer

100



In diesem Szenario sind die Anwendungspool-Dienstkonten für Internetinformationsdienste (Internet Information Services, IIS) so konfiguriert, dass eine Delegierung an den Dienst SQL Server Reporting Services (SSRS) erfolgt. Das SSRS-Dienstkonto ist für die Delegierung von Anmeldeinformationen an den SQL Server-Dienst konfiguriert. Beachten Sie, dass SQL Server Reporting Services im integrierten SharePoint-Modus keine Forderungsauthentifizierung zwischen Farmen verwendet und daher Kerberos-Authentifizierung für die delegierte Authentifizierung erfordert. Weitere Informationen finden Sie unter Anspruchsauthentifizierung und Reporting Services.

Domänenübergreifende Kerberos-DelegierungIm aktuellen Beispiel befindet sich die Datenquelle, mit der SSRS eine Verbindung herstellt, in der gleichen Domäne wie die SSRS-Server. In bestimmten Situationen ist es vielleicht erforderlich, auf Datenquellen außerhalb der Domäne zuzugreifen, in der sich SSRS befindet. Für die Authentifizierung mit domänenübergreifender Delegierung müssen Sie auf dem SSRS-Dienstkonto einfache (nicht eingeschränkte) Delegierung konfigurieren. Denken Sie daran, dass dies möglich ist, weil der SSRS-Dienst den Forderungen-zu-Windows-Tokens-Dienst (C2WTS) nicht verwendet und daher kein Protokollübergang über eingeschränkte Kerberos-Delegierung erforderlich ist. Beachten

101



Sie auch, dass gesamtstrukturübergreifende Delegierung nicht möglich ist, auch nicht bei einfacher Delegierung.


Konfigurieren von DNSKonfigurieren Sie DNS für die SSRS-NLB-Servergruppe (Network Load Balancing) in der vorgesehenen Umgebung. In diesem Beispiel werden zwei SSRS-Server verwendet, VMSSRS01 und VMSSRS02, für die ein Lastenausgleich durchgeführt wird und die zur gleichen NLB-VIP (192.168.24.180/24) aufgelöst werden. Die VIP wird auf den Host „FarmReports“ abgebildet und hat die URL http://FarmReports.


Konfigurieren Sie einen neuen DNS-A-Eintrag für den SSRS-Host. Im aktuellen Beispiel wird der Host „FarmReports“ so konfiguriert, dass er zu der VIP mit Lastenausgleich aufgelöst wird.

102




Active Directory-Verzeichnisdienst

Erstellen eines SSRS-DienstkontosEs wird empfohlen, SQL Server Reporting Services unter seiner eigenen Domänenidentität auszuführen. Bei diesem Beispiel wurden die folgenden Konten erstellt:

Dienst Dienstidentität

SQL Server Reporting Services vmlab\svcSQLRS

Konfigurieren von DienstprinzipalnamenDamit SSRS mithilfe von Kerberos-Authentifizierung eine Verbindung zu externen Datenquellen herstellt und bei diesen Datenquellen eine Authentifizierung durchführt, müssen für die Dienstkonten des Berichtsserver-Webdiensts und des Berichts-Managers und für das Dienstkonto für die externe Datenquelle Dienstprinzipalnamen konfiguriert sein. Informationen zum Konfigurieren und Validieren der erforderlichen Dienstprinzipalnamen für die Dienstkonten der SharePoint Server-Webanwendungen und von SQL Server finden Sie in den Szenarien 1 und 2 (Kernkonfiguration und Kerberos-Authentifizierung für SQL OLTP) in dieser Artikelreihe. Für die SSRS-Server wurden die folgenden Dienstprinzipalnamen definiert:

DNS-Host IIS-Anwendungspoolidentität Dienstprinzipalnamen

FarmReports.vmlab.local vmlab\svcSQLRS HTTP/FarmReports

HTTP/FarmReports.vmlab.local

In diesem Beispiel wurden die folgenden Befehle ausgeführt:

SetSPN -S HTTP/FarmReports vmlab\svcSQLRS

SetSPN -S HTTP/FarmReports.vmlab.local vmlab\svcSQLRS

103


Konfigurieren der DelegierungKerberos-Delegierung muss konfiguriert werden, damit SSRS die Identität des Clients an die Back-End-Datenquelle delegiert. In diesem Beispiel fragt SSRS Daten aus einer transaktionalen SQL Server-Datenbank unter Verwendung der Identität des Clients ab. Deshalb ist Kerberos-Delegierung erforderlich. Die eingeschränkte Kerberos-Delegierung ist in diesem Szenario keine Notwendigkeit (weil kein Protokollübergang erforderlich ist), es empfiehlt sich aber im Sinne einer Best Practice, sie zu konfigurieren.

Das SSRS-Dienstkonto, unter dem die SSRS-Dienste ausgeführt werden, muss vertrauenswürdig sein, damit die Anmeldeinformationen an die einzelnen Back-End-Dienste delegiert werden. In unserem Beispiel werden die folgenden Delegierungspfade benötigt:

Prinzipaltyp Prinzipalname Dienst, an den delegiert wird

User Vmlab\svcPortal10App HTTP/FarmReports

HTTP/FarmReports.vmlab.local

User Vmlab\svcSQLRS MSSQLSVC/MySqlCluster.vmlab.local:1433

Optional können Sie die folgenden Delegierungspfade konfigurieren, wenn Berichte mit Analysis Services-Datenquellen ausgeführt werden sollen:

Prinzipaltyp Prinzipalname Dienst, an den delegiert wird

User Vmlab\svcSQLRS MSOLAPSvc.3/MySqlCluster.vmlab.local

So konfigurieren Sie die eingeschränkte Delegierung

1. Öffnen Sie in Active Directory-Benutzer und -Computer die Eigenschaften des Active Directory-Objekts.

2. Navigieren Sie zur Registerkarte Delegierung.

104


3. Wählen Sie Benutzer bei Delegierungen angegebener Dienste vertrauen aus.

Hinweis:

Wenn Sie eine Authentifizierung bei Datenquellen innerhalb derselben Gesamtstruktur, aber außerhalb der Domäne, in der sich der SSRS-Server befindet, durchführen müssen, konfigurieren Sie für das SSRS-Dienstkonto einfache Delegierung statt eingeschränkter Delegierung. Dazu wählen Sie die Option Computer bei Delegierungen aller Dienste vertrauen. Denken Sie daran, dass eine gesamtstrukturübergreifende Kerberos-Delegierung nicht möglich ist.

4. Wählen Sie optional Beliebiges Authentifizierungsprotokoll verwenden aus. Dadurch wird der Protokollübergang aktiviert.

105


5. Klicken Sie auf die Schaltfläche Hinzufügen, um den Dienstprinzipal auszuwählen, an den delegiert werden kann.

6. Klicken Sie auf Benutzer und Computer.

7. Wählen Sie das Dienstkonto aus, unter dem der Dienst ausgeführt wird, an den die Delegierung erfolgen soll. Im aktuellen Beispiel ist dies das Dienstkonto für SQL Server Reporting Services.

106


Hinweis:

Dem ausgewählten Dienstkonto muss ein Dienstprinzipalname zugeordnet sein. In unserem Beispiel war der Dienstprinzipalname für dieses Konto (HTTP/FarmReports.vmlab.local) in einem früheren Schritt in diesem Szenario konfiguriert worden.

8. Klicken Sie auf OK. Anschließend werden Sie aufgefordert, auf der folgenden Seite die Dienstprinzipalnamen auszuwählen, an die delegiert werden soll.

9. Wählen Sie den Dienst aus, oder wählen Sie Alles markieren aus, und klicken Sie auf OK.

Die ausgewählten Dienstprinzipalnamen sollten nun in der Liste Dienste, für die dieses Konto delegierte Anmeldeinformationen verwenden kann angezeigt werden:

107


10. Wiederholen Sie diese Schritte für jeden Delegierungspfad, der weiter oben in diesem Abschnitt angegeben wurde. Sie müssen die Delegierung vom SQL Server Reporting Services-Dienstkonto zu einer oder mehreren Back-End-Datenquellen (in unseren Szenarien SQL OLTP oder SQL AS) konfigurieren.

108


Hinweis:

Wenn Sie eine Authentifizierung bei Datenquellen innerhalb derselben Gesamtstruktur, aber außerhalb der Domäne, in der sich der SSRS-Server befindet, durchführen müssen, konfigurieren Sie für das SSRS-Dienstkonto einfache Delegierung statt eingeschränkter Delegierung. Dazu wählen Sie die Option Computer bei Delegierungen aller Dienste vertrauen. Denken Sie daran, dass eine gesamtstrukturübergreifende Kerberos-Delegierung nicht möglich ist.

Überprüfen des MSSQLSVC-Dienstprinzipalnamens für das Dienstkonto, unter dem der Dienst auf dem Server mit SQL Server ausgeführt wird (Szenario 2)Stellen Sie sicher, dass der Dienstprinzipalname für das Analysis Services-Dienstkonto (vmlab\svcSQL) vorhanden ist, indem Sie den folgenden SetSPN-Befehl verwenden:

SetSPN -L vmlab\svcSQL

Folgendes sollte angezeigt werden:

MSOLAPSvc.3/MySqlCluster

MSSQLSVC/MySqlCluster.vmlab.local:1433

Überprüfen des MSOLAPSvc.3-Dienstprinzipalnamens für das Dienstkonto, unter dem der SSAS-Dienst auf dem Server mit SQL Server Analysis Services ausgeführt wird (Szenario 3)Stellen Sie sicher, dass der Dienstprinzipalname für das SQL Server-Dienstkonto (vmlab\svcSQLAS) vorhanden ist, indem Sie den folgenden SetSPN-Befehl verwenden:

SetSPN -L vmlab\svcSQLAS



MSOLAPSvc.3/MySqlCluster.vmlab.local

109


SQL Server Reporting Services

Installieren von SharePoint Server 2010Für SQL Server Reporting Services muss SharePoint Server 2010 auf jedem SSRS-Server installiert sein, damit SSRS im integrierten SharePoint-Modus ausgeführt wird. Installieren Sie SharePoint Server 2010 auf jedem Berichtsserver, und fügen Sie jeden Server der SharePoint Server-Farm hinzu.

Installieren und konfigurieren von SSRS im Modus für horizontale Skalierung mit LastenausgleichEine detaillierte Schritt-für-Schritt-Anleitung zum Konfigurieren von SQL Server Reporting Services im Modus für horizontale Skalierung mit Lastenausgleich würde den Rahmen dieses Dokuments sprengen. Ausführliche Anweisungen zum Installieren von SSRS finden Sie unter Bereitstellungstopologien für Reporting Services im integrierten SharePoint-Modus. Führen Sie nach der Installation von SSRS die unten beschriebenen zusätzlichen Schritte zur Konfiguration von SSRS aus, um die Installation abzuschließen.

Ändern von „Web.config“ auf den SSRS-ServernDie folgenden Änderungen müssen an den web.config-Dateien auf jedem SSRS-Server vorgenommen werden. Die Datei web.config befindet sich im Verzeichnis Programme, in dem SSRS installiert ist:

Hinzufügen des Elements <machineKey>

Für SSRS-Server in einer Konfiguration mit Lastenausgleich muss auf allen Servern der gleiche Computerschlüssel festgelegt sein. Fügen Sie das Computerschlüsselelement als untergeordnetes Element des Elements <system.web> in der Datei web.config hinzu. Im Folgenden ein Beispiel für einen Computerschlüssel:

<machineKey validationKey="54AEBD3BC893726E9B84D30F4970CB58F2086C2DAEE2F8D34A65A0632F4676DDBBC38779F2972C6596931E 13BD07A772BD4B9395BE38A43E461079E45D594E53" decryptionKey="" validation="SHA1" decryption="AES" />

110




Wichtig:

VERWENDEN SIE DEN BEISPIELCOMPUTERSCHLÜSSEL NICHT IN IHRER UMGEBUNG. Generieren Sie für Ihre Umgebung eigene Schlüsselwerte.

Ändern von „ReportingServer.config“Die folgenden Änderungen müssen an den ReportingServer.config-Dateien auf jedem SSRS-Server vorgenommen werden. Die Datei ReportingServer.config befindet sich im Verzeichnis Programme, in dem SSRS installiert ist:

Aktivieren der Kerberos-Authentifizierung

Zum Aktivieren der Kerberos-Authentifizierung legen Sie den Authentifizierungstyp auf „RSWindowsNegotiate“ fest. Ändern Sie das Element <AuthenticationTypes/>

und fügen Sie <RSWindowsNegotiate/> hinzu

<AuthenticationTypes> <RSWindowsNegotiate/> </AuthenticationTypes>

Ändern des URL-Stamms

Fügen Sie die URL für den Berichtsserver dem Tag <UrlRoot> im Tag <service> von ReportingServer.Config hinzu.

<UrlRoot>http://FarmReports/reportserver</UrlRoot>

Konfigurieren von „BackConnectionHostNames“ in der RegistrierungDamit SQL Server Reporting Services sich gegenseitig auf einem einzigen Computer authentifizieren können, muss NTLM-Loopbackerkennung adressiert werden. Es empfiehlt sich, anstatt die Loopbackerkennung zu deaktivieren, den „BackConnectionHostNames“-Wert in der Registrierung jedes SSRS-Servers zu konfigurieren. Weitere Informationen zu BackConnectionHostNames finden Sie unter

111


Wenn Sie SQL Server 2008 Reporting Services verwenden, wird die folgende Fehlermeldung angezeigt:.

Im aktuellen Beispiel konfigurieren wir die folgenden Werte für BackConnectionHostNames:

FarmReports

FarmReports.vmlab.local

Nachdem Sie die Werte für BackConnectionHostNames festgelegt haben, starten Sie den SSRS-Server neu.

Konfigurieren von SharePoint ServerIn der Zentraladministration finden Sie die Farmkonfigurationsoptionen für SSRS. Beachten Sie, dass Sie in SharePoint Server 2010 keine separate SSRS-Komponenteninstallation für SSRS-Administration und Webparts installieren müssen. Die SSRS-Farmoptionen finden Sie in der Zentraladministration im Abschnitt Allgemeine Anwendungseinstellungen unter Reporting Services.

112




Erteilen von Berechtigungen zur Inhaltsdatenbank der Webanwendung für das Reporting Services-DienstkontoEin erforderlicher Schritt beim Konfigurieren von SQL Server Reporting Services im integrierten SharePoint-Modus besteht darin, dem Reporting Services-Dienstkonto Zugriff auf die Inhaltsdatenbanken für Webanwendungen zu gewähren, die Berichte hosten. In unserem Beispiel erteilten wir dem Reporting Services-Konto mithilfe von Windows PowerShell Zugriff auf die Inhaltsdatenbank der Webanwendung „Portal“.

Führen Sie den folgenden Befehl an der SharePoint 2010-Verwaltungsshell aus:

$w = Get-SPWebApplication -Identity http://portal

$w.GrantAccessToProcessIdentity("vmlab\svcSQLRS")

Konfigurieren der Integration von Reporting ServicesGeben Sie im Dialogfeld Reporting Services-Integration die Lastenausgleichs-URL des Berichtsservers an. Wählen Sie außerdem die Option Feature in allen vorhandenen Sammlungen aktivieren, damit das Reporting Services-Feature automatisch in den Websitesammlungen aktiviert wird.

113


Hinzufügen der einzelnen Berichtsserver zur IntegrationGeben Sie im Dialogfeld Berichtsserver zur Integration hinzufügen jeden Knoten der Reporting Services-NLB-Gruppe an. Sie müssen dieses Dialogfeld für jeden Server öffnen, den Sie der Integration hinzufügen. Es besteht keine Möglichkeit, mehrere Server in einem einzigen Arbeitsschritt hinzuzufügen.

Festlegen von Standardwerten für ServerDie SSRS-Integration sollte jetzt konfiguriert sein. Zum Überprüfen der Konfiguration öffnen Sie die Seite Serverstandardwerte. Für das Beispiel im vorliegenden Dokument sind keine Änderungen erforderlich.

114


Überprüfen der Konfiguration

Erstellen einer Dokumentbibliothek für BerichteErstellen Sie eine Dokumentbibliothek zum Hosten von SSRS-Berichten in der SharePoint-Website. Im aktuellen Beispiel wird davon ausgegangen, dass eine Dokumentbibliothek namens „Reports“ unter http://portal/reports vorhanden ist.

115


Validieren der Websitesammlungseinstellungen für Reporting ServicesNavigieren Sie im Browser zu den Websiteeinstellungen der Website, von der die Dokumentbibliothek für SSRS-Berichte gehostet wird. In den Websiteeinstellungen sollte eine neue Kategorie namens Reporting Services angezeigt werden.

Wenn Sie das Feature Reporting Services nicht in der Liste der Websitesammlungsfeatures sehen, müssen Sie es u. U. über die Zentraladministration aktivieren. Weitere Informationen finden Sie unter Vorgehensweise: Aktivieren der Berichtsserverfunktion in der SharePoint-Zentraladministration (http://go.microsoft.com/fwlink/?LinkId=196878&clcid=0x407).

Klicken Sie auf den Link für die Websiteeinstellungen für Reporting Services, um sich zu vergewissern, dass Sie auf die Einstellungen zugreifen können.

116




Hinweis:

Für die vorliegende Demo sind keine Änderungen an den Reporting Services-Websiteeinstellungen erforderlich.

Erstellen und Veröffentlichen eines Testberichts in SQL Server Business Intelligence Development StudioNachdem Sie SSRS und die Integration in SharePoint Server konfiguriert haben, erstellen Sie einen Testbericht, um sicherzustellen, dass die Identitätsdelegierung ordnungsgemäß funktioniert.

1. Öffnen Sie SQL Server Business Intelligence Development Studio. Klicken Sie auf Datei, zeigen Sie auf Neu, und klicken Sie dann auf Projekt.

117


2. Wählen Sie Berichtsserverprojekt-Assistent aus, und geben Sie einen Projektnamen ein.

3. Konfigurieren Sie als Nächstes eine neue Datenquelle. Wählen Sie den Typ Microsoft SQL Server aus, und klicken Sie auf die Schaltfläche Bearbeiten.

118


4. Geben Sie unter Verbindungseigenschaften die Informationen zum Herstellen der Verbindung zum Demo-SQL Server-Cluster ein, der in Szenario 2 erstellt wurde.

119


5. Öffnen Sie den Abfrage-Designer, klicken Sie mit der rechten Maustaste in das Abfragefenster, und wählen Sie Tabelle hinzufügen aus.

120


6. Wählen Sie die Tabelle Sales aus (in Szenario 2 erstellt) und dann Alle Spalten.

121


7. Wählen Sie einen tabellarischen Berichtstyp aus.

122


8. Im aktuellen Beispiel wird nach Region gruppiert. Diesen Schritt können Sie überspringen, wenn Sie möchten.

9. Sobald das Projekt erstellt ist, öffnen Sie über das Menü Projekt die Projekteigenschaften.

123


10. Konfigurieren Sie die folgenden Projekteigenschaften:

a) TargetDatasetFolder – Auf den zuvor erstellten Testberichtordner festlegen

b) TargetDatasetFolder – Auf den zuvor erstellten Testberichtordner festlegen

c) TargetReportFolder – Auf den zuvor erstellten Testberichtsordner festlegen

d) TargetReportPartFolder – Auf den zuvor erstellten Testberichtsordner festlegen

e) TargetServerURL – Auf die URL der Webanwendung festlegen, die den Bericht hostet

124


11. Stellen Sie den Bericht in der SharePoint-Bibliothek bereit. Wählen Sie im Menü Erstellen den Befehl <Projektname> bereitstellen aus.

12. Wenn das Projekt erfolgreich bereitgestellt wurde, wird im Fenster Ausgabe eine entsprechende Meldung angezeigt.

125


Anzeigen des Testberichts in Internet ExplorerÖffnen Sie die Berichtsdokumentbibliothek, die Sie in den vorherigen Schritten dieses Szenarios erstellt haben, im Browser. Sie sollten die Berichtsdatei sehen, die Sie soeben veröffentlicht haben. Wird der Bericht nicht angezeigt, müssen Sie das Reporting Services-Feature u. U. in der Websitesammlung aktivieren. Weitere Informationen finden Sie unter Vorgehensweise: Aktivieren der Berichtsserverfunktion in der SharePoint-Zentraladministration (http://go.microsoft.com/fwlink/?LinkID=196878&clcid=0x407).

Klicken Sie auf den Bericht. Der Bericht wird im Browser gerendert.

126




Zur weiteren Überprüfung der Delegierung und der Datenverbindung ändern Sie die Quelldaten in SQL Server Management Studio und aktualisieren die Datenverbindung für den SSRS-Bericht im Browser. Die Datenänderungen sollten im Bericht wiedergegeben werden.

SSL-Konfiguration für Reporting ServicesIn manchen Umgebungen ist es möglicherweise erforderlich, die Kommunikation zwischen den Front-End-Webservern und den SSRS-Servern mit SSL zu schützen. Eine detaillierte Schritt-für-Schritt-Anleitung zum Konfigurieren von für Reporting Services übersteigt den Rahmen dieses Artikels. Deshalb sei hier nur eine Zusammenfassung der erforderlichen Schritte gegeben:

1. Konfigurieren Sie jeden Berichtsserver für SSL. Siehe Konfigurieren eines Berichtsservers für SSL-Verbindungen (Secure Sockets Layer) (http://go.microsoft.com/fwlink/?LinkId=196881&clcid=0x407).

2. Aktualisieren Sie die Datei ReportingServer.config. Ändern Sie den <UrlRoot> in die neue https://-URL.

3. Starten Sie den SQL Server Reporting Services-Dienst neu.

127




4. Ändern Sie in der Zentraladministration die Einstellungen für die Reporting Services-Integration, und ändern Sie die URL für den Berichtsserver-Webdienst in die neue https://-URL.

5. Starten Sie Internetinformationsdienste (IIS) in jeder Instanz von SharePoint Server neu, in der der Webanwendungsdienst ausgeführt wird.

Sie müssen keinen der Dienstprinzipalnamen ändern, die Sie beim Konfigurieren von Reporting Services mit HTTP in den vorherigen Schritten erstellt haben. Der Dienstprinzipalname für einen HTTP-Dienst über SSL bleibt HTTP/<Dienst>. Dies sehen Sie, wenn Sie NetMon verwenden, um den Front-End-Webserver anzuzeigen, der mit dem Reporting Services-Server kommuniziert.

Beachten Sie die hervorgehobene Ticket-Granting Service-Anforderung und den angeforderten Sname. Auf den Berichtsserverdienst wurde über „https:// “ zugegriffen, und für den SName im angeforderten Ticket gilt wie erwartet weiter „HTTP/“. Um sicherzustellen, dass das Web-Front-End tatsächlich SSL für die Kommunikation mit dem Berichtsserver verwendet hat, wurde weiterer Datenverkehr erfasst und analysiert:

128


Beachten Sie, dass alle Anforderung vom Web-Front-End an den Berichtsserver über SSL geschützt sind. Dies bestätigt, dass SSL für die Kommunikation zwischen den Web-Front-Ends und dem Berichtsserver verwendet wurde.

129


Identitätsdelegierung für Excel Services (SharePoint Server 2010)Veröffentlichung: 02.12.10

In diesem Szenario fügen Sie die Excel Services-Dienstanwendung der SharePoint Server-Umgebung hinzu. Anschließend konfigurieren Sie die eingeschränkte Kerberos-Delegierung, damit der Dienst Daten auf einem Arbeitsblatt in einer SQL Server-Datenquelle aktualisiert.

Hinweis:



Voraussetzungen für dieses SzenarioBevor Sie dieses Szenario angehen, müssen die folgenden Aufgaben erledigt sein:





Active Directory-Konfiguration

Erstellen eines Excel Services-Dienstkontos

Konfigurieren eines Dienstprinzipalnamens für das Excel Services-Dienstkonto

130






Konfigurieren der eingeschränkten Kerberos-Delegierung für Server mit Excel Services

Konfigurieren der eingeschränkten Kerberos-Delegierung für das Excel Services-Dienstkonto

SharePoint Server-Konfiguration

Starten des Forderungen an den Windows-Tokendiensts (C2WTS) auf Servern mit Excel Services

Starten der Excel Services-Dienstinstanz auf dem Server mit Excel Services

Erstellen der Excel Services-Dienstanwendung und des Proxys

Konfigurieren des vertrauenswürdige Dateispeicherorts und von Authentifizierungseinstellungen für Excel Services

Überprüfen der eingeschränkten Excel Services-Delegierung

Erstellen einer Dokumentbibliothek zum Hosten einer Testarbeitsmappe

Erstellen der SQL-Testdatenbank und -tabelle

Erstellen einer Excel-Testarbeitsmappe mit SQL-Datenverbindung

Veröffentlichen der Arbeitsmappe in SharePoint Server und Aktualisieren der Datenverbindung

131



Pfade der eingeschränkten Kerberos-Delegierung

In diesem Szenario wird das SharePoint Server Excel Services-Dienstkonto für die eingeschränkte Kerberos-Delegierung für den SQL Server-Dienst konfiguriert.

132


Hinweis:

In diesem Szenario wird der Forderungen an den Windows-Tokendienst für die Verwendung eines dedizierten Dienstkontos konfiguriert. Wenn Sie den Forderungen an den Windows-Tokendienst (C2WTS) weiter das Konto Lokales System verwenden lassen, müssen Sie die eingeschränkte Delegierung für das Computerkonto des Computers konfigurieren, auf dem der Forderungen an den Windows-Tokendienst (C2WTS) und Excel Services ausgeführt werden.

Logische SharePoint Server-Authentifizierung

Die Authentifizierung in diesem Szenario beginnt mit der Clientauthentifizierung über Kerberos auf dem Web-Front-End-Server. SharePoint Server 2010 wandelt das Windows-Authentifizierungstoken mithilfe des lokalen Sicherheitstokendiensts in ein Forderungstoken um. Die Excel-Dienstanwendung akzeptiert das Forderungstoken und wandelt es mithilfe des zum Windows Identity Framework (WIF) gehörenden Forderungen an den Windows-Tokendiensts (C2WTS) in ein Windows-Token (Kerberos) um. Die Excel-Dienstanwendung verwendet anschließend das Kerberos-Ticket zur Authentifizierung bei der Datenquelle im Back-End.

133




Erstellen eines Excel Services-DienstkontosEmpfohlen wird, die Excel Services-Anwendung unter ihrer eigenen Domänenidentität auszuführen. Zum Konfigurieren der Excel Services-Anwendung müssen Active Directory-Konten erstellt werden. Bei diesem Beispiel wurden die folgenden Konten erstellt:

SharePoint Server-Dienst IIS-Anwendungspoolidentität

Excel Services vmlab\svcExcel

Konfigurieren eines Dienstprinzipalnamens für das Excel Services-DienstkontoDie eingeschränkte Kerberos-Delegierung muss konfiguriert werden, wenn Excel Services die Identität des Clients an die Datenquelle im Back-End zurück delegieren soll. In diesem Beispiel fragt Excel Services Daten aus einer SQL-Transaktionsdatenbank ab, weshalb die Kerberos-Delegierung erforderlich ist.

Die Kerberos-Delegierung wird zumeist im Active Directory-Snap-In Benutzer und Computer konfiguriert. Hierfür muss dem zu konfigurierenden Active Directory-Objekt ein Dienstprinzipalname zugeordnet werden. Andernfalls wird die Registerkarte Delegierung des Objekts in dessen Eigenschaftendialogfeld nicht angezeigt. Wenngleich Excel Services für den Betrieb keinen Dienstprinzipalnamen benötigt, wird für diesen Zweck einer konfiguriert.

Führen Sie an der Eingabeaufforderung folgenden Befehl aus:

SETSPN -S SP/ExcelServices

134


Hinweis:

Der Dienstprinzipalname ist kein gültiger Dienstprinzipalname und wird dem angegebenen Dienstkonto zugeordnet, um die Delegierungsoptionen im Active Directory-Snap-In Benutzer und Computer zu veranschaulichen. Es gibt andere unterstützte Möglichkeiten zur Angabe der Delegierungseinstellungen (insbesondere das Attribut msDS-AllowedToDelegateTo), die in diesem Artikel jedoch nicht behandelt werden.

Konfigurieren der eingeschränkten Kerberos-Delegierung für Excel ServicesDamit Excel Services die Identität des Clients delegieren kann, muss die eingeschränkte Kerberos-Delegierung konfiguriert werden. Ferner müssen Sie die eingeschränkte Delegierung mit Protokollübergang für die Umwandlung von Forderungstoken in Windows-Token über den Forderungen an den Windows-Tokendienst von Windows Identity Framework (WIF) konfigurieren.

Servern, auf denen Excel Services ausgeführt wird, muss für die Delegierung von Anmeldeinformationen an alle Back-End-Dienste vertraut werden, bei denen sich Excel authentifiziert. Darüber hinaus muss das Excel Services-Dienstkonto ebenfalls für das Zulassen der Delegierung an dieselben Back-End-Dienste konfiguriert werden.

In unserem Beispiel werden die folgenden Delegierungspfade definiert:


User svcExcel MSSQLSVC/MySqlCluster.vmlab.local:1433

*Benutzer svcC2WTS MSSQLSVC/MySqlCluster.vmlab.local:1433

**Computer VMSP10APP01 MSSQLSVC/MySqlCluster.vmlab.local:1433

* Wird in diesem Szenario später konfiguriert

** Nur erforderlich, wenn der Forderungen an den Windows-Tokendienst (C2WTS) als Lokales System ausgeführt wird

135



1. Öffnen Sie die Eigenschaften des Active Directory-Objekts in Active Directory-Benutzer und -Computer.



4. Wählen Sie anschließend Beliebiges Authentifizierungsprotokoll verwenden aus. Diese Einstellung ermöglicht den Protokollübergang und ist für das Dienstkonto erforderlich, damit der Forderungen an den Windows-Tokendienst (C2WTS) genutzt werden kann.

136


5. Klicken Sie auf die Schaltfläche Hinzufügen, um den Dienstprinzipal auszuwählen, an den die Delegierung erfolgen darf.

6. Wählen Sie Benutzer und Computer aus.

7. Wählen Sie das Dienstkonto aus, mit dem der Dienst ausgeführt wird, an den die Delegierung erfolgen soll. In diesem Beispiel ist dies das Dienstkonto für den SQL Server-Dienst.

137


Hinweis:

Dem ausgewählten Dienstkonto muss ein Dienstprinzipalname zugeordnet sein. In unserem Beispiel wurde der Dienstprinzipalname für dieses Konto in einem vorherigen Szenario konfiguriert.

8. Klicken Sie auf OK. Im folgenden Fenster werden Sie aufgefordert, die Dienstprinzipalnamen auszuwählen, an die die Delegierung erfolgen soll.

9. Wählen Sie die Dienste für den SQL Server-Cluster aus, und klicken Sie auf OK.

10. Die ausgewählten Dienstprinzipalnamen sollten nun in der Liste Dienste, für die dieses Konto delegierte Anmeldeinformationen verwenden kann enthalten sein.

138


11. Wiederholen Sie diese Schritte für alle Delegierungspfade, die am Anfang dieses Abschnitts definiert wurden.

Überprüfen Sie den MSSQLSVC-Dienstprinzipalnamen für das Dienstkonto, mit dem der Dienst auf dem Server mit SQL Server ausgeführt wird (in Szenario 2 erfolgt).Überprüfen Sie mit dem folgenden SetSPN-Befehl, ob der Dienstprinzipalname für das SQL Server-Dienstkonto (vmlab\svcSQL) vorhanden ist:







Konfigurieren und Starten des Forderungen an den Windows-Tokendiensts (C2WTS) auf Servern mit Excel ServicesDer Forderungen an den Windows-Tokendienst (C2WTS) ist eine Komponente von Windows Identity Foundation (WIF) und für das Umwandeln von Benutzerforderungstoken in Windows-Token zuständig. Dies erfolgt in Excel Services, wenn die Dienste Anmeldeinformationen an ein Back-End-System delegieren müssen, das mit der integrierten Windows-Authentifizierung arbeitet. WIF wird mit SharePoint Server 2010 bereitgestellt, der Forderungen an den Windows-Tokendienst (C2WTS) kann in der Zentraladministration gestartet werden.

Auf jedem Excel Services-Anwendungsserver muss der Forderungen an den Windows-Tokendienst (C2WTS) lokal ausgeführt werden. Dieser Dienst öffnet keine Ports, und Remoteaufrufer können nicht auf ihn zugreifen. Darüber hinaus muss die Dienstkonfigurationsdatei des Forderungen an den Windows-Tokendiensts (C2WTS) so konfiguriert werden, dass der lokalen aufrufenden Clientidentität vertraut wird.

Empfohlen wird, den Forderungen an den Windows-Tokendienst (C2WTS) mit einem dedizierten Dienstkonto und nicht als Lokales System (Standardkonfiguration) auszuführen. Das Dienstkonto des Forderungen an den Windows-Tokendiensts (C2WTS) erfordert spezielle lokale Berechtigungen für jeden Server, auf dem der Dienst ausgeführt wird. Die entsprechenden Berechtigungen müssen jedes Mal konfiguriert werden, wenn der Dienst auf einem Server gestartet wird. Optimal ist die Konfiguration der Berechtigungen des Dienstkontos auf dem lokalen Server, bevor der Forderungen an den Windows-Tokendienst (C2WTS) gestartet wird. Falls dies jedoch im Anschluss erfolgt, können Sie den Forderungen an den Windows-Tokendienst (C2WTS) über die Windows-Dienstverwaltungskonsole (services.msc) neu starten.

So starten Sie den Forderungen an den Windows-Tokendienst (C2WTS)

1. Erstellen Sie in Active Directory ein Dienstkonto, unter dem der Dienst ausgeführt wird. In diesem Beispiel wird vmlab\svcC2WTS erstellt.

SetSPN -S SP/C2WTS vmlab\svcC2WTS

2. Ordnen Sie dem Dienstkonto einen beliebigen Dienstprinzipalnamen zu, um die Delegierungsoptionen für dieses Konto in Active Directory-Benutzer und -Computer anzuzeigen. Dieser Name darf ein beliebiges Format haben, da beim Forderungen an den Windows-Tokendienst (C2WTS) keine Kerberos-Authentifizierung erfolgt. Es wird empfohlen, keinen HTTP-Dienstprinzipalnamen zu wählen, damit in Ihrer Umgebung keine doppelten Namen generiert werden. Im Beispiel wurde SP/C2WTS bei vmlab\svcC2WTS mit folgendem Befehl registriert:

140


3. Konfigurieren Sie die eingeschränkte Kerberos-Delegierung für das Dienstkonto des Forderungen an den Windows-Tokendiensts (C2WTS). In diesem Szenario werden Anmeldeinformationen an den SQL-Dienst delegiert, der mit dem Dienstprinzipalnamen MSSQLSVC/MySqlCluster.vmlab.local:1433 ausgeführt wird.

4. Konfigurieren Sie anschließend die vom Forderungen an den Windows-Tokendienst (C2WTS) benötigten lokalen Serverberechtigungen, die auf allen Servern konfiguriert werden müssen, auf denen der Forderungen an den Windows-Tokendienst (C2WTS) ausgeführt wird. In unserem Beispiel ist dies VMSP10APP01. Melden Sie sich an diesem Server an, und erteilen Sie dem Forderungen an den Windows-Tokendienst (C2WTS) die folgenden Berechtigungen:

a) Fügen Sie das Dienstkonto der lokalen Gruppe Administratoren hinzu.

b) Erteilen Sie in der lokalen Sicherheitsrichtlinie (secpol.msc) unter Zuweisen von Benutzerrechten dem Dienstkonto die folgenden Berechtigungen:

141


i. Einsetzen als Teil des Betriebssystems

ii. Annehmen der Clientidentität nach Authentifizierung

iii. Anmelden als Dienst

5. Öffnen Sie die Zentraladministration.

6. Registrieren Sie im Abschnitt Sicherheit unter Verwaltete Dienstkonten konfigurieren das Dienstkonto des Forderungen an den Windows-Tokendiensts (C2WTS) als verwaltetes Konto.

7. Wählen Sie unter Dienste den Eintrag Dienste auf dem Server verwalten aus.

8. Wählen Sie im Auswahlfeld Server rechts oben den/die Server aus, auf dem/denen Visio Services ausgeführt wird. In diesem Beispiel heißt der Server VMSP10APP01.

9. Navigieren Sie zu Forderungen an den Windows-Tokendienst, und starten Sie den Dienst.

142


10. Wechseln Sie im Abschnitt Sicherheit zu Dienstkonten verwalten. Ändern Sie die Identität des Forderungen an den Windows-Tokendiensts (C2WTS) in das neue verwaltete Konto.

Hinweis:

Wenn der Forderungen an den Windows-Tokendienst (C2WTS) bereits ausgeführt wurde, bevor Sie das dedizierte Dienstkonto konfiguriert haben, oder Sie die Berechtigungen des Dienstkontos nach Start des Forderungen an den Windows-Tokendiensts (C2WTS) ändern müssen, starten Sie den Dienst über die Konsole Dienste neu.

Falls darüber hinaus Probleme mit dem Forderungen an den Windows-Tokendienst (C2WTS) nach dem Neustart des Diensts vorliegen sollten, müssen Sie ggf. die IIS-Anwendungspools zurücksetzen, die mit dem Forderungen an den Windows-Tokendienst (C2WTS) kommunizieren.

Hinzufügen von Startabhängigkeiten zum Forderungen an den Windows-Tokendienst (C2WTS) im WIFBeim Forderungen an den Windows-Tokendienst (C2WTS) gibt es ein bekanntes Problem. Der Dienst wird bei einem Systemneustart nicht automatisch erfolgreich gestartet. Dieses Problem kann behoben werden, indem für die Kryptografiedienste eine Abhängigkeit konfiguriert wird:

143



1. Öffnen Sie das Eingabeaufforderungsfenster.

2. Geben Sie Folgendes ein: sc config "c2wts" depend= CryptSvc

3. Wechseln Sie in der Konsole Dienste zum Claims to Windows Token Service.

4. Öffnen Sie die Eigenschaften des Diensts.

5. Überprüfen Sie die RegisterkarteAbhängigkeiten. Prüfen Sie, ob Kryptografiedienste aufgeführt ist.

144


6. Klicken Sie auf OK.

Erteilen von Berechtigungen für die Inhaltsdatenbank der Webanwendung für das Excel Services-DienstkontoEin erforderlicher Schritt bei der Konfiguration von SharePoint Server 2010-Office-Webanwendungen besteht darin, dem Dienstkonto der Webanwendung den Zugriff auf die Inhaltsdatenbanken einer bestimmten Webanwendung zu ermöglichen. In diesem Beispiel wird dem Excel Services-Dienstkonto Zugriff auf die Inhaltsdatenbank der Webanwendung „portal“ über Windows PowerShell erteilt.



$w.GrantAccessToProcessIdentity("vmlab\svcExcel")

Starten der Excel Services-Dienstinstanz auf dem Server mit Excel ServicesStarten Sie vor dem Erstellen einer Excel Services-Dienstanwendung den Excel Services-Dienst auf den vorgesehenen Farmservern.



145



4. Starten Sie die Dienste für Excel-Berechnungen.

Erstellen der Excel Services-Dienstanwendung und des ProxysKonfigurieren Sie anschließend eine neue Excel Services-Dienstanwendung und einen Anwendungsproxy, um Webanwendungen die Nutzung von Excel Services zu ermöglichen:


2. Klicken Sie unter Anwendungsverwaltung auf Dienstanwendungen verwalten.

3. Klicken Sie auf Neu und dann auf Excel Services-Anwendung.

146


4. Konfigurieren Sie die neue Dienstanwendung. Wählen Sie das ordnungsgemäße Dienstkonto aus (erstellen Sie ein neues verwaltetes Konto, falls das Excel Services-Konto nicht in der Liste enthalten ist).

147


Konfigurieren des vertrauenswürdige Dateispeicherorts und von Authentifizierungseinstellungen für Excel ServicesNach Erstellen der Excel Services-Anwendung müssen Sie die Eigenschaften der neuen Dienstanwendung konfigurieren, um einen vertrauenswürdigen Hostspeicherort und Authentifizierungseinstellungen anzugeben.



148


3. Klicken Sie auf den Link der neuen Dienstanwendung (in diesem Beispiel Excel Services).

4. Klicken Sie auf dem Bildschirm zur Verwaltung von Excel Services auf Vertrauenswürdige Datenquellen-Speicherorte.

5. Fügen Sie einen neuen vertrauenswürdigen Dateispeicherort hinzu.

149


6. Geben Sie den Speicherort für Ihre Testbibliothek an.

Hinweis:

In diesem Beispiel wird der URL der Stammwebanwendung und allen untergeordneten URLs vertraut. In einer Produktionsumgebung müssen Sie die Vertrauensbeziehung ggf. stärker einschränken.

150


7. Wählen Sie unter Externe Daten zulassen die Option Vertrauenswürdige Datenverbindungsbibliotheken und eingebettete Verbindungen aus.

Hinweis:

In diesem Beispiel wird für die Verbindung mit SQL Server eine eingebettete Verbindung verwendet. In Ihrer Umgebung müssen Sie ggf. eine gesonderte Verbindungsdatei erstellt und diese in einer vertrauenswürdigen Datenverbindungsbibliothek speichern. In diesem Fall können Sie ggf. nur vertrauenswürdige Datenverbindungsbibliotheken auswählen.

8. Ändern Sie die Gültigkeitsdauer des externen Datencaches. Zu Testzwecken empfiehlt es sich, die Gültigkeitsdauer des externen Datencaches zu ändern, um sicherzustellen, dass Datenaktualisierungen aus der Datenquelle und nicht aus dem Cache stammen. Ändern Sie unter Externe Daten die folgenden Einstellungen:

Automatische Aktualisierung (in bestimmten Abständen/beim Öffnen) = 0

Hinweis:

In einer Produktionsumgebung sollten Sie eine Cacheeinstellung größer 0 wählen. Das Festlegen des Caches auf 0 ist nur für Testzwecke vorgesehen.

Manuelle Aktualisierung = 0

151


Überprüfen der eingeschränkten Excel Services-Delegierung

Erstellen einer Dokumentbibliothek zum Hosten der TestarbeitsmappeÖffnen Sie eine Website im vertrauenswürdigen Pfad, der im vorherigen Schritt konfiguriert wurde. Erstellen Sie eine neue Dokumentbibliothek zum Hosten einer Excel-Testarbeitsmappe.

Erstellen einer Excel-Testarbeitsmappe mit SQL-DatenverbindungErstellen Sie als Nächstes eine Excel-Arbeitsmappe mit einer Datenverbindung mit der neuen Testdatenbank:

1. Öffnen Sie Excel.

2. Klicken Sie auf der Registerkarte Daten auf Aus anderen Quellen und dann auf Von SQL Server.

3. Stellen Sie eine Verbindung mit der SQL Server-Testdatenquelle her.

152


4. Wählen Sie die Testdatenbank und -tabelle aus (Sales in unserem Beispiel).

5. Klicken Sie auf Weiter. Klicken Sie auf die Schaltfläche Authentifizierungseinstellungen. Vergewissern Sie sich, dass Windows-Authentifizierung angegeben ist.

153


6. Klicken Sie auf Fertig stellen.

7. Wählen Sie PivotTable-Bericht aus.

8. Konfigurieren Sie die PivotTable. Stellen Sie sicher, dass Daten aus der SQL Server-Quelle zurückgegeben werden.

154


Veröffentlichen der Arbeitsmappe in SharePoint Server und Aktualisieren der DatenverbindungDer letzte Schritt bei der Überprüfung der Excel Services-Anwendung ist das Veröffentlichen der Arbeitsmappe und Testen der Aktualisierung der eingebetteten SQL Server-Verbindung.

1. Klicken Sie auf die Registerkarte Datei.

2. Klicken Sie auf Speichern und senden, dann auf In SharePoint speichern und schließlich auf Speicherort suchen.

155


3. Geben Sie den Speicherort der in den vorherigen Schritten erstellten vertrauenswürdigen Bibliothek ein.

4. Vergewissern Sie sich, dass Mit Excel im Browser öffnen ausgewählt ist.

An dieser Stelle wird ein neues Browserfenster mit Ihrer Testarbeitsmappe angezeigt. Aktualisieren Sie anschließend die Datenverbindung, indem Sie zuerst auf Daten und dann auf Alle Verbindungen aktualisieren klicken.

156


Wenn die Datenverbindung aktualisiert wird, haben Sie die Kerberos-Delegierung für Excel Services erfolgreich konfiguriert. Ändern Sie zum Testen der Verbindung die Quelldaten in SQL Management Studio, und aktualisieren Sie anschließend die Verbindung. Die geänderten Daten sollten in der Arbeitsmappe angezeigt werden. Wenn keine Änderungen erkennbar sind und bei der Aktualisierung keine Fehler angezeigt werden, sehen Sie höchstwahrscheinlich zwischengespeicherte Daten. Excel Services speichert standardmäßig Daten aus externen Datenquellen fünf Minuten zwischen. Sie können diese Cacheeinstellung ändern. Weitere Informationen finden Sie unter Konfigurieren des vertrauenswürdige Dateispeicherorts und von Authentifizierungseinstellungen für Excel Services in diesem Artikel.

157


Identitätsdelegierung für PowerPivot für SharePoint 2010 (SharePoint Server 2010)Veröffentlichung: 02.12.10

Die in Umgebung und Farmtopologie beschriebene Farmtopologie benötigt nicht die Kerberos-Authentifizierung, damit PowerPivot für Microsoft SharePoint 2010 funktioniert. Der PowerPivot-Systemdienst unterstützt Ansprüche bzw. Forderungen und verwendet den Forderungen an den Windows-Tokendienst zum erneuten Erstellen der Windows-Identität des Clients mithilfe des Forderungstokens des Clients, um eine Verknüpfung mit dem Analysis Service Vertipaq-Modul herzustellen, das auf dem Anwendungsserver ausgeführt wird.

Wenn eine PowerPivot-Arbeitsmappe in SharePoint Server hochgeladen wird, enthält sie bereits die von der Arbeitsmappe genutzten PowerPivot-Daten. Wenn der Benutzer die PowerPivot-Arbeitsmappe in Excel Web Access öffnet und mit den Slicern interagiert, lädt der PowerPivot-Systemdienst die Daten der Arbeitsmappe direkt in das dazugehörige Analysis Services-Modul. Auf die in die Arbeitsmappe eingebettete Datenverbindung erfolgt kein Zugriff.

Wenn die Ausführung eines Datenaktualisierungsauftrags für eine PowerPivot-Arbeitsmappe beginnt, führt der PowerPivot-Systemdienst eine Windows-Anmeldung mithilfe der im Secure Store Service von SharePoint Server gespeicherten

158


Anmeldeinformationen durch. Da die Windows-Identität auf dem Anwendungsserver erstellt wird, ist die Verbindung vom PowerPivot Analysis Services Vertipaq-Modul (auf demselben Computer, VMSP10APP01) mit MySQLCluster der erste NTLM-Hop.

Hinweis:



Szenarien, in denen die Kerberos-Authentifizierung erforderlich istWie Sie sehen, ist in den meisten gängigen Szenarien mit PowerPivot keine Kerberos-Authentifizierung erforderlich. Es gibt jedoch einige ungewöhnliche Ausnahmefälle, bei den die Kerberos-Authentifizierung benötigt wird. Wenn beispielsweise Ihre PowerPivot-Arbeitsmappe eine Datenverbindung mit einer SQL Server-Instanz enthält, die mit einer weiteren SQL Server-Instanz auf einem anderen Computer verknüpft ist, müssen Sie die Kerberos-Authentifizierung mit Identitätsdelegierung konfigurieren, damit die Datenaktualisierung funktioniert. Wenn z. B. MySQLCluster mit einer anderen SQL Server-Remoteinstanz verknüpft ist, dann ist die Verknüpfung von MySQLCluster zum verknüpften Remoteserver der zweite Hop. In diesem Fall kann NTLM nicht mehr verwendet werden. Sie müssen die Kerberos-Delegierung konfigurieren, damit die Datenaktualisierung erfolgen kann.

159





Nachfolgend werden die wichtigsten Schritte zum Konfigurieren der Identitätsdelegierung für PowerPivot beschrieben, die jedoch über den Umfang der Szenarien in diesem Artikel hinausgehen:

1. Ändern des Dienstkontos des Forderungen an den Windows-Tokendiensts (C2WTS) in ein Domänenkonto (e.g. VMLAB\svcC2WTS). Das Konfigurieren des Forderungen an den Windows-Tokendiensts (C2WTS) wird in den anderen Szenarien in diesem Artikel ausführlich beschrieben:

Konfigurieren und Starten des Forderungen an den Windows-Tokendiensts (C2WTS) auf Servern mit Excel Services

Konfigurieren und Starten des Forderungen an den Windows-Tokendiensts (C2WTS) auf Servern mit Visio Services

Konfigurieren und Starten des Forderungen an den Windows-Tokendiensts (C2WTS) auf Servern mit PerformancePoint Services

2. Konfigurieren der Delegierung des Kontos VMLAB\svcSQL an den Dienstprinzipalnamen der verknüpften SQL Server-Instanz Konfigurationscheckliste


PowerPivot-Installation Installieren von SQL Server PowerPivot für SharePoint auf dem Anwendungsserver

160


Voraussetzungen für dieses SzenarioStreng genommen, sind die folgenden Kerberos-Authentifizierungsszenarien für PowerPivot für SharePoint nicht erforderlich. Sie beschleunigen jedoch nach erfolgreichem Abschluss den PowerPivot für SharePoint-Installationsprozess, da die Komponenten selbst Voraussetzung für PowerPivot für SharePoint darstellen.



(Optional) Szenario 3: Kerberos-Authentifizierung für SQL Server Analysis Services


KonfigurationsanweisungenInstallieren Sie PowerPivot für SharePoint auf dem Anwendungsserver (vmsp10app01). Detaillierte Anweisungen finden Sie unter Vorgehensweise: Installieren von PowerPivot für SharePoint in einer dreistufigen SharePoint-Farm in der MSDN-Onlinebibliothek. Wenn Sie bereits die anderen Szenarien in diesem Artikel durchlaufen haben, können Sie die Abschnitte im MSDN-Artikel überspringen, die bereits erledigt wurden.

Wichtig:

Der Anwendungspool für die SQL Server PowerPivot-Dienstanwendung muss mit dem Domänenkonto des SharePoint Server-Farmadministrators ausgeführt werden. In keinem anderen Benutzerkontext kann der PowerPivot-Systemdienst die Anmeldeinformationen des unbeaufsichtigten Kontos aus dem Secure Store Service abrufen.

161




Identitätsdelegierung für Visio Services (SharePoint Server 2010)Veröffentlichung: 02.12.10

In diesem Szenario fügen Sie eine Visio Services-Dienstanwendung der SharePoint Server-Umgebung hinzu. Anschließend konfigurieren Sie die eingeschränkte Kerberos-Delegierung, damit der Dienst Daten aus einer SQL Server-Datenquelle in einer Visio-Webzeichnung aktualisiert.

Hinweis:








Erstellen eines Visio Services-Dienstkontos

Konfigurieren eines Dienstprinzipalnamens für das Visio Services-Dienstkonto

162






Konfigurieren der eingeschränkten Kerberos-Delegierung für Server mit Visio Services

Konfigurieren der eingeschränkten Kerberos-Delegierung für das Visio Services-Dienstkonto


Starten des Forderungen an den Windows-Tokendiensts (C2WTS) auf Servern mit Visio Services

Erteilen von Berechtigungen für die Inhaltsdatenbank der Webanwendung für das Visio Services-Dienstkonto

Starten der Visio Services-Dienstinstanz auf dem Server mit Visio Services

Erstellen der Visio Services-Dienstanwendung und des Proxys

Überprüfen der eingeschränkten Visio Services-Delegierung

Konfigurieren der Cacheeinstellungen für Visio Services

Erstellen einer Dokumentbibliothek zum Hosten eines Visio-Testdiagramms

Erstellen einer Visio-Testwebzeichnung mit Shapes, die mit SQL Server-Daten verbunden sind

Veröffentlichen der Visio-Zeichnung in SharePoint Server und Aktualisieren der Datenverbindung

163




In diesem Szenario werden die Visio Services-Anwendungsserver und -Dienstkonten von SharePoint Server für die eingeschränkte Kerberos-Delegierung an den SQL Server-Dienst konfiguriert.


Die Authentifizierung in diesem Szenario beginnt mit der Clientauthentifizierung über Kerberos auf dem Web-Front-End-Server. SharePoint Server 2010 wandelt das Windows-Authentifizierungstoken mithilfe des lokalen Sicherheitstokendiensts in ein Forderungstoken um. Die Visio-Dienstanwendung akzeptiert das Forderungstoken und wandelt es mithilfe des zum Windows Identity Framework (WIF) gehörenden Forderungen an den Windows-Tokendiensts in ein Windows-Token (Kerberos) um. Die

164


Visio-Dienstanwendung verwendet anschließend das Kerberos-Ticket zur Authentifizierung bei der Datenquelle im Back-End.



Erstellen eines Visio Services-DienstkontosEmpfohlen wird, die Visio Services-Anwendung unter ihrer eigenen Domänenidentität auszuführen. Zum Konfigurieren der Visio Services-Anwendung müssen Active Directory-Konten erstellt werden. Bei diesem Beispiel wurden die folgenden Konten erstellt:


Visio Services vmlab\svcVisio

Konfigurieren eines Dienstprinzipalnamens für das Visio Services-DienstkontoDie eingeschränkte Kerberos-Delegierung muss konfiguriert werden, wenn Visio Services die Windows-Identität des Clients an die Datenquelle im Back-End zurück delegieren soll. In diesem Beispiel fragt Visio Services Daten aus einer SQL Server-Transaktionsdatenbank ab, weshalb die Kerberos-Delegierung erforderlich ist.

Die Kerberos-Delegierung wird zumeist im Active Directory-Snap-In Benutzer und Computer konfiguriert. Hierfür muss dem zu konfigurierenden Active Directory-Objekt ein Dienstprinzipalname zugeordnet werden. Andernfalls wird die Registerkarte Delegierung des Objekts in dessen Eigenschaftendialogfeld nicht angezeigt. Wenngleich Excel Services für den Betrieb keinen Dienstprinzipalnamen benötigt, wird für diesen Zweck einer konfiguriert.


SETSPN -S SP/VisioServices svc\VisioServices

165


Hinweis:


Konfigurieren der eingeschränkten Kerberos-Delegierung für Visio ServicesDamit Visio Services die Identität des Clients delegieren kann, muss die eingeschränkte Kerberos-Delegierung konfiguriert werden. Ferner müssen Sie die eingeschränkte Delegierung mit Protokollübergang für die Umwandlung von Forderungstoken in Windows-Token über den Forderungen an den Windows-Tokendienst (C2WTS) von Windows Identity Framework (WIF) konfigurieren.

Servern, auf denen Visio Services ausgeführt wird, muss für die Delegierung von Anmeldeinformationen an alle Back-End-Dienste vertraut werden, bei denen sich Visio authentifiziert. Darüber hinaus muss das Visio Services-Dienstkonto ebenfalls für das Zulassen der Delegierung an dieselben Back-End-Dienste konfiguriert werden.



User Vmlab\svcVisio MSSQLSVC/MySqlCluster.vmlab.local:1433

*Benutzer Vmlab\svcC2WTS MSSQLSVC/MySqlCluster.vmlab.local:1433

**Computer Vmlab\vmsp10app01 MSSQLSVC/MySqlCluster.vmlab.local:1433

* Wird in diesem Szenario später konfiguriert

** Optional. Die eingeschränkte Delegierung für das Computerkonto ist nur erforderlich, wenn der Forderungen an den Windows-Tokendienst (C2WTS) als Lokales System ausgeführt wird.

166






4. Wählen Sie anschließend Beliebiges Authentifizierungsprotokoll verwenden aus. Diese Einstellung ermöglicht den Protokollübergang und ist für das Visio-Dienstkonto erforderlich, damit der Forderungen an den Windows-Tokendienst (C2WTS) genutzt werden kann.

167


5. Klicken Sie auf die Schaltfläche Hinzufügen, um den Dienstprinzipal auszuwählen, an den die Delegierung erfolgen darf.



168


Hinweis:


8. Klicken Sie auf OK. Sie werden aufgefordert, die Dienstprinzipalnamen auszuwählen, an die die Delegierung erfolgen soll.



169


11. Wiederholen Sie diese Schritte für alle Delegierungspfade (Computer und Benutzer), die am Anfang dieses Abschnitts definiert wurden.



Folgendes sollte angezeigt werden:MSOLAPSvc.3/MySqlCluster




Konfigurieren und Starten des Forderungen an den Windows-Tokendiensts (C2WTS) auf Servern mit Visio ServicesDer Forderungen an den Windows-Tokendienst ist eine Komponente von Windows Identity Foundation (WIF) und für das Umwandeln von Benutzerforderungstoken in Windows-Token zuständig. Dies erfolgt im Visio-Grafikdienst, wenn der Dienst Anmeldeinformationen an ein Back-End-System delegieren muss, das mit der Windows-Authentifizierung arbeitet. WIF wird mit SharePoint Server 2010 bereitgestellt, der Forderungen an den Windows-Tokendienst (C2WTS) kann in der Zentraladministration gestartet werden.

Auf jedem Anwendungsserver mit dem Visio-Grafikdienst muss der Forderungen an den Windows-Tokendienst (C2WTS) lokal ausgeführt werden. Dieser Dienst öffnet keine Ports, und Remoteaufrufer können nicht auf ihn zugreifen. Darüber hinaus muss die Dienstkonfigurationsdatei des Forderungen an den Windows-Tokendiensts (C2WTS) so konfiguriert werden, dass der lokalen aufrufenden Clientidentität vertraut wird.

Empfohlen wird, den Forderungen an den Windows-Tokendienst (C2WTS) mit einem dedizierten Dienstkonto und nicht als Lokales System (Standardkonfiguration) auszuführen. Das Dienstkonto des Forderungen an den Windows-Tokendiensts (C2WTS) erfordert spezielle lokale Berechtigungen für jeden Server, auf dem der Dienst ausgeführt wird. Die entsprechenden Berechtigungen müssen jedes Mal konfiguriert werden, wenn der Dienst auf einem Server gestartet wird. Optimal ist die Konfiguration der Berechtigungen des Dienstkontos auf dem lokalen Server, bevor der Forderungen an den Windows-Tokendienst (C2WTS) gestartet wird. Falls dies jedoch im Anschluss erfolgt, können Sie den Forderungen an den Windows-Tokendienst (C2WTS)über die Windows-Dienstverwaltungskonsole (services.msc) neu starten.




SetSPN -S SP/C2WTS vmlab\svcC2WTS171


3. Konfigurieren Sie die eingeschränkte Kerberos-Delegierung für das Dienstkonto des Forderungen an den Windows-Tokendiensts (C2WTS). In diesem Szenario werden Anmeldeinformationen an den SQL Server-Dienst delegiert, der mit dem Dienstprinzipalnamen MSSQLSVC/MySqlCluster.vmlab.local:1433 ausgeführt wird.




172








8. Wählen Sie im Auswahlfeld Server rechts oben den/die Server aus, auf dem/denen der Visio-Grafikdienst ausgeführt wird. In diesem Beispiel heißt der Server VMSP10APP01.


173



Hinweis:

Wenn der Forderungen an den Windows-Tokendienst bereits ausgeführt wurde, bevor Sie das dedizierte Dienstkonto konfiguriert haben, oder Sie die Berechtigungen des Dienstkontos nach Start des Forderungen an den Windows-Tokendiensts (C2WTS) ändern müssen, starten Sie den Dienst über die Konsole Dienste neu.


Hinzufügen von Startabhängigkeiten zum Forderungen an den Windows-Tokendienst (C2WTS) im WIFBeim Forderungen an den Windows-Tokendienst (C2WTS) gibt es ein bekanntes Problem. Der Dienst wird bei einem Systemneustart nicht automatisch erfolgreich

174


gestartet. Dieses Problem kann behoben werden, indem für die Kryptografiedienste eine Abhängigkeit konfiguriert wird:

1. Öffnen Sie ein Eingabeaufforderungsfenster.

2. Geben Sie Folgendes ein: sc config "c2wts" depend= CryptSvc



175




Erteilen von Berechtigungen für die Inhaltsdatenbank der Webanwendung für das Visio Services-DienstkontoEin erforderlicher Schritt bei der Konfiguration von SharePoint Server 2010-Office-Webanwendungen besteht darin, dem Dienstkonto der Webanwendung den Zugriff auf die Inhaltsdatenbanken einer bestimmten Webanwendung zu ermöglichen. In diesem Beispiel wird dem Visio-Grafikdienstkonto Zugriff auf die Inhaltsdatenbank der Webanwendung portal über Windows PowerShell erteilt.



$w.GrantAccessToProcessIdentity("vmlab\svcVisio")

Starten der Visio-Grafikdienstinstanz auf dem Server mit VisioStarten Sie vor dem Erstellen einer Visio Services-Dienstanwendung den Visio Services-Dienst auf den vorgesehenen Farmservern.


176




4. Starten Sie Visio-Grafikdienst.

Erstellen der Visio-Grafikdienstanwendung und des ProxysKonfigurieren Sie anschließend eine neue Visio Services-Dienstanwendung und einen Anwendungsproxy, um Webanwendungen die Nutzung von Visio Services zu ermöglichen (falls noch nicht vorhanden):



177


3. Klicken Sie auf Neu und anschließend auf Visio-Grafikdienst.

4. Konfigurieren Sie die neue Dienstanwendung. Wählen Sie das ordnungsgemäße Dienstkonto aus (erstellen Sie ein neues verwaltetes Konto, falls das Visio-Dienstkonto nicht in der Liste enthalten ist).

178


Überprüfen der eingeschränkten Delegierung für den Visio-Grafikdienst

Konfigurieren der Cacheeinstellungen für Visio ServicesBasierend auf den Cacheeinstellungen des Diensts speichert der Visio-Grafikdienst die für Webclients gerenderten Webzeichnungen einige Minuten lang zwischen. Zum Testen der Delegierung wird der Dienst so konfiguriert, dass Zeichnungen nicht zwischengespeichert werden, um die Datenaktualisierung in einer Visio-Webzeichnung einfacher überprüfen zu können.

179


Hinweis:

Das Deaktivieren des Rendercaches wird für Produktionsumgebungen nicht empfohlen. Denken Sie daran, den Cache zu reaktivieren, nachdem Sie das Testen der Delegierung in Visio abgeschlossen haben.



3. Wählen Sie die im vorherigen Schritt erstellte Visio-Grafikdienstanwendung aus.

4. Wählen Sie Globale Einstellungen aus.

5. Legen Sie die Einstellung Minimales Cachealter auf 0 fest (kein Cache).

180


Hinweis:

Das Festlegen des minimalen Cachealters auf 0 ist nur für Testzwecke gedacht und sollte in einer Produktionsumgebung vermieden werden.

Erstellen einer Dokumentbibliothek zum Hosten einer Visio-TestwebzeichnungNavigieren Sie zur Portalanwendung (http://portal). Erstellen Sie eine neue Dokumentbibliothek zum Hosten einer Visio-Testwebzeichnung.

Erstellen einer Visio-Testwebzeichnung mit Shapes, die mit SQL Server-Daten verbunden sind1. Starten Sie Visio 2010.

2. Erstellen Sie unter Start im Abschnitt Allgemein ein neues Standarddiagramm.

3. Klicken Sie auf dem Menüband auf der Registerkarte Daten auf Daten mit Shapes verknüpfen.

181


4. Wählen Sie im Dialogfeld zur Datenauswahl Microsoft SQL Server-Datenbank aus.

5. Geben Sie den in Szenario 2 erstellten SQL Server-Cluster an, und wählen Sie Windows-Authentifizierung aus.

182


6. Wählen Sie die Datenbank Test und die Tabelle Sales aus.

183


7. Geben Sie einen benutzerfreundlichen Namen für die Verbindung ein, und speichern Sie sie in der im vorherigen Schritt erstellten Dokumentbibliothek.

184


8. Wählen Sie im Dialogfeld Datenauswahl die neu erstellte Verbindung aus, und klicken Sie dann auf Fertig stellen.

185


Unten im Zeichnungsfenster sollte nun das externe Datenfenster mit den zuvor erstellten Beispieldaten angezeigt werden.

9. Ziehen Sie die erste Datenzeile auf die Zeichnungsoberfläche. Dadurch wird ein neues Shape erstellt, das mit der Datenzeile verknüpft ist. Die Testzeichnung dient zum Testen der Delegierung und nicht zum Veranschaulichen der Erstellung einer vollfunktionsfähigen für die Produktion bereiten Webzeichnung.

186


Veröffentlichen der Visio-Zeichnung in SharePoint Server und Aktualisieren der Datenverbindung1. Veröffentlichen Sie die Zeichnung in einer SharePoint-Testdokumentbibliothek.

Klicken Sie auf der Registerkarte Datei auf Speichern und senden, In SharePoint speichern, Speicherort suchen und dann auf Webzeichnung.

2. Wechseln Sie zur Testdokumentbibliothek, geben Sie einen Namen für die Testzeichnung ein, und klicken Sie dann auf Speichern.

187


Die Zeichnung wird im Browser geöffnet.

3. Wählen Sie in der Benachrichtigung zur Deaktivierung der Aktualisierung Aktivieren (immer) aus.

188


4. Die Datenverbindung sollte automatisch aktualisiert werden, und keine Fehler sollten auftreten.

5. Öffnen Sie SQL Server Management Studio, und ändern Sie die in der Webzeichnung angezeigte Datenzeile.

6. Aktualisieren Sie die Datenverbindung, indem Sie oben im Zeichnungsfenster auf die Schaltfläche Aktualisieren klicken. Wenn die Delegierung ordnungsgemäß konfiguriert ist, sollte die Datenaktualisierung zu erkennen sein.

189


190


Identitätsdelegierung für PerformancePoint Services (SharePoint Server 2010)Veröffentlichung: 02.12.10

In diesem Szenario fügen Sie die PerformancePoint Services-Dienstanwendung der SharePoint Server-Umgebung hinzu. Anschließend konfigurieren Sie die eingeschränkte Kerberos-Delegierung, damit der Dienst Daten aus einem externen Analysis Services-Cube abrufen kann und die Möglichkeit hat, Daten aus SQL Server abzurufen.

Hinweis:





Szenario 2: Kerberos-Authentifizierung für SQL OLTP (optional)

Szenario 3: Kerberos-Authentifizierung für SQL Server Analysis Services

191








Erstellen eines PerformancePoint Services-Dienstkontos

Erstellen eines Dienstprinzipalnamens für das Dienstkonto, mit dem der PerformancePoint-Dienst auf dem Anwendungsserver ausgeführt wird

Überprüfen des Dienstprinzipalnamens von Analysis Services für das SQL Server Analysis Services-Dienstkonto, vmlab\svcSQLAS (erfolgt in Szenario 3)

und

(Optional) Überprüfen des Dienstkontos des SQL Server-Datenbankmoduls, vmlab\svcSQL (erfolgt in Szenario 2).

Konfigurieren eingeschränkter Kerberos-Delegierung für das Forderungen an den Windows-Tokendienst (C2WTS)-Dienstkonto für Analysis Services

Konfigurieren der eingeschränkten Kerberos-Delegierung für das PerformancePoint-

Services-Dienstkonto für Analysis Services


Starten des Forderungen an den Windows-Tokendiensts (C2WTS) auf Servern mit PerformancePoint Services

Starten der PerformancePoint Services-Dienstinstanz auf dem Server mit PerformancePoint Services

Erstellen der PerformancePoint Services-Dienstanwendung und des Proxys

Überprüfen der Identität der PerformancePoint-Anwendung

Erteilen von Berechtigungen für die Inhaltsdatenbank der

192



Webanwendung für das PerformancePoint Services-Dienstkonto

Konfigurieren des vertrauenswürdige Dateispeicherorts und von Authentifizierungseinstellungen für PerformancePoint Services

Überprüfen der eingeschränkten PerformancePoint Services-Delegierung

Erstellen einer Dokumentbibliothek zum Hosten eines Testdashboards

Erstellen einer Datenquelle, die auf einen vorhandenen SQL Server Analysis Services-Cube verweist

Erstellen einer vertrauenswürdigen PerformancePoint-Inhaltsliste

Erstellen des PerformancePoint-Testdashboards

Veröffentlichen des Dashboards in SharePoint Server



193


In diesem Szenario wird das PerformancePoint Services-Dienstkonto für die eingeschränkte Kerberos-Delegierung für den SQL Server-Dienst konfiguriert.

Hinweis:

In diesem Szenario wird der Forderungen an den Windows-Tokendienst (C2WTS) für die Verwendung eines dedizierten Dienstkontos konfiguriert. Wenn Sie den Forderungen an den Windows-Tokendienst (C2WTS) weiter das Konto Lokales System verwenden lassen, müssen Sie die eingeschränkte Delegierung für das Computerkonto des Computers konfigurieren, auf dem der Forderungen an den Windows-Tokendienst (C2WTS) und Excel Services ausgeführt werden.


Die Authentifizierung in diesem Szenario beginnt mit der Clientauthentifizierung über Kerberos auf dem Web-Front-End-Server. SharePoint Server 2010 wandelt das Windows-Authentifizierungstoken mithilfe des lokalen Sicherheitstokendiensts in ein Forderungstoken um. Die PerformancePoint Services-Anwendung akzeptiert das Forderungstoken und wandelt es mithilfe des zum Windows Identity Framework (WIF) gehörenden Forderungen an den Windows-Tokendienst (C2WTS) in ein Windows-Token (Kerberos) um. Die PerformancePoint Services-Anwendung verwendet anschließend das Kerberos-Ticket zur Authentifizierung bei der Datenquelle im Back-End.

194




Erstellen eines PerformancePoint Services-DienstkontosEmpfohlen wird, die PerformancePoint Services-Anwendung unter ihrer eigenen Domänenidentität auszuführen. Zum Konfigurieren der PerformancePoint Services-Anwendung muss ein Active Directory-Konto erstellt und in SharePoint Server 2010 als verwaltetes Konto registriert werden. Weitere Informationen zu finden Sie unter Verwaltete Konten in SharePoint 2010. In diesem Beispiel wird das folgende Konto erstellt und später in diesem Szenario registriert:


PerformancePoint-Dienste vmlab\svcPPS

* HINWEIS: Sie können optional ein einzelnes Domänenkonto für mehrere Dienste wiederverwenden. Diese Konfiguration wird in den folgenden Abschnitt nicht behandelt.

Erstellen eines Dienstprinzipalnamens für das Dienstkonto, mit dem der PerformancePoint-Dienst auf dem Anwendungsserver ausgeführt wirdDie Kerberos-Delegierung wird zumeist im Active Directory-Snap-In Benutzer und Computer konfiguriert. Hierfür muss dem zu konfigurierenden Active Directory-Objekt ein Dienstprinzipalname zugeordnet werden. Andernfalls wird die Registerkarte Delegierung des Objekts in dessen Eigenschaftendialogfeld nicht angezeigt. Wenngleich PerformancePoint Services für den Betrieb keinen Dienstprinzipalnamen benötigt, wird für diesen Zweck einer konfiguriert. Beachten Sie, dass wenn dem Dienstkonto bereits ein Dienstprinzipalname zugeordnet wurde (bei gemeinsamer Nutzung von Konten durch Dienste), dieser Schritt nicht erforderlich ist.

SETSPN -S SP/PPS vmlab\svcPPS


195

http://blogs.technet.com/b/wbaer/archive/2010/04/11/managed-accounts.aspx


Hinweis:


Überprüfen des Dienstprinzipalnamens von Analysis Services für das SQL Server Analysis Services-Dienstkonto, vmlab\svcSQLAS (erfolgt in Szenario 3) UND (Optional) Überprüfen des Dienstkontos des SQL Server-Datenbankmoduls, vmlab\svcSQL (erfolgt in Szenario 2)Stellen Sie sicher, dass der Dienstprinzipalname für das SQL Analysis Services-Konto (vmlab\svcSQLAS) vorhanden ist, indem Sie den folgenden SetSPN-Befehl verwenden:

SetSPN -L vmlab\svcSQLAS



Überprüfen Sie mit dem folgenden SetSPN-Befehl, ob der Dienstprinzipalname für das SQL Server-Dienstkonto (vmlab\svcSQL) vorhanden ist:




196


Konfigurieren der eingeschränkten Kerberos-Delegierung zwischen dem PerformancePoint Services-Dienstkonto und dem SSAS-Dienst und optional für SQL ServerDamit PerformancePoint-Dienste die Identität des Clients delegieren können, muss die eingeschränkte Kerberos-Delegierung konfiguriert werden. Ferner müssen Sie die eingeschränkte Delegierung mit Protokollübergang für die Umwandlung von Forderungstoken in Windows-Token über den Forderungen an den Windows-Tokendienst (C2WTS) von Windows Identity Framework (WIF) konfigurieren.

Servern, auf denen PerformancePoint-Dienste ausgeführt werden, muss für die Delegierung von Anmeldeinformationen an alle Back-End-Dienste vertraut werden, bei denen sich PerformancePoint authentifiziert. Darüber hinaus muss das PerformancePoint Services-Dienstkonto ebenfalls für das Zulassen der Delegierung an dieselben Back-End-Dienste konfiguriert werden. Beachten Sie auch, dass HTTP/Portal und HTTP/Portal.vmlab.local für die Delegierung konfiguriert sind, um eine SharePoint-Liste als optionale Datenquelle für Ihr PerformancePoint-Dashboard hinzuzufügen.


Prinzipaltyp Prinzipalname

User Vmlab\svcC2WTS

User Vmlab\svcPPS




197



4. Wählen Sie anschließend Beliebiges Authentifizierungsprotokoll verwenden aus.

5. Klicken Sie auf die Schaltfläche Hinzufügen, um den Dienstprinzipal auszuwählen.


198


7. Wählen Sie das Dienstkonto aus, mit dem der Dienst ausgeführt wird, an den die Delegierung erfolgen soll (SQL Server, SQL Server Analysis Services oder beides).

Hinweis:

Dem ausgewählten Dienstkonto muss ein Dienstprinzipalname zugeordnet sein. In unserem Beispiel wurde der Dienstprinzipalname für dieses Konto in einem vorherigen Szenario konfiguriert. Weitere Informationen finden Sie in den Abschnitt Kerberos-Authentifizierung für SQL OLTP und Kerberos-Authentifizierung für SQL Analysis Services in diesem Dokument.


9. Wählen Sie die Dienstprinzipalnamen aus, an die die Delegierung erfolgen soll, und klicken Sie dann auf OK.

199



200


11. Wiederholen Sie diese Schritte für alle Delegierungspfade, die am Anfang dieses Abschnitts definiert wurden.


Konfigurieren und Starten des Forderungen an den Windows-Tokendiensts (C2WTS) auf Servern mit PerformancePoint ServicesDer Forderungen an den Windows-Tokendienst (C2WTS) ist eine Komponente von Windows Identity Foundation (WIF) und für das Umwandeln von Benutzeranspruchstoken in Windows-Token zuständig. Dies erfolgt in PerformancePoint Services, wenn die Dienste Anmeldeinformationen an ein Back-End-System delegieren müssen, das mit der integrierten Windows-Authentifizierung arbeitet. WIF wird mit

201


SharePoint Server 2010 bereitgestellt, der Forderungen an den Windows-Tokendienst (C2WTS) kann in der Zentraladministration gestartet werden.

Auf jedem PerformancePoint Services-Anwendungsserver muss der Forderungen an den Windows-Tokendienst (C2WTS) lokal ausgeführt werden. Dieser Dienst öffnet keine Ports, und Remoteaufrufer können nicht auf ihn zugreifen. Darüber hinaus muss die Dienstkonfigurationsdatei des Forderungen an den Windows-Tokendiensts (C2WTS) so konfiguriert werden, dass der lokalen aufrufenden Clientidentität vertraut wird.

Empfohlen wird, den Forderungen an den Windows-Tokendienst (C2WTS) mit einem dedizierten Dienstkonto und nicht als Lokales System (Standardkonfiguration) auszuführen. Das Dienstkonto des Forderungen an den Windows-Tokendiensts (C2WTS) erfordert spezielle lokale Berechtigungen für jeden Server, auf dem der Dienst ausgeführt wird. Vergewissern Sie sich, dass Sie diese Berechtigungen konfiguriert haben, wenn Sie den Forderungen an den Windows-Tokendienst (C2WTS) mit einem Domänenkonto ausführen. Um sicherzustellen, dass das Konto des Forderungen an den Windows-Tokendienst (C2WTS) die benötigten Registerkarten auswählt, starten Sie den Server nach der Konfiguration des Forderungen an den Windows-Tokendiensts (C2WTS) neu.

*HINWEIS: Wenn Sie den Forderungen an den Windows-Tokendienst (C2WTS) als Lokales System konfigurieren, müssen Sie keine weitere lokalen Berechtigungen konfigurieren.




SetSPN -S SP/C2WTS vmlab\svcC2WTS

3. Konfigurieren Sie die eingeschränkte Kerberos-Delegierung für das Dienstkonto des Forderungen an den Windows-Tokendiensts (C2WTS). In diesem Szenario werden Anmeldeinformationen an den SQL Server-Dienst delegiert, der mit dem Dienstprinzipalnamen MSOLAPsvc.3/MySqlCluster.vmlab.local ausgeführt wird.

202




203









8. Wählen Sie im Auswahlfeld Server rechts oben den/die Server aus, auf dem/denen PerformancePoint-Dienste ausgeführt werden. In diesem Beispiel heißt der Server VMSP10APP01.


204



Hinweis:

Wenn der Forderungen an den Windows-Tokendienst (C2WTS) bereits ausgeführt wurde, bevor Sie das dedizierte Dienstkonto konfiguriert haben, oder Sie die Berechtigungen des Dienstkontos nach Start des Forderungen an den Windows-Tokendiensts (C2WTS) ändern müssen, starten Sie den Dienst über die Konsole Dienste neu.


Hinzufügen von Startabhängigkeiten zum Forderungen an den Windows-Tokendienst (C2WTS) im WIFBeim Forderungen an den Windows-Tokendienst (C2WTS) gibt es ein bekanntes Problem. Der Dienst wird bei einem Systemneustart nicht automatisch erfolgreich

205


gestartet. Dieses Problem kann behoben werden, indem für die Kryptografiedienste eine Abhängigkeit konfiguriert wird:

1. Öffnen Sie das Eingabeaufforderungsfenster.

2. Geben Sie Folgendes ein: sc config c2wts depend= CryptSvc



206




7. Starten Sie den Server neu. Vergewissern Sie sich, dass der Forderungen an den Windows-Tokendienst (C2WTS) nach dem Neustart des Computers gestartet wurde.

Starten der PerformancePoint Services-Dienstinstanz auf dem Server mit PerformancePoint ServicesStarten Sie vor dem Erstellen einer PerformancePoint Services-Dienstanwendung den PerformancePoint Services-Dienst auf den vorgesehenen Farmservern. Weitere Informationen zur PerformancePoint Services-Konfiguration finden Sie unter PerformancePoint Services-Verwaltung auf Microsoft TechNet.



3. Wählen Sie im Auswahlfeld Server rechts oben den/die Server aus, auf dem/denen PerformancePoint-Dienste ausgeführt werden. In diesem Beispiel heißt der Server VMSP10APP01.

207

http://technet.microsoft.com/de-de/library/ee681490.aspx


4. Starten Sie den Dienst PerformancePoint Services.

Erstellen der PerformancePoint Services-Dienstanwendung und des ProxysKonfigurieren Sie anschließend eine neue PerformancePoint Services-Dienstanwendung und einen Anwendungsproxy, um Webanwendungen die Nutzung von PerformancePoint Services zu ermöglichen:



208


3. Klicken Sie auf Neu und dann auf PerformancePoint Services-Anwendung.

4. Konfigurieren Sie die neue Dienstanwendung. Wählen Sie das ordnungsgemäße Dienstkonto aus, oder erstellen Sie ein neues verwaltetes Konto, falls noch nicht geschehen.

209


Hinweis:

Das Konfigurieren des unbeaufsichtigten Dienstkontos ist in diesem Szenario optional und nur erforderlich, wenn Sie auch die NTLM-Authentifizierung testen möchten.

Sie können ein neues Dienstkonto für einen vorhandenen dedizierten Anwendungspool für PerformancePoint Services vor diesem Schritt oder beim Erstellen des neuen PerformancePoint-Diensts erstellen und registrieren. Zum Zuordnen des Dienstkontos

210


zu einem vorhandenen dedizierten Anwendungspool für PerformancePoint oder Überprüfen eines vorhandenen Kontos führen Sie die folgenden Schritte aus.

1. Klicken Sie auf der Website für die Zentraladministration im Abschnitt Sicherheit auf Verwaltete Konten konfigurieren.

2. Wählen Sie im Dropdownfeld den Anwendungspool aus.

3. Wählen Sie das Active Directory-Konto aus.

Erteilen von Berechtigungen für die Inhaltsdatenbank der Webanwendung für das PerformancePoint Services-DienstkontoEin erforderlicher Schritt bei der Konfiguration von SharePoint Server 2010-Office-Webanwendungen besteht darin, dem Dienstkonto der Webanwendung den Zugriff auf die Inhaltsdatenbanken einer bestimmten Webanwendung zu ermöglichen. In diesem Beispiel wird dem PerformancePoint Services-Konto Zugriff auf die Inhaltsdatenbank der Webanwendung „portal“ über Windows PowerShell erteilt.



$w.GrantAccessToProcessIdentity("vmlab\svcPPS")

211


Konfigurieren des vertrauenswürdige Dateispeicherorts und von Authentifizierungseinstellungen für PerformancePoint ServicesNach Erstellen der PerformancePoint Services-Anwendung müssen Sie die Eigenschaften der neuen Dienstanwendung konfigurieren, um einen vertrauenswürdigen Hostspeicherort und Authentifizierungseinstellungen anzugeben.



3. Klicken Sie auf den Link der neuen Dienstanwendung PerformancePoint Services, und klicken Sie auf dem Menüband auf Verwalten.

4. Klicken Sie auf dem Bildschirm zur Verwaltung von PerformancePoint Services auf Vertrauenswürdige Datenquellen-Speicherorte.

212


5. Wählen Sie die Option Nur bestimmte Orte aus, und klicken Sie auf Vertrauenswürdigen Datenquellen-Speicherort hinzufügen.

6. Geben Sie die URL des Speicherorts ein, wählen Sie die Option Websitesammlung (und Unterstruktur) aus, und klicken Sie dann auf OK.

7. Wählen Sie die Option Nur bestimmte Orte aus, und klicken Sie auf Vertrauenswürdigen Datenquellen-Speicherort hinzufügen.

213


8. Geben Sie die URL des Speicherorts ein, wählen Sie die Option Website (und Unterstruktur) aus, und klicken Sie dann auf OK.

214


Überprüfen der eingeschränkten PerformancePoint Services-DelegierungHinweis: In größeren Umgebungen mit mehreren Servern mit Active Directory müssen Sie ggf. den Abschluss der Active Directory-Replikation abwarten, bevor Sie mit der Überprüfung der Konfiguration beginnen.

Erstellen eines PerformancePoint-Testdashboards mit einer SQL Server Analysis Services-DatenverbindungÖffnen Sie als Nächstes PerformancePoint Dashboard Designer, und erstellen Sie eine Analysis Services-Datenverbindung.

1. Öffnen Sie PerformancePoint Dashboard Designer, und klicken Sie dann mit der rechten Maustaste, um eine Verbindung zu erstellen.

2. Wählen Sie Analysis Services aus.

215


3. Geben Sie den Server, die Datenbank und den Cube an, und wählen Sie Identität pro Benutzer aus.

216


4. Klicken Sie auf Datenquelle testen, um die Verbindung zu testen.

217


5. Erstellen Sie einen Bericht und ein Dashboard.

6. Vergewissern Sie sich, dass Sie über eine Datenverbindung verfügen, indem Sie Measures und Dimensionen aus dem Detailbereich in den Berichts-Designer ziehen.

218


7. Ihr Bericht kann in das Dashboard einbezogen werden.

Wählen Sie Berichte aus, und ziehen Sie dann Mein Bericht auf die Seite Dashboardinhalt.

Veröffentlichen des Dashboards in SharePoint ServerDer letzte Schritt bei der Überprüfung der PerformancePoint Services-Anwendung ist das Veröffentlichen des Dashboards und Testen der Aktualisierung und Anzeige der Analysis Services-Daten. Gehen Sie dazu folgendermaßen vor:

1. Klicken Sie auf das helle Dateischaltflächensymbol.

219


2. Klicken Sie im Dateiauswahlbereich auf Bereitstellen.

3. Wählen Sie eine Gestaltungsvorlage aus, in der die Veröffentlichung erfolgen soll.

4. Klicken Sie im Browser auf die Schaltfläche Aktualisieren.

Wenn die Datenverbindung aktualisiert wird, haben Sie die Kerberos-Delegierung für PerformancePoint Services erfolgreich konfiguriert.

220


221


Identitätsdelegierung für Business Connectivity Services (SharePoint Server 2010)Veröffentlichung: 02.12.10

In diesem Szenario konfigurieren Sie die Business Data Connectivity-Dienstanwendung für die Verwendung der eingeschränkten Kerberos-Delegierung zur Authentifizierung bei SQL Server. Nach Abschluss der Konfiguration erstellen Sie einen neuen externen Inhaltstyp und eine externe Liste, um die Authentifizierung und Lesevorgänge in einer SharePoint-Website zu testen.

In diesem Szenario befinden sich die SharePoint Server-Farm und die BCS-Datenquelle beide in der gleichen Domäne. Daher konfigurieren wir eingeschränkte Kerberos-Delegierung, um die Identitätsdelegierung an die Back-End-Datenquelle zu ermöglichen. Wenn Sie sich bei Datenquellen in anderen Domänen in der gleichen Gesamtstruktur authentifizieren müssen, müssen Sie einfache (nicht eingeschränkte) Kerberos-Delegierung konfigurieren. Denken Sie daran, dass BCS den Forderungen-zu-Windows-Tokens-Dienst (C2WTS) nicht nutzt und daher einfache Delegierung verwenden kann.

Hinweis:



222





Voraussetzungen für dieses SzenarioDamit Sie dieses Szenario durcharbeiten können, müssen Sie Folgendes bereits ausgeführt haben:





Active Directory-Konfiguration Erstellen des BCS-Anwendungsdienstkontos

Überprüfen der Dienstprinzipalnamen

Delegierung konfigurieren

SharePoint Server-Konfiguration BCS-Dienstinstanz starten

BCS-Dienstanwendung erstellen

Überprüfung Externen BCS-Inhaltstyp erstellen

Sicherheit für BCS konfigurieren

Erstellen einer externen BCS-Liste

Öffnen der externen Liste im Browser

223



224




Erstellen des BCS-AnwendungsdienstkontosEs wird empfohlen, Business Connectivity Services unter einer eigenen Domänenidentität auszuführen. Zum Konfigurieren der BCS-Anwendung müssen Sie ein Active Directory-Konto erstellen. Bei diesem Beispiel wurden die folgenden Konten erstellt:


Business Connectivity Services vmlab\svcBDC

Überprüfen der DienstprinzipalnamenExterne BCS-Inhaltstypen werden innerhalb des Kontexts des IIS-Anwendungspools mithilfe des ECT-Typs ausgeführt, wenn BCS-Daten in SharePoint-Websites verwendet werden. Damit BCS mithilfe von Kerberos-Authentifizierung eine Verbindung zu externen Datenquellen herstellt und bei diesen Datenquellen eine Authentifizierung durchführt, müssen für die Dienstkonten des IIS-Anwendungspools und für das Dienstkonto für die externe Datenquelle Dienstprinzipalnamen konfiguriert sein. Informationen zum Konfigurieren und Überprüfen der erforderlichen Dienstprinzipalnamen in den Webanwendungen und SQL Server-Dienstkonten finden Sie in den Szenarien 1 und 2 in diesem Dokument.

Konfigurieren der DelegierungDamit BCS die Identität des Clients delegieren kann, muss Kerberos-Delegierung konfiguriert werden. Technisch gesehen ist zwar die eingeschränkte Delegierung nicht erforderlich – beispielsweise kann in Excel Services uneingeschränkte Delegierung für BCS verwendet werden –, doch hat es sich bewährt, den Umfang der Delegierungen zu begrenzen, die der Dienst ausführen kann. Deshalb wird in diesem Beispiel eingeschränkte Delegierung konfiguriert.

225


Jedes IIS-Anwendungspool-Dienstkonto, von dem die Website mit dem externen Inhaltstyp gehostet wird, muss so konfiguriert werden, dass Delegierung an die Back-End-Dienste erlaubt ist.

In unserem Beispiel werden die folgenden Delegierungspfade benötigt:


User svcPortal10App MSSQLSVC/MySqlCluster.vmlab.local:1433

User svcTeams10App MSSQLSVC/MySqlCluster.vmlab.local:1433




226



Hinweis:

Wenn BCS bei Datenquellen innerhalb derselben Gesamtstruktur, aber außerhalb der Domäne, in der sich SharePoint Server befindet, authentifiziert werden muss, empfiehlt es sich, Computer bei Delegierungen aller Dienste vertrauen auszuwählen, um einfache Delegierung statt eingeschränkter Delegierung zu konfigurieren. Der externe BCS-Inhaltstyp wird im IIS-Arbeitsprozess der Webanwendung ausgeführt und verwendet nicht den Forderungen-zu-Windows-Tokens-Dienst (C2WTS). Denken Sie daran, dass eine gesamtstrukturübergreifende Kerberos-Delegierung nicht möglich ist.

4. Klicken Sie auf die Schaltfläche Hinzufügen, um den Dienstprinzipal auszuwählen, an den delegiert werden kann.

227




228


Hinweis:



8. Wählen Sie die zu delegierenden Dienstprinzipalnamen aus, und klicken Sie dann auf OK.


Die ausgewählten Dienstprinzipalnamen sollten nun in der Liste Dienste, für die dieses Konto delegierte Anmeldeinformationen verwenden kann angezeigt werden:

229


10. Wiederholen Sie diese Schritte für jeden Delegierungspfad, der weiter oben in diesem Abschnitt angegeben wurde.



230






Starten der BCS-DienstinstanzBevor Sie eine BCS-Dienstanwendung erstellen, starten Sie den BCS-Dienst auf den vorgesehenen Farmservern.


2. Wählen Sie unter Dienste die Option Dienste auf dem Server verwalten aus.

3. Wählen Sie im Feld Serverauswahl in der rechten oberen Ecke den bzw. die Server mit Excel Services. In diesem Beispiel ist dies VMSP10APP01.

4. Starten Sie den Business Data Connectivity-Dienst.

Erstellen der BCS-DienstanwendungKonfigurieren Sie als Nächstes eine neue BDC-Dienstanwendung und einen Anwendungsproxy, damit Webanwendungen BDC-Dienste verwenden können:



231


3. Klicken Sie auf Neu und dann auf Business Data Connectivity-Dienst.

4. Konfigurieren Sie die neue Dienstanwendung. Wählen Sie das ordnungsgemäße Dienstkonto aus (erstellen Sie ein neues verwaltetes Konto, falls das BDC-Dienstkonto nicht in der Liste enthalten ist).

232


Überprüfung

Erstellen eines externen BCS-InhaltstypsFür den Zugriff auf externe Daten über BDC muss ein externer BDC-Inhaltstyp erstellt werden. Im aktuellen Beispiel erstellen wir den externen Inhaltstyp mithilfe von SharePoint Designer 2010 in der Portalwebanwendung (http://portal):

1. Öffnen Sie SharePoint Designer 2010.

2. Öffnen Sie die Testwebsitesammlung unter „http://portal“.

233


3. Klicken Sie im linken Navigationsbereich auf Externe Inhaltstypen.

4. Klicken Sie im Abschnitt Neu des Menübands in der linken oberen Ecke der Seite auf Externer Inhaltstyp.

234


5. Geben Sie einen Anzeigenamen für den externen Inhaltstyp ein.

235


6. Klicken Sie dann auf Klicken Sie hier, um externe Datenquellen zu ermitteln und Vorgänge zu definieren.

7. Klicken Sie auf Verbindung hinzufügen.

236


8. Wählen Sie in der Dropdownliste Datenquellentyp den Eintrag SQL Server aus, und fügen Sie die Informationen zum Herstellen der Verbindung zur Testdatenbank hinzu. Wählen Sie unbedingt Verbindung mit der Identität des Benutzers herstellen aus, um die Delegierung zu testen.

237


9. Erweitern Sie die neue Verbindung. Klicken Sie mit der rechten Maustaste auf die Testtabelle (Sales), und wählen Sie Alle Vorgänge erstellen aus.

10. Es sollte eine Fehlermeldung angezeigt werden, wonach kein eindeutiger Bezeichner definiert ist. Wählen Sie die Bezeichnerspalte aus, und aktivieren Sie das Kontrollkästchen Zuzuordnender Bezeichner. Klicken Sie auf Fertig stellen, um die Standardoptionen zu übernehmen und die Vorgänge für den externen Inhaltstyp zu erstellen.

238


11. Klicken Sie auf Speichern (STRG+S). Dadurch wird der externe Inhaltstyp im Metadatenspeicher der BDC-Dienstanwendung gespeichert.

Konfigurieren der Sicherheit für BCSBevor Clients den externen BCS-Inhaltstyp in der Portalwebanwendung verwenden können, müssen BCS-Berechtigungen konfiguriert werden. BCS unterstützt ein differenziertes Berechtigungsmodell. Zu Demozwecken konfigurieren wir jedoch Sicherheit auf der Metadatenspeicherebene und geben die Änderungen in Bezug auf Sicherheit an alle Objekte im Speicher weiter.



239


3. Klicken Sie auf den Link für die neue Dienstanwendung, in diesem Beispiel Business Data Services.

4. Wählen Sie Berechtigungen für den Metadatenspeicher festlegen aus.

240


5. Im aktuellen Beispiel haben wir für Organisations-Admins alle Berechtigungen und für Alle authentifizierten Benutzer alle Berechtigungen mit Ausnahme von Berechtigungen festlegen erteilt.

6. Stellen Sie sicher, dass das Kontrollkästchen Berechtigungen weitergeben aktiviert ist, und klicken Sie auf OK, um die Änderungen zu speichern.

Erstellen einer externen BCS-ListeZum Testen des externen Inhaltstyps konfigurieren wir eine externe Liste zum Anzeigen der externen Daten in der Portalanwendung:

1. Öffnen Sie SharePoint Designer 2010.


241


3. Wählen Sie im linken Bereich Externe Inhaltstypen aus.

242


243


4. Klicken Sie auf den Inhaltstyp, den Sie zuvor erstellt haben.

5. Klicken Sie auf dem Menüband auf Listen und Formulare erstellen.

6. Klicken Sie bei der Aufforderung, den externen Inhaltstyp zu speichern, auf Ja.

7. Geben Sie im Dialogfeld Liste und Formular erstellen im Textfeld Listenname einen Namen für die Liste ein, und klicken Sie auf OK.

Öffnen der externen Liste im Browser1. Öffnen Sie SharePoint Designer 2010.


244


3. Klicken Sie im linken Navigationsbereich auf Listen und Bibliotheken.

4. Wählen Sie die externe Liste am unteren Ende der Liste Listen und Bibliotheken aus.

5. Klicken Sie auf die Schaltfläche Browservorschau.

245


Internet Explorer wird geöffnet, und die ausgewählte Website und externe Liste wird angezeigt.

246


6. Vergewissern Sie sich, dass die externen Daten korrekt angezeigt werden. Zur weiteren Überprüfung der Verbindung ändern Sie die Quelldaten in SQL Server Management Studio und aktualisieren die Browserseite. Die Datenänderungen sollten im Browser wiedergegeben werden.

247


Bekannte Kerberos-Konfigurationsprobleme (SharePoint Server 2010)Veröffentlichung: 02.12.10

Kerberos-Authentifizierung und Nicht-StandardportsEs gibt ein bekanntes Problem mit Kerberos-Clients (u. a. .NET Framework, Internet Explorer 7 und 8), die beim Versuch der Authentifizierung mit für Kerberos aktivierten Webanwendungen, die für Nicht-Standardports (andere Ports als 80 und 443) konfiguriert sind, keine ordnungsgemäßen Dienstprinzipalnamen bilden. Die Ursache des Problems ist, dass der Client den Dienstprinzipalnamen in der TGS-Anforderung nicht ordnungsgemäß bildet, da die Angabe ohne Portnummer erfolgt (wie beim Sname der TGS-Anforderung gesehen).

Beispiel:

Wenn die Webanwendung unter http://intranet.contoso.com:1234 ausgeführt wird, fordert der Client ein Ticket für den Dienst mit dem Dienstprinzipalnamen http/intranet.contoso.com anstatt http/intranet.contoso.com:1234 an.

Einzelheiten zu dem Problem finden Sie in den folgenden Artikeln:

Internet Explorer 6 kann nicht das Kerberos-Authentifizierungsprotokoll verwenden, um eine Verbindung zu einer Website herzustellen, die einen nicht standardmäßigen Port in Windows XP und Windows Server 2003 verwendet (http://support.microsoft.com/kb/908209/de-de)

Konfigurieren der Kerberos-Authentifizierung (Office SharePoint Server 2007) (http://go.microsoft.com/fwlink/?LinkId=196987&clcid=0x407)

Registrieren Sie zum Umgehen dieses Problems Dienstprinzipalnamen mit und ohne Portnummer. Beispiel:

http://intranet.contoso.com:12345

248






http/intranet

http/intranet.contoso.com

http/intranet:12345

http/intranet.contoso.com:12345

Es wird empfohlen, den Nicht-Standardport zu registrieren, um sicherstellen, dass bei Behebung des Problems in einem künftigen Service Pack oder Hotfix die Anwendungen, die die Problemumgebung verwenden, weiter funktionieren.

Beachten Sie, dass diese Problemumgehung bei folgenden Bedingungen nicht funktioniert:

Am Nicht-Standardport werden mehrere Webanwendungen ausgeführt.

Die Webanwendungen sind entweder an den Hostnamen des Servers oder denselben Hostheader (an unterschiedlichen Ports) gebunden.

Die IIS-Anwendungspools der Webanwendung verwenden unterschiedliche Dienstkonten.

http://server.contoso.com:5000 AppPool Id: contoso\svcA

http://server.contoso.com:5001 AppPool Id: contoso\svcB

Wenn diese Bedingungen zutreffen, führt das Befolgen der Empfehlung in dieser Problemumgehung zu doppelten Dienstprinzipalnamen, die bei verschiedenen Dienstkonten registriert sind, wodurch die Kerberos-Authentifizierung nicht mehr funktioniert.

Wenn es mehrere Websites mit einem gemeinsamen Hostnamen gibt, der an mehreren Ports verwendet wird, und Sie unterschiedliche IIS-Anwendungspoolidentitäten für die Webanwendungen verwenden, kann die Kerberos-Authentifizierung nicht für alle Websites verwendet werden. (Eine Anwendung kann mit Kerberos arbeiten, während die anderen ein anderes Authentifizierungsprotokoll benötigen.) Damit Kerberos bei diesem Szenario für alle Anwendungen verwendet werden kann, müssen Sie einen der folgenden Schritte ausführen:

1. Alle Webanwendungen unter einem gemeinsamen Dienstkonto ausführen

2. Jede Website mit einem eigenen Hostheader ausführen

249


Kerberos-Authentifizierung und DNS CNAMEsEs gibt ein bekanntes Problem mit Kerberos-Clients (u. a. .NET Framework, Internet Explorer 7 und 8), die versuchen, sich mit für Kerberos aktivierten Diensten zu authentifizieren und für die eine Auflösung mithilfe von DNS CNAMEs anstatt mithilfe von A-Einträgen konfiguriert ist. Die Ursache des Problems ist, dass der Client in der TGS-Anforderung den Dienstprinzipalnamen nicht ordnungsgemäß bildet, da er unter Verwendung des Hostnamens (A-Eintrag) anstatt des Aliasnamens (CNAME) erstellt wird.

Beispiel:

A-Eintrag: wfe01.contoso.com

CNAME: intranet.contoso.com (als Alias zu wfe01.contoso.com)

Wenn der Client eine Authentifizierung mit http://intranet.contoso.com versucht, bildet der Client den Dienstprinzipalnamen nicht ordnungsgemäß und fordert ein Kerberos-Ticket für http/wfe01.contoso.com anstatt für http/intranet.contoso.com an.

Einzelheiten zu dem Problem finden Sie in den folgenden Artikeln:



Konfigurieren Sie zum Umgehen dieses Problems für Kerberos aktivierte Dienste mit DNS A-Einträgen anstatt CNAME-Aliasen. Der im Knowledge Base-Artikel erwähnte Hotfix korrigiert dieses Problem für Internet Explorer, aber nicht für .NET Framework (das von Microsoft Office SharePoint Server für die Webdienstkommunikation verwendet wird).

250




Kerberos- und Kernelmodusauthentifizierung

Hinweis:

Die Kernelmodusauthentifizierung wird von SharePoint Server 2010-Produkten nicht unterstützt. Diese Angaben dienen ausschließlich zu Informationszwecken.

Ab Internetinformationsdienste 7.0 (IIS) gibt es mit der Kernelmodusauthentifizierung eine neue Authentifizierungsmöglichkeit. Wenn eine IIS-Website für die Kernelmodusauthentifizierung konfiguriert ist, werden die Anforderungen des Clients automatisch durch HTTP.sys und nicht durch den Arbeitsprozess des Anwendungspools authentifiziert. Da HTTP.sys im Kernelmodus ausgeführt wird, ergibt sich eine bessere Leistung, wenn auch mit ein wenig mehr Komplexität hinsichtlich der Konfiguration von Kerberos. Der Grund ist, dass HTTP.sys unter der Identität des Computers und nicht unter der des Arbeitsprozesses ausgeführt wird. Wenn HTTP.sys ein Kerberos-Ticket empfängt, wird automatisch versucht, das Ticket mithilfe des Entschlüsselungsschlüssels (bzw. geheimen Schlüssels) des Servers und nicht mithilfe des Schlüssels der Identität zu entschlüsseln, unter der der Arbeitsprozess ausgeführt wird.

Wenn ein einzelner Webserver für die Kernelmodusauthentifizierung konfiguriert ist, funktioniert Kerberos ohne zusätzliche Konfiguration oder Dienstprinzipalnamen, da der Server automatischen einen Host-Dienstprinzipalnamen registriert, wenn er der Domäne hinzugefügt wird. Wenn mehrere Webserver dem Lastenausgleich unterliegen, funktioniert die Standardkonfiguration der Kernelmodusauthentifizierung nicht bzw. zwischenzeitlich nicht, da der Client keine Möglichkeit hat sicherzustellen, dass das in der TSG-Anforderung empfangene Dienstticket mit dem Server funktioniert, der die Anforderung authentifiziert.

Gehen Sie zum Umgehen dieses Problems wie folgt vor:

Deaktivieren Sie die Kernelmodusauthentifizierung.

Konfigurieren Sie HTTP.sys zum Entschlüsseln von Diensttickets für die Verwendung der Identität des IIS-Anwendungspools. Siehe Einstellungen für die Kernelmodusauthentifizierung in Internetinformationsdienste 7.0 (Internet Information Services, IIS).

Sie benötigen ggf. auch einen Hotfix, wenn Sie HTTP.sys für die Verwendung der Anmeldeinformationen des Anwendungspools konfigurieren: Update: Wenn das

251






AppPoolCredentials-Attribut auf „True“ festgelegt ist, erhalten Sie eine Stop 0x000000A5-Fehlermeldung auf einem blauen Bildschirm, wenn Sie ein Domänenkonto als Identität des Anwendungspools in IIS 7.0 verwenden

Kerberos- und sitzungsbasierte AuthentifizierungBei der Verwendung der Kerberos-Authentifizierung mit IIS 7.0 oder höher kommt es ggf. zu mehr Authentifizierungsdatenverkehr, was an die Windows-Authentifizierungseinstellungen in IIS liegen kann, insbesondere an Folgendem:

Einstellung Beschreibung

AuthPersistNonNTLM Optionales boolesches Attribut.

Gibt an, ob IIS automatisch alle Nicht-NTLM-Anforderungen (z. B. Kerberos) erneut authentifiziert, auch diejenigen über dieselbe Verbindung. Falls True, werden mehrere Authentifizierungen für dieselben Verbindungen aktiviert.

Der Standardwert ist False.

Hinweis:

Die Einstellung False bedeutet, dass der Client für dieselbe Verbindung nur einmal authentifiziert wird. IIS speichert ein Token oder Ticket auf dem Server für eine TCP-Sitzung, das eingerichtet bleibt.

authPersistSingleRequest Optionales boolesches Attribut.

Die Einstellung True gibt an, dass die Authentifizierung nur für eine einzelne Anforderung über eine Verbindung gilt. IIS setzt die Authentifizierung am Ende jeder Anforderung zurück und erzwingt die erneute Authentifizierung für die nächste Anforderung der Sitzung.

Der Standardwert ist False.

252




Anweisungen zum Konfigurieren der Authentifizierungspersistenz in IIS 7.0 finden Sie unter Möglicherweise verlangsamte Leistung, wenn Sie die integrierte Windows-Authentifizierung mit Kerberos-Authentifizierungsprotokoll in IIS 7.0 verwenden und Implementierung der Zugriffssteuerung.

Kerberos-Authentifizierung und Probleme mit doppelten/fehlenden DienstprinzipalnamenBeim Konfigurieren der Kerberos-Authentifizierung kann es leicht passieren, dass doppelte Dienstprinzipalnamen konfiguriert werden, insbesondere wenn Sie SetSPN -A oder das ADSI Edit-Tool (adsiedit.msc) zum Erstellen Ihrer Dienstprinzipalnamen verwenden. Generell wird empfohlen, zum Erstellen von Dienstprinzipalnamen SetSPN -S zu verwenden, da der Parameter -S nach einem doppelten Dienstprinzipalnamen sucht, bevor der angegebene Dienstprinzipalname erstellt wird.

Wenn Sie in Ihrer Umgebung doppelte Dienstprinzipalnamen vermuten, rufen Sie den Befehl SetSPN -X auf, um alle doppelten Dienstprinzipalnamen in Ihrer Umgebung abzurufen (nur unter Windows 2008 und höher). Wenn Dienstprinzipalnamen zurückgegeben werden, sollten Sie untersuchen, warum die Dienstprinzipalnamen registriert wurden, und nicht benötigte Duplikate löschen. Wenn Sie zwei Dienste haben, die mit zwei unterschiedlichen Identitäten ausgeführt werden, und beide denselben Dienstprinzipalnamen nutzen, müssen Sie einen dieser Dienste entweder für die Verwendung eines anderen Dienstprinzipalnamens konfigurieren oder beide eine gemeinsame Dienstidentität verwenden lassen.

Wenn Sie vermuten, dass ein Dienstprinzipalname nicht bzw. nicht im erforderlichen Format registriert wurde, können Sie den Befehl SetSPN -Q <Dienstprinzipalname einfügen> aufrufen, um zu prüfen, ob ein bestimmter Dienstprinzipalname vorhanden ist.

253





Maximale Größe des Kerberos-TokensIn bestimmten Umgebungen sind Benutzer ggf. Mitglieder vieler Active Directory-Gruppen, wodurch sich die Größe ihrer Kerberos-Tickets erhöhen kann. Wenn die Tickets zu groß werden, kann die Kerberos-Authentifizierung misslingen. Weitere Informationen zum Anpassen der maximalen Tokengröße finden Sie unter Neue Lösung für Probleme mit Kerberos-Authentifizierung, wenn Benutzer mehreren Gruppen angehören (http://support.microsoft.com/kb/327825/de-de).

Hinweis:

Beachten Sie beim Anpassen der maximalen Tokengröße, dass bei Festlegung einer maximalen Tokengröße über den Maximalwert der Registrierungseinstellung hinaus, es ggf. zu Kerberos-Authentifizierungsfehlern kommt. Als maximale Tokengröße sollte 65535 (dezimal) bzw. FFFF (hexadezimal) nicht überschritten werden.

Hotfixes für die Kerberos-Authentifizierung für Windows Server 2008 und Windows VistaKerberos-Authentifizierung misslingt bei Verwenden des AES-Algorithmus auf einem Computer mit Windows Server 2008 oder Windows Vista mit dem Fehlercode 0X80090302 oder 0x8009030f (http://support.microsoft.com/kb/969083/de-de)

Sie müssen ggf. auf allen Computern mit Windows Server 2008 und Windows Vista in Ihrer Umgebung einen Hotfix für die Kerberos-Authentifizierung installieren. Dazu zählen alle Computer mit SharePoint Server 2010, SQL Server bzw. Windows Server 2008, bei denen sich SharePoint Server mithilfe der Kerberos-Authentifizierung authentifizieren möchte. Befolgen Sie die Anweisung auf der Supportseite zum Anwenden des Hotfix, wenn die dokumentierten Symptome in Ihrer Umgebung auftreten sollten.

254








Zurücksetzen des C2WTS-Kontos (SharePoint Server 2010)Veröffentlichung: 02.12.10

Szenario: Das C2WTS-Konto (Claims to Windows Token Service, Forderungen an den Windows-Tokendienst) wird versehentlich geändert oder muss auf den Standardwert zurückgesetzt werden.

LösungDer Forderungen an den Windows-Tokendienst (C2WTS) kann nicht mithilfe der Zentraladministration auf das lokale Systemkonto zurückgesetzt werden. Die folgenden Windows PowerShell-Cmdlets können zum Zurücksetzen des Forderungen an den Windows-Tokendiensts (C2WTS) auf das lokale System verwendet werden.

Starten Sie die SharePoint-Verwaltungsshell auf dem Computer mit SharePoint Server.

Führen Sie das folgende Cmdlet aus, um eine Liste der Dienste anzuzeigen.

Get-SPServiceInstance

Suchen und kopieren Sie die ID des Forderungen an den Windows-Tokendiensts (C2WTS). Klicken Sie mit der rechten Maustaste in das Windows PowerShell-Fenster, und wählen Sie Markieren aus. Auf diese Weise können Sie die ID mit dem Mauscursor auswählen und kopieren. Drücken Sie die EINGABETASTE auf der Tastatur, nachdem Sie die ID hervorgehoben haben.

Testen Sie die ID durch Ausführen des folgenden Cmdlets.

255


Get-SPServiceInstance -identity <ID des Forderungen an den Windows-Tokendiensts (C2WTS) einfügen>

Klicken Sie mit der rechten Maustaste in das PowerShell-Fenster, und fügen Sie die zuvor kopierte ID ein.

Legen Sie im nächsten Schritt eine Variable fest, indem Sie das folgende Cmdlet ausführen:

$claims = get-spserviceinstance -identity <ID des Forderungen an den Windows-Tokendiensts (C2WTS) einfügen>

Führen Sie die folgenden Cmdlets aus, um C2WTS auf das lokale System zurückzusetzen:

$claims.Service.ProcessIdentity.CurrentIdentityType=0 // The 0 in the preceding line is IdentityType.LocalSystem $claims.Service.ProcessIdentity.Update() $claims.Service.ProcessIdentity.Deploy() $claims.Service.ProcessIdentity // This output demonstrates that the cmdlet was successful CurrentIdentityType : LocalSystem CurrentSecurityIdentifier : S-1-5-18 ManagedAccount : ProcessAccount : S-1-5-18 Username : NT AUTHORITY\SYSTEM

256

Documents

Konfigurieren der Kerberos-Authentifizierung für ...download.microsoft.com/download/4/5/E/45E08010-776… · Web viewIn diesem Dokument wird das Konzept der Identität in Microsoft