SharePoint Subsricpiton Edition und OpenID Connect mit AzureAD

SharePoint SE unterstützt OpenID Connect (OIDC)

Die SharePoint Server Subscription Edition (SE) ist seit einiger Zeit auf den Markt und bietet im Gegensatz zu den Vorgängern die Unterstützungen des OpenID Connect (OIDC) 1.0-Authentifizierungsprotokoll.

OIDC ist ein modernes Authentifizierungsprotokoll, das die Integration von Anwendungen und Geräten in die Identitäts- und Authentifizierungsmanagementlösungen eines Unternehmens vereinfacht und geniesst inzwischen eine sehr grosse Beliebtheit.

Bisher haben die früheren Versionen von SharePoint die folgenden drei Arten von Authentifizierungsmethoden unterstützt:

  • Windows-Authentifizierung (NTLM, Kerberos)
  • Formularbasierte Authentifizierung
  • SAML 1.1-basierte Authentifizierung

Microsoft bietet aktuell zwei Optionen zur Einrichtung von OIDC in SharePoint an:

  • Microsoft Azure Active Directory (Azure AD)
  • Active Directory Federation Services (AD FS)

Blog Inhalt – Konfiguration für OIDC mit Azure AD

In diesem Blog möchte ich dem Leser zeigen, wie eine funktionierende SharePoint SE-Farm mit OIDC zur Authentifizierung mit Azure AD konfiguriert werden kann.

Voraussetzung für die Konfiguration von OIDC ist eine funktionierende SharePoint SE-Farm. Es wird der für OIDC-relevante Teil beschrieben.

Ausgangslage und Herausforderung

Wir stellen fest, dass die ASR in den meisten Tenants nicht konfiguriert sind. Dadurch erhöht sich das Risiko eines erfolgreichen Angriffes auf ein Device. Bei einem erfolgreichen Angriff können Endgeräte kompromittiert werden und das Schadenspotenzial ist hoch.

Als mögliche Hürde zur Konfiguration der ASR sehe ich die hohe Komplexität des Themas, der Überschneidung von möglichen Sicherheitseinstellungen in Intune und im Defender und der damit verbundenen Aufgabe, dass zur korrekten Einführung ein konzeptioneller Aufwand und tiefe Kenntnisse notwendig sind.

Hauptschritte

Die Hauptschritte für die Konfiguration sehen wie folgt aus:

  • Erstellen eines SSL-Zertifikats für SharePoint Site
  • Einrichten eines Identitätsanbieters in Azure AD
  • Installieren des OIDC Nonce-Cookie-Zertifikats in SharePoint
  • Konfigurieren von SharePoint SPTrustedTokenIssuer
  • Konfigurieren der SharePoint Web Application
  • Festlegen des DNS-Namens für den neuen Hostname
  • Erteilen der Azure AD-Benutzerberechtigungen
  • Zugreifen auf die Website mit einem Azure AD-Benutzer

Prerequisites

Zum Ausführen der Konfigurationen werden folgende Ressourcen benötigt:

  • Farmadministratorenrechte für die SharePoint SE-Farm
  • Globaler Administrator für Azure AD
  • Ein lokaler Domain Controller mit Zertifizierungsstellendienst, der im eigenständigen Modus installiert ist

Schritt 1: Erstellen eines SSL-Zertifikats für SharePoint Site

Laden Sie das Powershell-Skript «GenerateCerts.ps1» von Rainer Asbachs Github-Seite herunter. Dieses Skript schließt den 3-stufigen Zertifikaterstellungsprozess (Anfordern, Signieren und Abschließen) mit einem einzigen Befehl mithilfe der neuen Zertifikatsverwaltung von SharePoint ab.

  1. Nachdem das Skript heruntergeladen wurde, kopieren sie es in einem Ordner, z.B. «C:\SPSE» auf dem Domain Controller.
  2. Melden Sie sich auf dem SharePoint-Front-End-Server als Farmadministrator an.
  3. Starten Sie eine PowerShell-Konsole mit erhöhten Rechten (Runas Administrator).

Führen Sie folgenden Befehl aus:

\\<ServernameDC>\c$\SPSE\GenerateCerts.ps1 -CertName “SharePoint Site” -ServerCertFileFolder \\<ServernameDC>\c$\SPSE\certs -CertCommonName “spaad.allgeier.local” -AlternativeNames

Schritt 2: Einrichten eines Identitätsanbieters in Azure AD

In diesem Schritt wird der Identitätsanbieter in Azure AD eingerichtet.

  1. Erstellen Sie im Azure AD eine neue App Registrierung, indem sie auf den folgenden Link klicken: https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps
  2. Wählen Sie + New registrationnew registration
  3. Schliessen Sie den Assistenten mit folgenden Einstellungen ab:EinstellungenRegister
  4. Wählen Sie Register.
  5. Speichern Sie die “Directory (tenant) ID” und die “Application (client) ID“, da sie im SharePoint-Setup als DefaultClientIdentifier verwendet werden.tenant
  6. Gehen Sie nach der Registrierung auf die Authentifizierungsseite und aktivieren Sie “ID tokens” auf der Seite. Wählen Sie Save.ID tokens
  7. Wählen Sie API permissions.
  8. Wählen Sie + Add a permissionad a permission
  9. Wählen Sie Microsoft Graph.Microsoft Graph
  10. Wählen Sie Delegated permissionsDelegated permissions
  11. Wählen Sie email und dann Add permissionsemail add permission
  12. Gehen Sie zu Token configuration
  13. Wählen Sie + Add optional claimadd optinal claim
  14. Wählen Sie unter Token type die Option ID aus und selektieren den Claim emailadd optional claim
  15. Klicken Sie auf den Button
  16. Wählen Sie + Add group claimadd group claim
  17. Aktivieren Sie alle Kontrollkästchen.edit group claims
  18. Klicken Sie auf den Button Add
  19. Sie sollten die Optional Claims wie folgt sehen:optinal claims
  20. Gehen Sie zur Seite Manifest und ändern Sie manuell “replyUrlsWithType” – “url” von “https://spaad.allgeier.local/” in “https://spaad.allgeier.local/*”. Und wählen Sie Save.SharePoint on prem
  21. Wählen Sie Overview aus der obersten Ebene der neuen App-Registrierung und dann EndpointsSharePoint On prem
  22. Kopieren Sie den Endpunkt “OpenID Connect metadata document“.End points

Schritt 3: Installieren des OIDC Nonce-Cookie-Zertifikats

In diesem Schritt wird das sogenannte «Nonce Cookie Signing Certificate» erstellt und es den SharePoint-Farmeigenschaften hinzugefügt.

  1. Öffnen Sie eine PowerShell-Konsole mit erweiterten Rechten (Runas Administrator).
  2. Führen Sie das folgende Skript aus:

    #Create a cookie signing cert from the On-Prem Server

    $cert = New-SelfSignedCertificate -CertStoreLocation “Cert:\LocalMachine\My” -Provider “Microsoft Enhanced RSA and AES Cryptographic Provider” -Subject “CN=SharePoint Nonce Cookie Cert”

    #Find the Private Key and Path

    $privatekey_rsa = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($cert)

    $fileName = $privatekey_rsa.key.UniqueName

    $path = “$env:ALLUSERSPROFILE\Microsoft\Crypto\RSA\MachineKeys\$fileName”

    #Get current permisions for the Private Key

    $permissions = Get-Acl -Path $path

    #Modify permissions to include the “WSS_WPG” Group

    $rule = New-Object System.Security.AccessControl.FileSystemAccessRule( “$env:COMPUTERNAME\WSS_WPG”, “Read”, “None”, “None”, “Allow”)

    $permissions.AddAccessRule($rule)

    Set-Acl -Path $path -AclObject $permissions

    #Set the Farm Properties with the Nonce Cookie using the new Cert

    $f = Get-SPFarm

    $f.Farm.Properties[‘SP-NonceCookieCertificateThumbprint’]=$cert.Thumbprint

    $f.Farm.Properties[‘SP-NonceCookieHMACSecretKey’]=’seed’

    $f.Farm.Update()

  3. Überprüfen Sie den “Private Key”, um sicherzustellen, dass die richtigen Berechtigungen angewendet wurden.
  4. Starten Sie MMC und fügen Sie das Snap-In “Zertifikate” hinzu.Snap inn
  5. Wählen Sie Computer accountCompunter account
  6. Wählen Sie dann Local computerselect computer
  7. Suchen Sie das SharePoint Nonce Cookie-Zertifikat und klicken Sie mit der rechten Maustaste darauf, und wählen Sie dann All Tasks > Manage Private Keys.manage private keys
  8. Stellen Sie sicher, dass die richtigen Berechtigungen angewendet wurden. Sie sollten “<Domain>\WSS_WPG” identifizieren.Berechtigungen

Wichtige Hinweise:

Wenn Sie über mehr als einen SharePoint-Server verfügen, muss das Zertifikat auf allen Servern installiert werden.

Das Zertifikat kann aus dem “Certificate Manager” (mit dem privaten Schlüssel) exportiert und manuell oder mit PowerShell in jeden Server importiert werden.

Schritt 4: Konfigurieren von SharePoint SPTrustedTokenIssuer

In diesem Schritt erstellen Sie einen SPTrustedTokenIssuer, der die Konfiguration speichert, die SharePoint benötigt, um AAD OIDC als OIDC-Anbieter zu vertrauen.

Es gibt 2 Möglichkeiten, dies zu konfigurieren, Automatisch mit Metadaten oder Manuell, indem Sie das richtige rotierende Zertifikat und die richtigen Endpunkte angeben.

Mithilfe des Metadatenendpunkts, der vom OIDC-Identitätsanbieter bereitgestellt wird, kann die richtige Konfiguration direkt vom Metadatenendpunkt des OIDC-Anbieters abgerufen und automatisch im STS konfiguriert werden.

In diesem Blog beschreibe ich im Folgenden das Vertrauen von Azure AD OIDC mithilfe des Metadatenendpunkts (welchen Sie am Ende von Schritt 4 gespeichert haben!).

Erstellen Sie den Token Issuer mithilfe des Email Claim Type:

  1. Öffnen Sie eine PowerShell-Konsole mit erweiterten Rechten (Runas Administrator) auf dem SharePoint-Server.
  2. Führen Sie das folgende Skript aus:

#Set the desired claim types

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

#Replace with your “Directory (tenant) ID”

$MetadataEndpoint = “https://login.microsoftonline.com/<TenantID>/v2.0/.well-known/openid-configuration”

#Replace with your “Application (Client) ID”

$clientIdentifier = “<Application ID>”

#Create a new SPTrustedIdentityTokenIssuer in SharePoint

New-SPTrustedIdentityTokenIssuer -Name “SP to AAD TokenIssuer” -Description “To Authorize users from AAD” -ClaimsMappings $emailClaimMap -IdentifierClaim $emailClaimMap.InputClaimType  -DefaultClientIdentifier $clientIdentifier -MetadataEndPoint $MetadataEndpoint

Schritt 5: Konfigurieren der SharePoint-Webanwendung

In diesem Schritt konfigurieren Sie eine Webanwendung in SharePoint für den Partnerverbund mit dem Azure AD OIDC mithilfe des zuvor erstellten SPTrustedIdentityTokenIssuer.

Es gibt einige wichtige Regeln, die es zu beachten gilt:

  • Für die Default-Zone der SharePoint-Webanwendung muss die Windows-Authentifizierung aktiviert sein. Dies ist für den Search Crawler erforderlich.
  • Die SharePoint-URL muss mit HTTPS konfiguriert werden, um den Azure AD-OID-Partnerverbund verwenden zu können.
  • Wenn Sie eine vorhandene Webanwendung erweitern, legen Sie die Azure AD-OIDC-Authentifizierung für eine neue Zone fest.

Führen Sie folgende Schritte aus, um die SharePoint-Webanwendung zu konfigurieren.

  1. Öffnen Sie eine PowerShell-Konsole mit erweiterten Rechten (Runas Administrator) auf dem SharePoint-Server.
  2. Führen Sie das folgende Skript aus

#This script extends an existing web application to set AAD authentication on a new zone

#URL of the default zone of the web application

$webAppDefaultZoneUrl = “http://spwfe/”

#URL of the SharePoint site federated with ADFS

$trustedSharePointSiteUrl = “https://spaad.allgeier.local/”

#Define Host Header Name

$hname = ‘spaad.allgeier.local’

#Setting the correct Cert to be used for extended Web APP

$spcert = Get-SPCertificate | Where-Object {$_.CommonName -Match “spaad.allgeier.local”}

#Set the correct SPTrustedIdentityTokenIssuer

$sptrust = Get-SPTrustedIdentityTokenIssuer “SP to AAD TokenIssuer”

#Create a new SP Auth Provider using the SPTrustedIdentityTokenIssuer

$ap = New-SPAuthenticationProvider -TrustedIdentityTokenIssuer $sptrust

#Set the Sp Web Application Object

$wa = Get-SPWebApplication $webAppDefaultZoneUrl

#Create the new extended zone to use the new Auth Provider

New-SPWebApplicationExtension -Name “SharePoint AAD” -Identity $wa -SecureSocketsLayer -Port 443 -Certificate $spcert -Zone Internet -Url $trustedSharePointSiteUrl -HostHeader $hname -AuthenticationProvider $ap -UseServerNameIndication

  1. Stellen Sie sicher, dass das SP-Zertifikat der erweiterten SharePoint-Website ordnungsgemäß hinzugefügt wurde.SP_Zertifikat
  2. Überprüfen Sie in der Central Administration, ob die neue alternative Zugriffszuordnung ordnungsgemäß hinzugefügt wurde.

Schritt 6: Festlegen des DNS-Namens für den neuen Hostname

Erstellen Sie einen A-Eintrag im internen DNS, damit auf den neuen SharePoint-Hostnamen zugegriffen werden kann und auf den Web Frontend verweist.

  1. Öffnen Sie vom Domain Controller aus den DNS-Manager.
  2. Wählen Sie die lokale Zone “local“.
  3. Klicken Sie mit der rechten Maustaste auf die Zone und wählen Sie New Alias (CNAME)…
  4. Geben sie «spaad» als Namen ein.
  5. Wählen Sie OK zum Hinzufügen.

Schritt 7: Erteilen der Azure AD-Benutzerberechtigungen

In diesem Schritt wird dem Global Admin des M365 Tenants die Full Control-Rechte für die SharePoint-Webanwendung erteilt.

  1. Öffnen Sie die SharePoint Central Administration
  2. Gehen Sie zu “Application management” > “Manage Web Application
  3. Wählen Sie die Standard-Webanwendung (diejenige, die erweitert wurde) und klicken auf User Policy.User policy
  4. Wählen Sie Add Users.
  5. Wählen Sie Internet in der Dropdown-Liste Zones und klicken auf Next.zones
  6. Klicken Sie auf People Picker-Adressbuch.policy for web applications
  7. Geben Sie die vollständige E-Mail-Adresse Ihres standardmäßigen Global Admin M365 Azure-Benutzers ein und klicken Sie auf Search.
  8. Der Benutzer sollte im Claim “EmailAddress” angezeigt werden, wählen Sie den Benutzer aus und fügen Sie ihn dann mit der Schaltfläche Add->
  9. Wählen Sie Full Control für den Benutzerpolicy for web applications
  10. Klicken Sie auf Finish.

Schritt 8: Zugreifen auf die Website mit einem Azure AD-Benutzer

Testen Sie den Zugriff auf die SharePoint-Webanwendung mit dem zuvor berechtigten Global Administrator.

  1. Starten Sie den Browser auf einem Client-Computer im “InPrivate-Modus
  2. Geben Sie in die Adresszeile die URL https://spaad.allgeier.ch
  3. Möglicherweise erhalten Sie beim ersten Zugriff eine Einwilligungswarnung, akzeptieren Sie einfach die Warnung.permissions requested
  4. Sie sollten von Azure AD zur Eingabe eines Kontos aufgefordert werden.Konto
  5. Die lokale SharePoint-Website sollte mit Ihrem Azure AD-Konto geladen werden.

Optionaler Schritt: Konfigurieren der UPA-Unterstützung

Wenn Benutzer über die Personenauswahl gefunden werden, wird traditionell eine LDAP-Abfrage für die Domäne / Gesamtstrukturen ausgeführt, die in den Konfigurationseinstellungen der Personenauswahl konfiguriert sind. Wenn Benutzer die “User Profile Service Application” (UPA) direkt aus der Personenauswahl abfragen möchten, ist ein benutzerdefinierter Claim Provider erforderlich.

In SharePoint SE wurde die Personenauswahl erweitert, um Benutzer direkt aus dem UPA zu suchen und auszuwählen. Wie dies konfiguriert wird, erkläre ich in einem nächsten Blogartikel.

Fragen Sie unsere Experten

Haben Sie Fragen zur Konfiguration von OpenID für SPS SE oder andere Fragen rund um Ihre SharePoint onPremise oder SharePoint Online Infrastruktur?  Treten Sie mit unseren Experten in Kontakt. Wir helfen Ihnen. Pragmatisch. Unkompliziert. Zielgerichtet.

;