Troubleshooting permission issues

In a previous post I gave a brief overview of the security model in MSCRM. And there definitely is more to be said about best practices when it comes to setting up security roles etc. which I will hopefully cover at some point.

That said, there are times when we encounter a permission error whereby a user cannot perform a certain action. Some times it is obvious such as not having "Create" permission on a given entity and sometimes it is less obvious when dealing with some of the more esoteric permissions in CRM that have dependencies on some other lesser known permissions in order to perform the action.

In these cases you will likely be presented with the "logged-on user does not have the appropriate security permissions to view the records or perform the specific action" message.

So what is the best way to troubleshot this type issue when it occurs?

Well first of all, you should consider which entities are involved in this action. When performing an update or assign action, there could be 2 entities involved. Both the one being assigned and updated and the parent entity that it is being assigned/updated to. That's because there is both the "Append" and "Append To" permissions and if these are not set up correctly it could result in a permission error even when trying to perform an action on a child entity (i.e. the permission problem could be indirect rather than directly on the entity you are trying to perform the action). A discussion of the "Append" and "Append To" privileges is outside the scope of this post, but once again I hope to address both in terms of explaining the difference between these somewhat confusing privileges along with best practices in terms of setting them.

If the above analysis does not lead you to the resolution of your permission error, you should employ the use of the CRM Diag Tool. As an aside, knowing how to properly analyze the log info produced by this tool can save you many support calls with Microsoft support (which will in turn save you time and money).

A good summary for the steps required for analyzing the log info is provided at the bottom of this post. Here is another rendition:

• Run the CRM Diag Tool and enable tracing
• Reproduce the error
• Disable trable
• Open up the log file and run a search on "Error Message" or "Error Number". You should find a section that looks like the following:

Stack Trace Info: [CrmSecurityException: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: ef295fca-91bf-dc11-99aa-0016353b5824 and PrivilegeId: c2aff40c-6e68-4437-a631-488a354a1860]

• The key piece of information is the Guid of the PrivilegeId
• Take this Guid and plug it into the following query:

select Name from PrivilegeBase where PrivilegeId = 'c2aff40c-6e68-4437-a631-488a354a1860'

...and you should be the returned with the name of the offending privilege: prvReadIncident

That is, in this case, the user does not have sufficient Read privileges on the Incident (aka Case) entity.

• Make some changes to this permission (e.g. increase scope from "user" to "BU") and your problem should be resolved