Azure als Identity Provider mithilfe von ADFS für SharePoint 2013

​​​​Im Kundenumfeld werden immer häufiger Hybridszenarien im SharePoint-Bereich in Erwägung gezogen, welche eine Kommunikation zwischen Office 365 und SharePoint on premise bereitstellen. Im dem folgenden Artikel wird erläutert, wie Office-365 -Benutzer (aus dem Azure Active Directory) mittels ADFS auf einen SharePoint 2013 on premise berechtigt werden und somit darauf zugreifen können. Eine Besonderheit hierbei ist, dass die Benutzer nicht aus dem lokalen Active Directory in das Azure Active Directory synchronisiert werden müssen. Die Authentifizierung findet somit durch eine direkte Kommunikation zwischen dem SharePoint-Server, dem ADFS-Server und dem Azure Active Directory statt.

Voraussetzungen

Folgende Voraussetzungen sind vor der Umsetzung dieser Anleitung zu erfüllen und werden nicht im Rahmen dieses Artikels erläutert. Es gibt jedoch Anleitungen im Netz, mit denen diese Voraussetzungen geschaffen werden können.

  • Installieren des ADFS auf einem separaten Server
  • Installation und Konfiguration eines SharePoint 2013 Servers inklusive der User Profile Service Application
  • Hinzufügen einer öffentlichen Domäne zum Office 365 Tenant
  • Grundkonfiguration des Azure Active Directorys in Verbindung mit dem zu verwendenden Office 365 Tenant
  • Der SharePoint-Dienst „Claims to Windows Token Service" muss gestartet sein

Den ADFS als Anwendung im Azure AD hinterlegen

Um das ADFS als Anwendung im Azure AD zu hinterlegen, müssen folgende Schritte durchgeführt werden:

  1. Im Azure AD des Office 365 Tenant anmelden
  2. Das Active-Directory-Verzeichnis auswählen
  3. In der oberen Navigation den Punkt „Anwendungen“ auswählen
  4. In der unteren Leiste auf“ Hinzufügen“ klicken
  5. Im erscheinenden Dialog die Option „Eine von meinem Unternehmen entwickelte Anwendung hinzufügen" auswählen
  6. Einen Anzeigenamen (beliebig) für die Anwendung vergeben und den Typ „Webanwendung und/oder WEB-API" auswählen
  7. Auf der Seite App-Eigenschaften die folgenden Angaben machen:
    1. URL für Anmeldung: https://[ADFS_Farm_Name]/adfs/ls/ (ADFS_Farm_Name ist der DNS Name des ADFS Servers)
    2. AP-ID-URI: http://[ADFS_Farm_Name]/adfs/services/trust (hier muss das http Protokoll verwendet werden)

Nach diesen Schritten ist die Konfiguration des Azure Active Directorys abgeschlossen

Das Azure AD als Identity Provider im ADFS hinzufügen

  1. Das ADFS Management Tool öffnen
  2. Den Knoten „Trust Relationships“ erweitern und auf „Claims Provider Trusts“ klicken
  3. In der „Actions“-Spalte auf „Claims Provider Trusts“ klicken
  4. Im neuen Fenster auf „Start“ klicken
  5. Unter „Select Data Source“ die Option "Import data about the claims provider published online or on a local network" auswählen und folgende URL hinterlegen: https://accounts.accesscontrol.windows.net/TenantName/FederationMetadata/2007-06/FederationMetadata.xml (TenantName ist der Name des zu verwendenden Azure AD Tenant und kann unter anderem aus der URL gelesen werden, welche angezeigt wird, während man sich z.B. auf der Seite "Anwendungen" im Azure Management Portal befindet) https://accounts.accesscontrol.windows.net/TenantName/FederationMetadata/2007-06/FederationMetadata.xml (TenantName ist der Name des zu verwendenden Azure AD Tenant und kann unter anderem aus der URL gelesen werden, welche angezeigt wird, während man sich z.B. auf der Seite "Anwendungen" im Azure Management Portal befindet)
  6. Auf der nächsten Seite einen Anzeige-Namen für den Claims Provider vergeben und auf „Next“ klicken
  7. Unter "Ready to Add Trust" werden noch einmal alle vorgenommenen Einstellungen aufgelistet
  8. Nach einem Klick auf „Next“ sollte der Haken bei "Open the Edit Claim Rules dialog for this claims provider trust when the wizard closes" gesetzt sein (ist dies nicht der Fall, sollte dieser gesetzt werden) und das Fenster kann geschlossen werden
  9. Im neuen Fenster auf „Add Rule…“ klicken
  10. Unter „Claim Rule template“ die Vorlage „Transform an Incoming Claim" auswählen
  11. 11. Auf der nächsten Seite müssen folgende Informationen angegeben werden:
    1. Claim rule name: ist beliebig wählbar
    2. Incoming Claim Type: Name
    3. Outgoing Claim Type: E-Mail-Addresse
  12. Nach einem Klick auf „Finish“ erscheint eine Warnung, welche ignoriert und mit „Yes“ bestätigt werden kann

Nach Abschluss dieser Schritte wurde das Azure AD erfolgreich als Identity Provider im ADFS hinterlegt.

Eine Relying Party für SharePoint im ADFS erstellen

  1. Das ADFS Management Tool öffnen
  2. Den Knoten „Trust Relationships“ erweitern und auf „Relying Party Trusts“ klicken
  3. In der „Actions“-Spalte auf „Add Relying Party Trust…“ klicken
  4. Im neuen Fenster auf „Start“ klicken
  5. Die Option "Enter data about the relying party manually" auswählen
  6. Auf der nächsten Seite einen Anzeigenamen und optional eine Beschreibung für den Relying Party Trust angeben und auf „Next“ klicken
  7. Die Option "AD FS profile" auswählen und auf „Next“ klicken
  8. Unter "Configure Certificate" kann ein Zertifikat angegeben werden, um das SAML Token selbst zu verschlüsseln. Dies ist normalerweise nicht notwendig, da ADFS voraussetzt, dass die Verbindung zum SharePoint via SSL verschlüsselt ist
  9. Im nächsten Fenster die Checkbox "Enable Support for the WS-Federation Passive Protocol" aktivieren. Als Protocol URL muss die SharePoint Web Application URL der SharePoint Root Site angegeben werden gefolgt von einem /_trust/
  10. Der realm dient zur Identifizierung zwischen einer SharePoint Web Application und dem ADFS Server. Pro Web Application wird ein eigener realm verwendet. Ein realm ist key-sensitive, das bedeutet, es wird bei dem Namen des realm zwischen Groß- und Kleinschreibung unterschieden. Ein realm wird in der Regel immer wie folgt aufgebaut: urn:sp:sharepoint. Dabei ist es sinnvoll, den mittleren Teil gleich dem Namen der Web Application zu benennen, für die der realm verwendet wird
  11. Multi-factor-Authentifizierung ist in diesem Fall nicht vorgesehen, daher wird die Option "I do not want to configure multi-factor authentication settings for this relying party trust at this time" ausgewählt
  12. Im Normalfall sollen alle Benutzer diesen Relying Party Trust nutzen können. Daher wird auf der nächsten Seite die Option "Permit all users to access this relying party" ausgewählt
  13. Unter "Ready to Add Trust" werden noch einmal alle vorgenommenen Einstellungen für den Relying Party Trust aufgelistet
  14. Nach einem Klick auf „Next“ sollte der Haken bei "Open the edit claim rules dialog for this relying party trust when the wizard closes" gesetzt sein (ist dies nicht der Fall, sollte dieser gesetzt werden)
  15. Danach kann der Wizard mit „Close“ geschlossen werden
  16. Im neuen Fenster auf „Add Rule…“ klicken (über die Regel wird dem ADFS mitgeteilt, welche Claims zum SharePoint zurückgesendet werden sollen)
  17. Als Claim rule template wird hier "Pass Through or Filter an Incoming Claim" ausgewählt
  18. Auf der nächsten Seite müssen folgende Informationen angegeben werden:
    1. Claim rule name: ist beliebig wählbar
    2. Incoming Claim Type: E-Mail-Addresse (die E-Mail-Adresse ist das Attribut, welches für die Authentifizierung genutzt werden soll)
  19. Danach auf „Finish“ und „Ok“ klicken

Nach Abschluss dieser Schritte wurde der Relying Party Trust erfolgreich erstellt.

Konfiguration der Zertifikate im ADFS Management Tool

Als nächstes müssen noch die Zertifikate im ADFS Management Tool hinzugefügt werden. Es werden vom ADFS zwar automatisch Zertifikate zur Verfügung gestellt, welche kopiert und auf den SharePoint-Servern installiert werden können, jedoch ist es in dem meisten Fällen sinnvoll, dss Zertifikat durch ein öffentliches oder selbst ausgestelltes Zertifikat auszutauschen, um das Ausrollen des Zertifikats auf den anderen Servern zu vereinfachen. Um das Zertifikat auszutauschen, muss wie folgt vorgegangen werden.

Im ADFS Management Tool zum Knoten "Service" und dann zu "Certificates" navigieren

In der „Actions“-Spalte unter "Add Token-Signing Certificate", "Token-Decrypting Certificate" und unter "Set Service Communications Certificate" muss jeweils das eigene Zertifikat hinzugefügt werden. Wird beim ersten Mal versucht, die Zertifikate zu ändern, wird eine Warnung angezeigt, dass zuvor der Dienst, welcher die ADFS-Zertifikate automatisiert bereitstellt, deaktiviert werden muss. Dies kann bestätigt werden. Danach müssen die Zertifikate der Management-Konsole ausgewählt und als primäre Zertifikate gekennzeichnet werden (ebenfalls über die „Actions“-Spalte). Die anderen Zertifikate können daraufhin aus dem Management Tool gelöscht werden.

Zusätzlich muss das verwendete Zertifikat auf dem oder den SharePoint-Servern installiert sein, damit eine Vertrauensstellung zwischen dem ADFS und dem SharePoint-Server existieren kann. Für die Konfiguration des SharePoint selbst (die Konfiguration wird im nächsten Schritt erläutert) wird ebenfalls das jeweilige Zertifikat als .cer Datei auf dem SharePoint-Server benötigt.

SharePoint konfigurieren, um sich mit Office-365-Benutzern authentifizieren zu können

Folgende Voraussetzungen müssen auf dem SharePoint-Server erfüllt worden sein, bevor die nachfolgende Konfiguration durchgeführt werden sollte:

  • Eine Web Application, welche Claims Based Authentication (und NTLM) nutzt
  • Die Web Application muss via SSL verschlüsselt sein und über das https-Protokoll aufgerufen werden können
  • Die im ADFS Management Tool verwendeten Zertifikate müssen als .cer Dateien auf dem SharePoint-Server vorhanden (Format: DER encoded binary X.509 (.CER)) und im Zertifikatsstore hinterlegt sein
  • Die übergeordneten Zertifikate müssen ebenfalls als .cer Dateien auf dem SharePoint-Server hinterlegt sein (Format: DER encoded binary X.509 (.CER))

Die Konfiguration des SharePoint erfolgt in folgenden Schritten.

  1. Die Zertifikate müssen via SharePoint Management Shell zu den trusted root authorities in SharePoint hinzugefügt werden. Dazu werden die beiden Zertifikate (in diesem Fall war ist es ein Hauptzertifikat und ein übergeordnetes Zertifikat) zunächst wie folgt in Variablen hinterlegt:
    1. Die SharePoint Management Shell als Administrator öffnen und folgende Befehle absetzen (der Pfad der Zertifikate kann sich je nach Ablageort unterscheiden):
    2. $root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\O365SyncWildcardParent.cer")
    3. $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\O365SyncWildcard.cer")
  2. 2. Danach werden für die beiden Zertifikate die Einträge in den trusted root authorities in SharePoint via Management Shell angelegt
    1. New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root
    2. New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert
  3. Im nächsten Schritt wird das Claim Mapping erstellt, welches SharePoint nutzen soll. Wie schon weiter oben erwähnt und im ADFS konfiguriert, soll hierzu die E-Mail-Adresse verwendet werden. Weitere Mappings können zu einem späteren Zeitpunkt über den gleichen Weg im ADFS und im SharePoint hinzugefügt werden, um zusätzliche Benutzerinformationen zu synchronisieren. Das Claim Mapping wird mit folgendem Befehl über die SharePoint Management Shell erstellt:
    1. $map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
  4. Danach wird eine Variable für den realm erstellt, welchen SharePoint nutzen soll. Dieser wurde im ADFS Management Tool bei der Konfiguration des Relying Party Trust definiert:
    1. $realm = "urn:sp:sharepoint"
  5. Nun kann der SPTrustedIdentityTokenIssuer über die SharePoint Management Shell erstellt werden. Dabei werden alle zuvor verwendeten Informationen in einem PowerShell-Befehl angegeben, weshalb die Management Shell während aller oben aufgeführten Schritte nicht geschlossen werden darf. Der Befehl sieht wie folgt aus:
    1. $ap = New-SPTrustedIdentityTokenIssuer -Name "SAML Provider" -Description "SharePoint secured by SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https://sts.o365sync.tk/adfs/ls/" -IdentifierClaimhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
  6. Zuletzt muss noch der in Schritt 5. erstellte Authentifizierungsanbieter für die jeweilige Web Application zur Verfügung gestellt werden. Dazu wird wie folgt vorgegangen:
    1. In der Zentraladministration auf "Manage Web Applications" klicken
    2. Die Web Application auswählen, welche die Authentifizierung via ADFS nutzen soll
    3. Im Ribbon auf "Authentication Providers" klicken und die Zone auswählen, für welche die ADFS-Authentifizierung bereitgestellt werden soll. In meinem Fall ist es die Zone "Default"
    4. Dann nach unten scrollen bis zum Abschnitt "Claims Authentication Types" und den Haken bei "Trusted Identity Provider" setzen. Darunter sollte nun der Eintrag "SAML Provider" vorhanden sein, welcher durch den PowerShell-Befehl in Schritt 5. erzeugt wurde. Dieser muss ebenfalls angehakt werden. Optional kann die Authentifizierung via NTLM deaktiviert werden oder aktiviert bleiben. Dann kann die Konfiguration mit einem Klick auf „Ok“ abgeschlossen werden

Damit ist die Konfiguration des SharePoint abgeschlossen und die jeweils verwendete Web Application nutzt nun den SAML Provider für die Authentifizierung der Office -365-Benutzer.

Abschließendes Testen der Konfiguration

Als letzten Schritt kann noch die zuvor vorgenommene Konfiguration getestet werden. Wenn alles korrekt konfiguriert wurde, sollte zum Schluss ein Office-365-Benutzer durch die Anmeldung mit seinen Office 365 Credentials auf eine SharePoint 2013 on-premise-Seite zugreifen können.

  1. ​​​​​Auf eine Site Collection der Web Application navigieren, für welche der SAML Provider konfiguriert wurde
  2. Einen Office-365-Benutzer des angebundenen Tenants auf die Site Collection mittels der Eingabe der E-Mail-Adresse berechtigen
  3. Wenn die Site Collection durch z.B. eine neue Browser-Session aufgerufen wird, erscheint zunächst ein Dialog, über welchen ausgewählt werden kann, welche Authentifizierungsmethode zum Öffnen der Seite verwendet werden soll. Hier wird der zuvor erstellte SAML Provider ausgewählt
  4. Daraufhin wird man auf die Office 365 Login-Seite weitergeleitet, auf welcher die korrekte O365-Verbindung ausgewählt werden muss. Diese wird über den Displaynamen erkennbar gemacht, welcher während der ADFS Konfiguratio​n angegeben wurde

  5. Nun müssen der O365-Benutzername (E-Mail-Adresse) und das Passwort des Benutzers angegeben werden, welcher zuvor auf die Site Collection berechtigt wurde

  6. Danach wird man automatisch mit den Office-365-Anmeldedaten auf der Site Collection angemeldet und auf diese weitergeleitet

Wird die SharePoint 2013 on-premise-Seite dargestellt, war die in diesem Artikel beschriebene Konfiguration erfolgreich. Es ist nun möglich, sich mit allen Benutzern anzumelden, welche im angebundenen Azure AD hinterlegt sind.

Die einzige Voraussetzung dafür ist, dass der jeweilige Account auf die SharePoint 2013 on-premise-Seite berechtigt ist.

Comments