You know the feeling, when you have designed comprehensive security model for the customer, and then you get the call that “something is not right, can you check it out”? If it’s production environment, then you are probably in a hurry already!

But nevertheless, privilege related problems in security roles are very typical, and can happen to anyone, no matter how fancy security model you have designed and implemented. And if you are the architect, but someone else configured your design in to the system, are you certain they did it correctly? Is it flaw in the design or faulty configuration? These thoughts often occur when you start diving into the problem.

I recently got involved in an interesting case, where the initial situation was quite typical, but still the case ended up being nothing like smooth sailing. In this article I want to share the problem scenario, provide some tips and tricks, tools to use and general know-how for troubleshooting similar situations.

NOTE: It is really important to know and understand the security model and practices of your own environment(s) before you can successfully troubleshoot these types of a problem.

Initial situation

It all begin with a typical scenario: “I’m having weird test results, the permissions don’t work as expected in this environment, but it does in this other environment”. User had more visibility to specific records than what was supposed to be.

As with all the projects where I am involved, we have ALM practices in place, managed solutions etc., so everything should’ve been correct, at least in theory. Yet there was definitely something wrong, as it was demonstrated to me in practice as well.

Basic things first

When the problem is: “user sees this and that, but it shouldn’t be possible”, and you know it shouldn’t be possible given the user’s Business Unit and teams, I find it to be usually the most simple scenario to investigate, since basically you just need to find out which security role is granting the excessive privileges.

First tool I usually start with is Access Checker, which can be started on most, if not all record types in your Dataverse. When you have the record open, it can be found in the command bar of that record.

Clicking on it opens this modal dialog, where you can select specific user in the lookup, and the tool will show the direct assigned roles, and roles which you inherit from teams you are a member of. Note that i’m using demo environment for the below illustration.

In the initial problem, the root cause found by this tool, as it directly was showing that the user has wrong role being inherited from a team, which was granting too much privileges for the user. Actually for all the users in that team, as it was not supposed to have that security role at all. Poor users had to go back to having visibility restricted 😛 So removing the security role from the team fixed the initial problem.

More problems

After the initial problem was resolved, I was soon called about another issue regarding an application user. This one was a bit trickier, or maybe it could’ve been straight forward case… check the “Fast track to resolution” section for some hindsight 🙂

Anyway, here is the (anonymized / generalized) error message I received.

The actual error in plain text:

SecLib::CheckPrivilege failed. User: {GUID_HERE}, PrivilegeName: prvReadAttribute, PrivilegeId: {GUID_HERE}, Required Depth: Basic, BusinessUnitId: {GUID_HERE}

Good thing about privilege related error messages is, that they almost always contain enough information to figure it out right away, or at least get some clues what is going on. While prvReadAttribute was not something I had encountered before, I could already see that read permission is required somewhere. But where? I knew that the security role, which was previously granted for the team, contained this privilege as this application user didn’t have the correct permission after removing the security role from the team.

So I opened that security role, and the one I had, side by side in the browser and did initial comparison. Typically there can be some obvious differences found already at this point, and most often it is related to custom entities which someone forgot to add into the security role. But not this time around. Time to see how different tools could help me move forward with this problem.

Tools used

As everything is nowadays about ChatGPT, Copilot, GenAI, LLM’s etc., I decided to start with Copilot.

Maybe it’s just my prompts, but like most of the times I have tried to get answers from it, the answer was not correct. Or at least not all the way correct, basic things were as it should be, but the final resolution was missing or wrong. Usually I only have to ask Copilot when situation is quite tricky, and thats also usually where it fails 😦

Funny enough though, Copilot did guide me to check Custom Entities, which was also my initial thought 😀 But it proved not to be the correct answer.

After some head scratching, I was sure that there HAS TO BE some tool in the XrmToolBox which will help me. And indeed there was! This is always my de facto toolkit, and it has helped me through so many situations. Kudos to all the magnificient people who has contributed to it!

First I wanted to do a more comprehensive comparison between the two security roles with an actual tool, instead of just my eyes trying to catch differences while clicking through the roles. There was tools “CRM Security Role Compare” and “Role Comparator”. Both tools have their own approach to the security role comparison.

One benefit for “CRM Security Role Compare” -tool is the ability to compare more than 2 roles at once in a easily readable format.

Here is the same view from the “Role Comparator” -tool. I tried to click multiple roles, but at least in the visualization I could not get it to display anything else than “left side vs right side”.

Notice that neither of these tools displays the privilege which was required to solve the case. Might have been a user issue, but with the amount of time I spent, I was not able to find the difference with these tools. For more trivial comparison cases, both of these tools will do it’s job, no question about it.

After a round of “Asking For A Friend” ™ from my colleagues, I was tipped about “Privileges Discovery” -tool. Just copypasted the privilege name into the Search -box, selected privilege and clicked “Display roles that match the selection”. I got a clear list of security roles, and the privilege levels of the specific privilege! Really cool tool 🙂

So with this tool I was finally able to confirm that this was in fact the difference between the security roles. Before this, it was just a hunch. But at this point, I still didn’t know WHERE or HOW can I actually grant this privilege, as I wasn’t previously able to pinpoint it in the security role matrix.

That’s when I found another tool: “Role Updater“. This tool seemed simple enough to fulfill my requirements, and get the job done. You just have to write your privilege name into the Search -box, and then you see all the privileges in the box below. Select corresponding privilege, select the permission level, and that’s it!

Then I also confirmed with our developer, that now the error message did not appear anymore, so problem was resolved.

Fast track to resolution

So what was the actual privilege in the Security Role UI?

As always in hindsight, and as some of you readers might have already began to think, is that if I would’ve just gone to check the Security role UI to privilege mapping table , and just searched with the PrivilegeName “prvReadAttribute“, I probably wouldn’t have had to go through so many investigation steps. But then again, I probably wouldn’t be writing this article either, if it would’ve been such an easy case 😉

The table I was supposed to be giving this permission was “Field“, which was found under Customization -tab. It would be really cool if this table name would be visible in the exception message, in addition to the actual privilege name.

Here you can see the privilege and table information in the official documentation:

And here was the missing permission in the Security Role UI:

Conclusion and thoughts

Oh, why did this occur in the first place? The privilege was probably missing because the security role was originally configured on the “Zero Trust security” -principle, and was only granted the privileges which was considered as being required to function properly.

Why the privilege was then not considered as being required? Actually that is very good question! Often security roles are just copies from the out-of-the-box security roles before being worked upon, and most of these “not so obvious” privileges are always included in those security roles already, so typically you wouldn’t have to worry about those.

And even in this case, from the UI there was no issues, as it was only appearing for the application user which was used by the integration.

For future reference to any developers out there, this privilege was apparently required for using RetrieveAttributeRequest in the code. At least this was the point where the exception happened when the privilege was missing.

Hope this helps to understand different possibilities for troubleshooting and fixing the security roles after privilege problems have appeared.

Happy troubleshooting!

PS. Got some tips or approaches which were not mentioned, but are worth mentioning? Let me know in the comments, or DM me! 🙂