Источник:
https://crmtipoftheday.com/1167/impe...-extra-powers/
==============
I did write before about
impersonating users. It’s a very straightforward “manoeuvre” and is commonly used when there is a service account (could be either
non-interactive user or, better,
application user) that needs to act as a specific user. There is even a built-in role
Delegate which contains an absolute minimum set of privileges required to impersonate someone, including coveted
prvActOnBehalfOfAnotherUser privilege.
I did manage to shoot myself in a foot though. I created an application user, granted it
Delegate role and fired away the test code creating a contact. Kaboom:
System.ServiceModel.FaultException`1: 'Principal user (Id=31ba5b71-82ad-e711-a823-000d3aa32537, type=8 , accessMode=0, roleCount=3 ) is missing prvCreateContact privilege (Id=a8bff87f-0df0-41d4-babd-f093faf1e32c)'
The user id was referring to the user being impersonated and that user definitely had permissions to create a contact. What the?
What happened is that I completely forgot one of the fundamental security principles:
One shall not pretend to be someone else to elevate permissions beyond of what they already have
Of course, it’s a case of
RTFM, and I quote:
The actual set of privileges … is the intersection of the privileges… 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
Oh, well, system administrator role it is then… Just kidding.
(
Facebook and twitter cover photo by Javardh on Unsplash)
Источник:
https://crmtipoftheday.com/1167/impe...-extra-powers/