Advanced Settings
Custom Credentials
Instead of connecting with the provider's embedded credentials, you can register an app to obtain the OAuthClientId and OAuthClientSecret.
When to Create a Custom OAuth App
Web Applications
You need to create a custom OAuth app in the web flow.
Desktop Applications
Creating a custom OAuth app is optional as the provider is already registered with Common Data Service and you can connect with its embedded credentials. You might want to create a custom OAuth app to change the information displayed when users log into the Common Data Service OAuth endpoint to grant permissions to the provider.
Headless Machines
Creating a custom OAuth app is optional to authenticate a headless machine; the provider is already registered with Common Data Service and you can connect with its embedded credentials. In the headless OAuth flow, users need to authenticate via a browser on another machine. You might want to create a custom OAuth app to change the information displayed when users log into the Common Data Service OAuth endpoint to grant permissions to the provider.
Creating a Custom OAuth App
When to Create a Custom OAuth App
You might want to create a custom OAuth app to change the information displayed when users log into the Common Data Service OAuth endpoint to grant permissions to the provider.
Follow the steps below to create a custom OAuth app and obtain the connection properties in a specific OAuth authentication flow.
Create a Custom OAuth App: Desktop
Follow the steps below to obtain the OAuth values for your app, the OAuthClientId and OAuthClientSecret.
- Log in to https://portal.azure.com.
- In the left-hand navigation pane, select Azure Active Directory then App Registrations and click the Add button.
- Select Web app / API.
- Enter an app name and any URL you would like for the sign-on URL. The sign-on URL is not used by the provider or in the authentication step, so it can be set to your home page or an arbitrary URL like http://localhost.
- After creating the app, in the Properties section of your app settings, set the Multi-Tenanted option to Yes.
- In the Reply URLs, enter http://localhost:33333, the provider's default. Or, set a different port of your choice and set CallbackURL to the exact reply URL you defined.
- In the Keys section, create a key for the app and select a duration.
- After you save the key, a value for the key is displayed once. Set OAuthClientSecret to the key value. Set OAuthClientId to the Application Id.
- Select Required Permissions and then click Add. Under Select an API, select the Common Data Service permissions.
- Save your changes.
Create a Custom OAuth App: Web Apps
Follow the steps below to obtain the OAuth values for your app, the OAuthClientId and OAuthClientSecret.- Log in to https://portal.azure.com.
- In the left-hand navigation pane, select Azure Active Directory then App Registrations and click the Add button.
- Select Web app / API.
- Enter an app name and any URL you would like for the sign-on URL. The sign-on URL is not used by the provider or in the authentication step, so it can be set to your home page or an arbitrary URL like http://localhost.
- After creating the app, in the Properties section of your app settings, set the Multi-Tenanted option to Yes.
- Set the reply URL to the URL where you want users to return bearing the access token after they grant permissions to your app.
- In the Keys section, create a key for the app and select a duration.
- After you save the key, a value for the key is displayed once. Set OAuthClientSecret to the key value. Set OAuthClientId to the Application Id.
- Select Required Permissions and then click Add. Under Select an API, select the Dynamics CRM Online permissions.
- Save your changes.
Create a Custom OAuth App: Headless Machines
Follow the steps below to obtain the OAuth values for your app, the OAuthClientId and OAuthClientSecret.- Log in to https://portal.azure.com.
- In the left-hand navigation pane, select Azure Active Directory then App Registrations and click the Add button.
- Select Web app / API.
- Enter an app name and any URL you would like for the sign-on URL. The sign-on URL is not used by the provider or in the authentication step, so it can be set to your home page or an arbitrary URL like http://localhost.
- After creating the app, in the Properties section of your app settings, set the Multi-Tenanted option to Yes.
- In the Reply URLs, enter http://localhost:33333, the provider's default. Or, set a different port of your choice.
- In the Keys section, create a key for the app and select a duration.
- After you save the key, a value for the key is displayed once. Set OAuthClientSecret to the key value. Set OAuthClientId to the Application Id.
- Select Required Permissions and then click Add. Under Select an API, select the Dynamics CRM Online permissions.
- Save your changes.
Customizing the SSL Configuration
By default, the provider attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store. To specify another certificate, see the SSLServerCert property for the available formats to do so.
Connecting Through a Firewall or Proxy
HTTP Proxies
To connect through the Windows system proxy, you do not need to set any additional connection properties. To connect to other proxies, set ProxyAutoDetect to false.
In addition, to authenticate to an HTTP proxy, set ProxyAuthScheme, ProxyUser, and ProxyPassword, in addition to ProxyServer and ProxyPort.
Other Proxies
Set the following properties:
- To use a proxy-based firewall, set FirewallType, FirewallServer, and FirewallPort.
- To tunnel the connection, set FirewallType to TUNNEL.
- To authenticate, specify FirewallUser and FirewallPassword.
- To authenticate to a SOCKS proxy, additionally set FirewallType to SOCKS5.
Troubleshooting the Connection
To show provider activity from query execution to network traffic, use Logfile and Verbosity. The examples of common connection errors below show how to use these properties to get more context. Contact the support team for help tracing the source of an error or circumventing a performance issue.
- Authentication errors: Typically, recording a Logfile at Verbosity 4 is necessary to get full details on an authentication error.
- Queries time out: A server that takes too long to respond will exceed the provider's client-side timeout. Often, setting the Timeout property to a higher value will avoid a connection error. Another option is to disable the timeout by setting the property to 0. Setting Verbosity to 2 will show where the time is being spent.
- The certificate presented by the server cannot be validated: This error indicates that the provider cannot validate the server's certificate through the chain of trust. If you are using a self-signed certificate, there is only one certificate in the chain.
To resolve this error, you must verify yourself that the certificate can be trusted and specify to the provider that you trust the certificate. One way you can specify that you trust a certificate is to add the certificate to the trusted system store; another is to set SSLServerCert.