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.
- Nachdem das Skript heruntergeladen wurde, kopieren sie es in einem Ordner, z.B. «C:\SPSE» auf dem Domain Controller.
- Melden Sie sich auf dem SharePoint-Front-End-Server als Farmadministrator an.
- 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.
- 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
- Wählen Sie + New registration
- Schliessen Sie den Assistenten mit folgenden Einstellungen ab:
- Wählen Sie Register.
- Speichern Sie die “Directory (tenant) ID” und die “Application (client) ID“, da sie im SharePoint-Setup als DefaultClientIdentifier verwendet werden.
- Gehen Sie nach der Registrierung auf die Authentifizierungsseite und aktivieren Sie “ID tokens” auf der Seite. Wählen Sie Save.
- Wählen Sie API permissions.
- Wählen Sie + Add a permission
- Wählen Sie Microsoft Graph.
- Wählen Sie Delegated permissions
- Wählen Sie email und dann Add permissions
- Gehen Sie zu Token configuration
- Wählen Sie + Add optional claim
- Wählen Sie unter Token type die Option ID aus und selektieren den Claim email
- Klicken Sie auf den Button
- Wählen Sie + Add group claim
- Aktivieren Sie alle Kontrollkästchen.
- Klicken Sie auf den Button Add
- Sie sollten die Optional Claims wie folgt sehen:
- 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.
- Wählen Sie Overview aus der obersten Ebene der neuen App-Registrierung und dann Endpoints
- Kopieren Sie den Endpunkt “OpenID Connect metadata document“.
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.
- Öffnen Sie eine PowerShell-Konsole mit erweiterten Rechten (Runas Administrator).
- 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()
- Überprüfen Sie den “Private Key”, um sicherzustellen, dass die richtigen Berechtigungen angewendet wurden.
- Starten Sie MMC und fügen Sie das Snap-In “Zertifikate” hinzu.
- Wählen Sie Computer account
- Wählen Sie dann Local computer
- 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.
- Stellen Sie sicher, dass die richtigen Berechtigungen angewendet wurden. Sie sollten “<Domain>\WSS_WPG” identifizieren.
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:
- Öffnen Sie eine PowerShell-Konsole mit erweiterten Rechten (Runas Administrator) auf dem SharePoint-Server.
- 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.
- Öffnen Sie eine PowerShell-Konsole mit erweiterten Rechten (Runas Administrator) auf dem SharePoint-Server.
- 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
- Stellen Sie sicher, dass das SP-Zertifikat der erweiterten SharePoint-Website ordnungsgemäß hinzugefügt wurde.
- Ü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.
- Öffnen Sie vom Domain Controller aus den DNS-Manager.
- Wählen Sie die lokale Zone “local“.
- Klicken Sie mit der rechten Maustaste auf die Zone und wählen Sie New Alias (CNAME)…
- Geben sie «spaad» als Namen ein.
- 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.
- Öffnen Sie die SharePoint Central Administration
- Gehen Sie zu “Application management” > “Manage Web Application“
- Wählen Sie die Standard-Webanwendung (diejenige, die erweitert wurde) und klicken auf User Policy.
- Wählen Sie Add Users.
- Wählen Sie Internet in der Dropdown-Liste Zones und klicken auf Next.
- Klicken Sie auf People Picker-Adressbuch.
- Geben Sie die vollständige E-Mail-Adresse Ihres standardmäßigen Global Admin M365 Azure-Benutzers ein und klicken Sie auf Search.
- 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->
- Wählen Sie Full Control für den Benutzer
- 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.
- Starten Sie den Browser auf einem Client-Computer im “InPrivate-Modus“
- Geben Sie in die Adresszeile die URL https://spaad.allgeier.ch
- Möglicherweise erhalten Sie beim ersten Zugriff eine Einwilligungswarnung, akzeptieren Sie einfach die Warnung.
- Sie sollten von Azure AD zur Eingabe eines Kontos aufgefordert werden.
- 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.
