Planen der Kerberos-Authentifizierung in SharePoint Server
GILT FÜR:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365
Das Kerberos-Protokoll unterstützt eine Authentifizierungsmethode, bei der von einer vertrauenswürdigen Quelle bereitgestellte Tickets verwendet werden. Kerberos-Tickets geben an, dass die Netzwerk-Anmeldeinformationen eines Benutzers authentifiziert wurden, der einem Clientcomputer zugeordnet ist. Das Kerberos-Protokoll definiert die Interaktion von Benutzern mit einem Netzwerkdienst, um Zugriff auf Netzwerkressourcen zu erhalten. Das Kerberos-Schlüsselverteilungscenter (Key Distribution Center, KDC) gibt im Auftrag des Benutzers ein Ticket-genehmigendes Ticket (ticket-granting-ticket, TGT) an einen Clientcomputer aus. In Windows ist der Clientcomputer Mitglied einer AD DS (Active Directory Domain Services)-Domäne und das TGT beweist, dass die Benutzeranmeldeinformationen vom Domänencontroller authentifiziert wurden.
Vor dem Herstellen einer Netzwerkverbindung mit einem Netzwerkdienst übergibt der Clientcomputer das TGT an das KDC und fordert ein Dienstticket an. Basierend auf dem zuvor ausgegebenen TGT, das die Authentifizierung des Clientcomputers bestätigt, gibt das KDC ein Dienstticket an den Clientcomputer aus. Der Clientcomputer übermittelt das Dienstticket dann an den Netzwerkdienst. Das Dienstticket muss auch einen zulässigen Dienstprinzipalnamen (Service Principal Name, SPN) enthalten, der den Dienst identifiziert. Damit die Kerberos-Authentifizierung möglich ist, müssen der Client- und der Servercomputer bereits über eine vertrauenswürdige Verbindung zum Schlüsselverteilungscenter verfügen. Außerdem müssen Client- und Servercomputer auf AD DS zugreifen können.
Kerberos-Authentifizierung und SharePoint Server
Folgende Gründe sprechen für die Kerberos-Authentifizierung:
Das Kerberos-Protokoll ist das sicherste Protokoll für die integrierte Windows-Authentifizierung. Es unterstützt erweiterte Sicherheitsfeatures wie etwa AES-Verschlüsselung (Advanced Encryption Standard) und gegenseitige Authentifizierung von Clients und Servern.
Das Kerberos-Protokoll ermöglicht die Delegierung von Clientanmeldeinformationen.
Von den verfügbaren sicheren Authentifizierungsmethoden beansprucht Kerberos den wenigsten Netzwerkdatenverkehr zu AD DS-Domänencontrollern. Kerberos kann in bestimmten Szenarien die Seitenwartezeit verringern oder die Anzahl der Seiten, die ein Front-End-Webserver bedienen kann, erhöhen. Zudem kann Kerberos die Last auf den Domänencontrollern reduzieren.
Das Kerberos-Protokoll ist ein offenes Protokoll, das von zahlreichen Plattformen und Herstellern unterstützt wird.
Kerberos-Authentifizierung ist aus folgenden Gründen u. U. nicht geeignet:
Im Gegensatz zu anderen Authentifizierungsmethoden erfordert die Kerberos-Authentifizierung eine zusätzliche Konfiguration der Infrastruktur und der Umgebung, damit sie ordnungsgemäß funktioniert. In vielen Fällen werden Domänenadministratorrechte zum Konfigurieren der Kerberos-Authentifizierung benötigt, die u. U. schwierig einzurichten und zu verwalten sind. Wird Kerberos falsch konfiguriert, kann es sein, dass Ihre Websites nicht erfolgreich authentifiziert werden können.
Die Kerberos-Authentifizierung erfordert eine Anbindung des Clientcomputers an ein KDC und einen AD DS-Domänencontroller. In einer Windows- und SharePoint-Bereitstellung ist das Schlüsselverteilungscenter ein AD DS-Domänencontroller. Das ist zwar in einem Organisationsintranet eine übliche Netzwerkkonfiguration, für Bereitstellungen mit Internetzugriff jedoch eher untypisch.
Kerberos-Delegierung
Die Kerberos-Authentifizierung unterstützt die Delegierung von Clientidentitäten. Das bedeutet, dass ein Dienst die Identität eines authentifizierten Clients annehmen kann. Durch den Identitätswechsel kann ein Dienst die authentifizierte Identität im Namen des Clients an andere Netzwerkdienste übergeben. Auch die anspruchsbasierte Authentifizierung kann zum Delegieren von Clientanmeldeinformationen verwendet werden, dazu muss allerdings die Back-End-Anwendung Ansprüche unterstützen.
Bei Verwendung mit SharePoint Server ermöglicht es die Kerberos-Delegierung, dass ein Front-End-Dienst einen Client authentifiziert und sich dann anhand der Identität des Clients bei einem Back-End-System authentifiziert. Das Back-End-System führt dann eine eigene Authentifizierung durch. Wenn ein Client sich mithilfe der Kerberos-Authentifizierung bei einem Front-End-Dienst authentifiziert, kann mit der Kerberos-Delegierung die Identität eines Clients an ein Back-End-System übergeben werden. Das Kerberos-Protokoll unterstützt zwei Typen der Delegierung:
Kerberos-Standarddelegierung (uneingeschränkt)
Eingeschränkte Kerberos-Delegierung
Kerberos-Standarddelegierung und eingeschränkte Kerberos-Delegierung
Die Kerberos-Standarddelegierung funktioniert über Domänengrenzen innerhalb derselben Gesamtstruktur hinweg, aber nicht über die Grenzen von Gesamtstrukturen hinweg. Die eingeschränkte Kerberos-Delegierung funktioniert nicht über Domänen- oder Gesamtstrukturgrenzen hinweg, es sei denn, Sie verwenden Domänencontroller mit Windows Server 2012.
Je nachdem, welche Dienstanwendungen Teil einer SharePoint Server-Bereitstellung sind, kann bei Implementierung von Kerberos-Authentifizierungen mit SharePoint Server die eingeschränkte Kerberos-Delegierung erforderlich sein.
Wichtig
Um die Kerberos-Authentifizierung mit einer der folgenden Dienstanwendungen bereitzustellen, müssen sich SharePoint Server und alle externen Datenquellen in derselben Windows-Domäne befinden: > Excel Services > PerformancePoint Services > InfoPath Forms Services > Visio Services > Diese Dienstanwendungen sind in SharePoint Foundation 2013 nicht verfügbar. Excel Services ist in SharePoint Server 2016 nicht verfügbar.
Für die Bereitstellung von Kerberos-Authentifizierung mit einer bzw. einem der folgenden Dienstanwendungen oder -produkte kann SharePoint Server entweder Kerberos-Standarddelegierung oder eingeschränkte Delegierung verwenden:
Business Data Connectivity Service (diese Dienstanwendung ist in SharePoint Foundation 2013 nicht verfügbar)
Access Services (diese Dienstanwendung ist in SharePoint Foundation 2013 nicht verfügbar)
SQL Server Reporting Services (SSRS) (ein separates Produkt)
Project Server 2016 (ein separates Produkt)
Dienste, die Kerberos-Authentifizierung unterstützen, können Identitäten mehrmals delegieren. Während eine Identität zwischen Diensten übertragen wird, kann sich die Delegierungsmethode von Kerberos-Standarddelegierung in die eingeschränkte Kerberos-Delegierung ändern. Umgekehrt ist dies jedoch nicht möglich. Die Delegierungsmethode kann sich nicht von eingeschränkter in Kerberos-Standarddelegierung ändern. Daher ist es wichtig, im Vorfeld bereits zu klären, ob ein Back-End-Dienst Kerberos-Standarddelegierung erfordert, und entsprechend vorauszuplanen. Dies hat Auswirkungen auf die Planung und den Entwurf von Domänengrenzen.
Ein Kerberos-fähiger Dienst kann mithilfe des Protokollübergangs eine Kerberos-fremde Identität in eine Kerberos-Identität umwandeln, die dann an andere Kerberos-fähige Dienste delegiert werden kann. Diese Fähigkeit kann z. B. zum Delegieren einer Kerberos-fremden Identität von einem Front-End-Dienst an eine Kerberos-Identität in einem Back-End-Dienst verwendet werden.
Wichtig
[!WICHTIGER HINWEIS] Für den Protokollübergang ist die eingeschränkte Kerberos-Delegierung erforderlich. Deshalb können Identitäten mit Protokollübergang keine Domänengrenzen überwinden.
Alternativ zur Kerberos-Delegierung kann anspruchsbasierte Authentifizierung verwendet werden. Bei der anspruchsbasierten Authentifizierung kann der Authentifizierungsanspruch eines Clients zwischen verschiedenen Diensten übergeben werden, wenn die Dienste alle folgenden Kriterien erfüllen:
Zwischen den Diensten besteht eine Vertrauensstellung.
Die Dienste unterstützen Ansprüche.
Weitere Informationen zur Kerberos-Authentifizierung finden Sie in folgenden Ressourcen:
Kerberos-Authentifizierung und anspruchsbasierte Authentifizierung
SharePoint 2013 und SharePoint Server 2016 unterstützen anspruchsbasierte Authentifizierung. Die anspruchsbasierte Authentifizierung baut auf Windows Identity Foundation (WIF) auf, einem Satz der .NET Framework-Klassen, mit denen anspruchsbasierte Identität implementiert wird. Eine weitere Grundlage für diese Authentifizierungsmethode sind Standards wie WS-Federation und WS-Trust. Weitere Informationen zur anspruchsbasierten Authentifizierung finden Sie in folgenden Ressourcen:
Beim Erstellen einer SharePoint Server-Webanwendung mithilfe der Zentraladministration müssen Sie mindestens einen anspruchsbasierten Authentifizierungstyp wählen. Beim Erstellen einer SharePoint Server-Webanwendung mithilfe des Microsoft PowerShell-Cmdlets New-SPWebApplication können Sie entweder die Anspruchsauthentifizierung und Anspruchsauthentifizierungstypen oder den klassischen Authentifizierungsmodus angeben. Die Anspruchsauthentifizierung wird für alle SharePoint Server-Webanwendungen empfohlen. Bei Verwendung der Anspruchsauthentifizierung sind alle unterstützten Authentifizierungstypen für Ihre Webanwendungen verfügbar, und Sie können die Server-zu-Server-Authentifizierung sowie die App-Authentifizierung nutzen. Weitere Informationen finden Sie unter What's new in authentication for SharePoint Server 2013.
Wichtig
[!WICHTIGER HINWEIS] Bei den folgenden Dienstanwendungen in SharePoint Server müssen die anspruchsbasierten Anmeldeinformationen in Windows-Anmeldeinformationen übersetzt werden. Bei diesem Übersetzungsprozess wird der Anspruch an den Windows-Tokendienst (C2WTS): >Excel Services>PerformancePoint Services>InfoPath Forms Services>Visio Services>> Diese Dienstanwendungen sind in SharePoint Foundation 2013 nicht verfügbar. Excel Services ist in SharePoint Server 2016 nicht verfügbar.
Die Dienstanwendungen, die das C2WTS erfordern, müssen die eingeschränkte Kerberos-Delegierung verwenden, da C2WTS einen Protokollübergang erfordert, der nur von der eingeschränkten Kerberos-Delegierung unterstützt wird. Für die Dienstanwendungen in der vorherigen Liste übersetzt C2WTS Ansprüche innerhalb der Farm für die ausgehende Authentifizierung in Windows-Anmeldeinformationen. Es ist wichtig zu verstehen, dass diese Dienstanwendungen C2WTS nur verwenden können, wenn die eingehende Authentifizierungsmethode entweder Windows-Ansprüche oder der klassische Windows-Modus ist. Dienstanwendungen, auf die über Webanwendungen zugegriffen wird und SAML-Ansprüche (Security Assertion Markup Language) oder formularbasierte Authentifizierungsansprüche verwenden, verwenden C2WTS nicht. Daher können sie keine Ansprüche in Windows-Anmeldeinformationen übersetzen.
Kerberos-Authentifizierung und das neue SharePoint-App-Modell
Wenn Sie zur Benutzerauthentifizierung den Windows-Anspruchsmodus verwenden und die Webanwendung so konfiguriert ist, dass sie nur die Kerberos-Authentifizierung verwendet, ohne auf NTLM als Authentifizierungsprotokoll zurückzugreifen, funktioniert die App-Authentifizierung nicht. Weitere Informationen finden Sie unter Planen der App-Authentifizierung in SharePoint Server.
Siehe auch
Konzepte
Planen der Benutzerauthentifizierungsmethoden in SharePoint Server