Kerberos-Authentifizierung für Microsoft SharePoint 2010-Produkte (Übersicht)

 

Gilt für: SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

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

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

• Schrittweise 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 die 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.

Upgraden von Office SharePoint Server 2007

"Ich möchte wissen, was sich seit der Version 2007 geändert hat und worauf ich mich beim Upgraden 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:

• 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 Upgraden 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 1: Kernkonfiguration

• Szenario 2: Kerberos-Authentifizierung für SQL OLTP

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

• Szenario 4: Identitätsdelegierung für SQL Server 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-Dienste

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

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

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 Selektieren 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-Produkten

Wenn Sie sich mit dem Konzept der Identität im Zusammenhang mit der Authentifizierung in SharePoint 2010-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.

Eingehende Identität

Im 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 2010-Produkte unterstützen zwei Modi zum Authentifizieren eines Clients für die Plattform, nämlich den klassischen Modus und den anspruchsbasierten Modus.

Klassischer Modus

Der 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

Die integrierte Windows-Authentifizierung ermöglicht die problemlose Authentifizierung von Windows-Clients mit SharePoint Server, ohne dass Anmeldeinformationen (Benutzername/Kennwort) manuell eingegeben 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. 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 anhand der Anmeldeinformationen des gerade ausgeführten Threads zu authentifizieren; dies ist standardmäßig die Identität des Prozesses.

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 (https://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.

• 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 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. Zum Aktivieren der Kerberos-Authentifizierung müssen der Client- und Servercomputer über eine vertrauenswürdige Verbindung zur Schlüsselverteilungscenter-Domäne (Key Distribution Center, KDC) 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 (https://go.microsoft.com/fwlink/?linkid=196644&clcid=0x407) und Microsoft Kerberos. (https://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) (https://go.microsoft.com/fwlink/?linkid=196646&clcid=0x407).

Anspruchsbasierte Authentifizierung

Die 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 (https://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 transformiert.

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

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 Anspruchsanbieter (z. B. der 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 C2WTS

Für einige Dienstanwendungen müssen Sie C2WTS (Claims to Windows Token Service, Ansprüche für 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-Umgebung

SharePoint 2010-Produkte-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.

Ausgehende Identität

Die 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 Subsystem

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

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.

Delegierung

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

In SharePoint 2010-Produkte 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.

• 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 hinaus

Für die Szenarien in dieser Artikelfolge zur Kerberos-Authentifizierung müssen sich der SharePoint Server-Dienst und externe Datenquellen in derselben Windows-Domäne 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, Ansprüche für 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 Services

• InfoPath Forms Services

• Visio Services

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

• Business Data Connectivity Service und Microsoft Business Connectivity 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

Einführung in Ansprüche

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

Einführung in das Kerberos-Protokoll

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

Vorteile des Kerberos-Protokolls

Bevor 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 (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übergang

Das 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.
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 (https://technet.microsoft.com/de-de/library/cc739587(ws.10).aspx)

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

• Eingeschränkte Kerberos-Delegierung erfordert möglicherweise den Protokollübergang in Szenarien mit mehreren Hops (https://support.microsoft.com/kb/2005838/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 7

In 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 (https://go.microsoft.com/fwlink/?linkid=196655&clcid=0x407) und Verbesserungen bei Kerberos (https://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 (https://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-Produkten

Die meisten grundlegenden Konzepte zum Konfigurieren der Kerberos-Authentifizierung in SharePoint 2010-Produkte 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, Ansprüche für Windows-Tokendienst) verwenden. Die eingeschränkte Delegierung ist erforderlich, damit vom Protokollübergang Ansprüche in Windows-Token konvertiert werden können.

• 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-Produkte werden von Dienstanwendungen die anspruchsbasierte Authentifizierung und C2WTS verwendet, weshalb diese Änderungen nicht mehr nötig sind.

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

Überlegungen beim Upgraden von Office SharePoint Server 2007

Beim Upgraden einer Office SharePoint Server 2007-Farm auf SharePoint Server 2010 sollten Sie Folgendes 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, Ansprüche für Windows-Tokendienst) auf den Servern, auf denen Dienstanwendungen ausgeführt werden, für die eine Delegierung erforderlich ist (z. B. Excel Services, Visio-Grafikdienst).

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