Microsoft Dynamics 365 Blog

This article pertains to Trust for Delegation issues encountered in on-premise installations of Microsoft Dynamics CRM 4.0 (MS CRM) when CRM server and SharePoint Server exist on different physical machines. If you have List Web Part (LWP) deployed for IFD version of MS CRM, or both Microsoft Dynamics CRM and SharePoint Server are on same machine then your deployment is not affected by the trust for delegations issue.

In scenarios, where MS CRM on-premise and SharePoint are setup on separate machines, Microsoft Dynamics users of LWP face issues during authentication. If the SharePoint Server is not setup for Trust for Delegation then the user’s Active Directory credentials are not passed to the MS CRM server. The LWP deployed on SharePoint does not receive the CRM authentication ticket from SharePoint and displays the sign on form used with an IFD installation. The screen below shows the configuration pane of LWP and sign on form. This form appears when a Trust For Delegation ( also known as Double-Hop impersonation ) is not present.


Figure 1 : IFD login from configuration pane

What is Double Hop issue?

In situations where SharePoint Server and MS CRM server are on different machines, the first hop is from the LWP user’s IE browser to the SharePoint server, and then from the SharePoint server to the MS CRM Server. This is the second hop. Windows credentials cannot be passed in second hop, due to security issues. To enable the SharePoint Server to pass the user credentials, the SharePoint server must be configured for Trust for Delegation.

Setting up ‘Trust for Delegation’

To make it easier to understand the configuration settings, consider the following topology:

  • Machine #1 Active Directory

  • Machine #2 SQL Server

  • Machine #3 Microsoft Dynamics CRM 4.0 Server

  • Machine #4 Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007

  • Machine #5 User accessing SP using IE


Figure 2: Independent CRM and SharePoint Server topology

1. First, configure IIS and IE for delegation using the steps in following KB Article;en-us;810572

Note: To perform remaining steps , the user must be a member of the Domain Adminstrators group or the Enterprise Adminstrators group in Active Directory, or user must have been delegated the appropriate authority.

As a security best practice, consider using Run as to perform this procedure.

2. Click Start >> Control Panel >> Administrative Tools >> Active Directory Users and Computers.

3. In the console tree, click Computers.

4. In the details pane, right-click the computer you want to trust for delegation and then click Properties. In our case its Windows SharePoint Services 3.0 server or MOSS 2007 server (machine # 4 in figure 2) .

5. On the Delegation tab, click Trust this computer for delegation to specified services only.


Figure 3 : Trust for delegation to specific service

6. Depending upon the IIS authentication type in WSS/MOSS Web application, do one of the following:

  • If IIS authentication type is NTLM , Click Use any authentication protocol .


  • If IIS authentication Setting is Integrated Windows authentication with Negotiate (Kerberos), click Use Kerberos only ( see figure 7 ).

7. Click Add and, in Add Services, click Users and Computers.

8. In Enter the object names to select (examples), type the name of the computer that the computer will be trusted to delegate for example, Dynamics CRM 4.0 computer (Server no 3 in figure 2) , and then click OK.


Figure 4 : Select User and Computers

If the machine name does not resolve, Click Advanced

      • After opening Select Users or Computer dialog , click Find Now

      • Select CRM server computer from list and then click OK. In Select Users or Computer dialog , CRM server machine name will appear, Click OK.


Figure 5 : Select User and Computers using advanced dialog

9. In Add Services, click the Http service that will be trusted for delegation and click OK.


Figure 6 : Set trust for specified service


  • If you cannot see the Delegation tab as shown in Figure 3, do one or both of the following:

    • Register a Service Principal Name (SPN) for the computer account using the Setspn utility in the support tools that are on your CD. Delegation is only intended to be used by service accounts, which should have registered SPNs, as opposed to a regular user account which typically does not have SPNs.

    • Raise the functional level of your domain to Windows Server 2003 .

  • Constrained delegation, delegation of authentication for only specified services, can only be enabled on a member of the Windows Server 2003 family.

The following steps are necessary if you want to use Kerberos in WSS/MOSS.

10. In SharePoint Central administrator site, In Application Management, Select Authentication Providers

11. In Authentication Provider select Window Membership Provider from default zone and Check IIS Authentication Settings.

a. Integrated Windows authentication check box should be selected

b. Select Negotiate (Kerberos) option


Figure 7 : SharePoint Central Admin – Edit Authentication

You should now be able to login to List Web Part and view the configuration page.


Figure 8 : Successful Login in List Web Part


Suraj Supekar

We're always looking for feedback and would like to hear from you. Please head to the Dynamics 365 Community to start a discussion, ask questions, and tell us what you think!