Planen der Benutzerauthentifizierungsmethoden in SharePoint Server

 

**Gilt für:**SharePoint Server 2013, SharePoint Server 2016

**Letztes Änderungsdatum des Themas:**2018-03-02

**Zusammenfassung:**In diesem Artikel erfahren Sie, wie Sie verschiedene Methoden zur Benutzerauthentifizierung verwenden können, um für Webanwendungsbenutzer in SharePoint Server 2013 und SharePoint Server 2016 eine sichere Benutzererfahrung zu gewährleisten.

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.

Inhalt dieses Artikels:

• Einführung

• Anspruchsbasierte Authentifizierung

• Unterstützte Authentifizierungstypen und -methoden

• Planen der Windows-Authentifizierung

• Planen der formularbasierten Authentifizierung

• Planen der auf SAML-Token basierenden Authentifizierung

• Planen von Zonen für Webanwendungen

Einführung

Die Benutzerauthentifizierung ist die Überprüfung der Identität eines Benutzers anhand eines Authentifizierungsanbieters. Dabei handelt es sich um ein Verzeichnis oder eine Datenbank, das bzw. die die Anmeldeinformationen des Benutzers enthält und bestätigen kann, dass der Benutzer diese ordnungsgemäß übermittelt hat. Ein Beispiel für einen Authentifizierungsanbieter sind Active Directory-Domänendienste (AD DS). Weitere Begriffe für 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.

Bei der Planung der Benutzerauthentifizierungstypen und -methoden sollte Folgendes bestimmt werden:

• Die Benutzerauthentifizierungstypen und -methoden für alle Webanwendungen und -zonen

• Die erforderliche Authentifizierungsinfrastruktur zum Unterstützen der festgelegten Authentifizierungstypen und -methoden

  Hinweis

  Die Windows-Authentifizierung im klassischen Modus wird in SharePoint Server 2016 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 Methode funktioniert zwar in Windows-Umgebungen einwandfrei, kann jedoch nicht auf Drittauthentifizierungsanbieter und Umgebungen mehrerer Anbieter ausskaliert werden, die Internet-, Partner- oder cloudbasierte Computermodelle 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 Datenelement zu einem Benutzer dar, wie z. B. Name, 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:

• Anspruchsbasierte Identität für Windows (Whitepaper)

• Windows Identity Foundation-Startseite

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.

Bei der anspruchsbasierten Authentifizierung ändert SharePoint Server alle Benutzerkonten automatisch in Anspruchsidentitäten, woraus sich ein Sicherheitstoken (auch als Anspruchstoken bezeichnet) für jeden Benutzer ergibt. Das Anspruchstoken enthält die Ansprüche, die zu dem betreffenden Benutzer gehören. Windows-Konten werden in Windows-Ansprüche konvertiert. Benutzer mit formularbasierter Mitgliedschaft werden in Ansprüche für formularbasierte Authentifizierung umgewandelt. SharePoint Server kann Ansprüche in SAML-basierten Token verwenden. Darüber hinaus können SharePoint-Entwickler und -Administratoren Benutzertoken um zusätzliche Ansprüche erweitern. Beispielsweise können Windows-Benutzerkonten und formularbasierte Konten 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.

Zum Konfigurieren einer Webanwendung für den klassischen Authentifizierungsmodus müssen Sie sie mithilfe des PowerShell-Cmdlets New-SPWebApplication erstellen. SharePoint 2010-Produkte-Webanwendungen, die für den klassischen Authentifizierungsmodus konfiguriert sind, behalten beim Upgrade auf SharePoint 2013 ihre Authentifizierungseinstellungen bei. 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 bei Benutzerkonten nicht zwischen herkömmlichen Windows-Konten und anspruchsbasierten Windows-Konten.

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 Migrieren von der klassischen Authentifizierung zur anspruchsbasierten Authentifizierung in SharePoint 2013.

Informationen zum Erstellen von Webanwendungen in SharePoint 2013, die den klassischen Authentifizierungsmodus verwenden, finden Sie unter Create web applications that use classic mode authentication in SharePoint Server. Beachten Sie, dass eine Migration von Webanwendungen mit anspruchsbasierter Authentifizierung zu klassischer Authentifizierung nicht möglich ist.

Unterstützte Authentifizierungstypen und -methoden

SharePoint Server unterstützt eine Vielzahl von Authentifizierungsmethoden und Authentifizierungsanbietern 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 folgende Windows-Authentifizierungsmethode wird bei der anspruchsbasierten Authentifizierung verwendet:

• 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 es sich nicht um einen Windows-Authentifizierungstyp handelt, unterstützt SharePoint Server auch die anonyme Authentifizierung. Benutzer können ohne Überprüfung ihrer Anmeldeinformationen auf SharePoint-Inhalte zugreifen. Die anonyme Authentifizierung ist standardmäßig deaktiviert. Sie wird in der Regel verwendet, wenn Sie SharePoint Server zur Veröffentlichung von Inhalten verwenden, die keine Sicherheit erfordern und für alle Benutzer verfügbar sind. Ein Beispiel hierfür sind öffentliche Internetwebsites.

Beachten Sie, dass neben der Aktivierung der anonymen Authentifizierung auch die Konfiguration des anonymen Zugriffs (Berechtigungen) auf Websites und Websiteressourcen erforderlich ist.

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 wie den folgenden gespeichert sind:

• 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 zu einer Anmeldeseite umgeleitet, auf der ein Benutzer gültige Anmeldeinformationen eingeben muss und das Formular übermittelt. 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

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 folgende Authentifizierungsanbieter (Attributspeicher für AD FS 2.0) vorhanden sein:

• 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. Sie sollten den Authentifizierungstyp verwenden, der zu Ihrer aktuellen LDAP-Umgebung passt. Wenn Sie noch nicht über eine LDAP-Umgebung verfügen, empfehlen wir die formularbasierte Authentifizierung, 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 macht die Implementierung von Windows-Authentifizierungsmethoden nicht komplizierter. 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 handelt es sich dabei um die Anmeldeinformationen, die der Benutzer zum Anmelden am 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 am einfachsten zu implementierende Form der Windows-Authentifizierung und erfordert in der Regel keine zusätzliche Konfiguration der Authentifizierungsinfrastruktur. Wählen Sie diese Option einfach aus, wenn Sie die Webanwendung erstellen oder konfigurieren.

Das Kerberos-Protokoll unterstützt die Authentifizierungsticketausstellung. Die Verwendung des Kerberos-Protokolls erfordert eine weiter gehende 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. Das ist zwar in einem Organisationsintranet eine übliche Netzwerkkonfiguration, für Bereitstellungen mit Internetzugriff jedoch eher untypisch.

Folgende Schritte stellen eine Zusammenfassung der Konfiguration der Kerberos-Authentifizierung dar:

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

2. Erstellen Sie SPNs für Webanwendungen, für die Kerberos-Authentifizierung verwendet wird.

3. Installieren Sie die SharePoint Server-Farm.

4. Konfigurieren Sie einzelne Dienste innerhalb der Farm für die Verwendung von bestimmten Konten.

5. 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 Internetinformationsdienste (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 dann verwenden, wenn Sie auch SSL zum Verschlüsseln des Websitedatenverkehrs verwenden.

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 Internetinformationsdienste (IIS)-Snap-In entspricht.

Lesen Sie Folgendes, wenn Sie die anspruchsbasierte Authentifizierung verwenden:

• Configure digest authentication for a claims-based web application in SharePoint Server

• Configure basic authentication for a claims-based web application in SharePoint Server

Planen der formularbasierten Authentifizierung

Zum Verwenden der formularbasierten Authentifizierung von Benutzern in einem externen oder nicht auf Windows basierten Identitätsverwaltungssystem müssen Sie den Mitgliedschaftsanbieter und den Rollen-Manager in der Datei "Web.config" 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. Außerdem müssen Sie den Mitgliedschaftsanbieter und den Rollen-Manager in der Datei "Web.config" für die Webanwendung registrieren, 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 2013

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. Dazu zählen die Windows-Authentifizierung, die formularbasierte Authentifizierung und die auf SAML-Token basierende Authentifizierung.

• Tokensignaturzertifikat ("ImportTrustCertificate")   Dies ist das Zertifikat, das Sie aus einem Identitätsanbieter-Sicherheitstokendienst (Identity Provider Security Token Service, IP-STS) exportieren, auf einen Server in der Farm kopieren und es dann der Liste mit vertrauenswürdigen Stammzertifizierungsstellen der Farm hinzufügen. Sobald Sie dieses Zertifikat zum Erstellen eines SPTrustedIdentityTokenIssuer-Objekts verwendet haben, können Sie es nicht noch einmal verwenden, um ein weiteres SPTrustedIdentityTokenIssuer-Objekt zu erstellen. 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.

• Andere Ansprüche   Hierbei handelt es sich um zusätzliche Ansprüche 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.

• Bereich   In der SharePoint-Anspruchsarchitektur stellt der URI oder die URL, der bzw. die einer SharePoint-Webanwendung zugeordnet ist, die für die Verwendung eines auf SAML-Token basierenden Anbieters konfiguriert ist, einen Bereich dar. Beim Erstellen eines Anbieters für die auf SAML-Token basierende Authentifizierung in der Farm geben Sie die Bereiche oder Webanwendungs-URLs, die vom IP-STS erkannt werden sollen, einzeln an. Der erste Bereich wird angegeben, wenn Sie das SPTrustedIdentityTokenIssuer-Objekt erstellen. Sie können nach der Erstellung des SPTrustedIdentityTokenIssuer-Objekts weitere Bereiche hinzufügen. Bereiche werden mithilfe einer Syntax angegeben, die der im Folgenden angegeben ähnelt: $realm = "urn:sharepoint:mysites". Nachdem Sie dem SPTrustedIdentityTokenIssuer-Objekt den Bereich hinzugefügt haben, müssen Sie eine RP-STS-Vertrauensstellung mit dem Bereichsbezeichner auf dem IP-STS-Server einrichten. Dabei müssen Sie die URL für die Webanwendung angeben.

• SPTrustedIdentityTokenIssuer   Dies ist das Objekt, das in der SharePoint-Farm erstellt wird. Es enthält die Werte, die für die Kommunikation mit dem IP-STS und für den Empfang von Token vom IP-STS benötigt werden. Bei der Erstellung des SPTrustedIdentityTokenIssuer-Objekts geben Sie das zu verwendende Tokensignaturzertifikat, den ersten Bereich, den Anspruch, der den Identitätsanspruch darstellt, und alle weiteren Ansprüche an. Sie können ein Tokensignaturzertifikat von einem STS nur einem einzigen SPTrustedIdentityTokenIssuer-Objekt zuordnen. Allerdings können Sie nach der Erstellung des SPTrustedIdentityTokenIssuer-Objekts weitere Bereiche für zusätzliche Webanwendungen hinzufügen. Nachdem Sie dem SPTrustedIdentityTokenIssuer-Objekt einen Bereich hinzugefügt haben, müssen Sie ihn auch dem IP-STS als vertrauende Seite hinzufügen. Das SPTrustedIdentityTokenIssuer-Objekt wird auf alle Server 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 für Identitätsanbieter (Identity Provider Security Token Service, IP-STS)   Dies ist der Sicherheitstokendienst in der Anspruchsumgebung, der SAML-Token im Namen von Benutzern ausstellt, die im zugeordneten 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. Dazu zählen:

• Ein einzelner Identitätsanspruch.

• Ein einzelner SignInURL-Parameter

  Der Parameter SignInURL gibt die URL an, zu der eine Benutzeranforderung umgeleitet werden soll, damit die Authentifizierung beim IP-STS erfolgt.

• Ein einzelner Wreply-Parameter

  Für manche IP-STS-Server ist der Parameter Wreply erforderlich, der auf true oder false festgelegt ist, wobei false den Standardwert darstellt. Verwenden Sie den Parameter Wreply nur, wenn er für den IP-STS erforderlich ist.

• Mehrere Bereiche.

• Zuordnung mehrerer Ansprüche.

Gehen Sie wie unten beschrieben vor, um die auf SAML-Token basierende Authentifizierung in SharePoint Server zu implementieren (diese Methode erfordert eine Planung im Voraus):

1. Exportieren Sie das Tokensignaturzertifikat aus dem IP-STS. Kopieren Sie das Zertifikat auf einen Server in der SharePoint Server-Farm.

2. Definieren Sie den Anspruch, der als eindeutiger Bezeichner des Benutzers verwendet wird. Dieser 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.

3. Definieren Sie zusätzliche Anspruchszuordnungen. Legen Sie fest, welche zusätzlichen Ansprüche aus dem eingehenden Token von der SharePoint Server-Farm verwendet werden. 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.

4. 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 die zusätzlichen Ansprüche an, die Sie zugeordnet haben. Sie müssen außerdem einen Bereich erstellen und angeben, der den ersten SharePoint-Webanwendungen zugeordnet ist, die Sie für die auf SAML-Token basierende Authentifizierung konfigurieren. Nachdem Sie das SPTrustedIdentityTokenIssuer-Objekt erstellt haben, können Sie weitere Bereiche für zusätzliche SharePoint-Webanwendungen erstellen und hinzufügen. Auf diese Weise können Sie konfigurieren, dass mehrere Webanwendungen ein und dasselbe SPTrustedIdentityTokenIssuer-Objekt verwenden.

5. Für jeden Bereich, den Sie dem SPTrustedIdentityTokenIssuer-Objekt hinzufügen, müssen Sie einen RP-STS-Eintrag im IP-STS erstellen. Diesen Schritt können Sie vor der Erstellung der SharePoint-Webanwendung durchführen. Unabhängig davon müssen Sie die URL planen, bevor Sie die Webanwendungen erstellen.

6. 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 anderen vertrauenswürdigen STS-Umgebungen verursachen hierbei keinen Konflikt.

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 und dem STS des Partners einzurichten. Bei dieser Vorgehensweise ist es nicht erforderlich, Ihrer SharePoint Server-Farm einen Authentifizierungsanbieter hinzuzufügen. Außerdem können Ihre Anspruchsadministratoren so die gesamte Anspruchsumgebung verwalten.

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

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 nur einen Windows-Authentifizierungstyp 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. Ist die NTLM-Authentifizierung in der Standardzone nicht konfiguriert, 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. Folglich werden die Endbenutzer wahrscheinlich auf die Standardzone zugreifen.

• 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. Erstellen Sie nur bei Bedarf neue Zugriffspunkte.

• 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 unbedingt 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. Die Mitarbeiter verwenden unterschiedliche Zonen, je nachdem, ob sie im Büro oder remote arbeiten.