Impersonation allows you to make CrmService or MetadataService API calls on behalf of another Microsoft Dynamics CRM system user. In this section we will discuss using impersonation in Web applications and also in plug-ins.
In Chapter 3, you learned how to create an instance of CrmService that you can then use for actions such as creating or updating an entity. When used in the context of Web pages, code executes under the security credentials of the user browsing the Web page, so by default all of your CrmService calls execute as the browsing user. At times, you might want to execute code using security credentials different from those of the user browsing the Web page. In Microsoft Dynamics CRM, you can execute business logic on behalf of another user through a technique called impersonation.
Impersonation requires you to take the following steps:
Explicitly set the authentication token’s CallerId property using a valid Microsoft Dynamics CRM system user.
Ensure that the network credentials of the user used to authenticate to the Web service are those of a member of the PrivUserGroup in the Active Directory directory service.
You can set the CallerId property very easily by adding the following line of code to your standard service setup.
token.CallerId = new Guid("00000000-0000-0000-0000-000000000000");Replace the string of zeros (also referred to as an empty Guid) with the actual systemuserid globally unique identifier (Guid) of the Microsoft Dynamics CRM user whom you want to impersonate. Microsoft Dynamics CRM ignores an empty Guid and uses the security credentials of the user browsing the Web page. If you specify a Guid that does not exist, Microsoft Dynamics CRM throws an exception.
Also note that the authenticating user of the API Web service must be a member of the PrivUserGroup in Active Directory. These are the network credentials specified in the service. Credentials property. The PrivUserGroup is an Active Directory group added during the installation of Microsoft Dynamics CRM.
Important
The user that corresponds to the systemuserid specified in the CallerId property is not the user who needs to be a member of the PrivUserGroup. The Active Directory user specified in the service.Credentials property is the user who must be added.
Although impersonation is a powerful technique, any time you impersonate you open a potential security risk and add configuration challenges to your implementation. We recommend that you try to avoid using impersonation whenever possible. In most cases, you can find an alternative way to execute the logic required by altering the user’s Microsoft Dynamics CRM security permissions or by changing the logic’s design.
In addition to using impersonation with the CrmService API, you can use impersonation with custom plug-ins. The plug-in code runs under the user defined on the Identity tab of the CrmAppPool Properties dialog box. The CrmAppPool Properties dialog box can be found in Internet Information Services (IIS) Manager under the Application Pools folder.
Accessing the CrmAppPool identity
Open Internet Information Services (IIS) Manager.
Expand the Application Pools folder.
Right-click CrmAppPool and select Properties.
Click the Identity tab.
Note
By default, CrmAppPool runs under the Network Service account. If this account is changed to another user account, that account must be added to the PrivUserGroup in Active Directory.
Setting up a CrmService instance for impersonation in a plug-in is pretty simple. To create an instance of the CrmService that will make its calls under the logged-on user, you would use the following line of code:
ICrmService crmService = context.CreateCrmService(true);
The preceding line provides the same functionality as the following line:
ICrmService crmService = context.CreateCrmService(context.UserId);
To avoid using impersonation when your plug-in executes, create the service by passing false into the CreateCrmService method:
ICrmService crmService = context.CreateCrmService(false);
Your calls will now run under the system account instead of the logged-on user’s account. The system account is set up by default when Microsoft Dynamics CRM is installed. This user account will not be displayed in the system user views in the user interface. If you query the SystemUserBase table for fullname equal to "SYSTEM" in the Microsoft Dynamics CRM database, you can find this user record. The system user account has high-level access with a few caveats, such as not being able to create a Task.
