Planen von Authentifizierungsmethoden (SharePoint Foundation 2010)

 

Gilt für: SharePoint Foundation 2010

Letztes Änderungsdatum des Themas: 2016-11-30

In diesem Artikel werden die von Microsoft SharePoint Foundation 2010 unterstützten Authentifizierungsmethoden und Authentifizierungsmodi beschrieben. Als Authentifizierung wird das Verfahren zur Überprüfung der Identität eines Benutzers bezeichnet. Nachdem die Identität eines Benutzers überprüft wurde, wird im Autorisierungsverfahren ermittelt, auf welche Websites, Inhalte und anderen Features der Benutzer zugreifen kann. Authentifizierungsmodi bestimmen, wie Konten intern von SharePoint Foundation 2010 verwendet werden.

Inhalt dieses Artikels:

• Unterstützte Authentifizierungsmethoden

• Authentifizierungsmodi – klassische oder forderungsbasierte Authentifizierung

• Implementieren der Windows-Authentifizierung

• Implementieren der formularbasierten Authentifizierung

• Implementieren der auf SAML-Token basierenden Authentifizierung

• Auswählen der Authentifizierung für LDAP-Umgebungen

• Planen von Zonen für Webanwendungen

• Architektur für auf SAML-Token basierende Authentifizierungsanbieter

Unterstützte Authentifizierungsmethoden

SharePoint Foundation 2010 unterstützt Authentifizierungsmethoden aus früheren Versionen sowie als Option die neu eingeführte tokenbasierte Authentifizierung, die auf SAML (Security Assertion Markup Language) basiert. In der folgenden Tabelle werden die unterstützten Authentifizierungsmethoden aufgeführt.

Methode	Beispiele	Hinweise
Windows	NTLM Kerberos Anonym Standard Digest	Derzeit wird die Windows-Zertifikatauthentifizierung nicht unterstützt.
Formularbasierte Authentifizierung	LDAP (Lightweight Directory Access-Protokoll) SQL-Datenbank oder andere Datenbank Benutzerdefiniert oder Drittanbieter für Mitgliedschaften und Rollen
Auf SAML-Token basierende Authentifizierung	Active Directory-Verbunddienste (AD FS) 2.0 Drittanbieter für Identitäten LDAP (Lightweight Directory Access-Protokoll)	Wird nur mit SAML 1.1 unterstützt, das WS-Federation-PRP (Passive Requestor Profile) verwendet.

Authentifizierungsmodi – klassische oder forderungsbasierte Authentifizierung

Neu in SharePoint Foundation 2010 ist die forderungsbasierte Authentifizierung, die auf Windows Identity Foundation (WIF) basiert. Für die forderderungsbasierte Authentifizierung können Sie eine beliebige unterstützte Authentifizierungsmethode verwenden. Sie können aber auch den klassischen Authentifizierungsmodus verwenden, der die Windows-Authentifizierung unterstützt.

Beim Erstellen einer Webanwendung wählen Sie einen der beiden Authentifizierungsmodi für die Webanwendung aus, nämlich den forderungsbasierten oder den klassischen Authentifizierungsmodus.

Wenn Sie den klassischen Authentifizierungsmodus auswählen, können Sie die Windows-Authentifizierung implementieren, und die Benutzerkonten werden von SharePoint Foundation 2010 als Active Directory-Domänendienste-Konto behandelt.

Wenn Sie die forderungsbasierte Authentifizierung auswählen, werden von SharePoint Foundation 2010 alle Benutzerkonten automatisch in Forderungsidentitäten geändert, wodurch sich ein Forderungstoken pro Benutzer ergibt. Das Forderungstoken enthält die Forderungen für den Benutzer. Windows-Konten werden in Windows-Forderungen konvertiert. Benutzer mit formularbasierter Mitgliedschaft werden in formularbasierte Authentifizierungsforderungen transformiert. Forderungen, die in SAML-basierten Token enthalten sind, können von SharePoint Foundation 2010 verwendet werden. Darüber hinaus können SharePoint-Entwickler und -Administratoren Benutzertoken durch zusätzliche Forderungen ergänzen. Beispielsweise können Windows-Benutzerkonten und formularbasierte Konten durch zusätzliche Forderungen ergänzt werden, die von SharePoint Foundation 2010 verwendet werden.

Im folgenden Diagramm finden Sie eine Übersicht über die Unterstützung der Authentifizierungstypen für die beiden Authentifizierungsmodi.

Typ	Klassischer Authentifizierungsmodus	Forderungsbasierte Authentifizierung
Windows NTLM Kerberos Anonym Standard Digest	Ja	Ja
Formularbasierte Authentifizierung LDAP SQL-Datenbank oder andere Datenbank Benutzerdefiniert oder Drittanbieter für Mitgliedschaften und Rollen	Nein	Ja
Auf SAML-Token basierende Authentifizierung AD FS 2.0 Windows Live ID Drittanbieter für Identitäten LDAP	Nein	Ja

Eine SharePoint Foundation 2010-Farm kann eine Mischung aus Webanwendungen enthalten, die beide Modi verwenden. Dienste unterscheiden nicht zwischen Benutzerkonten, die traditionelle Windows-Konten und Windows-Forderungskonten sind. Demzufolge erhält ein Benutzer, der Websites angehört, für die eine Kombination von Authentifizierungsmodi konfiguriert ist, Suchergebnisse mit Ergebnissen aus allen Websites, auf die der Benutzer Zugriff hat, und zwar unabhängig von dem für Webanwendungen konfigurierten Modus. Der Benutzer wird nicht als zwei unterschiedliche Benutzerkonten interpretiert. Dies liegt daran, dass Dienste und Dienstanwendungen Forderungsidentitäten für die Kommunikation zwischen den Farmen verwenden, unabhängig von dem für Webanwendungen und Benutzer ausgewählten Modus.

Benutzer, die mehreren von SharePoint Server-Webanwendungen erkannten Benutzerrepositorys angehören, werden jedoch in Abhängigkeit von der zum Anmelden verwendeten Identität als separate Benutzerkonten behandelt.

Die folgenden Hinweise sollen Ihnen die Entscheidung für einen Modus erleichtern:

• Verwenden Sie für neue Implementierungen von SharePoint Foundation 2010 die forderungsbasierte Authentifizierung. Mit dieser Option sind alle unterstützten Authentifizierungstypen für Webanwendungen verfügbar. Es gibt keinen praktischen Grund, für neue Bereitstellungen den klassischen Authentifizierungsmodus auszuwählen, auch wenn es in Ihrer Umgebung nur Windows-Konten gibt. Die Implementierung der Windows-Authentifizierung ist unabhängig vom ausgewählten Modus identisch. Bei Verwendung des forderungsbasierten Authentifizierungsmodus müssen zum Implementieren der Windows-Authentifizierung keine weiteren Schritte ausgeführt werden.

• Wenn Sie eine Lösung einer vorherigen Version auf SharePoint Foundation 2010 upgraden, die nur Windows-Konten aufweist, können Sie den klassischen Authentifizierungsmodus verwenden. Dadurch können Sie denselben Entwurf für Zonen und URLs verwenden.

• Wenn Sie eine Lösung upgraden, die die formularbasierte Authentifizierung erfordert, ist nur ein Upgrade auf die forderungsbasierte Authentifizierung möglich.

Berücksichtigen Sie Folgendes, wenn Sie von einer früheren Version auf SharePoint Foundation 2010 upgraden und die forderungsbasierte Authentifizierung auswählen:

• Benutzerdefinierter Code muss möglicherweise aktualisiert werden. Für Webparts oder sonstigen benutzerdefinierten Code, der Windows-Identitäten verwendet oder darauf basiert, ist eine Aktualisierung erforderlich. Falls im benutzerdefinierten Code Windows-Identitäten verwendet werden, sollten Sie den klassischen Authentifizierungsmodus verwenden, bis der Code aktualisiert wurde.

• Das Migrieren einer großen Anzahl von Windows-Benutzern zu Forderungsidentitäten ist zeitaufwändig. Wenn Sie während des Upgradevorgangs eine Webanwendung vom klassischen Authentifizierungsmodus in den forderungsbasierten Authentifizierungsmodus ändern, müssen Sie Windows PowerShell zum Konvertieren von Windows-Identitäten in Forderungsidentitäten verwenden. Dieser Vorgang kann lange dauern. Planen Sie Sie ausreichend Zeit zum Ausführen dieser Aufgabe während des Upgradevorgangs ein.

• Benachrichtigungen über Suchergebnisse werden derzeit für die forderungsbasierte Authentifizierung nicht unterstützt.

Die Forderungsauthentifizierung basiert auf WIF. Bei WIF handelt es sich um .NET Framework-Klassen zum Implementieren einer forderungsbasierten Identität. Die Forderungsauthentifizierung basiert auf Standards wie z. B. WS-Federation, WS-Trust und Protokollen wie z. B. SAML. Weitere Informationen zur Forderungsauthentifizierung finden Sie in den folgenden Ressourcen:

• Forderungsbasierte Identität für Windows: Eine Einführung in Active Directory--Verbunddienste 2.0, Windows CardSpace 2.0 und Windows Identity Foundation (Whitepaper) (https://go.microsoft.com/fwlink/?linkid=198942&clcid=0x407)

• Windows Identity Foundation-Homepage (https://go.microsoft.com/fwlink/?linkid=198943&clcid=0x407)

Sie müssen kein Forderungsarchitekt sein, um die Forderungsauthentifizierung in SharePoint Foundation 2010 zu verwenden. Das Implementieren der auf SAML-Token basierenden Authentifizierung erfordert jedoch wie weiter unten in diesem Artikel beschrieben die Koordination mit Administratoren Ihrer forderungsbasierten Umgebung.

Implementieren der Windows-Authentifizierung

Der Implementierungsvorgang für Windows-Authentifizierungsmethoden ist für beide Authentifizierungsmodi ähnlich (klassische oder forderungsbasierte Authentifizierung). Durch die Auswahl der forderungsbasierten Authentifizierung für eine Webanwendung nimmt die Komplexität der Implementierung von Windows-Authentifizierungsmethoden nicht zu. In diesem Abschnitt finden Sie eine Zusammenfassung der Vorgehensweise für beide Methoden.

Integrierte Windows-Authentifizierung – Kerberos und NTLM

Sowohl das Kerberos-Protokoll als auch NTLM sind integrierte Windows-Authentifizierungsmodi, mit denen Clients problemlos authentifiziert werden können, ohne zur Eingabe von Anmeldeinformationen aufgefordert zu werden. Benutzer, die in Windows-Explorer auf SharePoint-Websites zugreifen, authentifizieren sich mit den 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 im integrierten Windows-Authentifizierungsmodus auf SharePoint Server zugreifen, versuchen sich mit den Anmeldeinformationen des ausgeführten Threads anzumelden, der standardmäßig der Identität des Prozesses entspricht.

NTLM ist die am einfachsten zu implementierende Form der Windows-Authentifizierung. Wählen Sie einfach diese Option aus, wenn Sie eine Webanwendung erstellen.

Beim Kerberos-Protokoll handelt es sich um ein Sicherheitsprotokoll, das das Authentifizierungs-Ticketing unterstützt. Für die Verwendung des Kerberos-Protokolls sind zusätzliche Konfigurationen der Umgebung erforderlich. 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. Beim Konfigurieren des Kerberos-Protokolls müssen die Dienstprinzipalnamen (Service Principal Names, SPNs) in den Active Directory-Domänendiensten (Active Directory Domain Services, AD DS) eingerichtet werden, bevor Sie SharePoint Foundation 2010 installieren.

Die folgenden Schritte stellen eine Zusammenfassung des Konfigurationsvorgangs für die Kerberos-Authentifizierung dar:

1. Konfigurieren Sie die Kerberos-Authentifizierung für die SQL-Kommunikation, indem Sie in den Active Directory-Domänendiensten Dienstprinzipalnamen für das SQL Server-Dienstkonto erstellen.

2. Erstellen Sie Dienstprinzipalnamen für Webanwendungen, die die Kerberos-Authentifizierung verwenden.

3. Installieren Sie die SharePoint Foundation 2010-Farm.

4. Konfigurieren Sie für bestimmte Dienste innerhalb der Farm die Verwendung bestimmter Konten.

5. Erstellen Sie die Webanwendungen, die die Kerberos-Authentifizierung verwenden.

Weitere Informationen finden Sie unter Planen der Kerberos-Authentifizierung (SharePoint Server 2010).

Darüber hinaus muss für Webanwendungen mit Forderungsauthentifizierung für den Forderungen an den Windows-Tokendienst die eingeschränkte Delegierung konfiguriert werden. Die eingeschränkte Delegierung ist erforderlich, um Forderungen in Windows-Token zu konvertieren. Für Umgebungen mit mehreren Gesamtstrukturen ist die bidirektionale Vertrauensstellung zwischen Gesamtstrukturen erforderlich, um den Forderungen an den Windows-Tokendienst zu verwenden. Weitere Informationen zum Konfigurieren dieses Diensts finden Sie unter Konfigurieren der Kerberos-Authentifizierung für den Forderungen-zu-Windows-Tokens-Dienst (SharePoint Server 2010).

Die Kerberos-Authentifizierung ermöglicht die Delegierung von Clientanmeldeinformationen für den Zugriff auf Back-End-Datensysteme, was in Abhängigkeit vom Szenario zusätzliche Konfigurationsschritte erfordert. In der folgenden Tabelle finden Sie Beispiele.

Szenario	Zusätzliche Konfigurationsschritte
Delegieren der Identität eines Clients an einen Back-End-Server Anzeigen von RSS-Feeds zu authentifizierten Inhalten	Konfigurieren Sie für Computer und Dienstkonten die eingeschränkte Kerberos-Delegierung.
Identitätsdelegierung für Microsoft SQL Server Reporting Services (SSRS)	Konfigurieren Sie Dienstprinzipalnamen für SQL Server Reporting Services-Konten. Konfigurieren Sie die Delegierung für SQL Server Reporting Services.
Identitätsdelegierung für Excel Services in SharePoint	Konfigurieren Sie für Server mit Excel Services die eingeschränkte Delegierung. Konfigurieren Sie für das Excel Services-Dienstkonto die eingeschränkte Delegierung.

Weitere Informationen zum Konfigurieren der Kerberos-Authentifizierung, einschließlich der Konfigurationsschritte für allgemeine Szenarien, finden Sie unter Konfigurieren der Kerberos-Authentifizierung für Microsoft SharePoint 2010-Produkte und -Technologien (Whitepaper) (https://go.microsoft.com/fwlink/?linkid=197178&clcid=0x407).

Digest- und Standardauthentifizierung

Für die Implementierung der Digest- und Standardauthentifizierung müssen diese Authentifizierungsmethoden direkt in den Internetinformationsdiensten (Internet Information Services, IIS) konfiguriert werden.

Implementieren der formularbasierten Authentifizierung

Die formularbasierte Authentifizierung ist ein Identitätsverwaltungssystem, das auf der ASP.NET-Mitgliedschaft und der Rollenanbieterauthentifizierung basiert. In SharePoint Foundation 2010 ist die formularbasierte Authentifizierung nur verfügbar, wenn Sie die forderungsbasierte Authentifizierung verwenden.

Die formularbasierte Authentifizierung kann mithilfe von Anmeldeinformationen verwendet werden, die in Active Directory-Domänendiensten, in einer Datenbank wie z. B. einer SQL Server-Datenbank oder in einem LDAP-Datenspeicher wie z. B. Novell eDirectory, NDS (Novell Directory Services) oder Sun ONE gespeichert sind. Die formularbasierte Authentifizierung ermöglicht die Benutzerauthentifizierung basierend auf der Überprüfung von Anmeldeinformationen, die in einem Anmeldeformular eingegeben werden. Nicht authentifizierte Anforderungen werden an eine Anmeldeseite umgeleitet, auf der der Benutzer gültige Anmeldeinformationen eingeben muss und das Formular übermittelt. Wenn die Anforderung authentifiziert werden kann, wird ein Cookie ausgestellt, das einen Schlüssel zum Wiederherstellen der Identität für nachfolgende Anforderungen enthält.

Zur Verwendung der formularbasierten Authentifizierung für die Benutzerauthentifizierung mit einem Identitätsverwaltungssystem, das nicht auf Windows basiert oder das extern ist, müssen Sie den Mitgliedschaftsanbieter und den Rollen-Manager in der Datei Web.config registrieren. Die obligatorische Registrierung des Rollen-Managers ist neu in SharePoint Foundation 2010. In der vorherigen Version war dies optional. In SharePoint Foundation 2010 wird die Standardschnittstelle für den ASP.NET-Rollen-Manager verwendet, um Gruppeninformationen zum aktuellen Benutzer zu erfassen. Jede ASP.NET-Rolle wird von der Autorisierung in SharePoint Foundation 2010 als Domänengruppe behandelt. Sie registrieren Rollen-Manager in der Datei Web.config auf dieselbe Weise wie dies beim Registrieren von Mitgliedschaftsanbietern für die Authentifizierung der Fall ist.

Wenn Sie auf der Website für die SharePoint-Zentraladministration Mitgliedschaftsbenutzer oder Rollen verwalten möchten, müssen Sie den Mitgliedschaftsanbieter und den Rollen-Manager in der Datei Web.config für die Website für die Zentraladministration registrieren. Darüber hinaus müssen Sie den Mitgliedschaftsanbieter und den Rollen-Manager in der Datei Web.config für die Webanwendung registrieren, die den Inhalt hostet.

Weitere Informationen zum Konfigurieren der formularbasierten Authentifizierung finden Sie in den folgenden Ressourcen:

• TechNet-Artikel: Konfigurieren der formularbasierten Authentifizierung für eine forderungsbasierte Webanwendung (SharePoint Server 2010)

• MSDN-Blogartikel: Claims-based authentication "Cheat Sheet" Part 1 (https://go.microsoft.com/fwlink/?linkid=198944&clcid=0x407) ("Spickzettel" für die forderungsbasierte Authentifizierung – Teil 1)

• MSDN-Artikel: Formularauthentifizierung in SharePoint-Produkten und -Technologien (Teil 2): Beispiele für eine Mitgliedschaft und für Rollenanbieter (https://go.microsoft.com/fwlink/?linkid=198945&clcid=0x407)

Implementieren der auf SAML-Token basierenden Authentifizierung

Die auf SAML-Token basierende Authentifizierung erfordert die Koordination mit Administratoren einer forderungsbasierten Umgebung, unabhängig davon, ob es sich dabei um Ihre interne Umgebung oder eine Partnerumgebung handelt. Active Directory-Verbunddienste 2.0 ist ein Beispiel für eine forderungsbasierte Umgebung.

Eine forderungsbasierte Umgebung enthält einen Identitätsanbieter-Sicherheitstokendienst (Identity Provider Security Token Service, IP-STS). Der Identitätsanbieter-Sicherheitstokendienst stellt SAML-Token im Namen von Benutzern aus, die im zugeordneten Benutzerverzeichnis enthalten sind. Token können eine beliebige Anzahl von Forderungen zu einem Benutzer enthalten, wie z. B. einen Benutzernamen und Gruppen, denen der Benutzer angehört.

SharePoint Foundation 2010 nutzt Forderungen, die in von einem Identitätsanbieter-Sicherheitstokendienst bereitgestellten Token enthalten sind, um Benutzer zu autorisieren. In forderungsbasierten Umgebungen wird eine Anwendung, die SAML-Token akzeptiert, als Sicherheitstokendienst der vertrauenden Seite (Relying Party Security Token Service, RP-STS) bezeichnet. Eine Anwendung der vertrauenden Seite empfängt das SAML-Token und entscheidet mithilfe der internen Forderungen, ob dem Client der Zugriff auf die angeforderte Ressource erteilt werden soll. In SharePoint 2010-Produkte wird jede Webanwendung, für die die Verwendung eines SAML-Anbieters konfiguriert ist, dem Server mit dem Identitätsanbieter-Sicherheitstokendienst als separater Eintrag für den Sicherheitstokendienst der vertrauenden Seite hinzugefügt. In einer SharePoint-Farm können mehrere Einträge für den Sicherheitstokendienst der vertrauenden Seite vorhanden sein.

Das Implementieren der auf SAML-Token basierenden Authentifizierung für SharePoint 2010-Produkte beinhaltet die folgenden Schritte, die eine frühzeitige Planung erfordern:

1. Exportieren Sie das Tokensignaturzertifikat aus dem Identitätsanbieter-Sicherheitstokendienst. Dieses Zertifikat wird als ImportTrustCertificate-Objekt bezeichnet. Kopieren Sie das Zertifikat auf einen Servercomputer in der SharePoint Foundation 2010-Farm.

2. Definieren Sie die Forderung, die als eindeutiger Bezeichner des Benutzers verwendet wird. Dies wird als Identitätsforderung bezeichnet. In vielen Beispielen für diesen Vorgang wird der E-Mail-Name des Benutzers als Benutzer-ID verwendet. Bestimmen Sie zusammen mit dem Administrator des Identitätsanbieter-Sicherheitstokendiensts die richtige ID, da nur der Besitzer des Identitätsanbieter-Sicherheitstokendiensts weiß, welcher Wert im Token für jeden Benutzer immer eindeutig sein wird. Das Identifizieren des eindeutigen Bezeichners für den Benutzer ist Teil des Forderungszuordnungsprozesses. Forderungszuordnungen werden mithilfe von Windows PowerShell erstellt.

3. Definieren Sie zusätzliche Forderungszuordnungen. Definieren Sie, welche zusätzlichen Forderungen aus dem eingehenden Token von der SharePoint Foundation 2010-Farm verwendet werden. Benutzerrollen sind ein Beispiel für eine Forderung, die für Berechtigungsressourcen in der SharePoint Foundation 2010-Farm verwendet werden kann. Alle Forderungen aus einem eingehenden Token, die keine Zuordnung aufweisen, werden verworfen.

4. Erstellen Sie mithilfe von Windows PowerShell einen neuen Authentifizierungsanbieter, um das Tokensignaturzertifikat zu importieren. Hierbei wird das SPTrustedIdentityTokenIssuer-Objekt erstellt. Während dieses Prozesses geben Sie die Identitätsforderung und zusätzliche Forderungen, die Sie zugeordnet haben, an. Darüber hinaus müssen Sie einen Bereich erstellen und angeben, der den ersten SharePoint-Webanwendungen zugeordnet wird, die Sie für die auf SAML-Token basierende Authentifizierung konfigurieren. Nachdem das SPTrustedIdentityTokenIssuer-Objekt erstellt wurde, können Sie weitere Bereiche für zusätzliche SharePoint-Webanwendungen erstellen und hinzufügen. Auf diese Weise können Sie für mehrere Webanwendungen die Verwendung desselben SPTrustedIdentityTokenIssuer-Objekts konfigurieren.

5. Für jeden Bereich, der dem SPTrustedIdentityTokenIssuer-Objekt hinzugefügt wird, müssen Sie einen Eintrag für den Sicherheitstokendienst der vertrauenden Seite im Identitätsanbieter-Sicherheitstokendienst erstellen. Dies ist vor dem Erstellen der SharePoint-Webanwendung möglich. Unabhängig davon müssen Sie die URL planen, bevor Sie die Web-Anwendungen erstellen.

6. Erstellen Sie eine neue SharePoint-Webanwendung und konfigurieren Sie dafür den neu erstellten Authentifizierungsanbieter. Der Authentifizierungsanbieter wird als Option in der Zentraladministration angezeigt, wenn der Forderungsmodus für die Webanwendung ausgewählt ist.

Sie können mehrere auf SAML-Token basierende Authentifizierungsanbieter konfigurieren. Ein Tokensignaturzertifikat kann allerdings nur einmal in einer Farm verwendet werden. Alle konfigurierten Anbieter werden als Optionen in der Zentraladministration angezeigt. Forderungen von anderen vertrauenswürdigen Sicherheitstokendienst-Umgebungen führen nicht zu Konflikten.

Wenn Sie die auf SAML-Token basierende Authentifizierung für ein Partnerunternehmen implementieren und in Ihrer Umgebung ein Identitätsanbieter-Sicherheitstokendienst vorhanden ist, sollten Sie gemeinsam mit dem Administrator der internen forderungsbasierten Umgebung eine Vertrauensstellung zwischen Ihrem internen Identitätsanbieter-Sicherheitstokendienst und dem Partner-Sicherheitstokendienst einrichten. Bei dieser Vorgehensweise muss Ihrer SharePoint Foundation 2010-Farm kein zusätzlicher Authentifizierungsanbieter hinzugefügt werden. Außerdem können die Forderungsadministratoren die gesamte forderungsbasierte Umgebung verwalten.

Hinweis

Wenn Sie die auf SAML-Token basierende Authentifizierung mit Active Directory-Verbunddiensten in einer SharePoint Foundation 2010-Farm verwenden, die mehrere Webserver in einer Konfiguration mit Lastenausgleich aufweist, könnten Leistung und Funktionalität beim Anzeigen von Clientwebseiten beeinträchtigt werden. Wenn das Authentifizierungstoken durch Active Directory-Verbunddienste dem Client bereitgestellt wird, wird dieses Token für jedes Seitenelement mit eingeschränkten Berechtigungen an SharePoint Foundation 2010 übermittelt. Falls die Lösung mit Lastenausgleich keine Affinität verwendet, wird jedes geschützte Element für mehrere SharePoint Foundation 2010-Server authentifiziert, was zur Ablehnung des Tokens führen kann. Nach der Ablehnung des Tokens wird der Client zur erneuten Authentifizierung durch SharePoint Foundation 2010 an den Server mit Active Directory-Verbunddiensten umgeleitet. Ein Server mit Active Directory-Verbunddiensten kann in diesem Fall mehrere Anforderungen ablehnen, die in einem kurzen Zeitraum erfolgen. Dieses Verhalten ist beabsichtigt und soll vor einem Denial-of-Service-Angriff schützen. Für den Fall, dass die Leistung beeinträchtigt wird oder Seiten nicht vollständig geladen werden, sollten Sie eventuell für den Netzwerklastenausgleich die einfache Affinität festlegen. Dadurch werden die Anforderungen für SAML-Token auf einen einzelnen Webserver beschränkt.

Weitere Informationen zum Konfigurieren der auf SAML-Token basierenden Authentifizierung finden Sie in den folgenden Ressourcen:

• TechNet-Artikel: Konfigurieren der Authentifizierung mithilfe eines SAML-Sicherheitstokens (SharePoint Server 2010)

• MSDN-Blogartikel: Claims-based authentication "Cheat Sheet" Part 2 (https://go.microsoft.com/fwlink/?linkid=198946&clcid=0x407) ("Spickzettel" für die forderungsbasierte Authentifizierung – Teil 2)

• TechNet-Blogartikel: Planning Considerations for Claims Based Authentication in SharePoint 2010 (https://go.microsoft.com/fwlink/?linkid=198947&clcid=0x407) (Planungsüberlegungen für die forderungsbasierte Authentifizierung in SharePoint 2010)

• TechNet-Blogartikel: Creating both an Identity and Role Claim for a SharePoint 2010 Claims Auth Application (https://go.microsoft.com/fwlink/?linkid=198948&clcid=0x407) (Erstellen einer Identitäts- und Rollenforderung für eine SharePoint 2010-Forderungsauthentifizierungsanwendung)

• TechNet-Blogartikel: How to Create Multiple Claims Auth Web Apps in a Single SharePoint 2010 Farm (https://go.microsoft.com/fwlink/?linkid=198949&clcid=0x407) (Erstellen mehrerer Webanwendungen mit forderungsbasierter Authentifizierung in einer einzelnen SharePoint 2010-Farm)

Auswählen der Authentifizierung für LDAP-Umgebungen

LDAP-Umgebungen können mit der formularbasierten Authentifizierung oder der auf SAML-Token basierenden Authentifizierung implementiert werden. Die formularbasierte Authentifizierung wird aufgrund ihrer geringeren Komplexität empfohlen. Wenn allerdings die Umgebung WS-Federation 1.1 und SAML Token 1.1 unterstützt, wird SAML empfohlen. Die Profilsynchronisierung wird für LDAP-Anbieter, die nicht ADFS 2.0 zugeordnet sind, nicht unterstützt.

Planen von Zonen für Webanwendungen

Zonen stellen verschiedene logische Pfade für den Zugriff auf dieselben Websites in einer Webanwendung dar. Eine Webanwendung kann bis zu fünf Zonen enthalten. Beim Erstellen einer Webanwendung wird die Standardzone erstellt. Zusätzliche Zonen werden erstellt, indem Sie die Webanwendung erweitern und einen der restlichen Zonennamen auswählen: Intranet, Extranet, Internet oder Benutzerdefiniert.

In früheren Versionen wurden mithilfe von Zonen verschiedene Authentifizierungstypen für Benutzer aus anderen Netzwerken oder Authentifizierungsanbietern implementiert. In der aktuellen Version ermöglicht die Forderungsauthentifizierung das Implementieren mehrerer Authentifizierungstypen in derselben Zone.

Ihre Planung für Zonen hängt davon ab, welcher der folgenden Modi für eine Webanwendung ausgewählt wird:

• Klassischer Modus – Ähnlich wie in früheren Versionen kann nur ein Authentifizierungstyp pro Zone implementiert werden. In der aktuellen Version kann jedoch nur die Windows-Authentifizierung implementiert werden, wenn der klassische Modus ausgewählt wird. Demzufolge können mehrere Zonen nur zum Implementieren mehrere Windows-Authentifizierungstypen oder aber zum Implementieren desselben Windows-Authentifizierungstyps für andere Active Directory-Speicher verwendet werden.

• Forderungsauthentifizierung – Mehrere Authentifizierungsanbieter können in einer einzelnen Zone implementiert werden. Mehrere Zonen können ebenfalls verwendet werden.

Implementieren mehrerer Authentifizierungstypen in einer einzelnen Zone

Wenn Sie die Forderungsauthentifizierung verwenden und mehrere Authentifizierungstypen implementieren, empfiehlt es sich, mehrere Authentifizierungstypen in der Standardzone zu implementieren. Dadurch ergibt sich für alle Benutzer die gleiche URL.

Beim Implementieren mehrerer Authentifizierungstypen in derselben Zone gelten die folgenden Einschränkungen:

• Nur eine Instanz der formularbasierten Authentifizierung kann in einer Zone implementiert werden.

• Die Zentraladministration erlaubt die gleichzeitige Verwendung sowohl der integrierten Windows-Authentifizierung als auch der Standardauthentifizierung. Ansonsten können in einer Zone nicht mehrere Windows-Authentifizierungstypen implementiert werden.

Falls mehrere auf SAML-Token basierende Authentifizierungsanbieter für eine Farm konfiguriert sind, werden sie alle beim Erstellen einer Webanwendung oder einer neuen Zone als Optionen angezeigt. Mehrere SAML-Anbieter können in derselben Zone konfiguriert werden.

Im folgenden Diagramm ist die Implementierung mehrerer Authentifizierungstypen in der Standardzone für eine Website für die Partnerzusammenarbeit veranschaulicht.

In diesem Diagramm greifen Benutzer aus verschiedenen Verzeichnisspeichern mit der gleichen URL auf die Partnerwebsite zu. In einem gestrichelten Feld um die Partnerunternehmen ist die Beziehung zwischen dem Benutzerverzeichnis und dem in der Standardzone konfigurierten Authentifizierungstyp dargestellt. Weitere Informationen zu diesem Entwurfsbeispiel finden Sie unter Entwurfsbeispiel: Bereitstellung im Unternehmen (SharePoint Server 2010).

Planen des Durchforstens von Inhalt

Die Durchforstungskomponente benötigt Zugriff auf Inhalt mithilfe von NTLM. Für mindestens eine Zone muss die Verwendung der NTLM-Authentifizierung konfiguriert sein. Falls die NTLM-Authentifizierung nicht in der Standardzone konfiguriert ist, kann die Durchforstungskomponente eine andere Zone verwenden, für die die Verwendung der NTLM-Authentifizierung konfiguriert ist.

Implementieren mehrerer Zonen

Beachten Sie die folgenden Richtlinien, wenn Sie mehrere Zonen für Webanwendungen implementieren möchten:

• 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 minimale Anzahl von Zonen, um den Benutzern den Zugriff zu ermöglichen. Jeder Zone ist eine neue IIS-Website und -Domäne für den Zugriff auf die Webanwendung zugeordnet. Fügen Sie neue Zugriffspunkte nur dann hinzu, wenn diese benötigt werden.

• Stellen Sie sicher, dass für mindestens eine Zone die NTLM-Authentifizierung für die Durchforstungskomponente konfiguriert ist. Erstellen Sie keine dedizierte Zone für die Indexkomponente, sofern dies nicht erforderlich ist.

Im folgenden Diagramm ist die Implementierung mehrerer Zonen dargestellt, um unterschiedliche Authentifizierungstypen für eine Website für die Partnerzusammenarbeit zu ermöglichen.

In diesem Diagramm wird die Standardzone für Remotemitarbeiter verwendet. Jeder Zone ist eine andere URL zugeordnet. Die von den Mitarbeitern verwendete Zone hängt davon ab, ob sie im Büro oder unterwegs arbeiten. Weitere Informationen zu diesem Entwurfsbeispiel finden Sie unter Entwurfsbeispiel: Bereitstellung im Unternehmen (SharePoint Server 2010).

Architektur für auf SAML-Token basierende Authentifizierungsanbieter

Die Architektur zum Implementieren von auf SAML-Token basierenden Authentifizierungsanbietern weist die folgenden Komponenten auf:

SharePoint-Sicherheitstokendienst   Mit diesem Dienst werden die von der Farm verwendeten SAML-Token erstellt. Der Dienst wird auf allen Servern in einer Serverfarm automatisch erstellt und gestartet. Der Dienst wird für die Kommunikation zwischen den Farmen verwendet, da für die gesamte Kommunikation zwischen Farmen die Forderungsauthentifizierung verwendet wird. Dieser Dienst wird auch für Authentifizierungsmethoden verwendet, die für Webanwendungen implementiert werden, von denen die Forderungsauthentifizierung verwendet wird. Hierzu zählen die Windows-Authentifizierung, die formularbasierte Authentifizierung und die auf SAML-Token basierende Authentifizierung. Sie müssen den Sicherheitstokendienst während der Bereitstellung konfigurieren. Weitere Informationen finden Sie unter Konfigurieren des Sicherheitstokendiensts (SharePoint Server 2010).

Tokensignaturzertifikat (ImportTrustCertificate)   Dieses Zertifikat wird aus einem Identitätsanbieter-Sicherheitstokendienst exportiert. Das Zertifikat wird auf einen Server in der Farm kopiert. Sobald Sie mit diesem Zertifikat ein SPTrustedIdentityTokenIssuer-Objekt erstellt haben, können Sie damit kein weiteres SPTrustedIdentityTokenIssuer-Objekt erstellen. Um mit dem Zertifikat ein weiteres SPTrustedIdentityTokenIssuer-Objekt zu erstellen, müssen Sie vorher das vorhandene Objekt löschen. Zuvor müssen Sie jedoch die Zuordnung des Objekts zu Webanwendungen, die dieses Objekt verwenden, aufheben.

Identitätsforderung   Die Identitätsforderung ist die Forderung aus einem SAML-Token, das der eindeutige Bezeichner des Benutzers ist. Nur der Besitzer des Identitätsanbieter-Sicherheitstokendiensts weiß, welcher Wert im Token für jeden Benutzer immer eindeutig sein wird. Die Identitätsforderung wird beim Zuordnen der gewünschten Forderungen als reguläre Forderungszuordnung erstellt. Die Forderung, die als Identitätsforderung dient, wird beim Erstellen des SPTrustedIdentityTokenIssuer-Objekts deklariert.

Weitere Forderungen   Diese Forderungen bestehen aus zusätzlichen Forderungen aus einem SAML-Ticket, mit denen Benutzer beschrieben werden. Hierzu können Benutzerrollen, Benutzergruppen oder andere Forderungstypen wie z. B. das Alter zählen. Alle Forderungszuordnungen werden als Objekte erstellt, die an die Server in einer SharePoint Foundation-Farm repliziert werden.

Bereich   Bei der SharePoint-Forderungsarchitektur stellt der URI oder die URL, der bzw. die einer SharePoint-Webanwendung zugeordnet ist, für die die Verwendung eines auf SAML-Token basierenden Authentifizierungsanbieters konfiguriert ist, einen Bereich dar. Beim Erstellen eines auf SAML-Token basierenden Authentifizierungsanbieters in der Farm geben Sie nacheinander die Bereiche, oder Webanwendungs-URLs, an, die der Identitätsanbieter-Sicherheitstokendienst erkennen soll. Der erste Bereich wird beim Erstellen des SPTrustedIdentityTokenIssuer-Objekts angegeben. Zusätzliche Bereiche können nach dem Erstellen des SPTrustedIdentityTokenIssuer-Objekts hinzugefügt werden. Bereiche werden mithilfe von Syntax angegeben, die so oder ähnlich aussieht: $realm = "urn:sharepoint:mysites". Nachdem Sie den Bereich dem SPTrustedIdentityTokenIssuer-Objekt hinzugefügt haben, müssen Sie eine Vertrauensstellung für den Sicherheitstokendienst der vertrauenden Seite mit dem Bereich auf dem Server mit dem Sicherheitstokendienst der vertrauenden Seite einrichten. Dabei müssen Sie die URL für die Webanwendung angeben.

SPTrustedIdentityTokenIssuer   Dieses Objekt wird in der SharePoint-Farm erstellt und enthält die erforderlichen Werte, um mit dem Identitätsanbieter-Sicherheitstokendienst zu kommunizieren und Token von diesem zu empfangen. Beim Erstellen des SPTrustedIdentityTokenIssuer-Objekts definieren Sie das zu verwendende Tokensignaturzertifikat, den ersten Bereich, die Forderung, die die Identitätsforderung repräsentiert, und etwaige weitere Forderungen. Ein Tokensignaturzertifikat eines Sicherheitstokendiensts kann nur einem SPTrustedIdentityTokenIssuer-Objekt zugeordnet werden. Nachdem das SPTrustedIdentityTokenIssuer-Objekt erstellt wurde, können Sie jedoch weitere Bereiche für zusätzliche Webanwendungen hinzufügen. Wenn ein Bereich dem SPTrustedIdentityTokenIssuer-Objekt hinzugefügt wurde, muss er auch dem Identitätsanbieter-Sicherheitstokendienst als vertrauenden Seite hinzugefügt werden. Das SPTrustedIdentityTokenIssuer-Objekt wird an die Server in der SharePoint Foundation-Farm repliziert.

Sicherheitstokendienst der vertrauenden Seite (RP-STS)   In SharePoint Foundation 2010 wird jede Webanwendung, für die die Verwendung eines SAML-Anbieters konfiguriert ist, dem Server mit dem Identitätsanbieter-Sicherheitstokendienst als Eintrag für den Sicherheitstokendienst der vertrauenden Seite hinzugefügt. In einer SharePoint Foundation-Farm können mehrere Einträge für den Sicherheitstokendienst der vertrauenden Seite vorhanden sein.

Identitätsanbieter-Sicherheitstokendienst (IP-STS)   Dies ist der Sicherheitstokendienst in der Forderungsumgebung, der SAML-Token im Namen von Benutzern ausstellt, die im zugeordneten Benutzerverzeichnis enthalten sind.

Im folgenden Diagramm ist die SharePoint 2010-Produkte-Forderungsarchitektur dargestellt.

Das SPTrustedIdentityTokenIssuer-Objekt wird mithilfe mehrerer Parameter erstellt. Im folgenden Diagramm sind die wichtigsten Parameter dargestellt.

Wie im Diagramm aufgezeigt kann ein SPTrustedIdentityTokenIssuer-Objekt nur eine Identitätsanforderung, einen SignInURL-Parameter und einen Wreply-Parameter enthalten. Es sind jedoch mehrere Bereiche und Forderungszuordnungen möglich. Mit dem SignInURL-Parameter wird die URL angegeben, an die eine Benutzeranforderung zur Authentifizierung beim Identitätsanbieter-Sicherheitstokendienst umgeleitet werden soll. Einige Server mit dem Identitätsanbieter-Sicherheitstokendienst erfordern den Wreply-Parameter, der entweder auf true oder false festgelegt ist. Der Standardwert ist false. Verwenden Sie den Wreply-Parameter nur, wenn dies für den Identitätsanbieter-Sicherheitstokendienst erforderlich ist.