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, 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.

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.

People Picker with Active Directory Filtering

Currently, the Okta People Picker shows Active Directory (AD) imported users twice: as an Okta user, and as an AD domain user. Now admins have the ability to see and manage only the original AD users. Admins 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 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 2013. (Source: https://docs.microsoft.com/en-us/sharepoint/administration/people-picker-and-claims-providers-overview)

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:

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 new 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 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.