Security behavior

(0) Share

Report

Posted on by Community Member

Hello,

I created a new security role and assigned it to "user". The role has a privilege "Write" for all records of some entity (global level).

There is a code that tries to update entity by ID:

ClientCredentials clientCredentials = new ClientCredentials();
clientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;               
clientCredentials.Windows.ClientCredential = new System.Net.NetworkCredential("user", "password", "domain");               

OrganizationServiceProxy _crmService = new OrganizationServiceProxy(new Uri("crm.com/.../Organization.svc"), null, clientCredentials, null);                    

Entity entity = new Entity("new_entity");
entity.Id = new Guid("11111111-1111-1111-1111-111111111111");
entity["new_textattribute"] = "Try to update...";

_crmService.Update(entity);

When executing the code, an error occurs that requires a privilege "Read":

Principal user is missing prvReadnew_entity privilege

Is this normal security behavior?

This role should not have a privilege to Read, only to Write.

Any suggestions?

*This post is locked for comments

I have the same question (0)

All responses (13)

Answers (1)

Suggested answer

Wayne Walton 13,730 on at

Like (0)

Report

You can't write to an entity without being able to read the existing record. You can, however, create new records without read permissions.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Why, when setting the privilege to Write, does not autotmatically set the privilege for Reading?

Is it a bug in the interface of the role?

Was this reply helpful? Yes No
Wayne Walton 13,730 on at

Like (0)

Report

It's by design.

Was this reply helpful? Yes No
Suggested answer

Rawish Kumar 13,758 on at

Like (0)

Report

Hi, its an expected behavior.

it will not set any other privileges automatically. You have to add read privileges manually.

Was this reply helpful? Yes No
Suggested answer

gdas 50,091 Moderator on at

Like (0)

Report

Hi ,

If you logically think like unless if you have read access you can not edit the record and this is applicable from anywhere you create the record using Organization service .

You can check the dependency access rights in below reference -

msdn.microsoft.com/.../gg334673.aspx

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

"Dependency access rights" don't contain information that the privilege "Write" requires privilege “Read”. Where is in SDK it explicitly indicated that Write privilege requires Read privilege?

Sorry, but for me it looks like a bug.

Is there a way to update the entity for an user without Read privilege?

Was this reply helpful? Yes No
Verified answer

Wayne Walton 13,730 on at

Like (0)

Report

It explicitly is not a bug. Just because the behavior in't how you would prefer, it is exactly how MS wrote it. (which is not to say there aren't things I would change about the CRM security model, but there's a difference between an unwanted feature and a bug)

There is no way to update an entity without Read access. You cannot blind-update a record.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Clearly, this is an undocumented feature, and it suits most)

Is there a solution for this task?

Update an estimated amount of an opportunity when the user changes the opportunity product amount, but for the user the opportunity is not available, and the opportunity must have logging, who changed the estimated amount.

Was this reply helpful? Yes No
Wayne Walton 13,730 on at

Like (0)

Report

No, it's documented: docs.microsoft.com/.../security-model There's a whole section on how the security model works. you can even search by priv failures to find exactly what access your security role lacks.

To solve your problem, you're going to have issues anyway, because how are you going to let your users update an Opportunity Product without access to an Opportunity? The true solution would be to give this special user Read and Append To permission to the Opportunity, then Read, Edit, and Append permissions to the Opp Product. The system will do the recalculation for you, that's literally built into the Opportunity process.

If there is any specific data on an Opportunity they can't be allowed to see, protect that field with field-level security, not by banning them from reading the Opp.

Frankly, the requirement makes no sense, and it's something I would push back on to the business.

Was this reply helpful? Yes No
gdas 50,091 Moderator on at

Like (0)

Report

Hello ,

I agreed with you , but seems you missed the URL which I have shared , here its clearly mentioned that to create record you should have Read and Write both access rights.

This is how dynamics CRM security model works and this is not a bug. You can compare with real life scenario like if a sales person does not have any read access to opportunity record the he should not able to update the opportunity as won from UI of Dynamics 365.

So you can say this is bug as you have the Write access but you can not modify the record in that perspective. But keeping in mind both the scenario update from UI and update from back end (Update via code) , to align with same structure Microsoft use the common rules for both the cases , so you can say its by design.

Hope this helps you to understand

Was this reply helpful? Yes No