Tipps zu Ansprüchen – 1: Informationen zur anspruchsbasierten Authentifizierung in SharePoint 2010

Artikel
06/24/2015

Zusammenfassung: Sie erfahren fünf Tipps zur anspruchsbasierten Authentifizierung in SharePoint 2010.

Letzte Änderung: Freitag, 12. August 2011

Inhalt dieses Artikels
Überblick über den Themenbereich dieses Artikels
Tipp 1: Erstellen mehrerer Webanwendungen mit Anspruchsauthentifizierung in einer einzigen SharePoint 2010-Farm
Tipp 2: Migrieren einer Webanwendung von der klassischen Windows-Authentifizierung zur anspruchsbasierten Authentifizierung in SharePoint 2010
Tipp 3: Verwenden von Benutzergruppen in Verbindung mit Anspruchsauthentifizierungssites in SharePoint 2010
Tipp 4: Erstellen einer Identitätsrolle und eines Rollenanspruchs für eine SharePoint 2010-Anwendung mit Anspruchsauthentifizierung
Tipp 5: Ermitteln, welche Ansprüche in SharePoint 2010 vorliegen
Schlussbemerkung
Weitere Ressourcen

Bereitgestellt von: Steve Peschka, Microsoft Corporation

Inhalt

Überblick über den Themenbereich dieses Artikels
Tipp 1: Erstellen mehrerer Webanwendungen mit Anspruchsauthentifizierung in einer einzigen SharePoint 2010-Farm
Tipp 2: Migrieren einer Webanwendung von der klassischen Windows-Authentifizierung zur anspruchsbasierten Authentifizierung in SharePoint 2010
Tipp 3: Verwenden von Benutzergruppen in Verbindung mit Anspruchsauthentifizierungssites in SharePoint 2010
Tipp 4: Erstellen einer Identitätsrolle und eines Rollenanspruchs für eine SharePoint 2010-Anwendung mit Anspruchsauthentifizierung
Tipp 5: Ermitteln, welche Ansprüche in SharePoint 2010 vorliegen
Schlussbemerkung
Weitere Ressourcen

Laden Sie das zu diesem Artikel gehörende Codebeispiel herunter:SharePointClaims_MSDNExample.zip

Überblick über den Themenbereich dieses Artikels

Dieser Artikel enthält Tipps und Antworten zu häufig gestellten Fragen zur anspruchsbasierten Authentifizierung in Microsoft SharePoint 2010. Zudem werden Tipps und Anleitungen zur Lösung von Problemen im Zusammenhang mit dem Konfigurieren von Ansprüchen bereitgestellt, und es wird auf andere Ressourcen mit weiteren Informationen hingewiesen.

Hinweis
Das zu diesem Artikel gehörende Codebeispiel SharePointClaims_MSDNExample.zip ist für Tipp 5: Ermitteln, welche Ansprüche in SharePoint 2010 vorliegen vorgesehen.

Tipp 1: Erstellen mehrerer Webanwendungen mit Anspruchsauthentifizierung in einer einzigen SharePoint 2010-Farm

In der Frage, wie mehrere Webanwendungen, die die Anspruchsauthentifizierung verwenden, in SharePoint 2010 konfiguriert werden können, besteht vor allem Unklarheit in Bezug auf das SPTrustedIdentityTokenIssuer-Objekt. Wie ich im Blogeintrag Planning Considerations for Claims Based Authentication in SharePoint 2010 (Planungsaspekte im Zusammenhang mit der anspruchsbasierten Authentifizierung in SharePoint 2010) angemerkt habe, kann ein Tokensignaturzertifikat nur von einem Sicherheitstokendienst (STS) einem SPTrustedIdentityTokenIssuer-Objekt zugeordnet werden. Wenn Sie das SPTrustedIdentityTokenIssuer-Objekt erstellen, erhält das SPTrustedIdentityTokenIssuer-Objekt folgende Informationen:

Das Tokensignaturzertifikat, das verwendet wird
Der verwendete Bereich

Der Bereich ist wichtig, weil er in die Abfragezeichenfolge aufgenommen wird, die zum STS zurückgesendet wird. Der STS ermittelt anhand dieses Bereichs, welche vertrauende Stelle vorliegt, damit der STS weiß, welche Anspruchsregeln verarbeitet werden müssen, unter welcher URL die Vertrauensrichtlinie für die Webanwendung zu finden ist usw. Obwohl Sie beispielsweise einem Active Directory-Verbunddienste (AD FS) 2.0 mehrere Tokensignaturzertifikate hinzufügen können, gibt es keine Möglichkeit, ein bestimmtes Tokensignaturzertifikat einer bestimmten vertrauenden Seite zuzuordnen. Daher müssen Sie eine Methode finden, wie sie mit dem vorliegenden Zertifikat verwendet werden kann.

Das SPTrustedIdentityProvider-Objekt verfügt über die ProviderRealmsEigenschaft, der mehrere Bereiche zugeordnet werden können. Nehmen wir beispielsweise an, Sie haben zwei Webanwendungen: https://collab und https://mysites. Sie erstellen mit Windows PowerShell ein SPTrustedIdentityTokenIssuer-Objekt, das so ähnlich wie der folgende cmdlet-Codeausschnitt aussieht.

$realm = "urn:sharepoint:collab"
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS v2" -Description "ADFS v2" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https://URLToYourAdfsServer/adfs/ls" -IdentifierClaim https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Das SPTrustedIdentityTokenIssuer-Objekt wird jetzt erstellt und hat den Standardbereich urn:sharepoint:collab. Wir erstellen in AD FS 2.0 eine vertrauende Seite und geben die Bezeichner urn:sharepoint:collab und https://collab/_trust/ an. Für unsere zweite Webanwendung müssen wir jetzt einen zweiten Bereich dem SPTrustedIdentityTokenIssuer-Objekt hinzufügen. Es folgt der Windows PowerShell-Code hierfür.

$uri = new-object System.Uri("https://mysites")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:mysites")
$ap.Update()

Das wichtigste Element ist hier der URI. Als URI sollte die URL der Webanwendung, die den betreffenden Bereich nutzt, angegeben werden. Während der Authentifizierung führt SharePoint eine Nachschlagefunktion aus, um den Bereich zu finden, der dem URI der Webanwendung zugeordnet ist. Dieser URI wird dann von SharePoint verwendet. In diesem Fall soll der Bereich urn:sharepoint:mysites in Verbindung mit der Webanwendung unter https://mysites verwendet werden. Daher wurde dieser URI beim Hinzufügen des Bereichs angegeben. Jetzt können wir zu AD FS 2.0 zurückkehren und eine zweite vertrauende Seite mit dem Bezeichner urn:sharepoint:mysites und https://mysites/_trust/ definieren, und alles sollte wie gewünscht funktionieren.

Tipp 2: Migrieren einer Webanwendung von der klassischen Windows-Authentifizierung zur anspruchsbasierten Authentifizierung in SharePoint 2010

Wie gehe ich vor, wenn ich eine Webanwendung habe, die die klassische Windows-Authentifizierung verwendet, und ich möchte sie abändern, damit sie die anspruchsbasierte Windows-Authentifizierung verwendet? Vielleicht haben Sie mit der klassischen Windows-Authentifizierung begonnen und möchten jetzt auf die anspruchsbasierte Authentifizierung umstellen; oder Sie hatten vielleicht eine SharePoint 2007-Site, die Sie aktualisiert haben. Ich habe dies in einem relativ kleinen Testfall getan und möchte die Vorgehensweise und die Dinge, die ich untersucht habe, weitergeben.

Vorsicht
Wenn Sie einmal auf die anspruchsbasierte Windows-Authentifizierung umgestellt haben, können Sie nicht zur klassischen Windows-Authentifizierung zurückkehren. Bevor Sie beginnen, müssen Sie sicherstellen, dass Sie über gute Sicherungen verfügen. Ich habe meine Inhaltsdatenbank in Microsoft SQL Server und meine Webanwendung in der Zentraladministration gesichert. Ich rate Ihnen dringend, dies zuerst in einer Versuchsumgebung auszuprobieren, bevor Sie die Produktionsumgebung verändern.

Wenn Sie einmal auf die anspruchsbasierte Windows-Authentifizierung umgestellt haben, können Sie nicht zur klassischen Windows-Authentifizierung zurückkehren. Bevor Sie beginnen, müssen Sie sicherstellen, dass Sie über gute Sicherungen verfügen. Ich habe meine Inhaltsdatenbank in Microsoft SQL Server und meine Webanwendung in der Zentraladministration gesichert. Ich rate Ihnen dringend, dies zuerst in einer Versuchsumgebung auszuprobieren, bevor Sie die Produktionsumgebung verändern.

Nachdem wir die erforderlichen Vorsichtsmaßnahmen eingegangen sind, ist das Vorgehen recht unkompliziert. Mit einigen Zeilen Windows PowerShell-Code und etwas Zeit sollte es Ihnen gelingen. Nachfolgend sind die Windows PowerShell-Befehle angegeben.

$WebAppName = "http://yourWebAppUrl"
$account = "yourDomain\yourUser"
$wa = get-SPWebApplication $WebAppName

Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
#This causes a prompt about migration. Click Yes and continue.

#The following step sets the user as an administrator for the site. 
$wa = get-SPWebApplication $WebAppName
$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()

#After the user is added as an administrator, we set the policy so that the user can have the correct access.
$zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()

#The final step is to trigger the user-migration process.
$wa = get-SPWebApplication $WebAppName
$wa.MigrateUsers($true)

Einige Dinge können noch problematisch sein, nachdem Sie die oben angegebenen Befehle implementiert haben:

Benutzer können sich nicht anmelden. Sie stellen möglicherweise fest, dass sich Benutzer nicht bei der Website anmelden können. Nachdem Sie die Anmeldeinformationen eingegeben haben, werden Sie darüber informiert, dass Sie Domäne\Benutzer sind, aber über keine Zugriffsberechtigungen verfügen. Wenn Sie diese Meldung erhalten, haben Sie vor der Migration wahrscheinlich dieportalsuperuseraccount-Eigenschaft und die portalsuperreaderaccount-Eigenschaft vor der Migration konfiguriert. Sie müssen diese Eigenschaften mit dem Benutzerkontonamen für die anspruchsbasierte Authentifizierung aktualisieren. Um den anspruchsbasierten Benutzerkontonamen zu erhalten, sehen Sie sich nach der Migration die Webanwendungsrichtlinie für die Webanwendung an. Kopieren Sie den hier angegebenen Kontonamen.
Vorhandene Warnungen werden nicht ausgegeben. Wenn vorhandene Warnungen nicht ausgegeben werden, lässt sich das Problem derzeit nur dadurch umgehen, dass Sie die Warnungen löschen und erneut erstellen.
Die Suchdurchforstung funktioniert nicht mehr. Überprüfen Sie die Webanwendungsrichtlinien genau, und stellen Sie sicher, dass der neue Kontoname als Suchdurchforstungskonto angezeigt wird. Ist dies nicht der Fall, müssen Sie für das Durchforstungskonto von Hand eine neue Richtlinie erstellen.

Da das Cmdlet MigrateUsers in einem Zeitgeberauftrag ausgeführt wird, müssen Sie unter Umständen warten, bis der Auftrag abgeschlossen wurde. Nach dessen Abschluss habe ich Folgendes überprüft:

Benutzer können sich anmelden. Die Benutzer, die einzeln hinzugefügt wurden, und die Benutzer, die Mitglied einer Active Directory-Gruppe sind, die einer SharePoint-Gruppe hinzugefügt wurde, können sich anmelden.
Die Aufgabenansicht einer Aufgabenliste funktioniert noch. Elemente, die mir als Benutzer mit klassischer Windows-Authentifizierung zugewiesen wurden, werden nach wie vor in meiner Aufgabenliste angezeigt (d. h. das System weiß, dass "Anspruchsbasiertes-Windows-Steve" früher "Klassisches-Windows-Steve" war).
Meine Genehmigungsworkflows, die verarbeitet wurden, funktionieren noch. Ich kann die Genehmigungsworkflows immer noch erfolgreich ausführen.
Meine benutzerdefinierten SharePoint Designer-Workflows, die verarbeitet wurden, funktionieren noch. Ich kann meine benutzerdefinierten Workflows nach wie vor erfolgreich ausführen.
Ich kann SharePoint Designer-Workflows erstellen. Ich kann neue Instanzen von Standardworkflows und benutzerdefinierten SharePoint Designer-Workflows erstellen.
Ich kann die Webanwendung durchforsten. Ich kann die Webanwendung erfolgreich durchforsten.
Ich kann den Inhalt abfragen. Ich kann die Webanwendung durchforsten und dadurch erfolgreich Inhalte abfragen.

Bislang habe ich nur eine Unregelmäßigkeit festgestellt: Wenn ich eine neue Warnung auf der Website erstelle, wird gemeldet, sie sei erfolgreich erstellt worden (ich erhalte sogar eine E-Mail-Nachricht, die dies bestätigt), aber wenn ich meine Warnungen verwalte, wird sie nicht in der Liste angezeigt. Außerdem wird bei Änderungen keine E-Mail-Nachricht mit einer Warnung generiert. Wenn ich andere Besonderheiten bemerke, werde ich versuchen, diese in meinem Blog zu veröffentlichen.

Tipp 3: Verwenden von Benutzergruppen in Verbindung mit Anspruchsauthentifizierungssites in SharePoint 2010

Möglicherweise haben Sie beim Einsatz von SAML-Ansprüchen (Security Assertion Markup Language) nicht berücksichtigt, wie sich dies auf die Benutzergruppenfunktion in SharePoint 2010 auswirkt. Standardmäßig werden Benutzer nur aus Verzeichnissen wie Active Directory und einigen LDAP-Quellen (Lightweight Directory Access Protocol) importiert.

Das Problem besteht darin, dass der Kontoname für SAML-Anspruchsbenutzer etwa so aussieht i:05:t|adfs with roles|fred@contoso.com. Können Benutzergruppen mit dieser Art von Benutzern verwendet werden? Die Frage lässt sich glücklicherweise bejahen, aber Sie müssen etwas dafür tun.

Als Erstes müssen Sie Profile für diese Personen erstellen; das ist am wichtigsten. Sie können die Profile manuell erstellen, oder Code schreiben, der dies für Sie erledigt. Auf jeden Fall müssen Sie diese Profile erstellen und eine Zeichenfolge wie i:05:t|adfs with roles|fred@contoso.com als Kontonamen angeben. Dann füllen Sie die anderen Felder mit den Daten, die Sie in den Benutzergruppen verwenden möchten.

Als Nächstes erstellen Sie neue Benutzergruppen. Es ist nicht möglich, benutzerbasierte Benutzergruppen, wie Mitglied von Gruppe zu definieren (zumindest nicht, ohne zusätzlichen Code zu schreiben, und darauf einzugehen, würde hier zu weit führen). Stattdessen werden Sie eigenschaftenbasierte Benutzergruppen. In meinem Szenario verwendete ich das Feld Office aus dem Profil als Grundlage für meine Zielgruppe. Ich erstellte zwei Profile für zwei verschiedene Benutzer mit Anspruchsauthentifizierung und habe für einen Benutzer das Feld Office mit dem Wert Contoso und für den anderen Benutzer das Feld Office mit dem Wert Wingtip Toys festgelegt. In meiner neuen Benutzergruppe erstellte ich daraufhin die Regel Office = Contoso und nannte sie Contoso Employees. Nachdem ich die Benutzergruppe kompiliert hatte, sah ich, dass die beiden Benutzer mit Anspruchsauthentifizierung darin aufgeführt wurden.

Um dies genauer zu überprüfen, wechselte ich zu meiner Anspruchswebsite und definierte einen Webpart für eine Benutzergruppe. Alles verlief wie erwartet, nur die Personenauswahl wurde nicht ordnungsgemäß mit einer Liste aller Benutzergruppen gefüllt. Als ich dann aber nach Contoso Employeessuchte, wurde die von mir erstellte Benutzergruppe gefunden. Ich wählte diese Benutzergruppe als Webpartziel aus und speicherte meine Änderungen. Schließlich meldete ich mich unter den beiden Benutzernamen mit Anspruchsauthentifizierung an und navigierte zu dieser Website. Der Benutzer, der zur Benutzergruppe Contoso Employees gehörte, sah den Part, der andere dagegen nicht.

Tipp 4: Erstellen einer Identitätsrolle und eines Rollenanspruchs für eine SharePoint 2010-Anwendung mit Anspruchsauthentifizierung

Aus verschiedenen Gründen ist es mühsam, eine Webanwendung mit anspruchsbasierter Authentifizierung sowohl mit Identitäts- als auch mit Rollenansprüchen richtig zum Laufen zu bringen. Daher werde ich hier einfach die Schritte veröffentlichen, die zum Erstellen der Ansprüche und des SPTrustedIdentityTokenIssuer-Objekts erforderlich sind.

Erstellen Sie den Identitätsanspruch, wie im folgenden Code gezeigt.

$map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" 
-IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

Erstellen Sie den Rollenanspruch, wie im folgenden Code gezeigt.

$map2 = New-SPClaimTypeMapping -IncomingClaimType " https://schemas.microsoft.com/ws/2008/06/identity/claims/role " -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

Binden Sie beide Ansprüche beim Erstellen des SPTrustedIdentityTokenIssuer-Objekts ein, wie im folgenden Code gezeigt.

$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS v2" -Description "ADFS v2" 
-Realm "yourRealmName" -ImportTrustCertificate $yourCert -ClaimsMappings $map,$map2 
-SignInUrl "https://URLToYourAdfsServer/adfs/ls" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

Ein wichtiger Punkt ist hier, dass Sie beide Ansprüche beim Erstellen des Tokenherausgebers einbinden müssen; Sie können sie nicht danach hinzufügen. Dies ist eine der Beschränkungen von SPTrustedIdentityTokenIssuers.

Tipp 5: Ermitteln, welche Ansprüche in SharePoint 2010 vorliegen

Eines der interessanten Probleme, die ich zu lösen versuchte, hatte mit den seltsamen Berechtigungsfehlern bei einer Website mit anspruchsbasierter Authentifizierung zu tun. Ein Teil der Schwierigkeiten bei der Problembehebung besteht darin, dass wir die Ansprüche, von deren Vorhandensein SharePoint ausgeht, nicht aufzählen und sie irgendwohin ausgeben.

Wenn ich zu einer Website wechselte und mir entweder der Zugriff ganz verweigert wurde oder ich nicht auf alle Inhalte, auf die ich meiner Ansicht nach zugreifen können sollte, Zugriff erhielt, konnte ich nicht herausfinden, warum dies der Fall war. Um diese Art von Szenarien leichter debuggen zu können, schrieb ich eine recht einfache Assembly, die mir sagt, welche Ansprüche in SharePoint für mich vorliegen, d. h. die aktuelle Benutzeranforderung. Ich implementierte dies auf zweierlei Weise.

Ein Teil der Assembly wird als HttpModule implementiert. Sie zählt die Ansprüche auf und gibt sie in das ULS-Protokoll (Unified Logging Service) aus. Diese Einträge lassen sich leicht auffinden, indem das ULS-Protokoll nach der Kategorie SharePoint Claims Enumeration gefiltert wird. Das HttpModule ist in den Fällen hilfreich, in denen Sie sich bei der Website nicht einmal anmelden können.
Der zweite Teil der Assembly wird als Webpart implementiert. Sie gibt einfach die vorliegenden Ansprüche und jeweils den Wert der einzelnen Ansprüche aus. Dies ist hilfreich in Szenarien, in denen Sie sich bei der Website anmelden können, aber herauszufinden versuchen, warum Sie nicht auf alle Inhalte zugreifen können, auf die Sie Ihrer Meinung nach Zugriff haben sollten.

Das zu diesem Artikel gehörende Codebeispiel SharePointClaims_MSDNExample.zip enthält den Quellcode und die Debugversion dieser Assembly; Anweisungen finden Sie in der Datei Instructions.txt.

Ein weiterer wichtiger Punkt, den ich in Bezug auf Ansprüche in SharePoint in Erfahrung gebracht habe, ist, dass der Token nach der Authentifizierung beim STS an SharePoint zurückgegeben wird. SharePoint führt eine Liste mit allen Ansprüchen, die es erwartet. SharePoint hält nach diesen Ansprüchen Ausschau und integriert sie ein SPClaim-Objekt. Wenn der STS neben den Ansprüchen, die SharePoint erwartet, weitere Ansprüche sendet, dann ignoriert SharePoint diese zusätzlichen Ansprüche, und sie werden nicht dem SPClaim-Objekt hinzugefügt. Beim Versuch, Probleme mit der Anspruchsauthentifizierung zu beheben, kann es hilfreich sein, sich daran zu erinnern.

Schlussbemerkung

Dieser Artikel enthält Antworten auf häufig gestellte Fragen zur anspruchsbasierten Authentifizierung in SharePoint 2010. Zudem werden fünf Tipps und Anleitungen zur Lösung von Problemen im Zusammenhang mit dem Konfigurieren von Ansprüchen bereitgestellt, und es wird auf andere Ressourcen mit weiteren Informationen hingewiesen.

Weitere Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen:

Freigeben über