+- **Central site**ΓÇöThe location that hosts most of the company data and employee computers. A centralized SharePoint Server environment can consist of a single farm or multiple farms located in the same datacenter.

+- **Regional site**ΓÇöA location that hosts a subset of corporate data and employee computers that are connected by using a combination of local-area network (LAN) and WAN links.

+- **Distributed environment**ΓÇöAn environment in which employees and company data are dispersed across the globe.

+- **In-country farm** ΓÇö A farm that is deployed inside a political boundary to satisfy government regulations.

+- **BranchCache**-BranchCache, a feature of the Windows 7, Windows Server 2008 R2, and Windows Server 2012 operating systems, caches content from file and web servers on a WAN on computers at a local branch office. In a geographically distributed SharePoint Server environment, BranchCache can optimize WAN performance by caching large files that users download from SharePoint Server.

+- **Quality of Service (QoS)**ΓÇöWindows 2000 introduced QoS features that Windows Server 2012 has enhanced. QoS enables you to meet the service requirements of a workload or an application by measuring network bandwidth, detecting changing network conditions (such as congestion or availability of bandwidth), and prioritizing - or throttling - network traffic. For example, you can use QoS to prioritize traffic for latency-sensitive applications and to control the effect of latency-insensitive traffic (such as bulk data transfers). You can use QoS to prioritize requests for applications that are critical for users. In addition, you can deprioritize applications or processes that adversely affect performance, such as backup processes or large downloads. For more information about QoS features in Windows Server 2012, see [Quality of Service (QoS) Overview](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831679(v=ws.11)).

+An Office Online Server farm is typically located in the same datacenter as the SharePoint Server 2016 farm, although this is not a requirement. Locating an Office Online Server farm in a remote datacenter where SharePoint sites are not located will not improve performance. For more information, see [Office Web Apps Server overview](/webappsserver/office-web-apps-server-overview).

+> The new OneDrive sync app (OneDrive.exe) is supported on SharePoint Server Subscription Edition and 2019. For more information, see [Configure syncing with the new OneDrive sync app](../install/configure-syncing-with-the-onedrive-sync-app.md).

+|User experience <br/> |Users are presented with a single list of results. <br/> |Results are presented in a single list. However, the results are grouped in blocks by result source. You can configure the number of results within each group. <br/> |

+ Title: "Configure syncing with the new OneDrive sync app"

+audience: ITPro

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+- IT_Sharepoint_Server

+- IT_Sharepoint_Server_Top

+description: "Learn how to configure the new OneDrive sync app (OneDrive.exe) for SharePoint Server Subscription Edition or 2019."

+# Configure syncing with the new OneDrive sync app

+

+When you deploy SharePoint Server Subscription Edition or 2019 in your organization, your users can sync their OneDrive files as well as SharePoint team site files by using the new OneDrive sync app (_OneDrive.exe_) for Windows or Mac. Compared with the previous OneDrive sync app (_Groove.exe_), the new sync app provides:

+- Improved performance and reliability

+- Files On-Demand

+- Support for larger files

+- Higher sync limits

+- The ability to silently deploy. If your Windows users are already syncing document libraries with the previous OneDrive sync app, they will transition to the new sync app automatically.

+- Mac support

+

+## Requirements

+1. Install SharePoint Server Subscription Edition or 2019.

+2. Install the OneDrive sync app ([download](https://go.microsoft.com/fwlink/p/?LinkId=248256)). For deployment info, see:

+ - [Deploy OneDrive apps using Microsoft Endpoint Configuration Manager](/onedrive/deploy-on-windows)

+ - [Deploy OneDrive apps by using Intune](/onedrive/deploy-intune)

+ - [Deploy and configure the new OneDrive sync app for Mac](/onedrive/deploy-and-configure-on-macos)

+

+3. [Configure OneDrive for SharePoint Server 2019](../install/configure-syncing-with-the-onedrive-sync-app.md).

+

+## Recommendations

+### 1. Allow WNS Traffic

+For the best user experience, SharePoint Server Subscription Edition or 2019 will send change notifications to sync apps via WNS web push notifications. This feature ensures sync users quickly have the latest copies of any SharePoint Server file updates. You may need to take steps to ensure outbound requests from your SharePoint Server and your users' computers can reach and properly interact with the WNS service.

+For SharePoint Server:

+ - Allow outbound HTTPS connection to reach \*.notify.windows.com

+

+For computers running the OneDrive sync app:

+ - Allow outbound TLS encrypted TCP/IP socket connection to reach \*.wns.windows.com

+ - Avoid HTTPS decryption for \*.wns.windows.com on your proxy server as this likely will disconnect the socket connection.

+

+If either the SharePoint Server or the OneDrive sync app is unable to communicate with the WNS service, then the sync app will fall back to polling the SharePoint Server roughly every two minutes looking for changes. As a result, your users may see delays of more than two minutes from the time of a server change to when the sync app downloads a changed file.

+### 2. Opt in to sharing improvement information

+When configuring the SharePoint Server, you can enable sharing of improvement information with Microsoft. Enabling this option allows connected sync apps to send troubleshooting information. This allows the sync app team to proactively detect and correct problems, respond to customer reported problems, and improve the product over time. If this is disabled, customer escalations are harder to investigate and will require the customer to manually gather and provide logs from the impacted computers.

+## Configure OneDrive for SharePoint Server Subscription Edition or 2019

+To set up OneDrive with SharePoint Server Subscription Edition or 2019, you can either use Group Policy or set the registry keys directly.

+> [!NOTE]

+> For settings that require an organization ID, if you sync a single domain, you can use **OP1**. Do not use this if you sync multiple domains.

+>

+> The Known Folder Move settings don't work for SharePoint Server.

+### Using Group Policy

+Configure the following two Group Policy objects to configure OneDrive to be used with SharePoint Server Subscription Edition or 2019:

+

+**Specify SharePoint Server URL and organization name**

+The URL (_SharePointOnPremFrontDoorUrl_) is used by the sync app to authenticate the user and to set up syncing of the user's SharePoint Server hosted personal OneDrive site.

+The organization name (_SharePointOnPremTenantName_) lets you specify the name of the root folder that will be created in File Explorer. If you don't supply an organization name, the sync app will use the first segment of the URL as the name. For example, office.sharepoint.com would create the folder "office".

+**Specify the OneDrive location in a hybrid environment**

+This setting (_SharePointOnPremPrioritization_) lets you specify if the sync app should first set up a sync relationship with SharePoint in Microsoft 365 (the default) or the SharePoint on-premises server if the user identity exists in both identity providers. The sync application's **Settings** dialog can be used to "Add Account" the same identity for the other SharePoint realm after the first has been configured (if the user identity exists in both).

+You should be able to find these Group Policy objects using the Group Policy Editor (_gpedit.msc_) when navigating to _Computer Configuration\Administrative Templates\OneDrive_. If the OneDrive folder is not present, you can add the OneDrive Group Policy template by copying the following two files from the OneDrive installation folder after you have installed the latest OneDrive sync app on that computer:

+- C:\Users\\*username*\AppData\Local\Microsoft\OneDrive\\*onedrivesyncclientversion*\adm\OneDrive.admx

+to

+C:\Windows\PolicyDefinitions\OneDrive.admx

+- C:\Users\\*username*\AppData\Local\Microsoft\OneDrive\\*onedrivesyncclientversion*\adm\OneDrive.adml

+to

+C:\Windows\PolicyDefinitions\en-US\OneDrive.adml

+To automate this copying using PowerShell, use:

+```powershell

+Get-ChildItem -Recurse -Path "$env:LOCALAPPDATA\Microsoft\OneDrive" -Filter "OneDrive.admx" | ? FullName -like "*\adm\OneDrive.admx" | Copy-Item -Destination "$env:WINDIR\PolicyDefinitions" -Force

+Get-ChildItem -Recurse -Path "$env:LOCALAPPDATA\Microsoft\OneDrive" -Filter "OneDrive.adml" | ? FullName -like "*\adm\OneDrive.adml" | Copy-Item -Destination "$env:WINDIR\PolicyDefinitions\en-US" -Force

+```

+More information:

+[Learn how to manage OneDrive using Group Policy](/onedrive/use-group-policy)

+### By setting the registry keys

+Alternatively, you can also directly configure the following underlying registry keys:

+| Key | Type | Value | Required |

+|:--|:--|:--|:--|

+|HKLM:\\Software\Policies\Microsoft\OneDrive\SharePointOnPremFrontDoorUrl|String|https://sharepoint.contoso.local|required|

+|HKLM:\\Software\Policies\Microsoft\OneDrive\SharePointOnPremPrioritization|DWORD (32-bit)|1|optional|

+|HKLM:\\Software\Policies\Microsoft\OneDrive\SharePointOnPremTenantName|String|Contoso|optional|

+

+### Mac configuration

+To configure sync with SharePoint Server in a Mac environment, you can use the _SharePointOnPremFrontDoorUrl_, _SharePointOnPremPrioritizationPolicy_, and _SharePointOnPremTenantName_ settings. For more information, see [Deploy and configure the new OneDrive sync app for Mac](/onedrive/deploy-and-configure-on-macos).

+## Differences between syncing files in SharePoint Server and SharePoint in Microsoft 365

+If your organization also uses the OneDrive sync app to sync files in Microsoft 365, here's what will be different for users who sync on-premises files.

+### Single Top-level URL

+If you have deployed multiple on-premises SharePoint Server farms in your enterprise, on a given client computer, you will only specify a single _SharePointOnPremFrontDoorUrl_. For a given user, you must configure their computer with the SharePoint Server URL that hosts their individual OneDrive site or if they don't have a OneDrive site, where the team sites they are most likely to sync are hosted. Your users will be able to start syncing team site content from any of your on-premises SharePoint Server farms by navigating to the web experience of the Team Site and clicking the Sync button on that site.

+For example, you have a SharePoint Server farm for your Finance department and another for the rest of your organization. Users who are members of the Finance department have their individual OneDrive site hosted on the Finance department's SharePoint Server farm. For those Finance employees, you use your computer management system to set the _SharePointOnPremFrontDoorUrl_ registry key policy on their computer to have your Finance specific farm's URL. For all other employees, you set the SharePointOnPremFrontDoorUrl to your other SharePoint Server farm URL. The sync app will look for and provision the user's OneDrive on the appropriate SharePoint Server farm as needed.

+

+### Folder names

+The OneDrive sync app creates the following folders on users' computers:

+- _OneDrive ΓÇô Contoso_ (for syncing personal My Site files)

+- _Contoso_ (for syncing SharePoint team site files)

+In SharePoint in Microsoft 365, "_Contoso_" is the tenant name that has been set for the SharePoint in Microsoft 365 instance. In SharePoint on-premises, there is no tenant name associated to the instance of SharePoint. You can set this with the "Specify SharePoint Server URL and organization name" group policy, or the sync app will use the first segment of your SharePoint URL.

+

+### File thumbnails and previews

+Thumbnails don't appear in File Explorer for files synced from SharePoint on-premises. If you enable Files On-Demand, and a file is online-only, a file preview won't be available. Image files and Office files will not have a thumbnail in File Explorer until the file is downloaded.

+

+### Sharing from File Explorer

+When users share files and folders from File Explorer, the sharing option will open the browser instead of the Share dialog.

+

+### Privacy settings

+When setting up SharePoint Server, you'll be prompted to select if clients should send error reports and usage statistics back to Microsoft. If you enable the setting, individual users can opt out by following these steps:

+1. At the far right of the taskbar, in the notification area, right-click the OneDrive cloud icon.

+2. Select **Settings**.

+3. Select the **Settings** tab, and under **Privacy**, clear the option.

+description: "Learn how to set up OIDC authentication in SharePoint Server."

+OpenID Connect (OIDC) 1.0 is a modern authentication protocol that seamlessly integrates applications and devices with the identity and authentication management solutions to keep pace with the

+evolving security and compliance needs of your organization.

+1. Windows authentication (New Technology LAN Manager (NTLM), Kerberos, etc.)

+3. Security Assertion Markup Language (SAML) 1.1-based authentication

+SharePoint Server Subscription Edition now supports OIDC 1.0 authentication protocol. With this new capability, you can now set up an OIDC-enabled `SPTrustedIdentityTokenIssuer` that works with a remote identity provider to enable OIDC authentication.

+You can set up OIDC authentication in SharePoint Server with either of these options:

+- Microsoft Azure Active Directory (Azure AD). For more information, see [Set up OIDC authentication in SharePoint Server with Microsoft Azure Active Directory (Azure AD)](set-up-oidc-auth-in-sharepoint-server-with-msaad.md).

+- Active Directory Federation Services (AD FS). For more information, see [Set up OIDC authentication in SharePoint Server with Active Directory Federation Services (AD FS)](set-up-oidc-auth-in-sharepoint-server-with-adfs.md).

+ Title: "Set up OIDC authentication in SharePoint Server with Active Directory Federation Services (AD FS)"

+audience: ITPro

+f1.keywords:

+- NOCSH

+localization_priority: Normal

+ms.assetid: 5cdce2aa-fa6e-4888-a34f-de61713f5096

+description: "Learn how to set up OIDC authentication in SharePoint Server with Active Directory Federation Services (AD FS)."

+# Set up OIDC authentication in SharePoint Server with Active Directory Federation Services (AD FS)

+## Prerequisites

+When you configure with AD FS OIDC, you need the following resources to perform the configuration:

+1. A SharePoint Server farm.

+2. AD FS in Windows Server 2016 or later, already created, with the public key of the AD FS signing certificate exported in a `.cer` file.

+This article uses the following example values for AD FS OIDC setup:

+| Value | Link |

+|||

+| SharePoint site URL | `https://spsites.contoso.local/` |

+| AD FS site URL | `https://adfs.contoso.local/adfs/` |

+| AD FS authentication endpoint | `https://adfs.contoso.local/adfs/oauth2/authorize` |

+| RegisteredIssuerName URL | `https://adfs.contoso.local/adfs/` |

+| AD FS SignoutURL | `https://adfs.contoso.local/adfs/oauth2/logout` |

+| Identity claim type | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` |

+| Windows site collection administrator | contoso\yvand |

+| Email value of the federated (AD FS) site collection administrator | yvand@contoso.local |

+## Step 1: Setup identity provider

+Perform the following steps to set up OIDC with AD FS:

+1. In AD FS Management, right-click on **Application Groups** and select **Add Application Group**.

+2. Go to the **Welcome** page, enter **ADFSSSO** in the **Name** field and under **Client-Server applications**, select the **Web browser accessing a web application** template. Then, select **Next**.

+ :::image type="content" source="../media/add-application-group-wizard.png" alt-text="Add Application Group Wizard":::

+3. Go to the **Native Application** page and copy the **Client Identifier** value. It will be used later as the value for `DefaultClientIdentifier` parameter during SharePoint configuration.

+4. Under the **Redirect URL** field, enter `https://spsites.contoso.local/` and select **Add**. Then, select **Next**.

+ :::image type="content" source="../media/add-application-group-wizard-2.png" alt-text="Add Application Group Wizard 2":::

+5. Go to the **Summary** page and select **Next**.

+ :::image type="content" source="../media/add-application-group-wizard-3.png" alt-text="Add Application Group Wizard 3":::

+6. Go to the **Complete** page and select **Close**.

+7. Export **Token-signing** certificate from AD FS. This token-signing certificate will be used in SharePoint setup. The following images show how to export **Token-signing** certificate from AD FS:

+ :::image type="content" source="../media/adfs-certificates.png" alt-text="AD FS Certificate Export 1":::

+ :::image type="content" source="../media/adfs-certificate-export-2.png" alt-text="AD FS Certificate Export 2":::

+ :::image type="content" source="../media/adfs-certificate-export-3.png" alt-text="AD FS Certificate Export 3":::

+ :::image type="content" source="../media/adfs-certificate-export-4.png" alt-text="AD FS Certificate Export 4":::

+8. Ensure that the required claim ID is included in the `id_token` from AD FS. LetΓÇÖs consider email as an example:

+ We assume that your AD FS has configured the rule that read identifier claim from attribute store, such as AD. Perform the following steps to create **Issuance Transform Rule** for this specific web application we created in AD FS previously:

+ 1. Open the web application you created and go to the **Issue Transformation Rule** tab.

+ :::image type="content" source="../media/issue-transformation-rule.jpg" alt-text="Issue Transformation Rule":::

+ 2. Select **Add Rule** and select **Send LDAP Attributes as Claims** from the option list.

+ :::image type="content" source="../media/issue-transformation-add-rule.JPG" alt-text="Issue Transformation Add Rule":::

+ :::image type="content" source="../media/add-transform-claim-rule.png" alt-text="Add Transform Claim Rule":::

+ 3. Name your Claim rule as **AD** and select **Active Directory** from the **Attribute store** dropdown menu. Create two mappings using the drop-down boxes as shown:

+ | Attribute | Value |

+ |||

+ | E-Mail-Addresses | E-Mail Address |

+ | Token-Groups - Qualified by Domain Name | Role |

+ :::image type="content" source="../media/add-transform-claim-rule-2.png" alt-text="Add Transform Claim Rule 2":::

+ 4. Select **Finish** to close the Rule wizard and select **OK** to close the web application properties. Select **OK** one more time to complete the Rule.

+If you're setting OIDC with SharePoint Server, nbf claim must be configured in AD FS server side in the web application you created. If nbf claim doesnΓÇÖt exist in this web application, perform the following steps to create it:

+1. Open the web application you created and go to the **Issue Transformation Rule** tab.

+ :::image type="content" source="../media/issue-transformation-rule.jpg" alt-text="Issue Transformation Rule":::

+2. Select **Add Rule** and then select **Apply**. In the **Add Transform Claim Rule Wizard** select **Send Claims Using a Custom Rule** from the **Claim rule template** options.

+ :::image type="content" source="../media/issue-transformation-add-rule.JPG" alt-text="Issue Transformation Add Rule":::

+ :::image type="content" source="../media/add-transform-claim-rule-3.JPG" alt-text="Add Transform Claim Rule 3":::

+3. Select **Next** and input the following string in the **Custom rule** field:

+ `c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(Type = "nbf", Value = "0");`

+ :::image type="content" source="../media/add-transform-claim-rule-4.JPG" alt-text="Add Transform Claim Rule 4":::

+4. Select **Finish**.

+## Step 2: Change SharePoint farm properties

+In this step, you'll need to modify the SharePoint farm properties. Start the SharePoint Management Shell and run the following script:

+> [!NOTE]

+> Read the instructions mentioned in the following PowerShell script carefully.

+```powershell

+# Setup farm properties to work with OIDC

+#Create a self-signed certificate in one SharePoint Server in the farm

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

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

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

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

+$fileName = $rsaCert.key.UniqueName

+$path = "$env:ALLUSERSPROFILE\Microsoft\Crypto\RSA\MachineKeys\$fileName"

+$permissions = Get-Acl -Path $path

+#please replace the <web application pool account> with 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 we update farm properties

+$f = Get-SPFarm

+$f.Farm.Properties['SP-NonceCookieCertificateThumbprint']=$cert.Thumbprint

+$f.Farm.Properties['SP-NonceCookieHMACSecretKey']='seed'

+$f.Farm.Update()

+```

+## Step 3: Configure SharePoint to trust the identity providers

+In this step, you'll create a `SPTrustedTokenIssuer` that will store the configuration that SharePoint needs to trust AD FS as OIDC provider. Start the SharePoint Management Shell and run the following script to create it:

+> [!NOTE]

+> Read the instructions mentioned in the following PowerShell script carefully.

+```powershell

+# Define claim types

+$email = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

+# Public key of the AD FS signing certificate

+$signingCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\Data\Claims\ADFS Signing.cer")

+# Set the AD FS URL where users are redirected to authenticate

+$authendpointurl = "https://adfs.contoso.local/adfs/oauth2/authorize"

+$registeredissuernameurl = "https://adfs.contoso.local/adfs"

+$signouturl = "https://adfs.contoso.local/adfs/oauth2/logout"

+#Please replace <Client Identifier> with the value you saved in step #3 of AD FS Setup section

+$clientIdentifier = <Client Identifier>

+# Create a new SPTrustedIdentityTokenIssuer in SharePoint

+New-SPTrustedIdentityTokenIssuer -Name "Contoso.local" -Description "Contoso.local" -ImportTrustCertificate $signingCert -ClaimsMappings $email -IdentifierClaim $email.InputClaimType -RegisteredIssuerName $registeredissuernameurl -AuthorizationEndPointUri $authendpointurl -SignOutUrl $signouturl -DefaultClientIdentifier $clientIdentifier

+```

+Here, `New-SPTrustedIdentityTokenIssuer` PowerShell cmdlet is extended to support OIDC by using the following parameters:

+| Parameter | Description |

+||-|

+|Name | Gives a name to the new token issuer. |

+|Description | Gives a description to the new token issuer. |

+|ImportTrustCertificate | Imports a list of X509 Certificates, which will be used to validate `id_token` from OIDC identifier. If the OIDC IDP uses more than one certificate to digital sign the `id_token`, import these certificates and SharePoint will then validate `id_token` by matching the digital signature generated by using these certificates. |

+| ClaimsMappings | A `SPClaimTypeMapping` object, which will be used to identify which claim in the `id_token` will be regarded as identifier in SharePoint. |

+| IdentifierClaim | Specifies the type of identifier. |

+| RegisteredIssuerName | Specifies the issuer identifier, which issues the `id_token`. It will be used to validate the `id_token`. |

+| AuthorizationEndPointUrl | Specifies the authorization endpoint of the OIDC identity provider. |

+| SignoutUrl | Specifies the sign-out endpoint of the OIDC identity provider. |

+| DefaultClientIdentifier | Specifies the `client_id` of SharePoint server, which is assigned by OID identity provider. This will be validated against aud claim in `id_token`. |

+| ResponseTypesSupported | Specifies the response type of IDP, which can be accepted by this token issuer. It can accept two strings: `id_token` and `code id_token`. If this parameter isn't provided, it will use `code id_token` as default. |

+> [!IMPORTANT]

+> The relevant certificate must be added to the SharePoint root authority certificate store and there are two possible options to do this:

+>

+> - If the AD FS signing certificate is issued by a certificate authority (best practice for security reasons).

+>

+> The public key of the issuer's certificate (and all the intermediates) must be added to the store. Start the SharePoint Management Shell and run the following script to add the certificate:

+>

+> ```powershell

+> $rootCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\Data\Claims\ADFS Signing issuer.cer")

+> New-SPTrustedRootAuthority -Name "adfs.contoso.local signing root authority" -Certificate $rootCert

+> ```

+>

+> - If the AD FS signing certificate is a self-signed certificate (not recommended for security reasons).

+>

+> The public key of the AD FS signing certificate itself must be added to the store. Start the SharePoint Management Shell and run the following script to add the certificate:

+>

+> ```powershell

+> $rootCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\Data\Claims\ADFS Signing.cer")

+> New-SPTrustedRootAuthority -Name "adfs.contoso.local signing certificate" -Certificate $rootCert

+> ```

+## Step 4: Configure a SharePoint web application

+In this step, you'll configure a web application in SharePoint to be federated with the AD FS OIDC, using the `SPTrustedIdentityTokenIssuer` that was created in the previous step.

+> [!IMPORTANT]

+>

+> - The default zone of the SharePoint web application must have Windows authentication enabled. This is required for the search crawler.

+> - SharePoint URL that will use AD FS OIDC federation must be configured with HTTPS.

+You can do this configuration either by:

+- Creating a new web application and using both Windows and AD FS OIDC authentication in the Default zone. To create a new web application, do the following:

+ 1. Start the SharePoint Management Shell and run the following script to create a new `SPAuthenticationProvider`:

+ ```powershell

+ # This script creates a trusted authentication provider for OIDC

+

+ $sptrust = Get-SPTrustedIdentityTokenIssuer "contoso.local"

+ $trustedAp = New-SPAuthenticationProvider -TrustedIdentityTokenIssuer $sptrust

+ ```

+ 2. Follow [Create a web application in SharePoint Server](/sharepoint/administration/create-a-web-application) to create a new web application enabling HTTPS/SSL named SharePoint - OIDC on contoso.local.

+ 3. Open the SharePoint Central Administration site.

+ 4. Open the web application you created and pick **contoso.local** as **Trusted Identity Provider**.

+ :::image type="content" source="../media/authentication-providers-3.jpg" alt-text="Authentication Providers 3":::

+ 5. Navigate to **System Settings** > **Configure Alternate Access Mappings** > **Alternate Access Mapping Collection**.

+ 6. Filter the display with the new web application and confirm that you see the following information:

+ :::image type="content" source="../media/alternate-access-mapping-collection.png" alt-text="Alternate Access Mapping Collection-1":::

+- Extending an existing web application to set AD FS OIDC authentication on a new zone. To extend an existing web application, do the following:

+ 1. Start the SharePoint Management Shell and run the following script:

+ ```powershell

+ # This script creates a trusted authentication provider for OIDC

+

+ $sptrust = Get-SPTrustedIdentityTokenIssuer "contoso.local"

+ $ap = New-SPAuthenticationProvider -TrustedIdentityTokenIssuer $sptrust

+ ```

+ 2. Open the SharePoint Central Administration site.

+ 3. Open the web application you want to extend OIDC authentication to and pick **contoso.local** as **Trusted Identity Provider**.

+ :::image type="content" source="../media/authentication-providers-4.jpg" alt-text="Authentication Providers 4":::

+ 4. Navigate to **System Settings** > **Configure Alternate Access Mappings** > **Alternate Access Mapping Collection**.

+ 5. Filter the display with the web application that was extended and confirm that you see the following information:

+ :::image type="content" source="../media/alternate-access-mapping-collection-2.png" alt-text="Alternate Access Mapping Collection":::

+## Step 5: Ensure the web application is configured with SSL certificate

+Since OpenID Connect 1.0 authentication can only work with HTTPS protocol, a certificate must be set on the corresponding web application. Perform the following steps to set a certificate:

+- Generate the site certificate:

+ > [!NOTE]

+ > You may skip this step if you have already generated the certificate.

+ 1. Open the SharePoint PowerShell console.

+ 2. Run the following script to generate a self-signed certificate and add it to the SharePoint farm:

+ ```powershell

+ 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

+ ```

+ > [!IMPORTANT]

+ > Self-signed certificates are suitable only for test purposes. In production environments, we strongly recommend that you use certificates issued by a certificate authority instead.

+- Set the certificate:

+ You can use the following PowerShell cmdlet to assign the certificate to the web application:

+ ```powershell

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

+ ```

+## Step 6: Create the site collection

+In this step, you create a team site collection with two administrators: One as a Windows administrator and one as a federated (AD FS) administrator.

+1. Open the SharePoint Central Administration site.

+2. Navigate to **Application Management** > **Create site collections**.

+3. Type a Title, URL, and select the template Team Site.

+4. In the **Primary Site Collection Administrator** section, select the book icon to open the People Picker dialog.

+5. In the People Picker dialog, type the Windows administrator account, for example **yvand**.

+6. Filter the list on the left by selecting **Organizations**. Following is a sample output:

+ :::image type="content" source="../media/select-people-3.png" alt-text="Select People 3":::

+7. Go to the account and select **OK**.

+8. In the **Secondary Site Collection Administrator** section, select the book icon to open the People Picker dialog.

+9. In the People Picker dialog, type the exact email value of the AD FS administrator account, for example **yvand@contoso.local**.

+10. Filter the list on the left by selecting **Contoso.local**. Following is a sample output:

+ :::image type="content" source="../media/select-people-4.png" alt-text="Select People 4":::

+11. Go to the account and select **OK**.

+12. Select **OK** to create the site collection.

+Once the site collection is created, you will be able to sign-in using either the Windows or the federated site collection administrator account.

+## Step 7: Set up People Picker

+In OIDC authentication, the People Picker doesn't validate the input, which can lead to misspellings or users accidentally selecting the wrong claim type. This can be addressed using the new UPA-backed claim provider in SharePoint Server.

+Perform the following steps to help People Picker validate the input using the new UPA-backed claim provider:

+### 1. Create a new claim provider

+In the [previous step](#step-3-configure-sharepoint-to-trust-the-identity-providers), you've already created an OIDC `SPTrustedIdentityTokenIssuer` by using `New-SPTrustedIdentityTokenIssuer` PowerShell cmdlet. In this step, you'll use the following PowerShell cmdlet to create a claim provider, which uses the User Profile Application service to search and resolve users and groups in the People Picker and specifies to use the OIDC `SPTrustedIdentityTokenIssuer`:

+ ```powershell

+ $claimprovider = New-SPClaimProvider -AssemblyName "Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, publicKeyToken=71e9bce111e9429c" -DisplayName 'OIDC Claim Provider' -Type "Microsoft.SharePoint.Administration.Claims.SPTrustedBackedByUPAClaimProvider" -TrustedTokenIssuer $tokenissuer -Description ΓÇ£OIDC Claim ProviderΓÇ¥ -Default:$false

+ ```

+Specify the following parameters:

+| Parameter | Description |

+||-|

+| AssemblyName | To be specified as `Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, publicKeyToken=71e9bce111e9429c`. |

+| Type | To be specified as `Microsoft.SharePoint.Administration.Claims.SPTrustedBackedByUPAClaimProvider` so that this command creates a claim provider, which uses UPA as the claim source. |

+| TrustedTokenIssuer | To be specified as the OIDC `SPTrustedIdentityTokenIssuer` created in the [previous step](#step-3-configure-sharepoint-to-trust-the-identity-providers), which will use this claim provider. This is a new parameter the user needs to provide when the type of the claim provider is `Microsoft.SharePoint.Administration.Claims.SPTrustedBackedByUPAClaimProvider`. |

+| Default | As we've created a claim provider by using this cmdlet, this cmdlet can only work with `SPTrustedIdentityTokenIssuer` and `Default` parameter must be set to false so that it wonΓÇÖt be used by any other authentication method assigned to the web application by default. |

+### 2. Connect `SPTrustedIdentityTokenIssuer` with `SPClaimProvider`

+In this step, the OIDC `SPTrustedIdentityTokenIssuer` uses the claim provider created in [step 1](#1-create-a-new-claim-provider) for searching and resolving users and groups:

+ ```powershell

+ Set-SPTrustedIdentityTokenIssuer <token issuer name> -ClaimProvider <claim provider object> -IsOpenIDConnect

+ ```

+Specify the following parameters:

+| Parameter | Description |

+||-|

+| token issuer name | The token issuer this People Picker will use. |

+| -ClaimProvider | The `SPClaimProvider`, which will be used to generate claim. |

+| -IsOpenIDConnect | Required when `SPTrustedIdentityTokenIssuer` is OIDC `SPTrustedIdentityTokenIssuer`. Without this parameter, OIDC `SPTrustedIdentityTokenIssuer` configuration will fail. |

+An example of this command is:

+ ```powershell

+ $claimprovider = Get-SPClaimProvider -Identity "UPATest"

+ Set-SPTrustedIdentityTokenIssuer "ADFS Provider" -ClaimProvider $claimprovider -IsOpenIDConnect

+ ```

+### 3. Synchronize profiles to user profile service application (UPSA)

+Now, customers can start to synchronize profiles into the SharePoint UPSA from the identity provider used in the organization so that the newly created claim provider can work on the correct data set.

+There are two ways to synchronize user profiles into the SharePoint UPSA:

+- Create a new SharePoint Active Directory Import (AD Import) connection with **Trusted Claims Provider Authentication** as the **Authentication Provider Type** in the connection setting. To utilize AD Import, see [Manage user profile synchronization in SharePoint Server](/sharepoint/administration/manage-profile-synchronization).

+ :::image type="content" source="../media/add-new-sync-connection-2.png" alt-text="Add New Synchronization Connections":::

+- Use Microsoft Identity Manager (MIM). To utilize MIM, see [Microsoft Identity Manager in SharePoint Servers 2016 and 2019](/sharepoint/administration/microsoft-identity-manager-in-sharepoint-server-2016).

+ - There should be two agents inside the MIM Synchronization Service Manager UX after MIM is set up. One agent is used to import user profiles from the source IDP to the MIM database. The other agent is used to export user profiles from the MIM database to the SharePoint UPSA.

+During the synchronization, the following three properties must be provided to the UPSA:

+- `SPS-ClaimID`

+- `SPS-ClaimProviderID`

+- `SPS-ClaimProviderType`

+ 1. `SPS-ClaimID`

+ During the synchronization, you must pick which unique identity property in the source will be mapped to the `SPS-ClaimID` property in the UPSA. We suggest using **Email** or **User Principal Name** for the `SPS-ClaimID`. The corresponding **IdentifierClaim** value needs to be set when token issuer is created from the [New-SPTrustedIdentityTokenIssuer](/powershell/module/sharepoint-server/new-sptrustedidentitytokenissuer) cmdlet.

+ For AD Import synchronization, **Central Administration > Application Management > Manage service applications > User Profile Service Application > Manage User Properties** will allow administrators to edit the `SPS-ClaimID` to indicate which property in the source identity provider should be synchronized to `SPS-ClaimID`. (The display name of this property is **Claim User Identifier** and it can be customized to other display names by the administrator.) For example, if email is to be used as the `SPS-ClaimID`, **Claim User Identifier** should be set to **Email**.

+ :::image type="content" source="../media/SPS-ClaimID-1.png" alt-text="SPS-ClaimID":::

+ :::image type="content" source="../media/SPS-ClaimID-2.png" alt-text="SPS-ClaimProviderID":::

+ :::image type="content" source="../media/SPS-ClaimID-3.png" alt-text="SPS-ClaimProviderType":::

+ MIM synchronization is done by mapping **Email** or **User Principal Name** to `SPS-ClaimID` in the MIM database to the SharePoint UPSA agent:

+ - In the MIM Synchronization Service Manager, select the agent and open the **Configure Attribute Flow**. You can map **mail** to `SPS-ClaimID`.

+ :::image type="content" source="../media/SPS-ClaimID-4.png" alt-text="SPS-ClaimID4":::

+ 2. `SPS-ClaimProviderID` and `SPS-ClaimProviderType`

+ For AD Import synchronization, these properties can be modified in **User Profile Service Application > Configure Synchronization Connections > Create New Connection** when you create a new AD Import synchronization connection.

+ - `SPS-ClaimProviderID` should be set to the provider name created in [step 1](#1-create-a-new-claim-provider) by the `New-SPClaimProvider` cmdlet.

+ - `SPS-ClaimProviderType` should be set to `SPTrustedBackedByUPAClaimProvider`.

+ For MIM synchronization, these properties can be set in the **Configure Attribute Flow** for the MIM database to SharePoint UPSA agent:

+ - `SPS-ClaimProviderType` should be set to **Trusted** as Constant type.

+ - `SPS-ClaimProviderID` should be set to the provider name created in [step 1](#1-create-a-new-claim-provider) by the `New-SPClaimProvider` cmdlet.

+ :::image type="content" source="../media/configure-attribute-flow-2.png" alt-text="Configure Attribute Flow":::

+### 4. Make groups searchable

+Perform the following steps to enable the People Picker control to work with groups:

+1. Group object must have a property named `SID` of type `groupid` in the identity provider.

+ You can create a `ClaimTypeMapping` object by using [New-SPClaimTypeMapping](/powershell/module/sharepoint-server/new-spclaimtypemapping) and then provide this object to [New-SPTrustedIdentityTokenIssuer](/powershell/module/sharepoint-server/new-sptrustedidentitytokenissuer) cmdlet with `-ClaimsMappings` parameter.

+ ```powershell

+ $sidClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid" -IncomingClaimTypeDisplayName "SID" -SameAsIncoming

+ $tokenissuer = New-SPTrustedIdentityTokenIssuer -ClaimsMappings $sidClaimMap, $emailClaimMap

+ ```

+ This sample cmdlet first creates a `claimmap` object of type `groupsid` and indicates that it works with the `SID` property of the group and then creates a new identity issuer, which can understand this mapping.

+2. Synchronize `SID` property of groups from the identity provider to the `SID` property in UPSA.

+ 1. For AD Import synchronization, `SID` will be synchronized automatically without additional setup from the source identity provider to the SharePoint UPSA.

+ 2. For MIM synchronization, the property mapping needs to be taken from the identity provider to MIM and then from MIM to the SharePoint UPSA so that MIM can synchronize the group `SID` from the identity provider to the SharePoint UPSA. This is similar to how we do user profile synchronization for the `SPS-ClaimID` property for user profiles.

+3. For MIM synchronization, `sAMAccountName` should also be mapped to `accountName` from MIM to the SharePoint UPSA. If it doesnΓÇÖt exist, admin should create mapping pair from `sAMAccountName` to `accountName` in MIM manually.

+### 5. Enable fields being searchable in UPSA

+To make People Picker work, the final step is to enable fields to be searchable in UPSA.

+Users can set which properties are searched by the People Picker by following this sample PowerShell script:

+ ```powershell

+ #Get the property list of UPSA connected with the web application

+ $site = $(Get-SPWebApplication $WebApplicationName).Sites[0]

+ $context= Get-SPServiceContext $site

+ $psm = [Microsoft.Office.Server.UserProfiles.ProfileSubTypeManager]::Get($context)

+ $ps =

+ $psm.GetProfileSubtype([Microsoft.Office.Server.UserProfiles.ProfileSubtypeManager]::GetDefaultProfileName([Microsoft.Office.Server.UserProfiles.ProfileType]::User))

+ $properties = $ps.Properties

+ #Enable people picker search for property name 'FistName', 'LastName' and 'SPS-ClaimID'

+ $PropertyNames = 'FirstName', 'LastName', 'SPS-ClaimID'

+ foreach ($p in $PropertyNames) {

+ $property = $properties.GetPropertyByName($p)

+ if ($property) {

+ $property.CoreProperty.IsPeoplePickerSearchable = $true

+ $property.CoreProperty.Commit()

+ $property.Commit()

+ }

+ }

+ ```

+ Title: "Set up OIDC authentication in SharePoint Server with Microsoft Azure Active Directory (Azure AD)"

+audience: ITPro

+f1.keywords:

+- NOCSH

+localization_priority: Normal

+ms.assetid: 5cdce2aa-fa6e-4888-a34f-de61713f5096

+description: "Learn how to set up OIDC authentication in SharePoint Server with Microsoft Azure Active Directory (Azure AD)."

+# Set up OIDC authentication in SharePoint Server with Microsoft Azure Active Directory (Azure AD)

+## Prerequisites

+When you configure OIDC with Azure AD, you need the following resources:

+1. A SharePoint Server Subscription Edition farm

+2. Azure AD Global Administrator role of the M365 tenant

+This article uses the following example values for Azure AD OIDC setup:

+| Value | Link |

+|||

+| SharePoint site Uniform Resource Locator (URL) | `https://spsites.contoso.local/` |

+| OIDC site URL | `https://sts.windows.net/<tenantid>/` |

+| Azure AD OIDC authentication endpoint | `https://login.microsoftonline.com/<tenantid>/oauth2/authorize` |

+| Azure AD OIDC RegisteredIssuerName URL | `https://sts.windows.net/<tenantid>/` |

+| Azure AD OIDC SignoutURL | `https://login.microsoftonline.com/<tenantid>/oauth2/logout` |

+| Identity claim type | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` |

+| Windows site collection administrator | contoso\yvand |

+| Email value of the federated site collection administrator | yvand@contoso.local |

+## Step 1: Setup identity provider

+Perform the following steps to set up OIDC with Azure AD:

+1. Select **New Registration**.

+2. Go to the **Register an application** page `https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps`.

+3. Enter the following value for **Redirect URL**: `https://spsites.contoso.local/` and select **Register**.

+ :::image type="content" source="../media/register-an-app.PNG" alt-text="Register an application":::

+4. Save **Directory (tenant) ID** as the tenant ID we'll use in future and save **Application (client) ID** which we'll use as **DefaultClientIdentifier** in SharePoint setup.

+ :::image type="content" source="../media/sharepoint-onprem-oidc-connection.png" alt-text="Save Application":::

+5. After you register the application, go to the **Authentication** tab, enable **ID tokens** and select **Save**.

+ :::image type="content" source="../media/sharepoint-oidc-authentication.png" alt-text="Enable ID Tokens":::

+6. Go to the **API permissions** tab and add **email** and **profile** permissions.

+ :::image type="content" source="../media/sharepoint-oidc-api-permissions.png" alt-text="API Permissions":::

+7. Go to the **Token configuration** tab and add **email**, **groups** and **upn** optional claims.

+ :::image type="content" source="../media/sharepoint-oidc-token-configuration.png" alt-text="Token Configuration":::

+8. Go to the **Manifest** tab, and manually change **replyUrlsWithType** from `https://spsites.contoso.local/` to `https://spsites.contoso.local/*`. Then select **Save**.

+ :::image type="content" source="../media/sharepoint-oidc-manifest.png" alt-text="Manifest":::

+9. Get OIDC authentication information from OIDC discovery endpoint.

+In Azure AD, there are two versions of OIDC authentication endpoints. Therefore, there are two versions of OIDC discovery endpoints respectively:

+- V1.0: `https://login.microsoftonline.com/<TenantID>/.well-known/openid-configuration`

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

+> [!NOTE]

+> For OIDC authentication, both endpoints are supported but we recommend using V2.0.

+Replace TenantID with the **Directory (tenant) ID** saved in the third step mentioned previously and connect to the endpoint through your browser. Then, save the following information:

+| Value | Link |

+|||

+| authorization_endpoint | `https://login.microsoftonline.com/<tenantid>/oauth2/authorize` |

+| end_session_endpoint | `https://login.microsoftonline.com/<tenantid>/oauth2/logout` |

+| issuer | `https://sts.windows.net/<tenantid>/` |

+| jwks_uri | `https://login.microsoftonline.com/common/discovery/keys` |

+Open jwks_uri (`https://login.microsoftonline.com/common/discovery/keys`) and save the **x5c** certificate string of the first key for later use in SharePoint setup (if the first key doesnΓÇÖt work, try the second or third key).

+## Step 2: Change SharePoint farm properties

+In this step, you'll need to modify SharePoint farm properties. Start the SharePoint Management Shell and run the following script:

+> [!NOTE]

+> Read the instructions mentioned in the following PowerShell script carefully.

+```powershell

+# Setup 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 certificate by Export-PfxCertificate and import certificate to all other SharePoint servers in the farm by Import-PfxCertificate.

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

+$path = "$env:ALLUSERSPROFILE\Microsoft\Crypto\RSA\MachineKeys\$fileName"

+$permissions = Get-Acl -Path $path

+#Please replace the <web application pool account> with 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 we update farm properties

+$f = Get-SPFarm

+$f.Farm.Properties['SP-NonceCookieCertificateThumbprint']=$cert.Thumbprint

+$f.Farm.Properties['SP-NonceCookieHMACSecretKey']='seed'

+$f.Farm.Update()

+```

+## Step 3: Configure SharePoint to trust the identity provider

+You can configure SharePoint to trust the identity provider in either of the following ways:

+- Configure SharePoint to trust Azure AD as the OIDC provider manually.

+- Configure SharePoint to trust Azure AD as the OIDC provider by using metadata endpoint.

+ - By using metadata endpoint, a lot of parameters you need in 'Configure SharePoint to trust Azure AD as the OIDC provider manually' can be automatically retrieved by metadata endpoint.

+### Configure SharePoint to trust Azure AD as the OIDC provider manually

+In this step, you create a `SPTrustedTokenIssuer` that will store the configuration that SharePoint needs to trust Azure AD OIDC as the OIDC provider. Start the SharePoint Management Shell and run the following script to create it:

+> [!NOTE]

+> Read the instructions mentioned in the following PowerShell script carefully.

+```powershell

+# Define claim types

+$email = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -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

+$encodedCertStr = <x5c cert string>

+$signingCert = 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 $signingCert -ClaimsMappings $email -IdentifierClaim $email.InputClaimType -RegisteredIssuerName $registeredissuernameurl -AuthorizationEndPointUri $authendpointurl -SignOutUrl $signouturl -DefaultClientIdentifier $clientIdentifier

+```

+Here, `New-SPTrustedIdentityTokenIssuer` PowerShell cmdlet is extended to support OIDC by using the following parameters:

+| Parameter | Description |

+||-|

+|Name | Gives a name to the new token issuer. |

+|Description | Gives a description to the new token issuer. |

+|ImportTrustCertificate | Imports a list of X509 Certificates, which will be used to validate `id_token` from OIDC identifier. If the OIDC identity provider (IDP) uses more than one certificate to digital sign the `id_token`, import these certificates and SharePoint will then validate `id_token` by matching the digital signature generated by using these certificates. |

+| ClaimsMappings | A `SPClaimTypeMapping` object, which will be used to identify which claim in the `id_token` will be regarded as identifier in SharePoint. |

+| IdentifierClaim | Specifies the type of identifier. |

+| RegisteredIssuerName | Specifies the issuer identifier, which issues the `id_token`. It will be used to validate the `id_token`. |

+| AuthorizationEndPointUrl | Specifies the authorization endpoint of the OIDC identity provider. |

+| SignoutUrl | Specifies the sign-out endpoint of the OIDC identity provider. |

+| DefaultClientIdentifier | Specifies the `client_id` of SharePoint server, which is assigned by OIDC identity provider. This will be validated against aud claim in `id_token`. |

+| ResponseTypesSupported | Specifies the response type of IDP, which can be accepted by this token issuer. It can accept two strings: `id_token` and `code id_token`. If this parameter isn't provided, it will use `code id_token` as default. |

+> [!IMPORTANT]

+> The relevant certificate must be added to the SharePoint root authority certificate store:

+>

+> `New-SPTrustedRootAuthority -Name "AAD OIDC signing root authority" -Certificate $signingCert`

+### Configure SharePoint to trust Azure AD OIDC by using metadata endpoint

+SharePoint Server Subscription Edition now supports OIDC metadata discovery capability during configuration.

+By using the metadata endpoint provided by the OIDC identity provider, some of the configuration will be retrieved from the OIDC provider metadata endpoint directly, including:

+1. Certificate

+2. Issuer

+3. Authorization Endpoint

+4. SignoutURL

+This can simplify the configuration of the OIDC token issuer.

+With the following PowerShell example, we can use metadata endpoint from Azure AD to configure SharePoint to trust Azure AD OIDC.

+> [!NOTE]

+> Read the instructions mentioned in the following PowerShell script carefully.

+```powershell

+# Define claim types

+$email = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

+# Set the AAD metadata endpoint URL. Please replace <TenantID> with the value saved in step #3 in AAD 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 AAD setup section

+$clientIdentifier = <Application (Client)ID>

+# Create a new SPTrustedIdentityTokenIssuer in SharePoint

+New-SPTrustedIdentityTokenIssuer -Name "contoso.local" -Description "contoso.local" -ClaimsMappings $email -IdentifierClaim $email.InputClaimType -DefaultClientIdentifier $clientIdentifier -MetadataEndPoint $ metadataendpointurl

+```

+| Parameter | Description |

+||-|

+|Name | Gives a name to the new token issuer. |

+|Description | Gives a description to the new token issuer. |

+|ImportTrustCertificate | A certificate that will be used to validate `id_token` from OIDC identifier. |

+| ClaimsMappings | A `SPClaimTypeMapping` object, which will be used to identify which claim in the `id_token` will be regarded as identifier in SharePoint. |

+| IdentifierClaim | Specifies the type of identifier. |

+| DefaultClientIdentifier | Specifies the `client_id` of SharePoint server, which is assigned by OIDC identity provider. This will be validated against aud claim in `id_token`. |

+| MetadataEndPoint | Specifies the well-known metadata endpoint from OIDC identity provider, which can be used to retrieve latest certificate, issuer, authorization endpoint, and sign out endpoint. |

+## Step 4: Configure the SharePoint web application

+In this step, you'll configure a web application in SharePoint to be federated with the Azure AD OIDC, using the `SPTrustedIdentityTokenIssuer` created in the previous step.

+> [!IMPORTANT]

+>

+> - The default zone of the SharePoint web application must have Windows authentication enabled. This is required for the search crawler.

+> - The SharePoint URL that will use AAD OIDC federation must be configured with Hypertext Transfer Protocol Secure (HTTPS).

+You can do this configuration either by:

+- Creating a new web application and using both Windows and Azure AD OIDC authentication in the default zone.

+- Extending an existing web application to set Active Directory Federation Services (AD FS)/AAD OIDC authentication on a new zone.

+To create a new web application, do the following:

+ 1. Start the SharePoint Management Shell and run the following script to create a new `SPAuthenticationProvider`:

+ ```powershell

+ # This script creates a trusted authentication provider for OIDC

+

+ $sptrust = Get-SPTrustedIdentityTokenIssuer "contoso.local"

+ $trustedAp = New-SPAuthenticationProvider -TrustedIdentityTokenIssuer $sptrust

+ ```

+ 2. Follow [Create a web application in SharePoint Server](/sharepoint/administration/create-a-web-application) to create a new web application enabling HTTPS/Secure Sockets Layer (SSL) named SharePoint - OIDC on contoso.local.

+ 3. Open the SharePoint Central Administration site.

+ 4. Open the web application you created and pick **contoso.local** as **Trusted Identity Provider**.

+ :::image type="content" source="../media/authentication-providers.jpg" alt-text="Authentication Providers":::

+ 5. In the SharePoint Central Administration site, navigate to **System Settings** > **Configure Alternate Access Mappings** > **Alternate Access Mapping Collection**.

+ 6. Filter the display with the new web application and confirm that you see the following information:

+ :::image type="content" source="../media/new-web-application.png" alt-text="New web application":::

+To extend an existing web application, do the following:

+ 1. Start the SharePoint Management Shell and run the following script:

+ ```powershell

+ # This script creates a trusted authentication provider for OIDC

+

+ $sptrust = Get-SPTrustedIdentityTokenIssuer "Contoso.local"

+ $ap = New-SPAuthenticationProvider -TrustedIdentityTokenIssuer $sptrust

+ ```

+ 2. Open the SharePoint Central Administration site.

+ 3. Open the web application you want to extend OIDC authentication to and pick **contoso.local** as **Trusted Identity Provider**.

+ :::image type="content" source="../media/authentication-providers-2.jpg" alt-text="Authentication Providers 2":::

+ 4. In the SharePoint Central Administration site, navigate to **System Settings** > **Configure Alternate Access Mappings** > **Alternate Access Mapping Collection**.

+ 5. Filter the display with the web application that was extended and confirm that you see the following information:

+ :::image type="content" source="../media/sharepoint-administration-site.png" alt-text="SharePoint Administration Site":::

+## Step 5: Ensure the web application is configured with SSL certificate

+Since OIDC 1.0 authentication can only work with HTTPS protocol, a certificate must be set on the corresponding web application. Perform the following steps to set the certificate:

+1. Generate the site certificate:

+ > [!NOTE]

+ > You may skip this step if you have already generated the certificate.

+ 1. Open the SharePoint PowerShell console.

+ 2. Run the following script to generate a self-signed certificate and add it to the SharePoint farm:

+ ```powershell

+ 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

+ ```

+ > [!IMPORTANT]

+ > Self-signed certificates are suitable only for test purposes. In production environments, we strongly recommend that you use certificates issued by a certificate authority instead.

+2. Set the certificate:

+ You can use the following PowerShell cmdlet to assign the certificate to the web application:

+ ```powershell

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

+ ```

+## Step 6: Create the site collection

+In this step, you'll create a team site collection with two administrators: One as a Windows administrator and one as a federated (Azure AD) administrator.

+1. Open the SharePoint Central Administration site.

+2. Navigate to **Application Management** > **Create site collections** > **Create site collections**.

+3. Type a title, URL, and select the template Team Site.

+4. In the **Primary Site Collection Administrator** section, select the :::image type="content" source="../media/Book-icon.png" alt-text="Book Icon People Picker"::: (book) icon to open the People Picker dialog.

+5. In the People Picker dialog, type the Windows administrator account, for example **yvand**.

+6. Filter the list on the left by selecting **Organizations**. Following is a sample output:

+ :::image type="content" source="../media/select-people.png" alt-text="Select people":::

+7. Go to the account and select **OK**.

+8. In the **Secondary Site Collection Administrator** section, select the book icon to open the People Picker dialog.

+9. In the People Picker dialog, type the exact email value of the Azure AD administrator account, for example **yvand@contoso.local**.

+10. Filter the list on the left by selecting **contoso.local**. Following is a sample output:

+ :::image type="content" source="../media/select-people-2.png" alt-text="Select people 2":::

+11. Go to the account and select **OK** to close the People Picker dialog.

+12. Select **OK** again to create the site collection.

+Once the site collection is created, you will be able to sign-in using either the Windows or the federated site collection administrator account.

+## Step 7: Set up People Picker

+In OIDC authentication, the People Picker doesn't validate the input, which can lead to misspellings or users accidentally selecting the wrong claim type. This can be addressed using the new UPA-backed claim provider in SharePoint Server.

+To do this, perform the following steps:

+### 1. Create a new claim provider

+In the [previous step](#step-3-configure-sharepoint-to-trust-the-identity-provider), you've already created an OIDC `SPTrustedIdentityTokenIssuer` by using `New-SPTrustedIdentityTokenIssuer` PowerShell cmdlet. In this step, you'll use the following PowerShell cmdlet to create a claim provider, which uses the User Profile Application service to search and resolve users and groups in the People Picker and specifies to use the OIDC `SPTrustedIdentityTokenIssuer`:

+ ```powershell

+ $claimprovider = New-SPClaimProvider -AssemblyName "Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, publicKeyToken=71e9bce111e9429c" -DisplayName 'OIDC Claim Provider' -Type "Microsoft.SharePoint.Administration.Claims.SPTrustedBackedByUPAClaimProvider" -TrustedTokenIssuer $tokenissuer -Description ΓÇ£OIDC Claim ProviderΓÇ¥ -Default:$false

+ ```

+Specify the following parameters:

+| Parameter | Description |

+||-|

+| AssemblyName | To be specified as `Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, publicKeyToken=71e9bce111e9429c`. |

+| Type | To be specified as `Microsoft.SharePoint.Administration.Claims.SPTrustedBackedByUPAClaimProvider` so that this command creates a claim provider, which uses UPA as the claim source. |

+| TrustedTokenIssuer | To be specified as the OIDC `SPTrustedIdentityTokenIssuer` created in the [previous step](#step-3-configure-sharepoint-to-trust-the-identity-provider), which will use this claim provider. This is a new parameter the user needs to provide when the type of the claim provider is `Microsoft.SharePoint.Administration.Claims.SPTrustedBackedByUPAClaimProvider`. |

+| Default | As we've created a claim provider by using this cmdlet, this cmdlet can only work with `SPTrustedIdentityTokenIssuer` and `Default` parameter must be set to false so that it wonΓÇÖt be used by any other authentication method assigned to the web application by default. |

+### 2. Connect `SPTrustedIdentityTokenIssuer` with `SPClaimProvider`

+In this step, the OIDC `SPTrustedIdentityTokenIssuer` uses the claim provider created in [step 1](#1-create-a-new-claim-provider) for searching and resolving users and groups:

+ ```powershell

+ Set-SPTrustedIdentityTokenIssuer <token issuer name> -ClaimProvider <claim provider object> -IsOpenIDConnect

+ ```

+Specify the following parameters:

+| Parameter | Description |

+||-|

+| token issuer name | The token issuer this People Picker will use. |

+| -ClaimProvider | The `SPClaimProvider`, which will be used to generate claim. |

+| -IsOpenIDConnect | Required when `SPTrustedIdentityTokenIssuer` is OIDC `SPTrustedIdentityTokenIssuer`. Without this parameter, OIDC `SPTrustedIdentityTokenIssuer` configuration will fail. |

+An example of this command is:

+ ```powershell

+ $claimprovider = Get-SPClaimProvider -Identity "UPATest"

+ Set-SPTrustedIdentityTokenIssuer "ADFS Provider" -ClaimProvider $claimprovider -IsOpenIDConnect

+ ```

+### 3. Synchronize profiles to user profile service application

+Now, customers can start to synchronize profiles into the SharePoint user profile service application (UPSA) from the identity provider used in the organization so that the newly created claim provider can work on the correct data set.

+There are two ways to synchronize user profiles into the SharePoint UPSA:

+- Create a new SharePoint Active Directory Import (AD Import) connection with **Trusted Claims Provider Authentication** as the **Authentication Provider Type** in the connection setting. To utilize AD Import, see [Manage user profile synchronization in SharePoint Server](/sharepoint/administration/manage-profile-synchronization).

+ :::image type="content" source="../media/add-new-sync-connection-2.png" alt-text="Add New Synchronization Connections":::

+- Use Microsoft Identity Manager (MIM). To utilize MIM, see [Microsoft Identity Manager in SharePoint Servers 2016 and 2019](/sharepoint/administration/microsoft-identity-manager-in-sharepoint-server-2016).

+ - There should be two agents inside the MIM Synchronization Service Manager UX after MIM is set up. One agent is used to import user profiles from the source IDP to the MIM database. The other agent is used to export user profiles from the MIM database to the SharePoint UPSA.

+During the synchronization, the following three properties must be provided to the UPSA:

+- `SPS-ClaimID`

+- `SPS-ClaimProviderID`

+- `SPS-ClaimProviderType`

+ 1. `SPS-ClaimID`

+ During the synchronization, you must pick which unique identity property in the source will be mapped to the `SPS-ClaimID` property in the UPSA. We suggest using **Email** or **User Principal Name** for the `SPS-ClaimID`. The corresponding **IdentifierClaim** value needs to be set when token issuer is created from the [New-SPTrustedIdentityTokenIssuer](/powershell/module/sharepoint-server/new-sptrustedidentitytokenissuer) cmdlet.

+ For AD Import synchronization, **Central Administration > Application Management > Manage service applications > User Profile Service Application > Manage User Properties** will allow administrators to edit the `SPS-ClaimID` to indicate which property in the source identity provider should be synchronized to `SPS-ClaimID`. (The display name of this property is **Claim User Identifier** and it can be customized to other display names by the administrator.) For example, if email is to be used as the `SPS-ClaimID`, **Claim User Identifier** should be set to **Email**.

+ :::image type="content" source="../media/SPS-ClaimID-1.png" alt-text="SPS-ClaimID":::

+ :::image type="content" source="../media/SPS-ClaimID-2.png" alt-text="SPS-ClaimProviderID":::

+ :::image type="content" source="../media/SPS-ClaimID-3.png" alt-text="SPS-ClaimProviderType":::

+ MIM synchronization is done by mapping **Email** or **User Principal Name** to `SPS-ClaimID` in the MIM database to the SharePoint UPSA agent:

+ - In the MIM Synchronization Service Manager, select the agent and open the **Configure Attribute Flow**. You can map **mail** to `SPS-ClaimID`.

+ :::image type="content" source="../media/SPS-ClaimID-4.png" alt-text="SPS-ClaimID4":::

+ 2. `SPS-ClaimProviderID` and `SPS-ClaimProviderType`

+ For AD Import synchronization, these properties can be modified in **User Profile Service Application > Configure Synchronization Connections > Create New Connection** when you create a new AD Import synchronization connection.

+ - `SPS-ClaimProviderID` should be set to the provider name created in [step 1](#1-create-a-new-claim-provider) by the `New-SPClaimProvider` cmdlet.

+ - `SPS-ClaimProviderType` should be set to `SPTrustedBackedByUPAClaimProvider`.

+ For MIM synchronization, these properties can be set in the **Configure Attribute Flow** for the MIM database to SharePoint UPSA agent:

+ - `SPS-ClaimProviderType` should be set to **Trusted** as Constant type.

+ - `SPS-ClaimProviderID` should be set to the provider name created in [step 1](#1-create-a-new-claim-provider) by the `New-SPClaimProvider` cmdlet.

+ :::image type="content" source="../media/configure-attribute-flow-2.png" alt-text="Configure Attribute Flow":::

+### 4. Make groups searchable

+Perform the following steps to enable the People Picker control to work with groups:

+1. Group object must have a property named `SID` of type `groupid` in the identity provider.

+ You can create a `ClaimTypeMapping` object by using [New-SPClaimTypeMapping](/powershell/module/sharepoint-server/new-spclaimtypemapping) and then provide this object to [New-SPTrustedIdentityTokenIssuer](/powershell/module/sharepoint-server/new-sptrustedidentitytokenissuer) cmdlet with `-ClaimsMappings` parameter.

+ ```powershell

+ $sidClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid" -IncomingClaimTypeDisplayName "SID" -SameAsIncoming

+ $tokenissuer = New-SPTrustedIdentityTokenIssuer -ClaimsMappings $sidClaimMap, $emailClaimMap

+ ```

+ This sample cmdlet first creates a `claimmap` object of type `groupsid` and indicates that it works with the `SID` property of the group and then creates a new identity issuer, which can understand this mapping.

+2. Synchronize `SID` property of groups from the identity provider to the `SID` property in UPSA.

+ 1. For AD Import synchronization, `SID` will be synchronized automatically without additional setup from the source identity provider to the SharePoint UPSA.

+ 2. For MIM synchronization, the property mapping needs to be taken from the identity provider to MIM and then from MIM to the SharePoint UPSA so that MIM can synchronize the group `SID` from the identity provider to the SharePoint UPSA. This is similar to how we do user profile synchronization for the `SPS-ClaimID` property for user profiles.

+3. For MIM synchronization, `sAMAccountName` should also be mapped to `accountName` from MIM to the SharePoint UPSA. If it doesnΓÇÖt exist, admin should create mapping pair from `sAMAccountName` to `accountName` in MIM manually.

+### 5. Enable fields being searchable in UPSA

+To make People Picker work, the final step is to enable fields to be searchable in UPSA.

+Users can set which properties are searched by the People Picker by following this sample PowerShell script:

+ ```powershell

+ #Get the property list of UPSA connected with the web application

+ $site = $(Get-SPWebApplication $WebApplicationName).Sites[0]

+ $context= Get-SPServiceContext $site

+ $psm = [Microsoft.Office.Server.UserProfiles.ProfileSubTypeManager]::Get($context)

+ $ps =

+ $psm.GetProfileSubtype([Microsoft.Office.Server.UserProfiles.ProfileSubtypeManager]::GetDefaultProfileName([Microsoft.Office.Server.UserProfiles.ProfileType]::User))

+ $properties = $ps.Properties

+ #Enable people picker search for property name 'FistName', 'LastName' and 'SPS-ClaimID'

+ $PropertyNames = 'FirstName', 'LastName', 'SPS-ClaimID'

+ foreach ($p in $PropertyNames) {

+ $property = $properties.GetPropertyByName($p)

+ if ($property) {

+ $property.CoreProperty.IsPeoplePickerSearchable = $true

+ $property.CoreProperty.Commit()

+ $property.Commit()

+ }

+ }

+ ```

+ Title: "Plan for Microsoft OneDrive in Microsoft 365 or SharePoint Server"

+description: "Learn about things you need to consider when planning to set up Microsoft OneDrive in a SharePoint Server on-premises environment."

+# Plan for Microsoft OneDrive in Microsoft 365 or SharePoint Server

+One of the first planning considerations you should make is if you truly want to use Microsoft OneDrive in SharePoint Server, or if you would be better suited to use Microsoft OneDrive. Many companies select to use Microsoft OneDrive in an on-premises environment due to industry restrictions (for example, finance or government), or business rules that prohibit transmitting their data over the Internet. If your company isn't restricted by either, you should also explore the possibility of using Microsoft OneDrive. The key benefits in using Microsoft OneDrive are that you only need an internet connection to use it, versus being connected to your network, and that user storage is provided by your Microsoft 365 service.

+## Set up OneDrive

+To make Microsoft OneDrive in SharePoint Server available to your users, you need to configure the following services in SharePoint Server Central Administration:

+> For detailed info about how to set up each service as required for Microsoft OneDrive, see [Set up OneDrive in a SharePoint Server on-premises environment](set-up-onedrive-for-business.md).

+## Use of OneDrive sync app

+The Microsoft OneDrive [sync apps](https://go.microsoft.com/fwlink/?LinkId=522308) give users the convenience of local storage of their files. Sync apps also enable users to take documents offline. Users then can use those documents when they're disconnected from SharePoint Server. Later, when the client computer or device reconnects to SharePoint Server, the files are synchronized.

+In a SharePoint Server on-premises environment, you may have the option to save directly to your document library (for example, from Office 2016), which is where files are synchronized from your Microsoft OneDrive local folder anyway. When the Microsoft OneDrive sync app is used in an on-premises environment, its primary benefit is for synchronizing files on laptops that are used while disconnected from your corporate network at times, such as when traveling.

+The sync app also provides your users the added convenience of working with files directly from the local Microsoft OneDrive sync folder. Work with and saving your files directly in the folder is more convenient than opening your My Sites document library.

+> Use the [previous OneDrive for Business sync app _Groove.exe_](/onedrive/install-previous-sync-app.md) to sync files in SharePoint Server 2016 or earlier. The new OneDrive sync app OneDrive.exe is supported in SharePoint Server Subscription Edition and 2019. For more information, see [configure-syncing-with-the-onedrive-sync-app](../install/configure-syncing-with-the-onedrive-sync-app.md).

+Stopping a synchronization and starting a new one to the same Microsoft OneDrive library won't cause the loss of any data in the Microsoft OneDrive library. But users must re-synchronize all files to their local computer or device. This process may take some time and shouldn't be interrupted.

+There are several situations in which Microsoft OneDrive sync apps can cause unusually high network bandwidth usage:

+- When you first roll out Microsoft OneDrive and users are synchronizing all of their files for the first time.

+Sync apps use the `http://` or `https://` protocol of the site that they're synchronizing with to transfer data. If the Microsoft OneDrive site uses a Transport Layer Security (TLS) connection `https://`, then the data being transferred by the sync app is encrypted; otherwise, it's not.

+Microsoft 365 uses TLS for Microsoft OneDrive connections by default. If you're using SharePoint Server, it's recommended to configure your My Site host to use TLS for any connections that will occur outside your corporate domain. If you're using Active Directory directory services, you can configure the Group Policy setting **Sync Only On Domain Network**. The setting requires a TLS connection for Microsoft OneDrive clients that connect to SharePoint Server from outside the organization's Intranet.

+Once a document library is synchronized with a computer or mobile device, the files continue to exist there. The files remain on the computer or device even if the user's My Site and their user account are deleted. In this situation, although the files remain on the computer or device, the user can't synchronize the files with SharePoint Server again.

+## Move to a hybrid environment

+At a later time, you might be using Microsoft OneDrive for various reasons, such as keeping your on-premises sites and customizations in their current state, but offloading the personal storage aspect of it to the cloud. This can also provide your users access to their business files while they're not connected to the corporate network.

+## Upgrade from older to newer version of Microsoft OneDrive in SharePoint Server

+If you are using the older version of Microsoft OneDrive in SharePoint Server, then you can upgrade to the newer version of Microsoft OneDrive in SharePoint Server as part of the upgrade process. You can do this as part of the process to upgrade your My Sites Host site collection, which provides you with an option to upgrade the My Sites personal site collections, which are used to store your Microsoft OneDrive user files.

+Fast site creation in SharePoint Server 2019 allows users to create new sites in a few seconds. Fast site creation is only supported with the following site templates:

+SharePoint Server 2019 brings cloud closer to the Customers and Customers closer to the cloud. The cloud features Power Apps, Power BI, and Power Automate are now available. SharePoint Server 2019 includes process automation and forms technologies like Power Apps and Power Automate to connect with your on-premises data. These features need to be configured via gateway.

+Users can use the new OneDrive sync app (OneDrive.exe) instead of the previous OneDrive sync app (Groove.exe) to sync files in your SharePoint Server 2019 team sites and personal sites with your devices. The new OneDrive sync app supports advanced features such as Files On-Demand, push notification, and IRM protection, while still being easy to use. For more information, see [configure-syncing-with-the-onedrive-sync-app](../install/configure-syncing-with-the-onedrive-sync-app.md).