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

All responses (13)

Answers (1)

Community Member on at

Like (0)

Report

RE: Security behavior

I wrote the last answer of what, in my opinion, is not enough in the documentation.

I can unify the task - cascade update the parent (parent of parent \ parent of parent of parent \ and so on…) entity when changing the child. A user should not have access to parent (parent of parent \ …) entity. А business requirement is to see who caused the update of the parent (parent of parent \ …) entity.

It looks like that without the additional custom entities, that will store information about users, and plugins with “read parent (parent of parent \ ...) entity” user context, this task can’t be solved by basic behavior.
Community Member on at

Like (0)

Report

RE: Security behavior

I read SDK well, which you sent.)

My question was related only to updating the record, not creating.

“Dependencies between access rights” must also have a line that the WRITE requires WRITE and READ to be relevant to the behavior of the system. Updating a record can happen not only via code and the interface, but also through processes and dialogs.
Suggested answer

Arpit Shrivastava 7,518 User Group Leader on at

Like (0)

Report
RE: Security behavior

Hi,

By any chance, you tried to achieve this requirement using Roll-Up Field.

I think Rollup field will do this calculation for you automatically (by doing few simple configurations) without writing the script/code. The only limitation is, it's an async process, can take time to show updates (Max 1 hr).

Some examples of rollup fields include:

Total estimated revenue of open opportunities of an account

Total estimated revenue from open opportunities across all accounts in a hierarchy

Total estimated revenue of an opportunity including child opportunities

Total estimated value of qualified leads generated by a campaign

Number of high priority open cases across all accounts in a hierarchy

Earliest created time of all high priority open cases for an account

Hope it helps:

https://www.powerobjects.com/2014/10/10/roll-up-fields-dynamics-crm-2015/

https://technet.microsoft.com/en-us/library/dn832162.aspx?f=255&MSPPError=-2147217396

If my answer helped to resolve your issue, kindly verify it by clicking 'Yes'. It would be helpful to the other community members seeking to resolve a similar issue.

Cheers
Arpit
https://arpitmscrmhunt.blogspot.in
gdas 50,091 Moderator on at

Like (0)

Report

RE: Security behavior

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
Wayne Walton 13,728 on at

Like (0)

Report

RE: Security behavior

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.
Community Member on at

Like (0)

Report

RE: Security behavior

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.
Verified answer

Wayne Walton 13,728 on at

Like (0)

Report

RE: Security behavior

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.
Community Member on at

Like (0)

Report

RE: Security behavior

"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?
Suggested answer

gdas 50,091 Moderator on at

Like (0)

Report

RE: Security behavior

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
Suggested answer

Rawish Kumar 13,758 on at

Like (0)

Report

RE: Security behavior

Hi, its an expected behavior.

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