Microsoft Dynamics CRM

Authenticating to CRM On-Premises

For CRM on-premises, select an authentication method. By default, the connector uses Windows (NTLM) authentication: set Url to the root URL of your organization and set User, Password, and CRMVersion On-Premise.

To use another authentication type, such as Kerberos delegation, set AuthScheme.

Authenticating to CRM Internet Facing Deployments

For Dynamics CRM with IFD, set InternetFacingDeployment to true.

Authenticating with OAuth

Dynamics CRM Online/IFD supports the OAuth 2.0 authentication standard.

See Dynamics365 - Connection Settings

Using oAuth with IFD

After creating your OAuth Application, set the following connection properties for IFD:

  • AuthScheme: Set to OAuth.

  • OAuthClientId: Set to the consumer key in your app settings.

  • OAuthClientSecret(optional): Set to the consumer secret in your app settings.

  • ADFSServer: Set to the adfs server in your deployment.

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

  1. Gets the callback URL and sets the access token and ADFSServer to authenticate requests.

  2. Saves OAuth values in your connection settings to be persisted across connections.

  3. Exchanges the returned refresh token for a new, valid access token.

Using oAuth with Online Instances

After creating your OAuth Application, set the following connection properties for Online instances (Web flow):

Authenticating using a Client Secret

  • OAuthClientId: Set this to the Client Id in your app settings.

  • OAuthClientSecret: Set this to the Client Secret in your app settings.

  • CallbackURL: Set this to the Redirect URL in your app settings.

  • AuthScheme: Set this to the "AzureAD" in your app settings.

  • InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken. .

Authenticating using a Certificate

  • OAuthClientId: Set this to the Client Id in your app settings.

  • OAuthJWTCert: Set this to the JWT Certificate store.

  • OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.

  • CallbackURL: Set this to the Redirect URL in your app settings.

  • AuthScheme: Set this to the "AzureAD" in your app settings.

  • InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken. .

When you connect the connector opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider 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 to be persisted across connections.

Client OAuth Flow

In your App Registration in portal.azure.com, navigate to API Permissions and select the Microsoft Graph permissions. There are two distinct sets of permissions - Delegated and Application permissions. The permissions used during client credential authentication are under Application Permissions. Select the applicable permissions you require for your integration.

You are ready to connect after setting one of the below connection properties groups depending on the authentication type.

Authenticating using a Client Secret

  • InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.

  • AzureTenant: Set this to the tenant you wish to connect to.

  • OAuthGrantType: Set this to CLIENT.

  • OAuthClientId: Set this to the Client Id in your app settings.

  • OAuthClientSecret: Set this to the Client Secret in your app settings.

Authenticating using a Certificate

  • InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.

  • AzureTenant: Set this to the tenant you wish to connect to.

  • OAuthGrantType: Set this to CLIENT.

  • OAuthClientId: Set this to the Client Id in your app settings.

  • OAuthJWTCert: Set this to the JWT Certificate store.

  • OAuthJWTCertType: Set this to the type of the certificate store specified by OAuthJWTCert.

When you authenticate using client credentials, there is no Web flow as discussed under OAuth Authentication. Authentication with client credentials will take place automatically like any other connection, except there will be no window opened prompting the user. Because there is no user context, there is no need for a browser popup. Connections will take place and be handled internally.

Authenticating with Kerberos

To authenticate to Dynamics CRM using Kerberos, set the following properties:

  • AuthScheme: Set this to KERBEROS

  • KerberosKDC: Set this to the host name or IP Address of your Kerberos KDC machine.

  • KerberosSPN: Set this to the service and host of the Dynamics CRM Kerberos Principal. This will be the value prior to the '@' symbol (for instance, ) of the (for instance, ).

Retrieve the Kerberos Ticket

You can use one of the following options to retrieve the required Kerberos ticket.

MIT Kerberos Credential Cache File

This option enables you to use the MIT Kerberos Ticket Manager or kinit command to get tickets. Note that you won't need to set the User or Password connection properties with this option.

  1. Ensure that you have an environment variable created called KRB5CCNAME.

  2. Set the KRB5CCNAME environment variable to a path pointing to your credential cache file (for instance, C:\krb_cache\krb5cc_0 or /tmp/krb5cc_0). This file will be created when generating your ticket with MIT Kerberos Ticket Manager.

  3. To obtain a ticket, open the MIT Kerberos Ticket Manager application, click Get Ticket, enter your principal name and password, then click OK. If successful, ticket information will appear in Kerberos Ticket Manager and will now be stored in the credential cache file.

  4. Now that the credential cache file has been created, the provider will use the cache file to obtain the kerberos ticket to connect to Dynamics CRM.

As an alternative to setting the KRB5CCNAME environment variable, you can directly set the file path using the KerberosTicketCache property. When set, the connector will use the specified cache file to obtain the kerberos ticket to connect to Dynamics CRM.

Keytab File

If the KRB5CCNAME environment variable has not been set, you can retrieve a Kerberos ticket using a Keytab File. To do this, set the User property to the desired username and set the KerberosKeytabFile property to a file path pointing to the keytab file associated with the user.

User and Password

If both the KRB5CCNAME environment variable and the KerberosKeytabFile property have not been set, you can retrieve a ticket using a User and Password combination. To do this, set the User and Password properties to the user/password combo that you use to authenticate with Dynamics CRM.

Cross-Realm Authentication

More complex Kerberos environments may require cross-realm authentication where multiple realms and KDC servers are used (e.g. where one realm/KDC is used for user authentication and another realm/KDC used for obtaining the service ticket).

In such an environment, the KerberosRealm and KerberosKDC properties can be set to the values required for user authentication. The KerberosServiceRealm and KerberosServiceKDC properties can be set to the values required to obtain the service ticket.

The following are the connection properties for DynamicsCRM. Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.

Last updated