Connecting to SharePoint

Regardless of whether you will connect online or on-premesis, what architecture will be used, and which Lists and Documents will be accessed, connecting to SharePoint requires exactly two things:

• Set the URL connection property.
• Set the appropriate authentication properties for your working environment.

Setting URL:

SharePoint works with all Lists and Documents in the global Microsoft Sharepoint site, or all Lists and Documents at individual sites.

To work with all Lists and Documents in the global Microsoft Sharepoint site, set the URL connection property to your Site Collection URL. For example:

https://teams.contoso.com

To work with all Lists and Documents at an individual site, set the URL connection property to your individual site URL. For example:

 https://teams.contoso.com/TeamA

The following sections describe how to set the appropriate authentication properties for your working environment. For information about how to create a custom OAuth application (required for use with AzureAD in a Web application; optional for AzureAD access via a Desktop application or a Headless Server), see Creating a Custom OAuth Application.

SharePoint Online

Set SharePointEdition to "SharePoint Online" and set the User and Password to the credentials you use to log onto SharePoint, for example, the credentials to your Microsoft Online Services account.

SharePoint online supports a number of cloud-based architectures, each of which supports a different set of authentication schemes:

• AzureAD
• Single sign-on (SSO) via the ADFS, Okta, OneLogin, or PingFederate SSO identity provider
• Azure MSI
• Azure Password
• OAuthJWT
• SharePointOAuth

If the user account domain is different from the domain configured with the identity provider, set SSODomain to the latter. This property may be required for any SSO.

AzureAD

Azure Active Directory (AzureAD) is a connection type that leverages OAuth to authenticate. OAuth requires the authenticating user to interact with SharePoint using an internet browser. The driver facilitates this in several ways as described below. Set your AuthScheme to AzureAD. The AzureAD flows described below assume that you have done so.

Your organization may require Admin Consent when authorizing a new AzureAD application for your Azure Tenant. In all AzureAD flows, any initial installation and use of an AzureAD application requires that an administrator approve the application for their Azure Tenant. For details, see Creating a Custom OAuth Application.

Desktop Applications

CData provides an embedded OAuth application that simplifies OAuth desktop authentication. Alternatively, you can create a custom AzureAD application. See Creating a Custom OAuth Application for information about creating custom applications and reasons for doing so.

For authentication, the only difference between the two methods is that you must set two additional connection properties when using custom AzureAD applications.

After setting the following connection properties, you are ready to connect:

• InitiateOAuth: GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
• CallbackURL: The Redirect URL in your application settings.
• Custom applications only:
  • OAuthClientId: The client Id in your application settings.
  • OAuthClientSecret: The client secret in your application settings.

When you connect the adapter opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The adapter then completes the OAuth process:

1. Extracts the access token from the callback URL and authenticates requests.
2. Obtains a new access token when the old one expires.
3. Saves OAuth values in OAuthSettingsLocation. These stored values persist across connections.

Web Applications

When connecting via a Web application, you must create and register a custom AzureAD application with SharePoint. See Creating a Custom OAuth Application for more information about custom applications. You can then use the adapter to acquire and manage the OAuth token values.

Get an OAuth access token:

Set the following connection properties to obtain the OAuthAccessToken:

• OAuthClientId: The client Id in your application settings.
• OAuthClientSecret: The client secret in your application settings.

Call stored procedures to complete the OAuth exchange:

1. Call the GetOAuthAuthorizationURL stored procedure. Set the CallbackURL input to the callback URL you specified in your application settings. If necessary, set the Scope parameter to request custom permissions.

   The stored procedure returns the URL to the OAuth endpoint.

2. Open the URL, log in, and authorize the application. You are redirected back to the callback URL.
3. Call the GetOAuthAccessToken stored procedure. Set the AuthMode input to WEB. Set the Verifier input to the "code" parameter in the query string of the callback URL. If necessary, set the Scope parameter to request custom permissions.

Once you have obtained the access and refresh tokens, you can connect to data and refresh the OAuth access token either automatically or manually.

Automatic refresh of the OAuth access token:

To have the driver automatically refresh the OAuth access token, set the following on the first data connection:

• InitiateOAuth: REFRESH.
• OAuthClientId: The client Id in your application settings.
• OAuthClientSecret: The client secret in your application settings.
• OAuthAccessToken: The access token returned by GetOAuthAccessToken.
• OAuthRefreshToken: The refresh token returned by GetOAuthAccessToken.
• OAuthSettingsLocation: The location where the adapter saves the OAuth token values, which persist across connections.

On subsequent data connections, the values for OAuthAccessToken and OAuthRefreshToken are taken from OAuthSettingsLocation.

Manual refresh of the OAuth access token:

The only value needed to manually refresh the OAuth access token when connecting to data is the OAuth refresh token.

Use the RefreshOAuthAccessToken stored procedure to manually refresh the OAuthAccessToken after the ExpiresIn parameter value returned by GetOAuthAccessToken has elapsed, then set the following connection properties:

• OAuthClientId: The client Id in your application settings.
• OAuthClientSecret: The client secret in your application settings.

Now call RefreshOAuthAccessToken with OAuthRefreshToken set to the OAuth refresh token returned by GetOAuthAccessToken. After the new tokens have been retrieved, open a new connection by setting the OAuthAccessToken property to the value returned by RefreshOAuthAccessToken.

Finally, store the OAuth refresh token so that you can use it to manually refresh the OAuth access token after it has expired.

Headless Machines

To configure the driver to use OAuth with a user account on a headless machine, you must authenticate on another device that has an internet browser.

1. Choose one of these two options:
   • Option 1: Obtain the OAuthVerifier value as described in "Obtain and Exchange a Verifier Code" below.
   • Option 2: Install the adapter on another machine and transfer the OAuth authentication values after you authenticate through the usual browser-based flow, as described in "Transfer OAuth Settings" below.

2. Now configure the adapter to automatically refresh the access token from the headless machine.

Option 1: Obtain and Exchange a Verifier Code

To obtain a verifier code, you must authenticate at the OAuth authorization URL.

Follow the steps below to authenticate from the machine with an internet browser and obtain the OAuthVerifier connection property.

1. Choose one of these options:
   • If you are using the Embedded OAuth Application click SharePoint OAuth endpoint to open the endpoint in your browser.
   • If you are using a custom OAuth application, create the Authorization URL by setting the following properties:
     • InitiateOAuth: OFF.
     • OAuthClientId: The client Id assigned when you registered your application.
     • OAuthClientSecret: The client secret assigned when you registered your application.
     Now call the GetOAuthAuthorizationURL stored procedure with the appropriate CallbackURL. Open the URL returned by the stored procedure in a browser.

2. Log in and grant permissions to the adapter. You are redirected to the callback URL, which contains the verifier code.
3. Save the value of the verifier code. Later you will set this in the OAuthVerifier connection property.

Next, you must exchange the OAuth verifier code for OAuth refresh and access tokens. Set the following properties:

On the headless machine, set the following connection properties to obtain the OAuth authentication values:

• InitiateOAuth: REFRESH.
• OAuthVerifier: The verifier code.
• OAuthSettingsLocation: The location of the file where the driver saves the OAuth token values that persist across connections.
• Custom applications only:
  • OAuthClientId: The client Id in your custom OAuth application settings.
  • OAuthClientSecret: The client secret in the custom OAuth application settings.

After the OAuth settings file is generated, you must re-set the following properties to connect:

• InitiateOAuth: REFRESH.
• OAuthSettingsLocation: The location containing the encrypted OAuth authentication values. Make sure this location grants read and write permissions to the adapter to enable the automatic refreshing of the access token.
• Custom applications only:
  • OAuthClientId: The client Id assigned when you registered your application.
  • OAuthClientSecret: The client secret assigned when you registered your application.

Option 2: Transfer OAuth Settings

Prior to connecting on a headless machine, you must create and install a connection with the driver on a device that supports an internet browser. Set the connection properties as described in "Desktop Applications" above.

After completing the instructions in "Desktop Applications", the resulting authentication values are encrypted and written to the location specified by OAuthSettingsLocation. The default filename is OAuthSettings.txt.

Once you have successfully tested the connection, copy the OAuth settings file to your headless machine.

On the headless machine, set the following connection properties to connect to data:

• InitiateOAuth: REFRESH.
• OAuthSettingsLocation: The location of your OAuth settings file. Make sure this location gives read and write permissions to the adapter to enable the automatic refreshing of the access token.
• Custom applications only:
  • OAuthClientId: The client Id assigned when you registered your application.
  • OAuthClientSecret: The client secret assigned when you registered your application.

Single Sign-On Identity Providers

ADFS

Set the AuthScheme to ADFS. You must set the following connection properties:

• User: The ADFS user.
• Password: The user's ADFS password.
• SSODomain (optional): The domain configured with the ADFS identity provider.

Example connection string:

AuthScheme=ADFS;User=ADFSUserName;Password=ADFSPassword;URL='http://sharepointserver/mysite';

Okta

Set the AuthScheme to Okta. The following connection properties are used to connect to Okta:

• User: The Okta user.
• Password: The user's Okta password.
• SSODomain (optional): The domain configured with the OKTA identity provider.

Example connection string:

AuthScheme=Okta;User=oktaUserName;Password=oktaPassword;URL='http://sharepointserver/mysite';

OneLogin

Set the AuthScheme to OneLogin. The following connection properties are used to connect to OneLogin:

• User: The OneLogin user.
• Password: The user's OneLogin password.
• SSODomain (optional): The domain configured with the OneLogin identity provider.

Example connection string:

AuthScheme=OneLogin;User=OneLoginUserName;Password=OneLoginPassword;URL='http://sharepointserver/mysite';

PingFederate

Set the AuthScheme to PingFederate. The following connection properties are used to connect to PingFederate:

• User: The PingFederate user.
• Password: PingFederate password for the user.
• SSODomain (optional): The domain configured with the PingFederate identity provider.

Example connection string:

AuthScheme=PingFederate;User=PingFederateUserName;Password=PingFederatePassword;URL='http://sharepointserver/mysite';

Azure MSI

If you are running SharePoint on an Azure VM, you can leverage Azure Managed Service Identity (MSI) credentials to connect:

• AuthScheme: AzureMSI.

The MSI credentials are automatically obtained for authentication.

Azure Password

To connect using your Azure dredentials directly, specify the following connection properties:

• AuthScheme: AzurePassword
• User: The user account used to connect to Azure
• Password: The password used to connect to Azure
• AzureTenant: Directory (tenant) ID, found on the Overview page of the OAuth application used to authenticate to SharePoint on Azure.

OAuthJWT Certificate

Set the AuthScheme to OAUTHJWT. The following connection properties are used to connect to SharePoint:

• AzureTenant: The tenant you wish to connect to.
• OAuthJWTCert: The JWT certificate store.
• OAuthJWTCertType: The type of key store containing the JWT certificate.
• OAuthJWTIssuer: The OAuth client Id.
• OAuthJWTCertPassword: The password associated with the JWT certificate. Set this is your certificate type requires a password.

SharePointOAuth

Set the AuthScheme to SharePointOAuth. The following connection properties are used to connect to SharePointOAuth:

• Schema: REST.
• InitiateOAuth: GETANDREFRESH.
• OAuthClientId: The application's identity/Client Id.
• OAuthClientSecret: The application's Client Secret.

Example connection string:

SharePointEdition='SharepointOnline';URL=https://rssbuscrm.sharepoint.com;Schema=REST;AuthScheme=SharepointOAuth;InitiateOAuth=GETANDREFRESH;OAuthClientId=11111111-1111-1111-1111-111111111111;OAuthClientSecret=1111111111111/11111111111111/11111111111111=;

This AuthScheme works with the custom OAuth application. To generate credentials from a custom OAuth application, see Creating a Custom OAuth Application.

SharePoint On-Premises

SharePoint On-Premises supports a number of premise-based architectures:

• Windows (NTLM)
• Kerberos
• ADFS
• Anonymous Access

Set SharePointEdition to "SharePoint On-Premises" to use the following authentication types.

Windows (NTLM)

This is the most common authentication type. As such, the adapter is preconfigured to use NTLM as the default; simply set the Windows User and Password to connect.

Kerberos

Set the AuthScheme to NEGOTIATE, and then set the following Kerberos connection properties:

• KerberosKDC: The host name or IP Address of your Kerberos KDC machine.
• KerberosRealm: The realm of the SharePoint Kerberos principal. This is the value after the '@' symbol (for instance, EXAMPLE.COM) of the principal value (for instance, MyService/MyHost@EXAMPLE.COM).
• KerberosSPN: The service and host of the SharePoint Kerberos Principal. This is the value prior to the '@' symbol (for instance, MyService/MyHost) of the principal value (for instance, MyService/MyHost@EXAMPLE.COM).

For details on how to authenticate with Kerberos, see Using Kerberos.

ADFS

Set the AuthScheme to ADFS, and then set the following connection properties:

• User: The ADFS user.
• Password: ADFS password for the user.
• SSOLoginURL: The WS-trust endpoint of the ADFS server.

You also need the to set SSOProperties to authenticate to ADFS. Specify the value of the RelyingParty parameter; it is located on the ADFS server for Sharepoint. Example connection string:

AuthScheme=ADFS;User=ADFSUserName;Password=ADFSPassword;SSOLoginURL='https://<authority>/adfs/services/trust/2005/usernamemixed';SSO Properties ='RelyingParty=urn:sharepoint:sp2016;';

Anonymous Access

Set the AuthScheme to NONE along with the URL.