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:
Microsoft bietet aktuell zwei Optionen zur Einrichtung von OIDC in SharePoint an:
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.
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.
Die Hauptschritte für die Konfiguration sehen wie folgt aus:
Zum Ausführen der Konfigurationen werden folgende Ressourcen benötigt:
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.
Führen Sie folgenden Befehl aus:
\\<ServernameDC>\c$\SPSE\GenerateCerts.ps1 -CertName “SharePoint Site” -ServerCertFileFolder \\<ServernameDC>\c$\SPSE\certs -CertCommonName “spaad.allgeier.local” -AlternativeNames
In diesem Schritt wird der Identitätsanbieter in Azure AD eingerichtet.
In diesem Schritt wird das sogenannte «Nonce Cookie Signing Certificate» erstellt und es den SharePoint-Farmeigenschaften hinzugefügt.
#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()
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.
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:
#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
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ühren Sie folgende Schritte aus, um die SharePoint-Webanwendung zu konfigurieren.
#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
Erstellen Sie einen A-Eintrag im internen DNS, damit auf den neuen SharePoint-Hostnamen zugegriffen werden kann und auf den Web Frontend verweist.
In diesem Schritt wird dem Global Admin des M365 Tenants die Full Control-Rechte für die SharePoint-Webanwendung erteilt.
Testen Sie den Zugriff auf die SharePoint-Webanwendung mit dem zuvor berechtigten Global Administrator.
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.
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.
Wer steckt eigentlich hinter Allgeier? Marina verstärkt bei Allgeier seit Juli 2023 das Finanzteam. Im Interview erfahren wir mehr über ihre beruflichen Herausforderungen, worauf es in ihrem Job ankommt und wo man sie in ihrer Freizeit findet.
Ausgestattet mit modernster KI-Technologie, bietet die Plattform eine optimierte Verwaltung und Analyse digitaler Inhalte.
Kann AR die Produktion revolutionieren? Wo liegen mögliche Einsatzfelder und konkrete Vorteile? Im vierten Blog der Smart Maintenance Reihe werfen wir einen Blick in die Zukunft.
Smart Maintenance ist kein Trend, sondern eine Notwendigkeit, um wettbewerbsfähig zu bleiben. Doch welche Phasen durchläuft die Implementierung einer intelligenten Wartung?
Dass Smart Maintenance nicht nur für die Industrie relevant ist, zeigte der Vortrag von Mirko Maurer bei der maintenance Schweiz. Was Resilienz damit zu tun hat, erfahren Sie hier.
KI goes Microsoft 365: Was der intelligente Assistent Copilot kann und wie er die Zusammenarbeit auf neue Beine stellt.
Smarte Technologien, wertvolle Daten und vernetzte Mitarbeiter: Von der Herausforderung Smart Maintenance zu implementieren und wie man sie bewältigt. Alles im aktuellen Blog!
Vernetzt, automatisiert und mit Echtzeit-Daten gespickt – das sind die Kennzeichen von Industrie 4.0. Doch welche Rolle spielt Smart Maintenance dabei konkret? Wie kann es zur Effizienzsteigerung und Kostenreduktion führen – das verraten wir im neuen Blogbeitrag.
Zwischen Flexibilität und Festungsanlage: Wie Unternehmen in der modernen Arbeitswelt Sicherheit gewährleisten können. Ein Expertengespräch mit Christian Dunkel über Secure Workplace.
