Sorry for the broken formatting in the previous post.
According to the documentation there are some requirements concerning impersonation.
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/org-service/impersonate-another-user
a) User account (A) needs the privilege prvActOnBehalfOfAnotherUser, which is included in the Delegate security role.
b) 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.
I cannot observe either of these statements.
- I created a simple plugin, which queries records of entity X and outputs the count of found records
- I triggered the plugin with a System Administrator user and the query found all records, say 10. OK.
- I triggered the plugin with a restricted user A.
- This user did not have any privileges on entity X.
- This user did not have the prvActOnBehalfOfAnotherUser privilege
- As expected, an exception was thrown: Principal user ... is missing prvReadX privilege
- I triggered the plugin with a restricted user. This time the plugin impersonated as SYSTEM user
- The plugin executed without exception and found all 10 records.
I wonder:
- Why is impersonation possible even though user A does not have the prvActOnBehalfOfAnotherUser privilege?
- -> Contradiction to statement a) of the documentation.
- Why did the query find records of entity X even though user A does not have read access to any records of entity X?
- -> Contradiction to statement b) of the documentation.
I used two kinds of impersonation.
1) By the plugin itself at runtime:
var factory = (IOrganizationServiceFactory)localContext.ServiceProvider.GetService(typeof(IOrganizationServiceFactory));
var service = factory.CreateOrganizationService(null);
2) Using the plugin registration tool (Run in users context: SYSTEM)
I reproduced the behavior in Dynamics CRM 2011 and 2016 On Premises. And in Dynamics CRM 365 Online. In the On Premise environments, I did not configure anything special in Active Directory (PrivUserGroup).
Why does the observed behavior not correspond to the documentation?
Thanks!
Johannes.
