Durchgängiges Konfigurieren von SharePoint 2010 und AD FS v2 ~ Dynamics CRM 2015

Durchgängiges Konfigurieren von SharePoint 2010 und AD FS v2

In diesem Beitrag zeige ich in einer durchgängigen exemplarischen Vorgehensweise, wie Sie SharePoint 2010 und AD FS v2 (Active Directory Federation Services, Active Directory-Verbunddienste) zusammen für die Verwendung der SAML-Forderungsauthentifizierung konfigurieren. Ich zeige Ihnen dies in einem Beitrag, der alle entsprechenden Schritte und PowerShell-Skripts enthält.

Zuerst gebe ich Ihnen einen kurzen Überblick über die beteiligten Komponenten und über die Schritte, die Sie ausführen müssen. In diesem Szenario ist AD FS v2 der Identitätsanbieter, der auch als Identitätsanbieter-Sicherheitstokendienst (IP-STS) bezeichnet wird. Wir müssen AD FS mit Informationen zur vertrauenden Seite (Relying Party, RP) konfigurieren. In diesem Fall ist SharePoint die vertrauende Seite, da die Authentifizierung von AD FS ausgeführt wird und die Forderungen ebenfalls von AD FS bereitgestellt werden. Aus SharePoint-Sicht müssen wir SharePoint so konfigurieren, dass SharePoint dem Identitätsanbieter-Sicherheitstokendienst vertraut, von dem die Forderungen gesendet werden. Anschließend müssen wir eine Webanwendung und eine Website einrichten, von denen diese Forderungen verwendet werden.

Zunächst erstellen wir die vertrauende Seite in AD FS. Es spielt keine Rolle, in welcher Reihenfolge Sie diese Schritte ausführen, ich konfiguriere jedoch in der Regel zuerst AD FS. Öffnen Sie auf dem Server, auf dem AD FS installiert ist, die Verwaltungsanwendung für AD FS 2.0. Erweitern Sie den Knoten Vertrauensstellungen (Trust Relationships), und klicken Sie auf den Knoten Vertrauensstellungen der vertrauenden Seite (Relying Party Trusts).

Klicken Sie im linken Bereich auf den Link Vertrauensstellung der vertrauenden Seite hinzufügen (Add Relying Party Trust), um den Assistenten zum Hinzufügen von Vertrauensstellungen der vertrauenden Seite zu starten.

Klicken Sie auf die Schaltfläche Start, um den Vorgang fortzusetzen.

Wählen Sie die Option Konfiguration der vertrauenden Seite manuell eingeben (Enter data about the relying party manually) aus, und klicken Sie dann auf die Schaltfläche Weiter (Next).

Geben Sie einen Anzeigenamen und optional eine Beschreibung für die vertrauende Seite ein, und klicken Sie dann auf die Schaltfläche Weiter (Next).

Wählen Sie die Option zum Verwenden des AD FS 2.0-Profils aus, und klicken Sie dann auf die Schaltfläche Weiter (Next).

Sie können ein Zertifikat auswählen, um das SAML-Token selbst zu verschlüsseln. Dies wird selten getan, da für AD FS die Verbindung mit SharePoint über SSL hergestellt werden muss, das heißt, der Kanal, über den das Token gesendet wird, ist verschlüsselt. Klicken Sie auf die Schaltfläche Weiter (Next).

Aktivieren Sie das Kontrollkästchen Unterstützung für das WS-Passivverbund-Protokoll aktivieren aktivieren (Enable support for the WS-Federation Passive protocol). Für die Protokoll-URL müssen Sie die URL der Stammwebsite der SharePoint-Webanwendung eingeben und das Unterverzeichnis _trust einschließen. In diesem Beispiel lautet die URL der SharePoint-Webanwendung https://seo14. Entsprechend lautet die URL des WS-Passivverbund-Protokolls https://seo14/_trust/. Wenn Sie die URL eingegeben haben, klicken Sie auf die Schaltfläche Weiter (Next).

Als Bezeichner für die Vertrauensstellung der vertrauenden Seite müssen Sie einen Bereich eingeben, der von der Webanwendung an AD FS übergeben wird, wenn sich Benutzer bei der Webanwendung anmelden. Der Bereich wird im Allgemeinen im Format urn:foo:bar erstellt. Der Bereich ist einer Webanwendung zugeordnet. Auf diese Weise kann die eingehende Anmeldeanforderung von AD FS den vorhandenen Vertrauensstellungen der vertrauenden Seite zugeordnet werden. Wenn AD FS mit SharePoint verwendet wird, wird der der Anmeldeanforderung zugeordnete Bereich erkannt und nachgeschlagen, um die Vertrauensstellung der vertrauenden Seite zu suchen. Nach der Authentifizierung des Benutzers wird anhand dieser URL des WS-Passivverbund-Protokolls ermittelt, wohin der Benutzer anschließend umgeleitet werden soll. In diesem Fall habe ich den Bereich urn:seo:sharepoint eingegeben. Wenn ich zur SharePoint-Website https://seo14 zu navigieren versuche, werde ich an AD FS umgeleitet. Ich konfiguriere SharePoint so, dass für diese Anforderung der Bereich urn:seo:sharepoint verwendet wird. Nach der Authentifizierung durch AD FS werde ich wieder an https://seo14/_trust/ umgeleitet, da dies die URL des passiven Protokolls für diese vertrauende Seite ist. Fügen Sie hier einen beliebigen Bereich hinzu, und merken Sie sich den Namen, da Sie diesen beim Konfigurieren von SharePoint erneut eingeben müssen. Klicken Sie dann auf die Schaltfläche Weiter (Next).

In den meisten Fällen möchten Sie, dass alle Benutzer diese vertrauende Seite verwenden können. Wir nehmen an, dass dies in diesem Szenario der Fall ist. Übernehmen Sie also einfach die Standardauswahl, und klicken Sie auf die Schaltfläche Weiter (Next).

Wenn Sie andere Konfigurationsänderungen an der Vertrauensstellung der vertrauenden Seite vornehmen müssen, dann haben Sie hier dazu Gelegenheit. In diesem Szenario ist dies nicht notwendig. Klicken Sie daher einfach auf die Schaltfläche Weiter (Next), um den Vorgang fortzusetzen.

Wir sind jetzt mit dem Konfigurieren der Vertrauensstellung der vertrauenden Seite fertig, aber wir müssen noch eine Forderungsregel erstellen, aus der hervorgeht, welche Forderungen von AD FS zurück an SharePoint gesendet werden sollen. Lassen Sie das Kontrollkästchen zum Öffnen des Dialogfelds für die Bearbeitung von Forderungsregeln aktiviert, und klicken Sie auf die Schaltfläche Schließen (Close).

Nun erstellen wir eine neue Regel. Klicken Sie daher auf die Schaltfläche Regel hinzufügen (Add Rule).

Wir senden LDAP-Attribute als Forderungen, da wir in diesem Fall Informationen von Active Directory erhalten, das heißt, wir authentifizieren uns über AD FS und werden von AD FS anhand der Active Directory-Informationen des Unternehmens authentifiziert, anhand derer auch unsere Attribute ermittelt werden. Lassen Sie den Standardwert ausgewählt, und klicken Sie auf die Schaltfläche Weiter (Next), um den Vorgang fortzusetzen.

Geben Sie zunächst einen Namen für die Forderungsregel ein. Dabei können Sie einen beliebigen Namen verwenden. Wählen Sie dann in der Dropdownliste Attributspeicher (Attribute store) die Option Active Directory aus. Als Nächstes möchten wir für unser Szenario die E-Mail-Adresse und die Gruppen, zu denen der Benutzer gehört, zurück an SharePoint senden. Wir verwenden die E-Mail-Adresse als Bezeichner für den Benutzer, und wir möchten, dass alle Gruppen, zu denen ein Benutzer gehört, in der Rollenforderung gesendet werden. Wählen Sie für die Zuordnung das gewünschte Attribut aus der Dropdownliste auf der linken Seite aus, und wählen Sie dann aus der Dropdownliste auf der rechten Seite die Forderung aus, als die das Attribut gesendet werden soll. In diesem Fall soll das Attribut E-Mail-Adressen (E-Mail-Addresses) aus Active Directory in der standardmäßigen E-Mail-Adressenforderung gesendet werden. Wir möchten, dass die Gruppen, zu denen ein Benutzer gehört, in der standardmäßigen Rollenforderung gesendet werden. In diesem Fall habe ich Tokengruppen – Unvollständige Namen (Token-Groups – Unqualified Names) ausgewählt, da damit der Gruppenname als einfache Zeichenfolge (der Name der Gruppe) gesendet wird. Sie können die SID der Gruppen senden, dies wird jedoch schwieriger, wenn Sie versuchen, eine Rollenforderung einer SharePoint-Gruppe zuzuweisen. Wenn Sie mit dem Konfigurieren der Regel wie hier beschrieben fertig sind, klicken Sie auf die Schaltfläche Fertig stellen (Finish), um die Regel abzuschließen.

Klicken Sie auf die Schaltfläche OK, um den Erstellungsvorgang für die Vertrauensstellung der vertrauenden Seite in AD FS abzuschließen. Im Hinblick auf die Konfiguration in AD FS sind keine weiteren Schritte auszuführen. Es gibt jedoch noch etwas, das wir benötigen. In AD FS wird zum Signieren der gesendeten Token ein Zertifikat verwendet. Daher kann sich der Empfänger des Tokens darauf verlassen, dass das Token nach der Erstellung nicht manipuliert wurde. Zum Konfigurieren von SharePoint benötigen wir eine Kopie dieses Zertifikats, da wir dieses verwenden, wenn wir die Verwendung von AD FS als Identitätsanbieter-Sicherheitstokendienst konfigurieren. Zum Abrufen des Tokensignaturzertifikats aus AD FS erweitern Sie den Knoten Dienst (Service), und klicken Sie auf den Knoten Zertifikate (Certificates).

Hier wird ein Abschnitt für Tokensignaturzertifikate angezeigt. Auch wenn möglicherweise mehrere Tokensignaturzertifikate vorhanden sind, gibt es immer NUR ein primäres Tokensignaturzertifikat. Klicken Sie auf dieses Zertifikat und dann im rechten Bereich auf den Link Zertifikat anzeigen (View Certificate).

In diesem speziellen Fall möchte ich das Zertifikat verwenden, das ich für SSL auf der AD FS-Website erstellt habe. Damit möchte ich nicht sagen, dass dies notwendig ist oder empfohlen wird, es ist lediglich meine Wahl in diesem Fall. Das Zertifikat wird nun angezeigt. Klicken Sie oben im Dialogfeld auf die Registerkarte Details.

Klicken Sie auf die Schaltfläche In Datei kopieren (Copy to File). Daraufhin wird ein Assistent gestartet, mit dessen Hilfe Sie eine Kopie des Zertifikats auf dem Datenträger speichern können.

Klicken Sie auf die Schaltfläche Weiter (Next), um den Vorgang fortzusetzen.

Sie benötigen den privaten Schlüssel nicht. Übernehmen Sie daher die Standardeinstellungen, und klicken Sie auf die Schaltfläche Weiter (Next).

Das Standardformat ist geeignet. Klicken Sie auf die Schaltfläche Weiter (Next), um den Vorgang fortzusetzen.

Wählen Sie einen Speicherort für das Zertifikat aus, und klicken Sie auf die Schaltfläche Weiter (Next). Merken Sie sich diesen Speicherort unbedingt, da Sie das Zertifikat aus diesem Speicherort auf den SharePoint-Server kopieren müssen.

Alle zum lokalen Kopieren des Zertifikats benötigten Informationen sind jetzt erfasst. Klicken Sie auf die Schaltfläche Fertig stellen (Finish), um den Assistenten abzuschließen und das Zertifikat in einer lokalen Datei zu speichern. Kopieren Sie die Datei auf den SharePoint-Server. Damit sind wir mit dem AD FS-Server fertig.

Wechseln Sie zum SharePoint-Server, mit dessen Konfiguration wir jetzt beginnen. Bevor wir mit dem Konfigurieren von SharePoint beginnen, sollten Sie eine neue Webanwendung erstellen. Erstellen Sie die Webanwendung für die Verwendung der Forderungsauthentifizierung, wählen Sie aber in den Authentifizierungseinstellungen die Option Integrierte Windows-Authentifizierung - NTLM (Integrated Windows authentication – NTLM) aus. Konfigurieren Sie die Webanwendung für die Verwendung von Port 443, und wählen Sie das Optionsfeld Secure Sockets Layer (SSL) verwenden (Use Secure Sockets Layer (SSL)) aus. Denken Sie nach der Erstellung der Webanwendung daran, den IIS-Manager aufzurufen und die Bindungen für den neuen virtuellen Server zu bearbeiten, damit Sie das entsprechende SSL-Zertifikat zuweisen können. Diese Schritte werden in diesem Beitrag nicht behandelt, sind jedoch an vielen Stellen im Internet gut dokumentiert. Fassen wir zusammen: In unserem Szenario wird eine Webanwendung erstellt, von der Port 443 und SSL verwendet wird, und die URL für die Webanwendung lautet https://seo14.

Der erste Schritt auf der SharePoint-Seite besteht darin, das Tokensignaturzertifikat hinzufügen, das ich vom AD FS-Server kopiert habe. Vorher muss ich mir jedoch das Zertifikat ansehen. Die Kette des Tokensignaturzertifikats enthält möglicherweise ein oder mehrere übergeordnete Zertifikate. In diesem Fall muss ich jedes Zertifikat in dieser Kette der Liste der vertrauenswürdigen Stammzertifizierungsstellen in SharePoint hinzufügen. Dazu suche ich das aus AD FS kopierte Tokensignaturzertifikat und doppelklicke darauf. Daraufhin wird das Fenster mit den Zertifikateigenschaften angezeigt. Wenn Sie auf die Registerkarte Zertifizierungspfad (Certification Path) klicken, können Sie sehen, ob die Kette weitere Zertifikate enthält. In meinem Szenario HAT das Tokensignaturzertifikat ein übergeordnetes Zertifikat, nämlich das Zertifikat der Stammzertifizierungsstelle.

Jetzt muss ich für jedes Zertifikat, das sich in der Kette oberhalb des Tokensignaturzertifikats befindet, eine Kopie lokal speichern. Dazu kann ich auf das Zertifikat klicken. Dadurch wird im Dialogfeld die Schaltfläche Zertifikat anzeigen (View Certificate) aktiviert. Wenn ich auf diese Schaltfläche klicke, wird ein separates Eigenschaftendialogfeld für dieses Zertifikat geöffnet. Dann kann ich mithilfe des weiter oben beschriebenen Vorgangs eine Kopie des Zertifikats auf dem Datenträger speichern: Ich klicke auf die Registerkarte Details, klicke auf die Schaltfläche In Datei kopieren (Copy to File) und speichere dann das Zertifikat lokal als CER-Datei. In meinem Fall habe ich das getan und das Zertifikat unter C:\adfsParent.cer gespeichert. Auf dem SharePoint-Server befinden sich jetzt zwei Zertifikate:

· C:\adfs.cer, das vom AD FS-Server kopierte Tokensignaturzertifikat

· C:\adfsParent.cer, das übergeordnete Zertifikat des Tokensignaturzertifikats

Nun muss ich diese Zertifikate der Liste der vertrauenswürdigen Stammzertifizierungsstellen hinzufügen. Dafür verwende ich dieses Skript in PowerShell:

$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfsParent.cer")

New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfs.cer ")

New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert

Wenn ich diese Befehle in PowerShell ausgeführt habe, sieht die Ausgabe ungefähr so aus:

Als Nächstes erstelle ich die Forderungszuordnungen, die von SharePoint verwendet werden sollen. Weiter oben in diesem Artikel habe ich erwähnt, dass ich E-Mail-Adressen- und Rollenforderungen in SharePoint verwenden werde. Hier ist das PowerShell-Skript, das ich zum Erstellen dieser Zuordnungen verwenden werde:

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

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

Als Nächstes erstelle ich eine Variable für den Bereich, der in SharePoint verwendet werden soll. Wie bereits erwähnt werde ich in diesem Szenario den Bereich urn:seo:sharepoint verwenden. Hier ist das PowerShell-Skript zum Erstellen der Bereichsvariablen:

$realm = "urn:seo:sharepoint"

Jetzt kann ich den SPTrustedIdentityTokenIssuer erstellen. Hier verknüpfe ich alle Konfigurationsinformationen, damit diese in SharePoint zum Herstellen von Verbindungen mit dem Identitätsanbieter-Sicherheitstokendienst und zum Arbeiten mit diesem verwendet werden. Ich zeige Ihnen hier das PowerShell-Skript und erläutere dann die wichtigen Teile:

$ap = New-SPTrustedIdentityTokenIssuer -Name "SAML Provider" -Description "SharePoint secured by SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl "https://congen1.contoso.local/adfs/ls" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

Das Name-Attribut wird in der Webanwendung angezeigt, wenn Sie konfigurieren, welcher Authentifizierungsanbieter verwendet werden soll. In das realm-Attribut integrieren wir den Bereich, der von SharePoint für diesen vertrauenswürdigen Identitätstokenherausgeber verwendet werden soll. Im ImportTrustCertificate-Attribut übergeben wir das vom AD FS-Server kopierte Tokensignaturzertifikat. Mit dem ClaimsMappings-Attribut weisen wir Sharepoint an, welche Forderungen von diesem vertrauenswürdigen Identitätstokenherausgeber verwendet werden sollen. SignInUrl ist die URL, an die Benutzer umgeleitet werden sollen, damit diese mit dem Identitätsanbieter-Sicherheitstokendienst authentifiziert werden. In diesem Fall sollen die Benutzer mit integrierter Windows-Sicherheit über den AD FS-Server authentifiziert werden. Daher senden wir die Benutzer an das Unterverzeichnis /adfs/ls. Mit dem IdentifierClaim-Attribut schließlich wird SharePoint informiert, welche der Forderungen zum Identifizieren von Benutzern verwendet werden soll. In diesem Fall geben wir an, dass Benutzer anhand der E-Mail-Adresse identifiziert werden sollen.

Nach der Ausführung dieses letzten PowerShell-Befehls haben wir einen SPTrustedIdentityTokenIssuer, der für die SharePoint-Webanwendung verwendet werden kann. Öffnen Sie den Browser, und navigieren Sie zur Zentraladministration. Klicken Sie auf den Link Webanwendungen verwalten (Manage Web Applications), klicken Sie dann in der Liste auf die Webanwendung, für die die Authentifizierung mithilfe von AD FS ausgeführt werden soll, und klicken Sie dann auf dem Menüband auf die Schaltfläche Authentifizierungsanbieter (Authentication Providers). Klicken Sie im Dialogfeld auf den Link, der der Zone entspricht, in der Sie AD FS für die Authentifizierung verwenden möchten. Führen Sie einen Bildlauf nach unten zum Abschnitt Forderungsauthentifizierungstypen (Claims Authentication Types) aus. Sie können nun die Auswahl von NTLM aufheben, und in der Liste der vertrauenswürdigen Anbieter sollte ein neuer Anbieter mit dem Namen SAML Provider angezeigt werden.

Aktivieren Sie das Kontrollkästchen daneben, und klicken Sie auf die Schaltfläche Speichern (Save), um die Änderungen zu speichern. Nun können Sie eine Websitesammlung für die Webanwendung erstellen. Auch dieser Vorgang wird in diesem Beitrag nicht schrittweise beschrieben. Es gibt jedoch einen wichtigen Punkt, an den Sie dabei denken müssen. Denken Sie beim Hinzufügen des Websitesammlungsadministrators daran, den Namen im Format der Identitätsforderung einzugeben. In diesem Szenario beispielsweise handelt es sich bei der Identitätsforderung um eine E-Mail-Adresse. Ich habe also beim Hinzufügen des Websitesammlungsadministrators den Namen administrator@contoso.local verwendet, da dies die E-Mail-Adresse des Benutzers ist, der Websitesammlungsadministrator sein soll.

Jetzt kann ich zur neuen Websitesammlung wechseln. Ich öffne den Browser, gebe die Zeichenfolge https://seo14 ein, und drücke die EINGABETASTE. Als Erstes werde ich zur SignInUrl für den SPTrustedIdentityTokenIssuer umgeleitet, der der Webanwendung zugeordnet ist. Wie Sie sich aus dem PowerShell-Skript erinnern werden, das zum Erstellen des SPTrustedIdentityTokenIssuer verwendet wurde, lautet die URL https://congen1.contoso.local/adfs/ls. Die folgende Ausgabe wird angezeigt, wenn ich die URL der SharePoint-Website in den Browser eingebe:

Sie können sehen, dass die URL im Browserfenster jetzt auf den AD FS-Server zeigt und dass im Hintergrund hinter dem Anmeldedialogfeld die Grafik für den AD FS-Server angezeigt wird. Möglicherweise bemerken Sie auch, dass ich mich mit meinen Windows-Anmeldeinformationen (Domäne\Benutzer) anmelde. Wie Sie sich erinnern werden, ist dies möglich, weil ich mich über den AD FS-Server authentifiziere und nicht über SharePoint. SharePoint ist so konfiguriert, dass die E-Mail-Adresse als meine Identität verwendet wird. Ich authentifiziere mich jedoch über AD FS, und die Forderungsregel, die wir erstellt haben, wird verwendet, um meine E-Mail-Adresse und meine Gruppen abzurufen und diese in Forderungen einzufügen, die zurück an SharePoint gesendet werden. Nach der Authentifizierung werde ich gemäß der Konfiguration der vertrauenden Seite, die ich in AD FS eingerichtet habe, wieder an SharePoint unter https://seo14/_trust/ umgeleitet. An dieser Stelle wird der Authentifizierungsvorgang von SharePoint abgeschlossen, indem die im SAML-Token empfangenen Forderungen in eine SPUser-Klasse konvertiert werden. Schließlich befinde ich mich auf der Homepage der Website:

Wie Sie sehen, wird im Anmeldesteuerelement im rechten oberen Teil der Seite meine Identität als E-Mail-Adresse angezeigt, da dies meiner Identitätsforderung entspricht.

Das ist der vollständige durchgängige Vorgang mit begleitenden Erklärungen. Mithilfe dieser Anweisungen sollten Sie in der Lage sein, Websites zu konfigurieren und in Betrieb zu nehmen.

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Configuring SharePoint 2010 and ADFS v2 End to End