Impersonation is used to execute business logic (custom code) on behalf of a Microsoft Dynamics CRM system user to provide a desired feature or service for that user. Any business logic executed within a plug-in, including Web service method calls and data access, and is governed by the security privileges of the impersonated user.
Impersonation during plug-in registration
One method to impersonate a system user within a plug-in is by specifying the impersonated user during plug-in registration.
When registering a plug-in programmatically, if the SdkMessageProcessingStep.ImpersonatingUserId attribute is set to a specific Microsoft Dynamics CRM system user, Web service calls made by the plug-in execute on behalf of the impersonated user.
If ImpersonatingUserId is set to a value of null or Guid.Empty during plug-in registration, the calling/logged on user or the standard “system” user is the impersonated user
Impersonation during plug-in execution
Impersonation that was defined during plug-in registration can be altered in a plug-in at run time. Even if impersonation was not defined at plug-in registration, plug-in code can still use impersonation.
The platform passes the impersonated user ID to a plug-in at run time through the UserId property. This property can have one of three different values as shown in the table below.
|Initiating user or “system” user||The SdkMessageProcessingStep.ImpersonatingUserId attribute is set to null or Guid.Empty at plug-in registration.|
|Impersonated user||The ImpersonatingUserId property is set to a valid system user ID at plug-in registration.|
|“system” user||The current pipeline was executed by the platform, not in direct response to a service method call.|
The InitiatingUserId property of the execution context contains the ID of the system user that called the service method that ultimately caused the plug-in to execute.
|For plug-ins executing offline, any entities created by the plug-in are owned by the logged on user. Impersonation in plug-ins is not supported while in offline mode.|
User account (A) needs the privilege prvActOnBehalfOfAnotherUser, which is included in the Delegate role.
Alternately, for Active Directory directory service deployments only, user account (A) under which the impersonation code is to run can be added to the PrivUserGroup group in Active Directory. This group is created by Microsoft Dynamics CRM during installation and setup. User account (A) does not have to be associated with a licensed Microsoft Dynamics CRM user. However, the user who is being impersonated (B) must be a licensed Microsoft Dynamics CRM user.
The actual set of privileges that is used to modify data is the intersection of the privileges that the Delegate role user possesses with that of the user that is being impersonated. In other words, user A is allowed to do something if and only if user A and the impersonated user (B) have the privilege necessary for the action.
Impersonate a user
To impersonate a user, set the CallerId property on an instance of OrganizationServiceProxy before calling the service’s Web methods
This can be achieved by using impersonation. There are the two steps needed to impersonate in Microsoft Dynamics CRM:
- The user (impersonator) must have the ActOnBehalfOf privilege or be a member of the PrivUserGroup group in Active Directory
- Setting the CallerId property of the organization Web service proxy. Please find below a sample code that shows how to set the caller id of the organization service proxy