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)