Deployment Scenarios

Single Authentication Provider

SharePoint can use Classic Mode Authentication or claims-based authentication. Classic Mode Authentication is traditional Windows authentication such as Integrated Windows Authentication (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 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 https://intranet.company.com, for example. By default the user chooses the authentication method when signing in. Alternatively, the administrator can extend SharePoint to use programmatic methods of guiding the user to the correct authentication method (for example, based on IP address). SharePoint shows the single page for mixed authentication mode where the user can pick the provider.

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 a layer of abstraction for more configuration possibilities. A web application can have multiple URLs that all lead to the same place and use the same zone. This maximizes reuse and security.

People Picker with Active Directory Filtering

The Okta People Picker shows Active Directory (AD) imported users twice: as an Okta user, and as an AD domain user. Admins can see and manage only the original AD users. They can also specify that certain domains retain the original behavior.

Enabling this feature requires setting certain $farm object properties in SharePoint. Refer to Active Directory Filtering for the needed custom property values.

Hiding People Picker

People Picker is configured at the zone level for a farm through 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 2013. (Source: https://docs.microsoft.com/en-us/sharepoint/administration/people-picker-and-claims-providers-overview)

Restrict People Picker to a group in Active Directory

If a web application uses Windows authentication and the site user directory path isn't 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:

Copy 
stsadm ­o setsiteuseraccountdirectorypath ­-path <Valid OU name> –url <Web application URL>

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 web app to an existing authentication provider such as Okta, enter the following command:

Copy 
$ap = Get­SPTrustedIdentityTokenIssuer "Okta"
$uri = new­object System.Uri($sharepoint_app)
$ap.ProviderRealms.Add($uri, $realm)
$ap.Update()

Replace $sharepoint_app with the new SharePoint app URI and $realm with the generated realm from the Sign-on tab of the corresponding SharePoint app in Okta.