Einrichten der OIDC-Authentifizierung in SharePoint Server mit Microsoft Entra ID

GILT FÜR:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

Voraussetzungen

Wenn Sie OpenID Connect (OIDC) mit Microsoft Entra ID konfigurieren, benötigen Sie die folgenden Ressourcen:

1. Eine SharePoint Server-Abonnementedition-Farm (SPSE)

2. Microsoft Entra Rolle des globalen Administrators des M365-Mandanten

In diesem Artikel werden die folgenden Beispielwerte für Microsoft Entra OIDC-Setup verwendet:

Wert	Link
SharePoint-Website: Uniform Resource Locator (URL)	https://spsites.contoso.local/
URL der OIDC-Website	https://sts.windows.net/<tenantid>/
Microsoft Entra OIDC-Authentifizierungsendpunkt	https://login.microsoftonline.com/<tenantid>/oauth2/authorize
Microsoft Entra OIDC RegisteredIssuerName URL	https://sts.windows.net/<tenantid>/
Microsoft Entra OIDC SignoutURL	https://login.microsoftonline.com/<tenantid>/oauth2/logout
Identitätsanspruchstyp	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Windows-Websitesammlungsadministrator	contoso\yvand
Email Wert des Verbundwebsitesammlungsadministrators	yvand@contoso.local

Schritt 1: Einrichten des Identitätsanbieters

Führen Sie die folgenden Schritte aus, um OIDC mit Microsoft Entra ID einzurichten:

1. Navigieren Sie zum Entra ID-Verwaltungsportal, und melden Sie sich mit einem Konto mit der Rolle Globaler Administrator an.

2. Wählen Sie unter Anwendungen die Option App-Registrierungen aus.

3. Wählen Sie Neue Registrierung aus.

4. Wechseln Sie zur Seite https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredAppsAnwendung registrieren.

5. Wählen Sie im Abschnitt Umleitungs-URI die Option "Web" als Plattform aus, und geben Sie die URL Ihrer SharePoint Server-Webanwendung ein, z. B.: https://spsites.contoso.local/ und wählen Sie Registrieren aus.

   

6. Speichern Sie den Wert der Verzeichnis-ID (Mandanten-ID), da die Mandanten-ID in den nachfolgenden Schritten verwendet wird. Speichern Sie außerdem die Anwendungs-ID (Client-ID), die wir im SharePoint-Setup als DefaultClientIdentifier verwenden.

   

7. Wechseln Sie nach der Registrierung der Anwendung zur Registerkarte Authentifizierung , aktivieren Sie das Kontrollkästchen ID-Token , und wählen Sie Speichern aus.

   

8. Wechseln Sie zur Registerkarte API-Berechtigungen, und wählen Sie Berechtigung hinzufügen aus. Wählen Sie Microsoft Graph und dann Delegierte Berechtigungen aus. Wählen Sie E-Mail- und Profilberechtigungen hinzufügen aus, und wählen Sie Berechtigungen hinzufügen aus.

   

9. Wechseln Sie zur Registerkarte Tokenkonfiguration , und wählen Sie Optionalen Anspruch hinzufügen aus. Fügen Sie für jeden Tokentyp (ID, Access, SAML) E-Mail- und Upn-Ansprüche hinzu.

10. Wählen Sie außerdem auf der Registerkarte Tokenkonfiguration die Option Gruppenanspruch hinzufügen aus. Sicherheitsgruppen sind die häufigsten, aber die gruppentypen, die Sie auswählen, hängen davon ab, welche Gruppentypen Sie verwenden möchten, um Zugriff auf die SharePoint-Webanwendung zu gewähren. Weitere Informationen finden Sie unter Konfigurieren optionaler Gruppenansprüche und Konfigurieren von Gruppenansprüchen für Anwendungen mithilfe von Microsoft Entra ID.

    

11. Wechseln Sie zur Registerkarte Manifest , und ändern Sie replyUrlsWithType manuell von in https://spsites.contoso.local/https://spsites.contoso.local/*. Klicken Sie dann auf Speichern.

    

Schritt 2: Ändern von SharePoint-Farmeigenschaften

In diesem Schritt müssen Sie die SharePoint Server-Farmeigenschaften basierend auf der Version Ihrer SharePoint Server-Farm ändern.

• Weitere Informationen zum Konfigurieren von SharePoint-Farmeigenschaften für SharePoint Server-Abonnementedition Version 24H1 finden Sie unter Konfigurieren von SPSE Version 24H1 oder höher.
• Weitere Informationen zum Konfigurieren von SharePoint-Farmeigenschaften für SharePoint Server-Abonnementedition Version vor 24H1 finden Sie unter Konfigurieren von SPSE vor Version 24H1.

Konfigurieren SharePoint Server-Abonnementedition Version 24H1 oder höher

Ab SharePoint Server-Abonnementedition Version 24H1 (März 2024) können Sie SharePoint Server-Farmeigenschaften konfigurieren, indem Sie die SharePoint-Zertifikatverwaltung zum Verwalten des Nonce-Cookiezertifikats verwenden. Das Nonce-Cookiezertifikat ist Teil der Infrastruktur, um sicherzustellen, dass OIDC-Authentifizierungstoken sicher sind. Führen Sie zum Konfigurieren das folgende Skript aus:

Hinweis

Starten Sie die SharePoint-Verwaltungsshell als Farmadministrator, um das folgende Skript auszuführen. Lesen Sie die Anweisungen im folgenden PowerShell-Skript sorgfältig durch. Sie müssen an bestimmten Stellen ihre eigenen umgebungsspezifischen Werte eingeben.

# Set up farm properties to work with OIDC

# Create the Nonce certificate
$cert = New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Provider 'Microsoft Enhanced RSA and AES Cryptographic Provider' -Subject "CN=SharePoint Cookie Cert"

# Import certificate to Certificate Management
$certPath = <path to save the exported cert>
$certPassword = ConvertTo-SecureString -String <password> -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath $certPath -Password $certPassword
$nonceCert = Import-SPCertificate -Path $certPath -Password $certPassword -Store "EndEntity" -Exportable:$true

# Update farm property
$farm = Get-SPFarm 
$farm.UpdateNonceCertificate($nonceCert,$true)

Konfigurieren von SharePoint Server-Abonnementedition vor Version 24H1

Vor dem Update 24H1 (März 2024) muss das Nonce-Cookiezertifikat manuell verwaltet werden. Dies umfasst die manuelle Installation auf jedem Server in der Farm und das Festlegen von Berechtigungen für den privaten Schlüssel. Dazu kann das folgende PowerShell-Skript verwendet werden.

Hinweis

Starten Sie die SharePoint-Verwaltungsshell als Farmadministrator, um das folgende Skript auszuführen. Lesen Sie die Anweisungen im folgenden PowerShell-Skript sorgfältig durch. Sie müssen an bestimmten Stellen ihre eigenen umgebungsspezifischen Werte eingeben.

# Set up farm properties to work with OIDC
$cert = New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Provider 'Microsoft Enhanced RSA and AES Cryptographic Provider' -Subject "CN=SharePoint Cookie Cert"
$rsaCert = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($cert)
$fileName = $rsaCert.key.UniqueName

# If you have multiple SharePoint servers in the farm, you need to export the certificate by Export-PfxCertificate and import the certificate to all other SharePoint servers in the farm by Import-PfxCertificate. 

# After the certificate is successfully imported to SharePoint Server, we will need to grant access permission to the certificate's private key.

$path = "$env:ALLUSERSPROFILE\Microsoft\Crypto\RSA\MachineKeys\$fileName"
$permissions = Get-Acl -Path $path

# Replace the <web application pool account> with the real application pool account of your web application
$access_rule = New-Object System.Security.AccessControl.FileSystemAccessRule(<Web application pool account>, 'Read', 'None', 'None', 'Allow')
$permissions.AddAccessRule($access_rule)
Set-Acl -Path $path -AclObject $permissions

# Then update farm properties
$farm = Get-SPFarm
$farm.Properties['SP-NonceCookieCertificateThumbprint']=$cert.Thumbprint
$farm.Properties['SP-NonceCookieHMACSecretKey']='seed'
$farm.Update()

Wichtig

Das Nonce-Cookiezertifikat mit privatem Schlüssel muss auf allen SharePoint-Servern in der Farm installiert sein. Außerdem muss dem Dienstkonto des Webanwendungspools auf jedem Server die Berechtigung für den privaten Schlüssel erteilt werden. Wenn Dieser Schritt nicht abgeschlossen wird, führt dies zu Fehlern bei der OIDC-Authentifizierung. Es wird empfohlen, das obige PowerShell-Beispiel zu verwenden, um die Berechtigung für die Datei mit dem privaten Schlüssel festzulegen, um sicherzustellen, dass sie ordnungsgemäß ausgeführt wird.

Schritt 3: Konfigurieren von SharePoint zum Vertrauen des Identitätsanbieters

In diesem Schritt erstellen Sie eine SPTrustedTokenIssuer , die die Konfiguration speichert, die SharePoint zum Vertrauen Microsoft Entra OIDC als OIDC-Anbieter benötigt.

Sie können SharePoint auf eine der folgenden Arten so konfigurieren, dass dem Identitätsanbieter vertraut wird:

• Konfigurieren Sie SharePoint, um Microsoft Entra ID als OIDC-Anbieter zu vertrauen, indem Sie den Metadatenendpunkt verwenden.
  • Mithilfe des Metadatenendpunkts werden mehrere parameter, die Sie benötigen, automatisch aus dem Metadatenendpunkt abgerufen.
• Konfigurieren Sie SharePoint so, dass Microsoft Entra ID als OIDC-Anbieter manuell vertrauenswürdig ist.

Hinweis

Führen Sie entweder die manuellen Konfigurationsschritte oder die Schritte zum Metadatenendpunkt aus, aber nicht beides.
Die Verwendung des Metadatenendpunkts wird empfohlen, da er den Prozess vereinfacht.

Konfigurieren von SharePoint zum Vertrauen Microsoft Entra OIDC mithilfe des Metadatenendpunkts

SharePoint Server-Abonnementedition unterstützt jetzt die Verwendung der OIDC-Metadatenermittlungsfunktion beim Erstellen des Tokenausstellers für vertrauenswürdige Identitäten.

In Microsoft Entra ID gibt es zwei Versionen von OIDC-Ermittlungsendpunkten:

• V1.0: https://login.microsoftonline.com/<TenantID>/.well-known/openid-configuration
• V2.0: https://login.microsoftonline.com/<TenantID>/v2.0/.well-known/openid-configuration

Wichtig

Derzeit unterstützt SharePoint Server nur den v1.0-Metadatenendpunkt, wenn er zum Erstellen des Tokenausstellers für vertrauenswürdige Identitäten verwendet wird. Im folgenden PowerShell-Beispielskript wird der V1.0-Endpunkt verwendet.

Wenn Sie den vom OIDC-Identitätsanbieter bereitgestellten Metadatenendpunkt verwenden, wird ein Teil der Konfiguration direkt vom Metadatenendpunkt des OIDC-Anbieters abgerufen, einschließlich:

1. Zertifikat
2. Aussteller
3. Autorisierungsendpunkt
4. SignoutURL

Dies kann die Konfiguration des OIDC-Tokenausstellers vereinfachen.

Im folgenden PowerShell-Beispiel können wir den Metadatenendpunkt aus Microsoft Entra ID verwenden, um SharePoint so zu konfigurieren, dass Microsoft Entra OIDC als vertrauenswürdig eingestuft wird.

Hinweis

Lesen Sie die Anweisungen im folgenden PowerShell-Skript sorgfältig durch. Sie müssen an bestimmten Stellen ihre eigenen umgebungsspezifischen Werte eingeben. Ersetzen Sie <z. B. tenantid> durch Ihre eigene Verzeichnis-ID (Mandant).

# Define claim types
# In this example, we're using Email Address as the Identity claim.
$emailClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming

# Set the AAD metadata endpoint URL. Please replace <TenantID> with the value saved in step #3 in the Entra ID setup section  
$metadataendpointurl = "https://login.microsoftonline.com/<TenantID>/.well-known/openid-configuration"

# Please replace <Application (Client) ID> with the value saved in step #3 in the Entra ID setup section
$clientIdentifier = "<Application (Client)ID>"

# Create a new SPTrustedIdentityTokenIssuer in SharePoint
New-SPTrustedIdentityTokenIssuer -Name "contoso.local" -Description "contoso.local" -ClaimsMappings $emailClaimMap -IdentifierClaim $emailClaimMap.InputClaimType -DefaultClientIdentifier $clientIdentifier -MetadataEndPoint $metadataendpointurl -Scope "openid profile"

Parameter	Beschreibung
Name	Gibt dem neuen Tokenaussteller einen Namen.
Beschreibung	Gibt dem neuen Tokenaussteller eine Beschreibung.
ImportTrustCertificate	Ein Zertifikat, das zum Überprüfen id_token anhand des OIDC-Bezeichners verwendet wird.
ClaimsMappings	Ein SPClaimTypeMapping -Objekt, das verwendet wird, um zu identifizieren, welcher Anspruch in der id_token als Bezeichner in SharePoint angesehen wird.
IdentifierClaim	Gibt den Typ des Bezeichners an.
DefaultClientIdentifier	Gibt den client_id des SharePoint-Servers an, der vom OIDC-Identitätsanbieter zugewiesen wird. Dies wird anhand des aud-Anspruchs in id_tokenüberprüft.
MetadataEndPoint	Gibt den bekannten Metadatenendpunkt des OIDC-Identitätsanbieters an, der zum Abrufen des neuesten Zertifikats, des Ausstellers, des Autorisierungsendpunkts und des Abmeldeendpunkts verwendet werden kann.

Konfigurieren Sie SharePoint so, dass Microsoft Entra ID als OIDC-Anbieter manuell vertrauenswürdig ist.

Bei der manuellen Konfiguration müssen mehrere zusätzliche Parameter angegeben werden. Sie können die Werte vom OIDC-Ermittlungsendpunkt abrufen.

In Microsoft Entra ID gibt es zwei Versionen von OIDC-Authentifizierungsendpunkten. Daher gibt es jeweils zwei Versionen von OIDC-Ermittlungsendpunkten:

• V1.0: https://login.microsoftonline.com/<TenantID>/.well-known/openid-configuration
• V2.0: https://login.microsoftonline.com/<TenantID>/v2.0/.well-known/openid-configuration

Ersetzen Sie TenantID durch die Verzeichnis-ID (Mandant), die in Schritt 1: Einrichten des Identitätsanbieters gespeichert ist, und stellen Sie über Ihren Browser eine Verbindung mit dem Endpunkt her. Speichern Sie dann die folgenden Informationen:

Wert	Link
authorization_endpoint	https://login.microsoftonline.com/<tenantid>/oauth2/authorize
end_session_endpoint	https://login.microsoftonline.com/<tenantid>/oauth2/logout
Emittenten	https://sts.windows.net/<tenantid>/
jwks_uri	https://login.microsoftonline.com/common/discovery/keys

Öffnen Sie jwks_uri (https://login.microsoftonline.com/common/discovery/keys), und speichern Sie alle x5c-Zertifikatzeichenfolgen zur späteren Verwendung im SharePoint-Setup.

Starten Sie die SharePoint-Verwaltungsshell als Farmadministrator, und führen Sie nach der Eingabe der oben abgerufenen Werte das folgende Skript aus, um den Tokenaussteller für vertrauenswürdige Identitäten zu erstellen:

Hinweis

Lesen Sie die Anweisungen im folgenden PowerShell-Skript sorgfältig durch. Sie müssen an bestimmten Stellen ihre eigenen umgebungsspezifischen Werte eingeben. Ersetzen Sie <z. B. tenantid> durch Ihre eigene Verzeichnis-ID (Mandant).

# Define claim types
# In this example, we're using Email Address as the identity claim.
$emailClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming

# Public key of the AAD OIDC signing certificate. Please replace <x5c cert string> with the encoded cert string which you get from x5c certificate string of the keys of jwks_uri from Step #1
$encodedCertStrs = @()
$encodedCertStrs += <x5c cert string 1>
$encodedCertStrs += <x5c cert string 2>
...
$certificates = @()
foreach ($encodedCertStr in $encodedCertStrs) {
     $certificates += New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 @(,[System.Convert]::FromBase64String($encodedCertStr))
}

# Set the AAD OIDC URL where users are redirected to authenticate. Please replace <tenantid> accordingly
$authendpointurl = "https://login.microsoftonline.com/<tenantid>/oauth2/authorize"
$registeredissuernameurl = "https://sts.windows.net/<tenantid>/"
$signouturl = "https://login.microsoftonline.com/<tenantid>/oauth2/logout"

# Please replace <Application (Client) ID> with the value saved in step #3 in AAD setup section
$clientIdentifier = "<Application (Client)ID>"

# Create a new SPTrustedIdentityTokenIssuer in SharePoint
New-SPTrustedIdentityTokenIssuer -Name "contoso.local" -Description "contoso.local" -ImportTrustCertificate $certificates -ClaimsMappings emailClaimMap -IdentifierClaim $emailClaimMap.InputClaimType -RegisteredIssuerName $registeredissuernameurl -AuthorizationEndPointUri $authendpointurl -SignOutUrl $signouturl -DefaultClientIdentifier $clientIdentifier -Scope "openid profile"

Hier wird das PowerShell-Cmdlet erweitert, New-SPTrustedIdentityTokenIssuer um OIDC mithilfe der folgenden Parameter zu unterstützen:

Parameter	Beschreibung
Name	Gibt dem neuen Tokenaussteller einen Namen.
Beschreibung	Gibt dem neuen Tokenaussteller eine Beschreibung.
ImportTrustCertificate	Importiert eine Liste von X509-Zertifikaten, die zum Überprüfen id_token anhand des OIDC-Bezeichners verwendet wird. Wenn der OIDC-Identitätsanbieter (IDP) mehr als ein Zertifikat verwendet, um das digital zu signieren, id_tokenimportieren Sie diese Zertifikate, und SharePoint überprüft, indem sie die mit diesen Zertifikaten generierte id_token digitale Signatur abgleichen.
ClaimsMappings	Ein SPClaimTypeMapping -Objekt, das verwendet wird, um zu identifizieren, welcher Anspruch in der id_token als Bezeichner in SharePoint angesehen wird.
IdentifierClaim	Gibt den Typ des Bezeichners an.
RegisteredIssuerName	Gibt den Ausstellerbezeichner an, der ausgibt id_token. Es wird verwendet, um zu id_tokenüberprüfen.
AuthorizationEndPointUrl	Gibt den Autorisierungsendpunkt des OIDC-Identitätsanbieters an.
SignoutUrl	Gibt den Abmeldeendpunkt des OIDC-Identitätsanbieters an.
DefaultClientIdentifier	Gibt den client_id des SharePoint-Servers an, der vom OIDC-Identitätsanbieter zugewiesen wird. Dies wird anhand des aud-Anspruchs in id_tokenüberprüft.
ResponseTypesSupported	Gibt den Antworttyp des IDP an, der von diesem Tokenaussteller akzeptiert wird. Sie kann zwei Zeichenfolgen akzeptieren: id_token und code id_token. Wenn dieser Parameter nicht angegeben wird, wird code id_token als Standard verwendet.

Schritt 4: Konfigurieren der SharePoint-Webanwendung

In diesem Schritt konfigurieren Sie eine Webanwendung in SharePoint so, dass sie mit dem Microsoft Entra OIDC verbunden wird, indem Sie die SPTrustedIdentityTokenIssuer im vorherigen Schritt erstellte verwenden.

Wichtig

• Für die Standardzone der SharePoint-Webanwendung muss Windows-Authentifizierung aktiviert sein. Dies ist für den Search-Crawler erforderlich.
• Die SharePoint-URL, die Microsoft Entra OIDC-Verbund verwendet, muss mit Hypertext Transfer Protocol Secure (HTTPS) konfiguriert werden.

Sie können diese Konfiguration wie folgt abschließen:

• Erstellen einer neuen Webanwendung und Verwenden von Windows und Microsoft Entra OIDC-Authentifizierung in der Standardzone.
• Erweitern einer vorhandenen Webanwendung, um Microsoft Entra OIDC-Authentifizierung für eine neue Zone festzulegen.

Gehen Sie wie folgt vor, um eine neue Webanwendung zu erstellen:

1. Starten Sie die SharePoint-Verwaltungsshell, und führen Sie das folgende Skript aus, um eine neue SPAuthenticationProviderzu erstellen:

   # This script creates a trusted authentication provider for OIDC
   
   $sptrust = Get-SPTrustedIdentityTokenIssuer "contoso.local"
   $trustedAp = New-SPAuthenticationProvider -TrustedIdentityTokenIssuer $sptrust
   

2. Befolgen Sie Create einer Webanwendung in SharePoint Server, um eine neue Webanwendung zu erstellen, die HTTPS/Secure Sockets Layer (SSL) mit dem Namen SharePoint – OIDC auf contoso.local aktiviert.

3. Öffnen Sie die Website sharePoint-Zentraladministration.

4. Wählen Sie die erstellte Webanwendung aus, wählen Sie im Menüband "Authentifizierungsanbieter" aus, klicken Sie auf den Link für die Standardzone, und wählen Sie contoso.local als vertrauenswürdiger Identitätsanbieter aus.

   

5. Navigieren Sie auf der Website der SharePoint-Zentraladministration zu Systemeinstellungen>Konfigurieren alternativer ZugriffszuordnungenAlternative Zugriffszuordnungssammlung>.

6. Filtern Sie die Anzeige mit der neuen Webanwendung, und vergewissern Sie sich, dass die folgenden Informationen angezeigt werden:

   

Gehen Sie wie folgt vor, um eine vorhandene Webanwendung zu erweitern und für die Verwendung des vertrauenswürdigen Anbieters "contoso.local" zu konfigurieren:

1. Starten Sie die SharePoint-Verwaltungsshell, und führen Sie PowerShell aus, um die Webanwendung zu erweitern. Im folgenden Beispiel wird die Webanwendung auf die Intranetzone erweitert und die Zone so konfiguriert, dass der vertrauenswürdige Anbieter "Contoso.local" für die Authentifizierung verwendet wird.

Hinweis

Damit dies funktioniert, müssen Sie ein gültiges Zertifikat mit dem Namen "SharePoint OIDC-Website" in die Farm importiert haben. Weitere Informationen finden Sie unter Ssl-Zertifikatverwaltungsvorgänge .

# Get the trusted provider
$sptrust = Get-SPTrustedIdentityTokenIssuer "Contoso.local"
$ap = New-SPAuthenticationProvider -TrustedIdentityTokenIssuer $sptrust
# Get the web app
$wa = Get-SPWebApplication http://spsites
# Extend the web app to the "Intranet" zone using trusted provider (OIDC) auth and a SharePoint managed certificate called "SharePoint OIDC Site"
New-SPWebApplicationExtension -Identity $wa -Name "spsites" -port 443 -HostHeader 'spsites.contoso.local'-AuthenticationProvider $ap -SecureSocketsLayer -UseServerNameIndication -Certificate 'SharePoint OIDC Site' -Zone 'Intranet' -URL 'https://spsites.contoso.local' 

2. Navigieren Sie auf der Website der SharePoint-Zentraladministration zu Systemeinstellungen>Konfigurieren alternativer ZugriffszuordnungenAlternative Zugriffszuordnungssammlung>.

3. Filtern Sie die Anzeige mit der erweiterten Webanwendung, und vergewissern Sie sich, dass die folgenden Informationen angezeigt werden:

   

Schritt 5: Sicherstellen, dass die Webanwendung mit SSL-Zertifikat konfiguriert ist

Da die OIDC 1.0-Authentifizierung nur mit dem HTTPS-Protokoll funktionieren kann, muss ein Zertifikat für die entsprechende Webanwendung festgelegt werden. Führen Sie die folgenden Schritte aus, um das Zertifikat festzulegen, falls noch nicht konfiguriert:

1. Generieren Sie das Standortzertifikat:

   Hinweis

   Sie können diesen Schritt überspringen, wenn Sie das Zertifikat bereits generiert haben.

   1. Öffnen Sie die SharePoint PowerShell-Konsole.

   2. Führen Sie das folgende Skript aus, um ein selbstsigniertes Zertifikat zu generieren und es der SharePoint-Farm hinzuzufügen:

      New-SPCertificate -FriendlyName "Contoso SharePoint (2021)" -KeySize 2048 -CommonName spsites.contoso.local -AlternativeNames extranet.contoso.local, onedrive.contoso.local -OrganizationalUnit "Contoso IT Department" -Organization "Contoso" -Locality "Redmond" -State "Washington" -Country "US" -Exportable -HashAlgorithm SHA256 -Path "\\server\fileshare\Contoso SharePoint 2021 Certificate Signing Request.txt"
      Move-SPCertificate -Identity "Contoso SharePoint (2021)" -NewStore EndEntity
      

      Wichtig

      Selbstsignierte Zertifikate eignen sich nur zu Testzwecken. In Produktionsumgebungen wird dringend empfohlen, stattdessen Zertifikate zu verwenden, die von einer Zertifizierungsstelle ausgestellt wurden.

2. Legen Sie das Zertifikat fest:

   Sie können das folgende PowerShell-Cmdlet verwenden, um das Zertifikat der Webanwendung zuzuweisen:

   Set-SPWebApplication -Identity https://spsites.contoso.local -Zone Default -SecureSocketsLayer -Certificate "Contoso SharePoint (2021)"
   

Schritt 6: Create der Websitesammlung

In diesem Schritt erstellen Sie eine Teamwebsitesammlung mit zwei Administratoren: einen als Windows-Administrator und einen als Verbundadministrator (Microsoft Entra ID).

1. Öffnen Sie die Website sharePoint-Zentraladministration.

2. Navigieren Sie zu Anwendungsverwaltung>Create Websitesammlungen>Create Websitesammlungen.

3. Geben Sie einen Titel und eine URL ein, und wählen Sie die Vorlage Teamwebsite aus.

4. Wählen Sie im Abschnitt Primärer Websitesammlungsadministrator das (Buch) aus, um das Dialogfeld Personen Auswahl zu öffnen.

5. Geben Sie im Dialogfeld Personen Auswahl das Windows-Administratorkonto ein, z. B. yvand.

6. Filtern Sie die Liste auf der linken Seite, indem Sie Organisationen auswählen. Es folgt eine Beispielausgabe:

   

7. Wechseln Sie zum Konto, und wählen Sie OK aus.

8. Wählen Sie im Abschnitt Sekundärer Websitesammlungsadministrator das Buchsymbol aus, um das Dialogfeld Personen Auswahl zu öffnen.

9. Geben Sie im Dialogfeld Personen Auswahl den genauen E-Mail-Wert des Microsoft Entra Administratorkontos ein, zyvand@contoso.local. B. .

10. Filtern Sie die Liste auf der linken Seite, indem Sie contoso.local auswählen. Es folgt eine Beispielausgabe:

    

11. Wechseln Sie zum Konto, und wählen Sie OK aus, um das Dialogfeld Personen Auswahl zu schließen.

12. Klicken Sie erneut auf OK , um die Websitesammlung zu erstellen.

Nachdem die Websitesammlung erstellt wurde, sollten Sie sich entweder mit dem Windows- oder dem Verbundwebsitesammlungsadministratorkonto anmelden können.

Schritt 7: Einrichten Personen Pickers

Bei der OIDC-Authentifizierung überprüft der Personen Picker die Eingabe nicht, was dazu führen kann, dass Rechtschreibfehler auftreten oder Benutzer versehentlich den falschen Anspruchstyp auswählen. Dies kann entweder mithilfe eines benutzerdefinierten Anspruchsanbieters oder mithilfe des neuen UPA-gestützten Anspruchsanbieters behoben werden, der in SharePoint Server-Abonnementedition enthalten ist. Informationen zum Konfigurieren eines UPA-gestützten Anspruchsanbieters finden Sie unter Erweiterte Personen auswahl für moderne Authentifizierung.