Planen der Benutzerauthentifizierungsmethoden in SharePoint Server
GILT FÜR:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Hinweis
Die hier erwähnten Benutzerauthentifizierungsmethoden gelten für SharePoint Server 2013, SharePoint Server 2016, SharePoint Server 2019 und SharePoint Server-Abonnementedition.
Wir erläutern Ihnen die Verwendung der von SharePoint Server unterstützten Benutzerauthentifizierungstypen und -methoden und erklären Ihnen, wie Sie entscheiden können, welche Typen und Methoden jeweils die richtige Wahl für Ihre Webanwendungen und Zonen sind.
Erfahren Sie mehr über die SharePoint-Authentifizierung in Microsoft 365.
Hinweis
In der SharePoint Server-Abonnementedition unterstützen wir jetzt die OIDC 1.0-Authentifizierung. Weitere Informationen zum Arbeiten mit diesem neuen Authentifizierungstyp finden Sie unter OpenID Connect 1.0-Authentifizierung.
Einführung
Benutzerauthentifizierung ist die Überprüfung der Identität eines Benutzers gegenüber einem Authentifizierungsanbieter, bei dem es sich um ein Verzeichnis oder eine Datenbank handelt, das die Anmeldeinformationen des Benutzers enthält und bestätigen kann, dass der Benutzer sie ordnungsgemäß übermittelt hat. Ein Beispiel für einen Authentifizierungsanbieter ist Active Directory Domain Services (AD DS). Andere Begriffe für den Authentifizierungsanbieter sind Benutzerverzeichnis und Attributspeicher.
Eine Authentifizierungsmethode ist ein bestimmter Austausch von Kontoanmeldeinformationen und anderen Informationen, die die Identität eines Benutzers bestätigen. Das Ergebnis der Authentifizierungsmethode ist ein Beweis, meist in der Form eines Tokens, das Ansprüche enthält, dass ein Authentifizierungsanbieter einen Benutzer authentifiziert hat.
Ein Authentifizierungstyp ist eine bestimmte Möglichkeit zum Überprüfen von Anmeldeinformationen anhand mindestens eines Authentifizierungsanbieters, wobei gelegentlich ein Branchenstandardprotokoll verwendet wird. Ein Authentifizierungstyp kann mehrere Authentifizierungsmethoden verwenden.
Nachdem die Identität eines Benutzers überprüft wurde, wird im Autorisierungsverfahren ermittelt, auf welche Websites, Inhalte und anderen Features der Benutzer zugreifen kann.
Ihre Planung für Benutzerauthentifizierungstypen und -methoden sollte Folgendes bestimmen:
Die Benutzerauthentifizierungstypen und -methoden für alle Webanwendungen und -zonen
Die erforderliche Authentifizierungsinfrastruktur zum Unterstützen der festgelegten Authentifizierungstypen und -methoden
Hinweis
Die Authentifizierung im klassischen Windows-Modus wird in SharePoint Server 2016, SharePoint Server 2019 und sharePoint Server Subscription Edition nicht mehr unterstützt.
Anspruchsbasierte Authentifizierung
Die Benutzeridentität in AD DS basiert auf einem Benutzerkonto. Für eine erfolgreiche Authentifizierung gibt der Benutzer den Kontonamen an und beweist, dass ihm das Kennwort bekannt ist. Damit der Zugriff auf Ressourcen bestimmt werden kann, müssen Anwendungen möglicherweise AD DS nach Kontoattributen und weiteren Informationen abfragen, beispielsweise Gruppenmitgliedschaft oder Rolle im Netzwerk. Diese Funktionalität eignet sich zwar gut für Windows-Umgebungen, kann aber nicht auf Authentifizierungsanbieter von Drittanbietern und Umgebungen mit mehreren Anbietern skaliert werden, die Internet-, Partner- oder cloudbasierte Computingmodelle unterstützen.
Bei Verwendung von anspruchsbasierten Identitäten ruft ein Benutzer ein digital signiertes Sicherheitstoken von einem allgemein vertrauenswürdigen Identitätsanbieter ab. Das Token enthält einen Satz von Ansprüchen. Jeder Anspruch stellt ein bestimmtes Element von Daten zu Benutzern dar, z. B. deren Namen, Gruppenmitgliedschaften und Rolle im Netzwerk. Die anspruchsbasierte Authentifizierung ist eine Benutzerauthentifizierung, die anspruchsbasierte Identitätstechnologien und -infrastrukturen verwendet. Anwendungen, die die anspruchsbasierte Authentifizierung unterstützen, rufen anstelle von Anmeldeinformationen ein Sicherheitstoken von Benutzern ab und verwenden die Informationen in den Ansprüchen zum Bestimmen des Zugriffs auf Ressourcen. Eine separate Abfrage an einen Verzeichnisdienst wie z. B. AD DS ist nicht erforderlich.
Die anspruchsbasierte Authentifizierung in Windows baut auf Windows Identity Foundation (WIF) auf, einem Satz von .NET Framework-Klassen, mit denen die anspruchsbasierte Identität implementiert wird. Eine weitere Grundlage für die anspruchsbasierte Authentifizierung sind Standards wie WS-Federation, WS-Trust und Protokolle wie etwa SAML (Security Assertion Markup Language).
Weitere Informationen zur anspruchsbasierten Authentifizierung finden Sie in folgenden Ressourcen:
Aufgrund der verbreiteten Verwendung der anspruchsbasierten Authentifizierung zur Server-zu-Server-Authentifizierung und App-Authentifizierung empfehlen wir die anspruchsbasierte Authentifizierung für alle Webanwendungen und Zonen einer SharePoint Server-Farm. Weitere Informationen finden Sie unter Planen der Server-zu-Server-Authentifizierung in SharePoint Server. Wenn Sie die anspruchsbasierte Authentifizierung verwenden, sind alle unterstützten Authentifizierungsmethoden für Ihre Webanwendungen verfügbar, und Sie können neue Features und Szenarien in SharePoint Server nutzen, die Server-zu-Server- und App-Authentifizierung verwenden.
Für die anspruchsbasierte Authentifizierung ändert SharePoint Server automatisch alle Benutzerkonten in Anspruchsidentitäten. Diese Änderungen führen zu einem Sicherheitstoken (auch als Anspruchstoken bezeichnet) für jeden Benutzer. Das Anspruchstoken enthält die Ansprüche, die sich auf den Benutzer beziehen. Windows-Konten werden in Windows-Ansprüche konvertiert. Formularbasierte Mitgliedschaftsbenutzer werden in formularbasierte Authentifizierungsansprüche transformiert. SharePoint Server kann Ansprüche verwenden, die in SAML-basierten Token enthalten sind. Darüber hinaus können SharePoint-Entwickler und -Administratoren Benutzertoken mit weiteren Ansprüchen erweitern. Windows-Benutzerkonten und formularbasierte Konten können beispielsweise um zusätzliche Ansprüche erweitert werden, die von SharePoint Server verwendet werden.
Sie müssen kein Anspruchsarchitekt sein, um die anspruchsbasierte Authentifizierung in SharePoint Server verwenden zu können. Allerdings erfordert die Implementierung der auf SAML-Token basierenden Authentifizierung eine Koordination mit den Administratoren der anspruchsbasierten Umgebung, wie in Planen der auf SAML-Token basierenden Authentifizierung beschrieben.
Authentifizierung im klassischen Modus in SharePoint Server 2013
Wenn Sie in der SharePoint 2013-Zentraladministration eine Webanwendung erstellen, können Sie nur Authentifizierungstypen und -methoden für die anspruchsbasierte Authentifizierung angeben. In früheren SharePoint-Versionen war in der Zentraladministration auch der klassische Authentifizierungsmodus für Webanwendungen konfigurierbar. Der klassische Authentifizierungsmodus verwendet die Windows-Authentifizierung, und SharePoint 2013 behandelt die Benutzerkonten wie AD DS-Konten.
To configure a web application to use classic mode authentication, you must use the New-SPWebApplication PowerShell cmdlet to create it. SharePoint 2010 Products web applications that are configured for classic mode authentication retain their authentication settings when you upgrade to SharePoint 2013. Wir empfehlen jedoch, dass Sie Ihre Webanwendungen vor dem Upgrade auf SharePoint 2013 zur anspruchsbasierten Authentifizierungsmethode migrieren.
Eine SharePoint 2013-Farm kann eine Kombination aus Webanwendungen enthalten, für die beide Modi verwendet werden. Einige Dienste unterscheiden nicht zwischen Benutzerkonten, bei denen es sich um herkömmliche Windows-Konten handelt, und Windows-Anspruchskonten.
Weitere Informationen zum Migrieren vor dem Upgrade finden Sie unter Migrieren von der klassischen Authentifizierung zur anspruchsbasierten Authentifizierung.
Weitere Informationen zum Migrieren nach dem Upgrade finden Sie unter Migrate from classic-mode to claims-based authentication in SharePoint Server.
Informationen zum Erstellen von Webanwendungen in SharePoint 2013, die den klassischen Authentifizierungsmodus verwenden, finden Sie unter Erstellen von Webanwendungen, die die klassische Authentifizierung in SharePoint Server verwenden. Sie können eine Webanwendung, die anspruchsbasierte Authentifizierung verwendet, nicht migrieren, um die Authentifizierung im klassischen Modus zu verwenden.
Wichtig
Office Online kann nur von SharePoint 2013-Webanwendungen verwendet werden, von denen die anspruchsbasierte Authentifizierung genutzt wird. Das Rendern und die Bearbeitung mit Office Online funktioniert nicht für SharePoint 2013-Webanwendungen, von denen der klassische Authentifizierungsmodus genutzt wird. Wenn Sie SharePoint 2010-Webanwendungen, von denen der klassische Authentifizierungsmodus genutzt wird, zu SharePoint 2013 migrieren, müssen Sie dafür die Migration zur anspruchsbasierten Authentifizierung vornehmen, um die Verwendung mit Office Online zu ermöglichen.
Unterstützte Authentifizierungstypen und -methoden
SharePoint Server unterstützt verschiedene Authentifizierungsmethoden und Authentifizierungsanbieter für die folgenden Authentifizierungstypen:
Windows-Authentifizierung
Formularbasierte Authentifizierung
Auf SAML-Token basierende Authentifizierung
Windows-Authentifizierung
Der Windows-Authentifizierungstyp nutzt Ihren vorhandenen Windows-Authentifizierungsanbieter (AD DS) und die Authentifizierungsprotokolle, die eine Windows-Domänenumgebung zum Überprüfen der Anmeldeinformationen von verbundenen Clients verwendet. Die Windows-Authentifizierungsmethode, die von beiden anspruchsbasierten Authentifizierungen verwendet wird, umfasst Folgendes:
NTLM
Kerberos
Digest
Basic
Weitere Informationen hierzu finden Sie in diesem Artikel unter Planen der Windows-Authentifizierung.
Video zur Windows-Anspruchsauthentifizierung in SharePoint 2013 und SharePoint Server 2016
Obwohl kein Windows-Authentifizierungstyp, unterstützt SharePoint Server auch die anonyme Authentifizierung. Benutzer können auf SharePoint-Inhalte zugreifen, ohne ihre Anmeldeinformationen zu überprüfen. Die anonyme Authentifizierung ist standardmäßig deaktiviert. In der Regel verwenden Sie die anonyme Authentifizierung, wenn Sie SharePoint Server verwenden, um Inhalte zu veröffentlichen, die keine Sicherheit erfordern und für alle Benutzer verfügbar sind, z. B. eine öffentliche Internetwebsite.
Zusätzlich zum Aktivieren der anonymen Authentifizierung müssen Sie auch den anonymen Zugriff (Berechtigungen) auf Websites und Websiteressourcen konfigurieren.
Hinweis
Iis-Websites (Internetinformationsdienste), die von SharePoint für die Bereitstellung von Webanwendungen erstellt werden, haben immer die Methoden Anonyme Authentifizierung und Formularauthentifizierung aktiviert, auch wenn die SharePoint-Einstellung für anonyme Und Formularauthentifizierung deaktiviert ist. Dies ist beabsichtigt, und das Deaktivieren der anonymen oder Formularauthentifizierung direkt in den IIS-Einstellungen führt zu Fehlern auf der SharePoint-Website.
Formularbasierte Authentifizierung
Die formularbasierte Authentifizierung ist ein anspruchsbasiertes Identitätsverwaltungssystem, das auf der ASP.NET-Mitgliedschafts- und Rollenanbieterauthentifizierung basiert. Die formularbasierte Authentifizierung kann für Anmeldeinformationen verwendet werden, die in einem Authentifizierungsanbieter gespeichert sind, z. B.:
AD DS
Eine Datenbank wie z. B. eine SQL Server-Datenbank
Ein LDAP-Datenspeicher (Lightweight Directory Access-Protokoll) wie z. B. Novell eDirectory, Novell Directory Services (NDS) oder Sun ONE
Mit der formularbasierten Authentifizierung werden Benutzer anhand der Anmeldeinformationen überprüft, die Sie in ein Anmeldeformular eingeben (für gewöhnlich eine Webseite). Nicht authentifizierte Anforderungen werden an eine Anmeldeseite umgeleitet, auf der ein Benutzer gültige Anmeldeinformationen angeben und das Formular übermitteln muss. Das System gibt ein Cookie für authentifizierte Anforderungen aus, das einen Schlüssel zum Wiederherstellen der Identität für nachfolgende Anforderungen enthält.
Video zur formularbasierten Anspruchsauthentifizierung in SharePoint 2013 und SharePoint Server 2016
Hinweis
Bei der formularbasierten Authentifizierung werden die Benutzerkonto-Anmeldeinformationen als Nur-Text gesendet. Aus diesem Grund sollten Sie die formularbasierte Authentifizierung nicht verwenden, es sei denn, Sie verwenden auch SSL (Secure Sockets Layer) zum Verschlüsseln des Website-Datenverkehrs.
Weitere Informationen finden Sie unter Planen der formularbasierten Authentifizierung.
Auf SAML-Token basierende Authentifizierung
Die auf SAML-Token basierende Authentifizierung in SharePoint Server verwendet das SAML 1.1-Protokoll sowie WS-F RFP (WS-Federation Passive Requestor Profile). Sie erfordert eine Koordination mit den Administratoren der jeweiligen anspruchsbasierten Umgebung, ganz gleich, ob es sich um Ihre eigene interne Umgebung oder eine Partnerumgebung handelt. Wenn Sie Active Directory-Verbunddienste (AD FS) 2.0 verwenden, verfügen Sie über eine auf SAML-Token basierende Authentifizierungsumgebung.
Eine auf SAML-Token basierende Authentifizierungsumgebung beinhaltet einen Sicherheitstokendienst für Identitätsanbieter (Identity Provider Security Token Service, IP-STS). Der IP-STS stellt SAML-Token im Namen von Benutzern aus, deren Konten im zugehörigen Benutzerverzeichnis enthalten sind. Token können eine beliebige Zahl von Ansprüchen für einen Benutzer enthalten, z. B. einen Benutzernamen sowie Gruppen, denen der Benutzer angehört. Ein AD FS 2.0-Server ist ein Beispiel für einen IP-STS.
In SharePoint Server werden Ansprüche verwendet, die in von einem IP-STS für autorisierte Benutzer bereitgestellten Token enthalten sind. In anspruchsbasierten Umgebungen wird eine Anwendung, die SAML-Token akzeptiert, als eine Anwendung für den Sicherheitstokendienst der vertrauenden Seite (Relying Party-STS-Anwendung, RP-STS) bezeichnet. Eine Anwendung für die vertrauende Seite empfängt das SAML-Token und entscheidet anhand der darin enthaltenen Ansprüche, ob dem Client Zugriff auf die angeforderte Ressource erteilt wird. In SharePoint Server wird jede Webanwendung, die für die Verwendung eines SAML-Anbieters konfiguriert ist, dem IP-STS-Server als separater RP-STS-Eintrag hinzugefügt. Eine SharePoint-Farm kann mehrere verschiedene RP-STS-Einträge im IP-STS haben.
Video zur SAML-basierten Anspruchsauthentifizierung in SharePoint 2013 und SharePoint Server 2016
Die Authentifizierungsanbieter für die auf SAML-Token basierende Authentifizierung hängen vom IP-STS in Ihrer Anspruchsumgebung ab. Wenn Sie AD FS 2.0 verwenden, können Authentifizierungsanbieter (für AD FS 2.0 als Attributspeicher bezeichnet) Folgendes umfassen:
Windows Server 2003 Active Directory und AD DS in Windows Server 2008
Alle Editionen von SQL Server 2005 und SQL Server 2008
Benutzerdefinierte Attributspeicher
Weitere Informationen finden Sie unter Planen der auf SAML-Token basierenden Authentifizierung.
Auswählen der Authentifizierungstypen für LDAP-Umgebungen
Die formularbasierte Authentifizierung und die auf SAML-Token basierende Authentifizierung können LDAP-Umgebungen verwenden. Verwenden Sie den Authentifizierungstyp, der Ihrer aktuellen LDAP-Umgebung entspricht. Wenn Sie noch nicht über eine LDAP-Umgebung verfügen, wird empfohlen, die formularbasierte Authentifizierung zu verwenden, da sie weniger komplex ist. Wenn Ihre Authentifizierungsumgebung jedoch bereits WS-Federation 1.1 und SAML 1.1 unterstützt, empfehlen wir SAML. SharePoint Server verfügt über einen integrierten LDAP-Anbieter.
Planen der Windows-Authentifizierung
Der Prozess der Planung und Implementierung von Windows-Authentifizierungsmethoden ist für die anspruchsbasierte Authentifizierung ähnlich. Die anspruchsbasierte Authentifizierung für eine Webanwendung erhöht die Komplexität der Implementierung von Windows-Authentifizierungsmethoden nicht. In diesem Abschnitt wird die Planung der Windows-Authentifizierungsmethoden zusammenfassend dargestellt.
NTLM und das Kerberos-Protokoll
Sowohl NTLM als auch das Kerberos-Protokoll sind integrierte Windows-Authentifizierungsmethoden, mit denen Benutzer problemlos authentifiziert werden können, ohne zur Eingabe von Anmeldeinformationen aufgefordert zu werden. Beispiel:
Benutzer, die in Internet Explorer auf SharePoint-Websites zugreifen, verwenden für die Authentifizierung die Anmeldeinformationen, unter denen der Internet Explorer-Prozess ausgeführt wird. Standardmäßig sind diese Anmeldeinformationen die Anmeldeinformationen, die der Benutzer zum Anmelden beim Computer verwendet hat.
Dienste oder Anwendungen, die integrierte Windows-Authentifizierungsmethoden für den Zugriff auf SharePoint-Ressourcen verwenden, versuchen sich anhand der Anmeldeinformationen des Threads, der gerade ausgeführt wird, zu authentifizieren. Dies ist standardmäßig die Identität des Prozesses.
NTLM ist die einfachste Form der Zu implementierenden Windows-Authentifizierung und erfordert in der Regel keine zusätzliche Konfiguration der Authentifizierungsinfrastruktur. Wählen Sie diese Option aus, wenn Sie die Webanwendung erstellen oder konfigurieren.
Das Kerberos-Protokoll unterstützt die Authentifizierungsticketausstellung. Die Verwendung des Kerberos-Protokolls erfordert mehr Konfiguration der Umgebung. Damit die 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. Bei der Konfiguration des Kerberos-Protokolls müssen vor dem Installieren von SharePoint Server Dienstprinzipalnamen (Service Principal Names, SPNs) in AD DS eingerichtet werden.
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 möglicherweise nicht geeignet:
Die Kerberos-Authentifizierung erfordert eine weiter gehende Konfiguration der Infrastruktur und der Umgebung als andere Authentifizierungsmethoden, damit sie ordnungsgemäß funktioniert. In vielen Fällen werden zum Konfigurieren des Kerberos-Protokolls Domänenadministratorrechte benötigt. Die Kerberos-Authentifizierung ist möglicherweise schwierig einzurichten und zu verwalten. 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-Bereitstellung ist das Schlüsselverteilungscenter ein AD DS-Domänencontroller. Obwohl diese Netzwerkkonfiguration in einem Intranet einer Organisation üblich ist, werden Bereitstellungen mit Internetzugriff in der Regel nicht auf diese Weise konfiguriert.
Folgende Schritte stellen eine Zusammenfassung der Konfiguration der Kerberos-Authentifizierung dar:
Konfigurieren Sie die Kerberos-Authentifizierung für die SQL Server-Kommunikation durch Erstellen von Dienstprinzipalnamen (SPNs) in AD DS für das SQL Server-Dienstkonto.
Erstellen Sie SPNs für Webanwendungen, für die Kerberos-Authentifizierung verwendet wird.
Installieren Sie die SharePoint Server-Farm.
Konfigurieren Sie einzelne Dienste innerhalb der Farm für die Verwendung von bestimmten Konten.
Erstellen Sie die Webanwendungen, für die Kerberos-Authentifizierung verwendet wird.
Digest- und Standardauthentifizierung
Bei der Digestauthentifizierungsmethode werden die Benutzerkonto-Anmeldeinformationen als ein MD5-Nachrichtenhash an den Internet Information Services (IIS)-Dienst auf dem Webserver gesendet, der die Webanwendung oder -zone hostet. Bei der Standardauthentifizierungsmethode werden die Benutzerkonto-Anmeldeinformationen als Nur-Text gesendet. Daher sollten Sie die Standardauthentifizierungsmethode nur verwenden, wenn Sie auch SSL verwenden, um den Websitedatenverkehr zu verschlüsseln.
Möglicherweise müssen Sie diese älteren Authentifizierungsmethoden verwenden, wenn Ihre Umgebung Webbrowser oder Dienste verwendet, die nur die Digest- oder Standardauthentifizierung für Websites unterstützen.
Im Gegensatz zu den NTLM-, Kerberos- und den anonymen Authentifizierungsmethoden konfigurieren Sie die Digest- und Standardauthentifizierungsmethoden in den Eigenschaften der Website, die der Webanwendung oder -zone im Internet Information Services (IIS)-Snap-In entspricht.
Wenn Sie die anspruchsbasierte Authentifizierung verwenden, finden Sie weitere Informationen unter:
Planen der formularbasierten Authentifizierung
Wenn Sie die formularbasierte Authentifizierung verwenden möchten, um Benutzer bei einem Identitätsverwaltungssystem zu authentifizieren, das nicht auf Windows oder extern basiert, müssen Sie den Mitgliedschaftsanbieter und den Rollen-Manager in der Web.config-Datei registrieren. SharePoint Server verwendet die standardmäßige ASP.NET-Rollen-Manager-Schnittstelle zur Erfassung von Gruppeninformationen über den aktuellen Benutzer. Jede ASP.NET-Rolle wird im Autorisierungsprozess in SharePoint Server als Domänengruppe behandelt. Rollen-Manager werden auf die gleiche Weise in der Datei "Web.config" registriert wie Mitgliedschaftsanbieter für die Authentifizierung.
Wenn Sie Mitgliedschaftsbenutzer oder -rollen über die Website für die Zentraladministration verwalten möchten, müssen Sie den Mitgliedschaftsanbieter und den Rollen-Manager in der Datei "Web.config" für die Website der Zentraladministration registrieren. Registrieren Sie den Mitgliedschaftsanbieter und den Rollen-Manager in der Web.config-Datei für die Webanwendung, die den Inhalt hostet.
Ausführliche Schritte für die Konfiguration der formularbasierten Authentifizierung finden Sie unter Konfigurieren der formularbasierten Authentifizierung für eine anspruchsbasierte Webanwendung in SharePoint Server.
Planen der auf SAML-Token basierenden Authentifizierung
Die Architektur für die Implementierung von auf SAML-Token basierenden Anbietern umfasst die folgenden Komponenten:
SharePoint-Sicherheitstokendienst Dieser Dienst erstellt die von der Farm verwendeten SAML-Token. Der Dienst wird auf allen Servern in einer Serverfarm automatisch erstellt und gestartet. Der Dienst wird für die farmübergreifende Kommunikation verwendet, da die gesamte farmübergreifende Kommunikation die anspruchsbasierte Authentifizierung verwendet. Dieser Dienst wird auch für Authentifizierungsmethoden verwendet, die für Webanwendungen implementiert sind, die die anspruchsbasierte Authentifizierung verwenden. Zu diesen Methoden gehören windows-Authentifizierung, formularbasierte Authentifizierung und SAML-tokenbasierte Authentifizierung.
Tokensignaturzertifikat (ImportTrustCertificate) Dieses Zertifikat ist das Zertifikat, das Sie aus einem IP-STS exportieren und dann auf einen Server in der Farm kopieren und es der Liste der vertrauenswürdigen Stammzertifizierungsstelle der Farm hinzufügen. Nachdem Sie dieses Zertifikat zum Erstellen eines SPTrustedIdentityTokenIssuer verwendet haben, können Sie es nicht mehr zum Erstellen eines weiteren Zertifikats verwenden. Wenn Sie mithilfe dieses Zertifikats ein anderes SPTrustedIdentityTokenIssuer-Objekt erstellen möchten, müssen Sie das vorhandene zuerst löschen. Vor dem Löschen müssen Sie zuerst die Zuordnungen des bestehenden Objekts zu Webanwendungen aufheben, von denen es möglicherweise verwendet wird.
Identitätsanspruch Der Identitätsanspruch ist der Anspruch aus einem SAML-Token, der der eindeutige Bezeichner des Benutzers ist. Nur der Besitzer des IP-STS weiß, welcher Wert in dem Token für jeden Benutzer immer eindeutig ist. Der Identitätsanspruch wird während der Zuordnung aller gewünschten Ansprüche als reguläre Anspruchszuordnung erstellt. Der Anspruch, der als Identitätsanspruch dient, wird bei der Erstellung des SPTrustedIdentityTokenIssuer-Objekts deklariert.
Sonstige Ansprüche Diese Ansprüche bestehen aus zusätzlichen Ansprüchen aus einem SAML-Ticket, die Benutzer beschreiben. Dies können Benutzerrollen, Benutzergruppen oder andere Arten von Ansprüchen wie etwa das Alter sein. Alle Anspruchszuordnungen werden als Objekte erstellt, die auf die Server in einer SharePoint Server-Farm repliziert werden.
Realm In the SharePoint claims architecture, the URI or URL that is associated with a SharePoint web application that is configured to use a SAML token-based provider represents a realm. When you create a SAML-based authentication provider on the farm, you specify the realms, or web application URLs, that you want the IP-STS to recognize, one at a time. The first realm is specified when you create the SPTrustedIdentityTokenIssuer. You can add more realms after you create the SPTrustedIdentityTokenIssuer. Bereiche werden mithilfe einer Syntax wie der folgenden angegeben:
$realm = "urn:sharepoint:mysites". After you add the realm to the SPTrustedIdentityTokenIssuer, you must create an RP-STS trust with the realm identifier on the IP-STS server. This process involves specifying the URL for the web application.SPTrustedIdentityTokenIssuer Dies ist das Objekt, das in der SharePoint-Farm erstellt wird und die Werte enthält, die für die Kommunikation mit und den Empfang von Token von der IP-STS erforderlich sind. Beim Erstellen von SPTrustedIdentityTokenIssuer geben Sie an, welches Tokensignaturzertifikat verwendet werden soll, den ersten Bereich, den Anspruch, der den Identitätsanspruch darstellt, und alle anderen Ansprüche. Sie können ein Tokensignaturzertifikat aus einem STS nur einem SPTrustedIdentityTokenIssuer zuordnen. Nachdem Sie spTrustedIdentityTokenIssuer erstellt haben, können Sie jedoch weitere Bereiche für zusätzliche Webanwendungen hinzufügen. Nachdem Sie dem SPTrustedIdentityTokenIssuer einen Bereich hinzugefügt haben, müssen Sie ihn auch der IP-STS als vertrauende Seite hinzufügen. Das SPTrustedIdentityTokenIssuer-Objekt wird serverübergreifend in der SharePoint Server-Farm repliziert.
Sicherheitstokendienst einer vertrauenden Seite (Relying Party Security Token Service, RP-STS) In SharePoint Server wird jede Webanwendung, die für die Verwendung eines SAML-Anbieters konfiguriert ist, dem IP-STS-Server als ein RP-STS-Eintrag hinzugefügt. Eine SharePoint Server-Farm kann mehrere RP-STS-Einträge enthalten.
Sicherheitstokendienst des Identitätsanbieters (IP-STS) Dieser Dienst ist das sichere Token in der Anspruchsumgebung, das SAML-Token im Namen von Benutzern ausstellt, die im zugehörigen Benutzerverzeichnis enthalten sind.
Das Diagramm unten illustriert eine auf SAML-Token basierende SharePoint Server-Anspruchsarchitektur.
SAML-Token-Anspruchsarchitektur
Das SPTrustedIdentityTokenIssuer-Objekt wird mit mehreren Parametern erstellt, darunter:
Ein einzelner Identitätsanspruch.
Ein einzelner SignInURL-Parameter .
Der Parameter SignInURL gibt die URL an, an die eine Benutzeranforderung umgeleitet werden soll, um sich beim IP-STS zu authentifizieren.
Ein einzelner Wreply-Parameter .
Einige IP-STS-Server erfordern den Wreply-Parameter , der entweder auf true oder false festgelegt ist. Standardwert ist False. Verwenden Sie den Wreply-Parameter nur, wenn er für IP-STS erforderlich ist.
Mehrere Bereiche.
Zuordnung mehrerer Ansprüche.
Um die saml-tokenbasierte Authentifizierung mit SharePoint Server zu implementieren, implementieren Sie die folgenden Schritte, die im Voraus geplant werden müssen:
Exportieren Sie das Tokensignaturzertifikat aus dem IP-STS. Kopieren Sie das Zertifikat auf einen Server in der SharePoint Server-Farm.
Definieren Sie den Anspruch, der als eindeutiger Bezeichner des Benutzers verwendet wird. Dieser Anspruch wird als Identitätsanspruch bezeichnet. Der Benutzerprinzipalname (User Principal Name, UPN) oder der E-Mail-Name des Benutzers wird häufig als Benutzerbezeichner verwendet. Legen Sie in Abstimmung mit dem Administrator des IP-STS den richtigen Bezeichner fest, da nur der Besitzer des IP-STS weiß, welcher Wert in dem Token für jeden Benutzer immer eindeutig ist. Das Bestimmen des eindeutigen Bezeichners für den Benutzer ist Teil des Vorgangs der Zuordnung von Ansprüchen. Anspruchszuordnungen werden mithilfe von Microsoft PowerShell erstellt.
Definieren Sie zusätzliche Anspruchszuordnungen. Definieren Sie die zusätzlichen Ansprüche aus dem eingehenden Token, das von der SharePoint Server-Farm verwendet wird. Benutzerrollen sind ein Beispiel für einen Anspruch, der für die Erteilung von Berechtigungen für Ressourcen in der SharePoint Server-Farm verwendet werden kann. Alle Ansprüche aus einem eingehenden Token, die keine Zuordnung aufweisen, werden verworfen.
Erstellen Sie mithilfe von PowerShell einen neuen Authentifizierungsanbieter, um das Tokensignaturzertifikat zu importieren. In diesem Prozess wird das SPTrustedIdentityTokenIssuer-Objekt erstellt. Während dieses Prozesses geben Sie den Identitätsanspruch und zusätzliche Ansprüche an, die Sie zugeordnet haben. Erstellen Sie einen Bereich, der den ersten SharePoint-Webanwendungen zugeordnet ist, die Sie für die SAML-tokenbasierte Authentifizierung konfigurieren, und geben Sie ihn an. Nachdem Sie spTrustedIdentityTokenIssuer erstellt haben, können Sie weitere Bereiche für zusätzliche SharePoint-Webanwendungen erstellen und hinzufügen. Mit diesem Verfahren können Sie mehrere Webanwendungen für die Verwendung desselben SPTrustedIdentityTokenIssuer konfigurieren.
Für jeden Bereich, den Sie dem SPTrustedIdentityTokenIssuer-Objekt hinzufügen, müssen Sie einen RP-STS-Eintrag im IP-STS erstellen. Sie können diesen Eintrag erstellen, bevor die SharePoint-Webanwendung vorhanden ist. Unabhängig davon müssen Sie die URL planen, bevor Sie die Webanwendungen erstellen.
Konfigurieren Sie eine vorhandene oder neue SharePoint-Webanwendung für die Verwendung des neu erstellten Authentifizierungsanbieters. Der Authentifizierungsanbieter wird beim Erstellen einer Webanwendung in Zentraladministration als vertrauenswürdiger Identitätsanbieter angezeigt.
Sie können mehrere Anbieter für die auf SAML-Token basierende Authentifizierung konfigurieren. Allerdings können Sie ein Tokensignaturzertifikat nur einmal in einer Farm verwenden. Alle konfigurierten Anbieter werden in der Zentraladministration als Optionen angezeigt. Ansprüche aus verschiedenen vertrauenswürdigen STS-Umgebungen führen nicht zu Konflikten.
Wenn Sie die auf SAML-Token basierende Authentifizierung mit einem Partnerunternehmen implementieren und Ihre eigene Umgebung einen IP-STS enthält, empfiehlt es sich, in Zusammenarbeit mit dem Administrator Ihrer internen Anspruchsumgebung eine unidirektionale Vertrauensstellung zwischen Ihrem internen IP-STS zum STS des Partners einzurichten. Für diesen Ansatz müssen Sie Ihrer SharePoint Server-Farm keinen Authentifizierungsanbieter hinzufügen. Außerdem haben Ihre Anspruchsadministratoren hierbei die Möglichkeit, die gesamte Anspruchsumgebung zu verwalten.
Wichtig
Bei Verwendung der anspruchsbasierten Authentifizierung in SharePoint Server ist es jetzt nicht mehr erforderlich, den Netzwerklastenausgleich auf eine einzelne Affinität festzulegen.
Hinweis
[!HINWEIS] Wenn eine Webanwendung für die Verwendung der auf SAML-Token basierenden Authentifizierung konfiguriert ist, wird von der SPTrustedClaimProvider-Klasse keine Suchfunktionalität für das Personenauswahl-Steuerelement zur Verfügung gestellt. Jeder in das Personenauswahl-Steuerelement eingegebene Text wird automatisch angezeigt, als wäre er aufgelöst worden, unabhängig davon, ob es sich um einen gültigen Benutzer, eine gültige Gruppe oder einen gültigen Anspruch handelt. Falls Ihre SharePoint Server-Lösung die auf SAML-Token basierende Authentifizierung verwendet, sollten Sie die Erstellung eines benutzerdefinierten Anspruchsanbieters planen, um eine benutzerdefinierte Suche und Namensauflösung zu implementieren.
Ausführliche Schritte zum Konfigurieren der auf SAML-Token basierenden Authentifizierung mithilfe von AD FS finden Sie unter Konfigurieren von SAML-basierter Anspruchsauthentifizierung mit ADFS in SharePoint Server.
Planen von Zonen für Webanwendungen
Zonen stellen verschiedene logische Pfade für den Zugriff auf die gleichen Websites in einer Webanwendung dar. Jede Webanwendung kann fünf Zonen enthalten. Wenn Sie eine Webanwendung erstellen, wird die Standardzone durch Zentraladministration erstellt. Zusätzliche Zonen werden durch Erweitern der Webanwendung und durch Auswahl einer der verbleibenden Zonennamen erstellt: "Extranet", "Internet" oder "Benutzerdefiniert".
Ihre Planung der Zonen hängt von Folgendem ab:
- Anspruchsbasierte Authentifizierung (empfohlen) - Sie können mehrere Authentifizierungsanbieter in einer einzelnen Zone implementieren. Sie können auch mehrere Zonen verwenden.
Implementieren mehrerer Authentifizierungstypen für eine einzige Zone
Wenn Sie die anspruchsbasierte Authentifizierung verwenden und mehr als eine Authentifizierungsmethode implementieren, wird die Implementierung mehrerer Authentifizierungsmethoden in der Standardzone empfohlen. Daraus ergibt sich die gleiche URL für alle Benutzer.
Wenn Sie mehrere Authentifizierungsmethoden für die gleiche Zone implementieren, gelten die folgenden Beschränkungen:
Sie können nur eine Instanz der formularbasierten Authentifizierung in einer Zone implementieren.
Zentraladministration ermöglicht Ihnen die gleichzeitige Verwendung einer integrierten Windows-Methode und der Standardmethode. Andernfalls können Sie nicht mehr als einen Typ der Windows-Authentifizierung in einer Zone implementieren.
Werden für eine Farm mehrere Anbieter für auf SAML-Token basierende Authentifizierung konfiguriert, werden diese als Optionen angezeigt, wenn Sie eine Webanwendung oder eine neue Zone erstellen. Sie können mehrere SAML-Anbieter für die gleiche Zone konfigurieren.
Das folgende Diagramm zeigt die Implementierung mehrerer Authentifizierungstypen in der Standardzone für eine Website für die Partnerzusammenarbeit.
Implementierung mehrerer Authentifizierungstypen in der Standardzone
Wie Sie in dem Diagramm sehen, greifen Benutzer aus unterschiedlichen Verzeichnisspeichern mithilfe der gleichen URL auf die Partnerwebsite zu. Der gestrichelte Rahmen um die Partnerunternehmen herum zeigt die Beziehung zwischen dem Benutzerverzeichnis und dem Authentifizierungstyp, der in der Standardzone konfiguriert ist.
Planen der Durchforstung von Inhalten
Die Durchforstungskomponente erfordert Zugriff auf Inhalte mithilfe von NTLM. Mindestens eine Zone muss für die Verwendung der NTLM-Authentifizierung konfiguriert sein. Wenn die NTLM-Authentifizierung nicht für die Standardzone konfiguriert ist, kann die Durchforstungskomponente eine andere Zone verwenden, die für die Verwendung der NTLM-Authentifizierung konfiguriert ist.
Implementieren von mehr als einer Zone
Wenn Sie mehrere Zonen für Webanwendungen implementieren möchten, beachten Sie die folgenden Richtlinien:
Implementieren Sie in der Standardzone die sichersten Authentifizierungseinstellungen. Wenn eine Anforderung keiner bestimmten Zone zugeordnet werden kann, werden die Authentifizierungseinstellungen und andere Sicherheitsrichtlinien der Standardzone angewendet. Die Standardzone wird bei der anfänglichen Erstellung einer Webanwendung erstellt. Die sichersten Authentifizierungseinstellungen werden in der Regel für den Endbenutzerzugriff entwickelt. Daher greifen Endbenutzer wahrscheinlich auf die Standardzone zu.
Verwenden Sie die Mindestanzahl von Zonen, die für die Bereitstellung von Zugriff für Benutzer erforderlich ist. Jede Zone wird einer neuen IIS-Website und -Domäne für den Zugriff auf die Webanwendung zugeordnet. Fügen Sie neue Zugriffspunkte nur dann hinzu, wenn sie erforderlich sind.
Stellen Sie sicher, dass mindestens eine Zone für die Verwendung der NTLM-Authentifizierung für die Durchforstungskomponente konfiguriert ist. Erstellen Sie keine dedizierte Zone für die Indexkomponente, es sei denn, dies ist erforderlich.
Im folgenden Diagramm werden mehrere Zonen gezeigt, die für die Verwendung unterschiedlicher Authentifizierungstypen für eine Website für die Partnerzusammenarbeit implementiert sind.
Eine Zone pro Authentifizierungstyp
In diesem Diagramm wird die Standardzone für externe Mitarbeiter verwendet. Jeder Zone ist eine andere URL zugeordnet. Mitarbeiter verwenden eine andere Zone, je nachdem, ob sie im Büro arbeiten oder remote arbeiten.