Freigeben über

Planen von Authentifizierungsmethoden (SharePoint Server 2010)

  • Artikel

 

Gilt für: SharePoint Foundation 2010, SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

In diesem Artikel werden die von Microsoft SharePoint Server 2010 unterstützten Authentifizierungsmethoden und -modi 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. Dabei bestimmen die Authentifizierungsmodi, wie Konten intern von SharePoint Server 2010 verwendet werden.

Inhalt dieses Artikels:

  • Unterstützte Authentifizierungsmethoden

  • Implementieren der formularbasierten Authentifizierung

  • Implementieren der auf SAML-Token basierenden Authentifizierung

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

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

Unterstützte Authentifizierungsmethoden

SharePoint Server 2010 unterstützt Authentifizierungsmethoden, die bereits in Vorgängerversionen enthalten waren. Darüber hinaus wird die auf Token basierende Authentifizierung auf der Grundlage der Security Assertion Markup Language (SAML) als Option eingeführt. In der folgenden Tabelle werden die unterstützten Authentifizierungsmethoden aufgelistet.

Methode Beispiele Hinweise

Windows

  • NTLM

  • Kerberos

  • Anonym

  • Standard

  • Digest

Windows-Authentifizierung mit Zertifikaten wird derzeit nicht unterstützt.

Formularbasierte Authentifizierung

  • LDAP (Lightweight Directory Access Protocol)

  • SQL-Datenbank oder andere Datenbank

  • Benutzerdefiniert oder Drittanbieter für Mitgliedschaften und Rollen

Auf SAML-Token basierende Authentifizierung

  • Active Directory-Verbunddienste (Active Directory Federation Services, AD FS) 2.0

  • Drittanbieter für Identitäten

  • LDAP (Lightweight Directory Access Protocol)

Wird nur mit SAML 1.1 unter Verwendung des passiven WS-Federation-Profils unterstützt.

Authentifizierungsmodi – klassisch oder anspruchsbasiert

In SharePoint Server 2010 wird die anspruchsbasierte Authentifizierung eingeführt, die auf Windows Identity Foundation (WIF) aufbaut. Sie können eine beliebige unterstützte Authentifizierungsmethode mit anspruchsbasierter Authentifizierung verwenden. Oder Sie verwenden den klassischen Authentifizierungsmodus, der Windows-Authentifizierung unterstützt.

Beim Erstellen einer Webanwendung wählen Sie für die Webanwendung eine der zwei Authentifizierungsmodi aus, entweder anspruchsbasiert oder klassisch.

Forderungsbasierte oder klassische Authentifizierung

Wenn Sie den klassischen Modus auswählen, können Sie Windows-Authentifizierung implementieren. Dadurch werden die Benutzerkonten von SharePoint Server 2010 als Active Directory-Domänendienste-Konten (Active Directory Domain Services, AD DS) behandelt.

Wenn Sie die anspruchsbasierte Authentifizierung auswählen, ändert SharePoint Server 2010 alle Benutzerkonten automatisch in Anspruchsidentitäten, woraus sich ein Anspruchstoken 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. Ansprüche, die in auf SAML basierenden Token enthalten sind, können von SharePoint Server 2010 verwendet werden. Darüber hinaus können SharePoint-Entwickler und -Administratoren Benutzertoken mit zusätzlichen Ansprüchen erweitern. Beispielsweise können Windows-Benutzerkonten und formularbasierte Benutzerkonten mit zusätzlichen Ansprüchen erweitert werden, die von SharePoint Server 2010 verwendet werden.

Im folgenden Diagramm sehen Sie eine Übersicht darüber, welcher Authentifizierungstyp von welchem Authentifizierungsmodus unterstützt wird.

Typ Klassischer Authentifizierungsmodus Anspruchsbasierte 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 Server 2010-Farm kann eine Kombination aus Webanwendungen enthalten, für die beide Modi verwendet werden. Dienste unterscheiden bei Benutzerkonten nicht zwischen traditionellen Windows-Konten und anspruchsbasierten Windows-Konten. Folglich erhält ein Benutzer, der zu Websites gehört, die für die Verwendung einer Kombination aus Authentifizierungsmodi konfiguriert sind, Suchergebnisse aus allen Websites, auf die er Zugriff hat, unabhängig vom Modus, der für die Webanwendungen konfiguriert ist. Der Benutzer wird nicht als zwei verschiedene Benutzerkonten interpretiert. Der Grund hierfür ist, dass Dienste und Dienstanwendungen für die Kommunikation zwischen Farmen Anspruchsidentitäten verwenden, unabhängig davon, welcher Modus für Webanwendungen und Benutzer ausgewählt wird.

Benutzer, die zu mehr als einem Benutzerrepository gehören, das von SharePoint Server-Webanwendungen erkannt wird, werden jedoch als separate Benutzerkonten behandelt, je nachdem, welche Identität sie zum Anmelden verwenden.

Im Folgenden einige Orientierungshilfen für die Entscheidung, welchen Modus Sie auswählen sollen:

  • Für neue Implementierungen von SharePoint Server 2010 verwenden Sie anspruchsbasierte Authentifizierung. Mit dieser Option werden Webanwendungen alle unterstützten Authentifizierungstypen zur Verfügung gestellt. Es gibt keinerlei praktische Gründe, für neue Implementierungen die Authentifizierung im klassischen Modus auszuwählen, auch wenn Ihre Umgebung ausschließlich Windows-Konten umfasst. Die Windows-Authentifizierung wird immer gleich implementiert, egal, welcher Modus ausgewählt wird. Wenn Sie den anspruchsbasierten Authentifizierungsmodus wählen, müssen Sie keine zusätzlichen Schritte ausführen, um die Windows-Authentifizierung zu implementieren.

  • Wenn Sie eine Lösung, die auf einer Vorgängerversion basiert, auf SharePoint Server 2010 upgraden und die Lösung nur Windows-Konten umfasst, können Sie den klassischen Authentifizierungsmodus verwenden. Dadurch können Sie für Zonen und URLs das gleiche Design verwenden.

  • Wenn Sie eine Lösung upgraden, die formularbasierte Authentifizierung erfordert, besteht die einzige Option darin, auf anspruchsbasierte Authentifizierung zu upgraden.

Wenn Sie von einer früheren Version auf SharePoint Server 2010 upgraden und anspruchsbasierte Authentifizierung auswählen, sollten Sie Folgendes berücksichtigen:

  • Benutzerdefinierter Code muss u. U. aktualisiert werden. Webpart- oder anderer benutzerdefinierter Code, für den Windows-Identitäten verwendet werden, muss aktualisiert werden. Wenn der benutzerdefinierte Code auf Windows-Identitäten aufbaut, verwenden Sie den klassischen Authentifizierungsmodus, bis der Code aktualisiert worden ist.

  • Die Migration einer großen Anzahl von Windows-Benutzern zu Anspruchsidentitäten nimmt Zeit in Anspruch. Wenn Sie eine Webanwendung während des Upgrades vom klassischen Modus auf anspruchsbasierte Authentifizierung umstellen, müssen Sie Windows-Identitäten mithilfe von Windows PowerShell in Anspruchsidentitäten umwandeln. Dies kann ein zeitaufwändiger Prozess sein. Achten Sie darauf, dass Sie während des Upgrades genügend Zeit für die Durchführung dieses Schritts reservieren.

  • Benachrichtigungen über Suchergebnisse werden derzeit nicht mit anspruchsbasierter Authentifizierung unterstützt.

Die anspruchsbasierte Authentifizierung beruht auf WIF. WIF ist ein 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. Weitere Informationen zur anspruchsbasierten Authentifizierung finden Sie in folgenden Ressourcen:

Sie müssen kein Anspruchsarchitekt sein, um in SharePoint Server 2010 anspruchsbasierte Authentifizierung verwenden zu können. Allerdings erfordert die Implementierung der auf SAML-Token basierenden Authentifizierung eine Koordination mit den Administratoren der anspruchsbasierten Umgebung, wie weiter unten in diesem Artikel beschrieben.

Implementieren der Windows-Authentifizierung

Der Prozess der Implementierung von Windows-Authentifizierungsmethoden ist für beide Authentifizierungsmodi (klassisch oder anspruchsbasiert) ähnlich. Wenn Sie für eine Webanwendung die anspruchsbasierte Authentifizierung auswählen, wird dadurch die Implementierung von Windows-Authentifizierungsmethoden nicht komplizierter. In diesem Abschnitt werden die Vorgehensweisen für die einzelnen Methoden zusammenfassend dargestellt.

Integrierte Windows-Authentifizierung – Kerberos und NTLM

Sowohl das Kerberos-Protokoll als auch NTLM sind integrierte Windows-Authentifizierungsmethoden. Dies erlaubt eine nahtlose Authentifizierung von Clients, ohne dass Anmeldeinformationen angefordert werden. Benutzer, die über Windows Explorer auf SharePoint-Websites zugreifen, authentifizieren sich anhand der Anmeldeinformationen, unter denen der Internet Explorer-Prozess ausgeführt wird. Dies sind standardmäßig die Anmeldeinformationen, mit denen sich der Benutzer auf dem Computer angemeldet hat. Dienste oder Anwendungen, die im integrierten Windows-Authentifizierungsmodus auf SharePoint Server zugreifen, 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. Wählen Sie diese Option einfach aus, wenn Sie eine Webanwendung erstellen.

Das Kerberos-Protokoll ist ein Sicherheitsprotokoll, das Authentifizierungs-Ticketing unterstützt. Die Verwendung des Kerberos-Protokolls erfordert eine weiter gehende Konfiguration der Umgebung. Damit 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 2010 Dienstprinzipalnamen (Service Principal Names, SPNs) in AD DS eingerichtet werden.

Im Folgenden werden die Schritte zum Konfigurieren der Kerberos-Authentifizierung zusammengefasst:

  1. Konfigurieren Sie die Kerberos-Authentifizierung für die SQL-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 2010-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.

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

Darüber hinaus muss für Webanwendungen mit anspruchsbasierter Authentifizierung der Forderungen-zu-Windows-Tokens-Dienst für eingeschränkte Delegierung konfiguriert werden. Dies ist erforderlich, damit Ansprüche in Windows-Token konvertiert werden. Für Umgebungen, die mehrere Gesamtstrukturen umfassen, erfordert die Verwendung des Forderungen-zu-Windows-Tokens-Diensts eine bidirektionale Vertrauensstellung zwischen den Gesamtstrukturen. 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 erlaubt die Delegierung von Clientanmeldeinformationen, damit auf Back-End-Datensysteme zugegriffen werden kann. Dies erfordert je nach Szenario zusätzliche Konfigurationsschritte. In der folgenden Tabelle sehen Sie einige Beispiele hierfür.

Szenario Zusätzliche Konfigurationsschritte

Delegieren der Identität eines Clients an einen Back-End-Server.

Anzeigen von RSS-Feeds für authentifizierte Inhalte.

Eingeschränkte Delegierung von Kerberos für Computer und Dienstkonten konfigurieren.

Delegieren der Identität für Microsoft SQL Server Reporting Services (SSRS)

Dienstprinzipalnamen (SPNs) für SQL Server Reporting Services-Konten konfigurieren.

Delegierung für SQL Server Reporting Services konfigurieren.

Delegieren der Identität für Excel Services in SharePoint

Eingeschränkte Delegierung für Server konfigurieren, auf denen Excel Services ausgeführt wird.

Eingeschränkte Delegierung für das Excel Services-Dienstkonto konfigurieren.

Weitere Informationen zum Konfigurieren der Kerberos-Authentifizierung sowie eine Erklärung der Konfigurationsschritte für gängige Szenarien finden Sie unter Konfigurieren der Kerberos-Authentifizierung für Microsoft SharePoint 2010-Produkte (Whitepaper) (https://go.microsoft.com/fwlink/?linkid=197178&clcid=0x407).

Digest- und Standardauthentifizierung

Wenn Sie Digest- und Standardauthentifizierung implementieren möchten, müssen Sie die jeweilige Methode direkt in Internetinformationsdienste (Internet Information Services, IIS) konfigurieren.

Implementieren der formularbasierten Authentifizierung

Formularbasierte Authentifizierung ist ein Identitätsverwaltungssystem, das auf der ASP.NET-Mitgliedschafts- und Rollenanbieterauthentifizierung basiert. In SharePoint Server 2010 ist formularbasierte Authentifizierung nur verfügbar, wenn Sie anspruchsbasierte Authentifizierung verwenden.

Formularbasierte Authentifizierung kann mithilfe von Anmeldeinformationen verwendet werden, die in AD DS, in einer Datenbank wie beispielsweise einer SQL Server-Datenbank oder in einem LDAP-Datenspeicher wie etwa Novell eDirectory, Novell Directory Services (NDS) oder Sun ONE gespeichert sind. Die formularbasierte Authentifizierung ermöglicht die Benutzerauthentifizierung basierend auf der Überprüfung von Anmeldeinformationen, die in ein Anmeldeformular eingegeben werden. Nicht authentifizierte Anforderungen werden zu einer 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.

Wenn Sie formularbasierte Authentifizierung zum Authentifizieren von Benutzern gegenüber einem nicht auf Windows basierenden oder einem externen Identitätsverwaltungssystem verwenden möchten, müssen Sie den Mitgliedschaftsanbieter und den Rollen-Manager in der Datei Web.config registrieren. Die Registrierung des Rollen-Manager ist eine neue Voraussetzung für SharePoint Server 2010. In der Vorgängerversion war dieser Schritt optional. In SharePoint Server 2010 wird die Standardschnittstelle für den ASP.NET-Rollen-Manager verwendet, um Gruppeninformationen über den aktuellen Benutzer zu erfassen. Jede ASP.NET-Rolle wird vom Autorisierungsprozess in SharePoint Server 2010 als Domänengruppe behandelt. Sie registrieren Rollen-Manager in der Datei Web.config auf die gleiche Weise wie Mitgliedschaftsanbieter für die Authentifizierung.

Wenn Sie Mitgliedschaftsbenutzer oder -rollen über die Website für die SharePoint-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.

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

Implementieren der auf SAML-Token basierenden Authentifizierung

Für die auf SAML-Token basierende Authentifizierung ist eine Koordination mit den Administratoren einer anspruchsbasierten Umgebung erforderlich, ob dies Ihre eigene interne Umgebung oder eine Partnerumgebung ist. Active Directory-Verbunddienste (Active Directory Federation Services, AD FS ) 2.0 ist ein Beispiel für eine anspruchsbasierte Umgebung.

Eine anspruchsbasierte Umgebung 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, die 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.

In SharePoint Server 2010 werden Ansprüche, die in von einem IP-STS bereitgestellten Token enthalten sind, zum Autorisieren von Benutzern verwendet. 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 2010-Produkte 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 zahlreiche RP-STS-Einträge enthalten.

Die Implementierung der auf SAML-Token basierenden Authentifizierung mit SharePoint 2010-Produkte umfasst die folgenden Prozesse, für die eine Vorausplanung erforderlich ist:

  1. Exportieren Sie das Token-Signaturzertifikat aus dem IP-STS. Dieses Zertifikat wird als ImportTrustCertificate bezeichnet. Kopieren Sie das Zertifikat auf einen Servercomputer in der SharePoint Server 2010-Farm.

  2. Definieren Sie den Anspruch, der als eindeutiger Bezeichner des Benutzers verwendet wird. Dieser wird als Identitätsanspruch bezeichnet. In vielen Beispielen für diesen Prozess wird der E-Mail-Name des Benutzers 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 Windows PowerShell erstellt.

  3. Definieren Sie zusätzliche Anspruchszuordnungen. Legen Sie fest, welche zusätzlichen Ansprüche aus dem eingehenden Token von der SharePoint Server 2010-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 2010-Farm verwendet werden kann. Alle Ansprüche aus einem eingehenden Token, die keine Zuordnung aufweisen, werden verworfen.

  4. Erstellen Sie einen neuen Authentifizierungsanbieter, indem Sie mithilfe von Windows PowerShell das Token-Signaturzertifikat 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 wird, die Sie für die auf SAML-Token basierende Authentifizierung konfigurieren. Nachdem das SPTrustedIdentityTokenIssuer-Objekt erstellt worden ist, können Sie weitere Bereiche für zusätzliche SharePoint-Webanwendungen erstellen und hinzufügen. Auf diese Weise konfigurieren Sie mehrere Webanwendungen für die Verwendung desselben SPTrustedIdentityTokenIssuer.

  5. Für jeden Bereich, der dem SPTrustedIdentityTokenIssuer-Objekt hinzugefügt wird, 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. Erstellen Sie eine neue SharePoint-Webanwendung, und konfigurieren Sie sie für die Verwendung des neu erstellten Authentifizierungsanbieters. Der Authentifizierungsanbieter wird als eine Option in der Zentraladministration angezeigt, wenn Sie für die Webanwendung den anspruchsbasierten Modus auswählen.

Sie können mehrere Anbieter für die auf SAML-Token basierende Authentifizierung konfigurieren. Allerdings können Sie ein Token-Signaturzertifikat nur einmal in einer Farm verwenden. Alle konfigurierten Anbieter werden als Optionen in der Zentraladministration angezeigt. Ansprüche aus anderen vertrauenswürdigen STS-Umgebungen verursachen hierbei keinen Konflikt.

Wenn Sie 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 Vertrauensstellung zwischen Ihrem internen IP-STS zum STS des Partners einzurichten. Bei dieser Vorgehensweise ist es nicht erforderlich, der SharePoint Server 2010-Farm einen zusätzlichen Authentifizierungsanbieter hinzuzufügen. Außerdem haben Ihre Anspruchsadministratoren hierbei die Möglichkeit, die gesamte Anspruchsumgebung zu verwalten.

Hinweis

Wenn Sie auf SAML-Token basierende Authentifizierung mit Active Directory-Verbunddiensten (AD FS) in einer SharePoint Server 2010-Farm verwenden, die mehrere Webserver in einer Konfiguration mit Lastenausgleich umfasst, kann dies eine Auswirkung auf Leistung und Funktionalität von Client-Webseitenansichten haben. Wenn Active Directory-Verbunddienste dem Client das Authentifizierungstoken bereitstellt, wird dieses Token für jedes Seitenelement mit eingeschränkten Berechtigungen an SharePoint Server 2010 gesendet. Wird für die Lösung mit Lastenausgleich keine Affinität verwendet, wird jedes geschützte Element auf mehr als einem SharePoint Server 2010-Server authentifiziert, was zur Zurückweisung des Tokens führen kann. Nachdem das Token zurückgewiesen worden ist, wird der erneut zu authentifizierende Client von SharePoint Server 2010 zurück an den AD FS-Server geleitet. Danach kann es sein, dass ein AD FS-Server mehrere Anforderungen zurückweist, die innerhalb einer kurzen Zeitspanne gesendet werden. Dieses Verhalten ist beabsichtigt, damit Schutz vor Denial-of-Service-Angriffen gewährleistet ist. Falls die Leistung beeinträchtigt ist oder Seiten nicht vollständig geladen werden, sollten Sie erwägen, den Netzwerklastenausgleich auf eine einzelne Affinität festzulegen. Dadurch werden die Anforderungen für SAML-Token auf einen einzigen Webserver isoliert.

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

Auswählen der Authentifizierung für LDAP-Umgebungen

LDAP-Umgebungen (Lightweight Directory Access Protocol) können entweder mit formularbasierter oder mit auf SAML-Token basierter Authentifizierung implementiert werden. Wir empfehlen die formularbasierte Authentifizierung, weil diese weniger komplex ist. Unterstützt die Umgebung jedoch WS-Federation 1.1 und SAML Token 1.1, dann ist SAML zu empfehlen. Profilsynchronisierung wird für LDAP-Anbieter, die nicht mithilfe von Active Directory-Verbunddienste (AD FS) 2.0 zugeordnet sind, nicht unterstützt.

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. Beim Erstellen einer Webanwendung wird die Standardzone erstellt. Zusätzliche Zonen werden durch Erweitern der Webanwendung und Auswählen eines der verbleibenden Zonennamen erstellt: Intranet, Extranet, Internet oder Benutzerdefiniert.

In den Vorgängerversionen dienen Zonen zum Implementieren verschiedener Typen der Authentifizierung für Benutzer, die von anderen Netzwerken oder Authentifizierungsanbietern kommen. In der aktuellen Version erlaubt die anspruchsbasierte Authentifizierung die Implementierung mehrerer Authentifizierungstypen in derselben Zone.

Ihre Zonenplanung hängt davon ab, welchen der folgenden Modi Sie für eine Webanwendung ausgewählt haben:

  • Klassischer Modus – Ähnlich wie in früheren Versionen kann nur ein Authentifizierungstyp pro Zone implementiert werden. Allerdings kann in der aktuellen Version nur Windows-Authentifizierung implementiert werden, wenn der klassische Modus ausgewählt ist. Demzufolge können mehrere Zonen nur zum Implementieren mehrerer Typen der Windows-Authentifizierung oder zum Implementieren ein und desselben Windows-Authentifizierungstyps für unterschiedliche Active-Directory-Speicher verwendet werden.

  • Anspruchsbasierte Authentifizierung – Mehrere Authentifizierungsanbieter können für eine einzige Zone implementiert werden. Es können auch mehrere Zonen verwendet werden.

Implementieren mehrerer Authentifizierungstypen für eine einzige Zone

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

Wenn Sie mehrere Authentifizierungstypen für die gleiche Zone implementieren, gelten die folgenden Beschränkungen:

  • Nur eine einzige Instanz der formularbasierten Authentifizierung kann für eine Zone implementiert werden.

  • Die Zentraladministration erlaubt die gleichzeitige Verwendung der integrierten Windows-Methode und der Standardmethode. Andernfalls können mehrere Typen der Windows-Authentifizierung nicht für eine Zone implementiert werden.

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.

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

Mehrere Authentifizierungstypen in einer Zone

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. Weitere Informationen zu diesem Designbeispiel finden Sie unter Entwurfsbeispiel: Bereitstellung im Unternehmen (SharePoint Server 2010).

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 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 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 minimale Anzahl von Zonen, die erforderlich sind, um den Benutzern Zugriff zu geben. 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 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 dargestellt, die für die Verwendung unterschiedlicher Authentifizierungstypen für eine Website für die Partnerzusammenarbeit implementiert sind.

Eine Zone für jeden 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. Weitere Informationen zu diesem Designbeispiel finden Sie unter Entwurfsbeispiel: Bereitstellung im Unternehmen (SharePoint Server 2010).

Architektur für auf SAML-Token basierende Anbieter

Die Architektur für die Implementierung von auf SAML-Token basierenden Anbietern umfasst die folgenden Komponenten:

SharePoint-Sicherheitstokendienst (Security Token Service, STS)   Dieser Dienst erstellt die SAML-Token, die von der Farm verwendet werden. Der Dienst wird automatisch auf allen Servern in einer Serverfarm erstellt und gestartet. Er wird für die Kommunikation zwischen den Farmen verwendet, da für die gesamte farmübergreifende Kommunikation anspruchsbasierte Authentifizierung verwendet wird. Dieser Dienst wird darüber hinaus für Authentifizierungsmethoden eingesetzt, die für Webanwendungen implementiert werden, die anspruchsbasierte Authentifizierung verwenden, z. B. Windows-, formularbasierte und auf SAML-Token basierende Authentifizierung. Sie müssen den Sicherheitstokendienst während des Bereitstellungsprozesses konfigurieren. Weitere Informationen finden Sie unter Konfigurieren des Sicherheitstokendiensts (SharePoint Server 2010).

Token-Signaturzertifikat ("ImportTrustCertificate")   Dies ist das Zertifikat, das aus einem Identitätsanbieter-Sicherheitstokendienst (Identity Provider Security Token Service, IP-STS) exportiert wird. Das Zertifikat wird auf einen Server in der Farm kopiert. Sobald Sie dieses Zertifikat zum Erstellen eines SPTrustedIdentityTokenIssuer-Objekts verwendet haben, können Sie es nicht noch einmal verwenden, um einen weiteren SPTrustedIdentityTokenIssuer 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 u. U. 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 des Prozesses 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 den Servern 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 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. Zusätzliche Bereiche können nach der Erstellung des SPTrustedIdentityTokenIssuer-Objekts hinzugefügt werden. Bereiche werden mithilfe von Syntax ähnlich der folgenden angegeben: $realm = "urn:sharepoint:mysites". Nachdem Sie den Bereich dem SPTrustedIdentityTokenIssuer hinzugefügt haben, müssen Sie eine RP-STS-Vertrauensstellung mit dem Bereich auf dem IP-STS-Server einrichten. Dabei müssen Sie die URL für die Webanwendung angeben.

"SPTrustedIdentityTokenIssuer"   Dies ist das Objekt, das auf der SharePoint-Farm erstellt wird, das die Werte enthält, die für die Kommunikation mit dem IP-STS und für den Empfang von Token vom IP-STS benötigt werden. Beim Erstellen des SPTrustedIdentityTokenIssuer-Objekts geben Sie das zu verwendende Token-Signaturzertifikat, den ersten Bereich, den Anspruch, der den Identitätsanspruch darstellt, und zusätzliche Ansprüche an. Sie können ein Token-Signaturzertifikat aus einem STS nur einem einzigen SPTrustedIdentityTokenIssuer zuordnen. Allerdings können Sie nach dem Erstellen des SPTrustedIdentityTokenIssuer-Objekts weitere Bereiche für zusätzliche Webanwendungen hinzufügen. Nachdem Sie einen Bereich dem SPTrustedIdentityTokenIssuer-Objekt hinzugefügt haben, müssen Sie ihn auch dem IP-STS als vertrauende Seite hinzufügen. Das SPTrustedIdentityTokenIssuer-Objekt wird auf den Servern in der SharePoint Server-Farm repliziert.

Sicherheitstokendienst einer vertrauenden Seite (Relying Party Security Token Service, RP-STS)   In SharePoint Server 2010 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.

Im folgenden Diagramm wird die Anspruchsarchitektur von SharePoint 2010-Produkte dargestellt.

SharePoint-Komponenten für die Forderungsauthentifizierung

Das SPTrustedIdentityTokenIssuer-Objekt wird mithilfe von mehreren Parametern erstellt. Im folgenden Diagramm werden die wichtigsten Parameter dargestellt.

SPTrustedIdentityTokenIssuer-Design

Wie im Diagramm zu sehen, kann ein SPTrustedIdentityTokenIssuer-Objekt jeweils nur einen Identitätsanspruch, einen SignInURL-Parameter und einen Wreply-Parameter enthalten. Es kann jedoch mehrere Bereiche und mehrere Anspruchszuordnungen enthalten. Der SignInURL-Parameter gibt die URL an, zu der eine Benutzeranforderung umgeleitet werden soll, damit die Authentifizierung beim IP-STS erfolgt. Für manche IP-STS-Server ist der Wreply-Parameter erforderlich. Dieser ist entweder true oder false, wobei false der Standardwert ist. Verwenden Sie den Wreply-Parameter nur, wenn dies für den IP-STS erforderlich ist.