Okta Microsoft SharePoint On- Premises Deployment Guide

Transcription

1 Okta Microsoft SharePoint On- Premises Deployment Guide Okta Inc. 301 Brannan Street, 3rd Floor San Francisco CA,

2 Version History Date AD Agent Version Document Version April 2014 May 2014 SharePoint Foundation 2010, SharePoint Server 2010, and SharePoint 2013 SharePoint Foundation 2010, SharePoint Server 2010, and SharePoint Copyright 2014 Okta, Inc. All Rights Reserved. Window captures and dialog box sample views are the copyright of their respective owners. Use of this user documentation is subject to the terms and conditions of the applicable End- User License Agreement. Copyright 2014 Okta, Inc. All Rights Reserved. 1

3 Contents SharePoint Overview... 3 Claims Authentication Provider... 3 About Realms (Relying Party Trust Identifier)... 3 Okta People Picker... 4 Claims to Windows Token Service (C2WTS)... 4 Setting Up Microsoft SharePoint with Okta... 4 Before You Begin... 4 Adding the SharePoint (On-Premises) App in Okta... 5 Configuring Okta as a Claims Provider in SharePoint... 6 About the People Picker... 8 Setting Up the People Picker... 8 Configuring the People Picker... 8 Deploying the People Picker... 9 Uploading the Okta Certificate (People Picker) SharePoint 2010 ONLY Troubleshooting the People Picker Uninstalling the People Picker Uninstalling Okta Authentication Upgrading the Okta Claims Provider or People Picker Deployment Scenarios Single Authentication Provider Mixed Authentication Provider SharePoint with Okta and Windows Authentication Multiple Web Applications and Zones Hiding People Picker Restricting People Picker to a Certain Group in Active Directory Okta Claims Authentication with Multiple SharePoint Applications (SSO) Troubleshooting Appendix: Import the Security Certificate into SharePoint 2010 Trusted Root Certificate Authority Copyright 2014 Okta, Inc. All Rights Reserved. 2

4 SharePoint Overview Microsoft SharePoint collaboration software provides enterprise-scale capabilities to meet businesscritical needs such as managing content and business processes, simplifying how people find and share information across boundaries, and enabling users to make informed decisions. Using the collaboration features of Microsoft SharePoint Foundation or Microsoft SharePoint Server, you can enable your users to create, manage, and easily build SharePoint sites that are discoverable throughout your organizations. For detailed information about Microsoft SharePoint and Microsoft authentication, see Microsoft's SharePoint Authentication Guides for SharePoint Foundation 2010, SharePoint Server 2010, and SharePoint Claims Authentication Provider In addition to traditional Windows Authentication, Microsoft SharePoint also supports running in claims authentication mode. A key benefit of claims authentication is the ability to provide authenticated access to external entities from your organization. It also enables multiple authentication types in a single SharePoint zone. Access to SharePoint running in Claims Mode Authentication uses a Security Token Service (STS), which is essentially an authentication gateway to SharePoint that enables access for Integrated Windows Authentication (IWA), form-based authentication, and trusted claims providers. This layer or gate requires credentials, and upon successful evaluation, transitions to claims-based access with WS-Federation. In a claims model, SharePoint accepts one or more claims about an authenticating client to identify and authorize the client. The claims come in the form of SAML tokens and are simply facts about the client stated by a trusted authority. In SAML claims mode, SharePoint accepts SAML tokens from a trusted external STS, often known as a claims provider (like Okta). SharePoint accepts and processes these tokens, augmenting the claims and creating a claims identity object for the user. For more information about claims-based authentication, refer to the following resources: Claims- based Identity in Windows (White Paper) Windows Identity Foundation About Realms (Relying Party Trust Identifier) When configuring SharePoint for claims- based authentication or authorization, Microsoft SharePoint typically must connect to an identity provider (Okta) to retrieve user attributes as claims. To realize all the benefits of claims in an enterprise environment, administrators must make sure that SharePoint trusts the claims it receives. This often means configuring SharePoint to connect to a trusted identity provider like Okta. Okta retrieves user attributes from Active Directory (or another LDAP directory or data store), wraps them in a SAML token, digitally signs that token, and returns it to the calling application, which is part of a realm. The realm is associated with a web application and is how Okta maps the sign- in request to the relying party trusts. Copyright 2014 Okta, Inc. All Rights Reserved. 3

5 Okta People Picker Okta offers a SharePoint People Picker control to find and select native Okta users, groups, and claims when a site, list, or library owner assigns permissions in Microsoft SharePoint. SharePoint integrates with Okta using the Okta API. The Okta Create API enables administrators to manage permissions for native Okta users and groups in SharePoint. Administrators define access rules to the SharePoint site and can also filter and restrict the results that are displayed when a user searches for a user, group, or claim. These settings are applied to every site within the site collection. For example, administrators can grant access to users who match a certain address or who are part of an AD or Okta group. For more information, refer to People Picker and claims provider planning (SharePoint Server 2010) or People Picker and claims providers overview (SharePoint 2013) Claims to Windows Token Service (C2WTS) Enterprise SharePoint deployments can use backend components like SQL Server Reporting Services or a Server Message Block (SMB) file server with SharePoint. These backend services depend on Windows Authentication and require protocol transition from claims-based authentication Okta SSO to Windows Authentication. Okta s SharePoint solution enables this protocol transition using Kerberos Constrained Delegation and S4U. For more information on C2WTS, refer to the following resources: C2WTS Overview Configuring C2WTS Kerberos Constrained Delegation Note that C2WTS has additional requirements: Microsoft only enables C2WTS for SharePoint farm deployments single server SharePoint deployments with embedded MS SQL Server Express are not supported. SharePoint 2013 or later. Setting Up Microsoft SharePoint with Okta Before You Begin Install a supported version of Microsoft SharePoint o o SharePoint Foundation 2010, SharePoint Server 2010, SharePoint Foundation 2013, or SharePoint Server Make sure to run the prerequisites from the SharePoint installer. o Install.NET Framework o Make sure hardware requirements are met before starting the installation. Copyright 2014 Okta, Inc. All Rights Reserved. 4

6 Make sure your Okta org has the API feature enabled (contact support), then create a valid API token issued to a read- only administrator. The API token is required by Okta s People Picker plugin to read users and groups from Okta. Note that the token is only visible upon creation and cannot be retrieved later. If the token is lost, it must be revoked, regenerated, and reconfigured in the People Picker configuration. Okta highly recommends that you install the People Picker plugin in the SharePoint environment. The plugin makes it easy for administrators to manage claims into SharePoint. Adding the SharePoint (On- Premises) App in Okta To enable SharePoint (On- Premises) for Okta: 1. Add the SharePoint (On-Prem) application. Note: The SharePoint (On-Prem) app is a private app and must be enabled for each Okta org by Okta support. 2. The following fields are used to connect and send information as part of the SAML assertion to SharePoint. a. SharePoint Web Application URL: Points to the web application that is running on SharePoint, Copyright 2014 Okta, Inc. All Rights Reserved. 5

7 for example, There can be multiple apps running on SharePoint, each of which needs a SharePoint app within Okta. b. Application attributes or custom: This is a special case in which Okta can send information, like a title or city of employment, that you can use in SharePoint. You can use this information for auditing or logging purposes. This information is not used for authentication or authorizing apps in SharePoint. Okta typically sends UPN and as part of the assertion. c. Group filter: This field is sent as part of a SAML assertion. This is used for checking permissions in SharePoint. 3. Once the app has been installed, follow the WS-Federation setup instructions on the Sign On tab to set up Okta as a trusted authentication provider in SharePoint. Click the View Setup Instructions button to auto generate the PowerShell script to enable Okta as a claims provider. 4. The PowerShell script provides step-by-step instructions to install and deploy the Okta Claims Provider. Configuring Okta as a Claims Provider in SharePoint The instructions generated by Okta provide step-by-step instructions to do the following: 1. Download and install the trusted root authority certificate. 2. Create the claims mapping in SharePoint. 3. Create Okta as a new authentication provider in SharePoint. 4. Configure the SharePoint web application to use Okta as an identity provider. 5. Add additional SharePoint web applications to use Okta as an identity provider. 6. Configure SharePoint to query for native Okta users and groups. Note that configuring Okta as a claims provider in SharePoint requires PowerShell command entry. Make sure that the installation steps are executed as a user with the proper permissions to modify the SharePoint farm (such as the SharePoint setup user account referenced here). The supplied PowerShell commands require the SharePoint PowerShell snap-in. Either launch the SharePoint management shell or add the required snap-in to an existing PowerShell prompt by entering the following command: Copyright 2014 Okta, Inc. All Rights Reserved. 6

8 Add-PSSnapIn Microsoft.Sharepoint.Powershell After you complete the installation procedure, Okta should appear in the Trusted Identity Provider list on the SharePoint Central Administration console. View the Trusted Identity Provider list by selecting Security > Specify Authentication Providers > Default zone. Make sure you disable the Okta Identity Provider whenever you install, uninstall, or update the Okta People Picker. See the following section for information on installing the Okta People Picker. Copyright 2014 Okta, Inc. All Rights Reserved. 7

9 About the People Picker Install the Okta SharePoint People Picker plugin so you can fetch users and groups from Okta. The People Picker plugin is a Microsoft Windows executable that you can download from the Downloads page of your Okta Administrator Dashboard. Setting Up the People Picker Configuring Okta as a claims provider in SharePoint requires PowerShell command entry. Ensure that the installation steps are executed as a user with the proper permissions to modify the SharePoint farm (such as the SharePoint setup user account). The supplied PowerShell commands require the SharePoint PowerShell snap-in. Launch the SharePoint Management Shell or add the required snap-in to an existing PowerShell prompt by entering the following the command: Add-PSSnapIn Microsoft.Sharepoint.Powershell Configuring the People Picker You must set several configuration values in the SharePoint farm to install the Okta People Picker. These values are used to configure People Picker functionality and define the Okta org that you are integrating with this SharePoint environment. Okta API Key: Read-only administrator API key generated during prerequisite steps. BaseUrl: Okta subdomain. OktaClaimProviderDisplayName: Set to Okta by default, but this can be set to a different value if you prefer a different display name for the Okta People Picker. MapUpnToWindowsUser: Configuration flag to enable or disable C2WTS protocol translation. Copyright 2014 Okta, Inc. All Rights Reserved. 8

10 Replace the variables below with the appropriate values as defined above and enter the following commands: $farm = Get-SPFarm $farm.properties["oktaapikey"] = "OktaAPIKey" $farm.properties["oktabaseurl"] = " oktaorg.okta.com" $farm.properties["oktaloginprovidername"] = "Okta" $farm.properties["oktaclaimproviderdisplayname"] = "Okta" If C2WTS is to be enabled, also execute the following command: $farm.properties["mapupntowindowsuser"] = $true Finally, enter the following command: $farm.update() Deploying the People Picker Install and deploy the Okta SharePoint People Picker claims provider solution to the SharePoint farm environment. The default installation steps outlined below activate the feature at the farm level: 1. Download the SharePoint 2010 or SharePoint 2013 People Picker from the Okta Downloads page. Enter the following PowerShell commands to add and install the Okta SharePoint solution for People Picker. Replace the LiteralPath command line argument below with the path to the downloaded People Picker WSP solution file, and update the identity command line argument with the appropriate version-based file name. Copyright 2014 Okta, Inc. All Rights Reserved. 9

11 Add-SPSolution -LiteralPath "C:\OktaClaimsProviderxx.xxx.wsp" Install-SPSolution -Identity "oktaclaimsproviderxx.xxx.wsp" GACDeployment It might take a few minutes for the solution to be installed and deployed. You can query your deployment status by entering the following PowerShell command: Get-SPSolution The status output reads Deployed after the solution has been deployed to the farm. If the status output continues to read Not deployed after a few minutes, then sign into the SharePoint Central Administration console, select System Settings > Manage Farm Solutions, and check for error messages. If necessary, cancel the deployment and restart it using the Central Administration Management Console. After you have added the People Picker, you can also install or deploy the solution using the SharePoint Central Administration Console. You can confirm the installation and troubleshoot any issues. We highly recommend that you use a ULS viewer during the People Picker installation procedure to help you diagnose configuration issues. 7. Assign the Okta Claims Provider that was configured during the Okta SSO configuration as the SPTrustedIdentityTokenIssuer for People Picker. If the SPTrustedIdentityTokenIssuer was named something other than Okta during the SSO configuration, update the commands below with the correct values. $trust = Get-SPTrustedIdentityTokenIssuer "Okta" $trust.claimprovidername = "OktaClaimsProvider" $trust.update() Copyright 2014 Okta, Inc. All Rights Reserved. 10

12 8. To validate the installation and configuration enter the following PowerShell command to retrieve the OktaClaimsProvider value: Get-SPClaimProvider Make sure the Okta provider is Enabled and configured as Default. Uploading the Okta Certificate (People Picker) SharePoint 2010 ONLY For SharePoint 2010 only, the SharePoint administrator must import the Okta DigiCert Root Certificate into the SharePoint certificate store. Perform the procedure described in Copyright 2014 Okta, Inc. All Rights Reserved. 11

13 Appendix: Import the Security Certificate into SharePoint 2010 Trusted Root Certificate Authority. In some cases, the parent DigiCert Root Certificate must also be uploaded if it does not already exist. Troubleshooting the People Picker Look for OktaClaimsProvider in the SharePoint ULS logs to monitor the activity of the claims provider. A ULS log viewer is recommended. Uninstalling the People Picker To uninstall the People Picker, do the following: 1. Before upgrading the Okta Claims Provider or People Picker, disable the Okta Trusted Identity provider. From your SharePoint Central Administration console, select General Security > Specify Authentication providers > Zone (Default). Before proceeding, note the People Picker solution name from the SharePoint Solution Management console and insert the value for the Okta Claims Provider in the PowerShell commands below. You can obtain the solution name by opening your SharePoint Central Administration console, selecting Manage farm solutions, and looking under the System Settings section. 9. After you have disabled your Okta Trusted Identity provider, reset IIS and uninstall the People Picker solution with the following PowerShell commands: $cp = Get-SPClaimProvider Where-Object \\ (command continued on next line) {$_.TypeName -eq 'OktaClaimsProvider.OktaClaimsProvider'} Remove-SPClaimProvider $cp 10. Validate that the People Picker has been removed by running the following command and confirming that Okta is not listed: Get-SPClaimProvider 11. After you have removed the Okta Claims Provider, remove the People Picker SharePoint solution with the PowerShell commands below. Substitute the People Picker solution WSP name with the solution name captured from the SharePoint Central Administration console in the steps above: Uninstall-SPSolution -Identity "OktaClaimsProvider xxxxxx.wsp" Copyright 2014 Okta, Inc. All Rights Reserved. 12

14 You can confirm and troubleshoot issues with the uninstallation from the SharePoint Central Administration console. 12. Validate that the WSP file is now Not Deployed and troubleshoot errors with the uninstallation. After you have successfully uninstalled the solution, enter the following PowerShell command to remove the SharePoint People Picker solution: Remove-SPSolution -Identity "OktaClaimsProvider xxxxxx.wsp" If successful, the People Picker solution should no longer appear in the Central Administration console. Uninstalling Okta Authentication After you have removed the People Picker solution, you can also remove Okta as an authentication claims provider by entering the following PowerShell command: Remove-SPTrustedIdentityTokenIssuer Identity Okta Validate your uninstallation by going to the Authentication Providers page in the SharePoint Central Administration console and confirming that Okta is no longer listed. Upgrading the Okta Claims Provider or People Picker Before you upgrade the Okta Claims Provider or People Picker, we highly recommended that you completely remove the previous version of the Okta People Picker. Follow the uninstallation instructions above and then deploy the new version using the deployment procedure. Deployment Scenarios Copyright 2014 Okta, Inc. All Rights Reserved. 13

15 Single Authentication Provider SharePoint can use Classic Mode Authentication or claims-based authentication. Classic Mode Authentication is traditional Windows authentication such as IWA (NTLM/Kerberos) or basic username/password schemes. Claims-based authentication is new to SharePoint as of SharePoint 2010 and is built on the Windows Identity Foundation (WIF). There are three types of claims-based authentication schemes: Windows claims, form-based, and SAML claims. Mixed Authentication Provider You can now configure multiple authentication providers with SharePoint (Windows authentication, forms authentication, and trusted Identity providers) using the same URL without having to extend the web application. Both external and internal users would access the web site on for example. By default the user chooses the authentication method when signing in, or the administrator can extend SharePoint to use programmatic methods of guiding the user to the correct authentication method (based on IP address for example). SharePoint shows the single page for mixed authentication mode where the user can pick the provider as shown below. SharePoint with Okta and Windows Authentication See the above section for mixed-mode authentication. Multiple Web Applications and Zones For technical purposes a zone is a logical path through which users gain access to a web application. The URL is a common public face of a zone. The purpose of the zone is to let users into a web application or other SharePoint application. Most people don t think about the zone. Users envision a URL that directly accesses the web application, but a zone adds an additional layer of abstraction for added configuration possibilities. A web application can have multiple URLs, all of which lead to the same place and use the same zone. This maximizes re-use and security. Hiding People Picker People Picker is configured at the zone level for a farm by using the stsadm setproperty operation. By configuring the settings for the control, administrators can filter and restrict the results that are displayed when a user searches for a user, group, or claim. Those settings apply to every site in a specific site collection. For more information about how to configure People Picker, see Configure People Picker in SharePoint Copyright 2014 Okta, Inc. All Rights Reserved. 14

16 Restricting People Picker to a Certain Group in Active Directory If a web application is using Windows authentication and the site user directory path is not set, the People Picker control searches all of Active Directory to resolve users' names or find users, instead of searching only users in a particular organizational unit (OU). The Stsadm setsiteuseraccountdirectorypath operation allows you to set the user's directory path to a specific OU in the same domain. After the directory path is set to a site collection, the People Picker control only searches under that particular OU. To restrict People Picker to a certain OU in Active Directory, enter the following command: stsadm -o setsiteuseraccountdirectorypath -path Valid OU name url Web application URL For more information refer to Microsoft s TechNet article. Okta Claims Authentication with Multiple SharePoint Applications (SSO) Administrators configure a corresponding Okta app for each SharePoint app. The realm establishes the trust relationship between Okta and the SharePoint application. For each SharePoint application, Okta generates a new "realm" that is used to define a relationship. To add a new web app to an existing authentication provider such as Okta, enter the following command: $ap = Get-SPTrustedIdentityTokenIssuer "Okta" $uri = new-object System.Uri($sharepoint_app) $ap.providerrealms.add($uri, $realm) $ap.update() Replace the $sharepoint_app value with the new SharePoint app URI and the $realm attribute with the new realm generated by the Sign-on tab from the corresponding SharePoint app in Okta. Copyright 2014 Okta, Inc. All Rights Reserved. 15

17 Troubleshooting Problem: The Trusted Identity Provider section is grayed out on the Edit Authentication page. Solution: Make sure Claims Based Authentication is selected as the preferred mode of authentication for this SharePoint application. From the Windows PowerShell command prompt, enter the following to set the specified user account as an administrator for the site: $WebAppName = " $wa = get-spwebapplication $WebAppName $wa.useclaimsauthentication = $true $wa.update() Problem: Authentication fails and shows a webpage with the error, "An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed." Solution Open the web.config file for this web application and make sure custom errors are turned off in the web.config file. <system.web>... <customerrors mode="off"/> Problem: Unable to redeploy PeoplePicker solution because getting the following SharePoint error: System.Exception: Error installing the Okta Claims Provider feature. Exception: Objects cannot be used once they have been deleted. Solution: This is caused by the People Picker Diagnostic service not being properly removed during the uninstall process. This can happen if the Okta claims provider is not disabled during an uninstallation of the PeoplePicker solution. Enter the following PowerShell commands to manually remove the Diagnostic service: [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Sharepoint.Administration") $farm = [Microsoft.Sharepoint.Administration.SPFarm]::Local $svc = $farm.services Where-Object {$_.TypeName -eq 'OktaClaimsProvider.OktaClaimsDiagnosticService'} $svc.delete() Problem: Authentication fails showing a webpage with the error, The Audience URI could not be validated." Solution: Open the web.config file for this web application and add the following line (mode=never) (Note that Never must be entered with a capital N). <microsoft.identitymodel>... <audienceuris mode="never"/> Problem: I see both Windows Authentication and Okta for SSO when I try to sign in. Solution: Both Windows Authentication and Okta are chosen as Identity Trust provider, as shown below. Uncheck Windows Authentication if you just want Okta to act as a trust provider Logs: SharePoint provides ULSViewer through which you can view logs. Copyright 2014 Okta, Inc. All Rights Reserved. 16

18 Problem: I change authentication providers but there is no effect. Solution: Refer us/library/cc288091(v=office.12).aspx Resetting your IIS server (iisreset) should usually help. Copyright 2014 Okta, Inc. All Rights Reserved. 17

19 Appendix: Import the Security Certificate into SharePoint 2010 Trusted Root Certificate Authority 1. Copy the certificate below to the file oktarootcert.cer and upload it to the SharePoint 2010 server BEGIN CERTIFICATE----- MIIGoDCCBYigAwIBAgIQDmzArJs7k+wRdHLxC4HcUjANBgkqhkiG9w0BAQUFADBm MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuzglnawnlcnquy29tmsuwiwydvqqdexxeawdpq2vydcbiawdoiefzc3vyyw5j ZSBDQS0zMB4XDTEzMDIxMjAwMDAwMFoXDTE2MDYxNjEyMDAwMFowZDELMAkGA1UE BhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lz Y28xEzARBgNVBAoTCk9rdGEsIEluYy4xEzARBgNVBAMMCioub2t0YS5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCozueVlFrIEGWU5sonymMV/rz0 VhPO8tSlaWnWweluZWpqiLOyIF08aDeFUOVY5rRVCvOBWJoAl5+oHoemIYrEmunw DlvVjRIp28L8/zcPbjgcCl6AiVfXrg1vXxPowwTnAC1zzMUZqVcMbawNSmmbquQw rklyaxtvf7uahhhrzqx4i0p4pfphol4drmx0qqxz0i0abu76t64dbab/2eqp2rhk Mt7WRqhy5szuJDQZt+NAzT8xwnWSjtcEWscUw4c0PJp8M8lOSZFVWH+X+KG8zxIv HVneASd9SHrVkSK8cT1LWh82XGoYoypDN20PNC700Sz6JvFDT+Lrq9g0J46xAgMB AAGjggNKMIIDRjAfBgNVHSMEGDAWgBRQ6nOJ2yn7EI+e5QEg1N55mUiD9zAdBgNV HQ4EFgQU+1kZEfq9c1WO6MDr6V2cTjy7Fh0wHwYDVR0RBBgwFoIKKi5va3RhLmNv byiib2t0ys5jb20wdgydvr0paqh/baqdagwgmb0ga1udjqqwmbqgccsgaqufbwmb BggrBgEFBQcDAjBhBgNVHR8EWjBYMCqgKKAmhiRodHRwOi8vY3JsMy5kaWdpY2Vy dc5jb20vy2ezlwcxos5jcmwwkqaoocagjgh0dha6ly9jcmw0lmrpz2ljzxj0lmnv bs9jytmtzze5lmnybdccacqga1udiascabswggg3miibswyjyiziayb9baebmiib pda6bggrbgefbqccaryuahr0cdovl3d3dy5kawdpy2vydc5jb20vc3nslwnwcy1y ZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgbzahqaaqb0ahuadablahmaiabhagmaywblahaadabhag4aywblacaabwbmacaa daboaguaiabeagkazwbpaemazqbyahqaiabdafaalwbdafaauwagageabgbkacaa daboaguaiabsaguabab5agkabgbnacaauabhahiadab5acaaqqbnahiazqblag0a ZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQA eqagageabgbkacaayqbyaguaiabpag4aywbvahiacabvahiayqb0aguazaagagga ZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB7BggrBgEFBQcB AQRvMG0wJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBFBggr BgEFBQcwAoY5aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0SGln aefzc3vyyw5jzunbltmuy3j0mawga1udeweb/wqcmaawdqyjkozihvcnaqefbqad ggebadrm6oqfe64thdmskr594fif0+h+hwxve2xdiz4/m7yhveqlvf/lolz/asbb /4KUcK+uJGMP5h/0y+qJcSllYPT+WsHJPb0zRUv8QKzcKtzWKVhUyqWgASgDStBR KK33poiJ473w42lYgZZLJtxYySwOjkBmtJnYfsz4G1AKfR1/ESc7Afg+szIG3YuU 3l0nRm6dk6GeJVCpaihA+Sxh2D89GBPy2LTIPJ1juLJMdB8wAdoHwZtlbrSXiAY/ erpm7sqhfktku7sb3vxpqvetzyhufsau0y4ojp20gs3obrffhz/6ky24dnwof+4q YxWB+hdG2bZTNWq478o5vLDj04c= -----END CERTIFICATE From SharePoint Central Administration, select Security > Manage Trust. Copyright 2014 Okta, Inc. All Rights Reserved. 18

20 14. In the ribbon interface, select the Trust Relationships tab, and then select Manage group. Then click the New button. 15. Enter the Okta root certificate as the name. 16. In the Root Certificate to trust relationship section, click Browse. Browse to the certificate file (oktarootcert.cer). Copyright 2014 Okta, Inc. All Rights Reserved. 19

21 17. Click the OK button. The certificate is imported to the SharePoint trusted root authority. 18. Restart IIS and test the People Picker functionality. Copyright 2014 Okta, Inc. All Rights Reserved. 20