Act on Behalf of Another User

Colin Maitland, 18 July 2013

In my previous two blogs I wrote about: 

• Use of a dedicated Non-Interactive Microsoft Dynamics CRM Online User to restrict access to Microsoft Dynamics CRM for use by integration between Microsoft Dynamics CRM Online and another system.

• Use of a dedicated Microsoft Dynamics CRM Security Role to restrict access to Microsoft Dynamics CRM for use by an integration between Microsoft Dynamics CRM and another system. 

In this blog, I will briefly mention the use of the Act On Behalf of Another User privilege in Microsoft Dynamics CRM 2011. 

Microsoft Dynamics CRM provides a Security Role named Delegate. This Security Role contains a single privilege named Act on Behalf of Another User. 

 

In some circumstances a Microsoft Dynamics CRM User, such as that used by an integration between Microsoft Dynamics CRM and another system, such as a Web Site, or that used by a Plugin Process, needs to impersonate another user when performing certain actions such as creating, reading, writing, activating/deactivating, assigning or sharing records in Microsoft Dynamics CRM. 

There are two ways in which this ability to impersonate (or act on behalf of) another user may be provided: 

• For Microsoft Dynamics CRM Online and Microsoft Dynamics CRM On Premise deployments the Delegate Security Role may be assigned to the user who needs to impersonate other users.

• Alternately, for Active Directly service deployments, the user who needs to impersonate other users may be added to the PrivUserGroup in Active Directory. 

Note: The ability to impersonate other users in Microsoft Dynamics CRM applies only to applications written to use the Microsoft Dynamics CRM Web Services. This ability does not apply to users using Microsoft Dynamics CRM using the Microsoft Dynamics CRM Web Client or the Microsoft Dynamics CRM for Outlook Client. 

With respect to security there are a couple of important points to be aware of: 

• When acting on behalf of another user, the delegate user will not have access to any additional privileges; such as create, read, write, delete, append, append to, assign or share; that they do not already have themselves. For example, if the delegate user has the privileges required to Create, Read, Write, Append and Append To Account and Contact records, but does not have the privileges required to Delete, Assign or Share Account and Contact records, then even though the user they are acting on behalf of may have all of these privileges, the delegate user will not be able to perform any of the actions for which they themselves do not have the required privileges; i.e. Delete, Assign and Share.

Privileges Assigned to the Delegate User 

 

Privileges Assigned to the Impersonated User 

 

Effective Privileges

In this example, when the delegate user is acting on behalf of the other user the following are the effective privileges they will have: 

 

• When acting on behalf of another user, the delegate user will have access to the same level of privileges assigned to the user they are acting on behalf of.

(a)    This may result in the delegate user being granted elevated privileges. For example, if the delegate user has Business Unit access level privileges to Create, Read, Write, Append and Append To Account and Contact records and the user they are acting on behalf of has Organisation access level privileges to Create, Read, Write, Append and Append To Account and Contact records, then the delegate  user will be able to perform those actions with Organisation access level when acting on behalf of the other user.  

Privileges Assigned to the Delegate User 

 

Privileges Assigned to the Impersonated User 

 

Effective Privileges

In this example, when the delegate user is acting on behalf of the other user the following are the effective privileges they will have: 

 

Note: In this example, even though the impersonating user has Organisation level access to Create, Read, Write, Append and Append To Account and Contact records when acting on behalf of the impersonated user, they will not have any access to Delete, Assign or Share Account or Contact records. 

(b)   Conversely, this may result in the delegate user being granted reduced privileges. For example: 

Privileges Assigned to the Delegate User 

 

Privileges Assigned to the Impersonated User 

 

Effective Privileges

In this example, when the delegate user is acting on behalf of the other user the following are the effective privileges they will have: 

 

The following article provides a technical description and sample how to Impersonate Another User using the Software Development Kit (SDK):

http://msdn.microsoft.com/en-us/library/gg334744.aspx and http://msdn.microsoft.com/en-us/library/gg309629.aspx.