Viewing all CRM Privileges, including hidden Privileges
Our guest blogger today is CRM MVP David Jennaway, the technical director of Excitation Ltd, a Microsoft Gold Partner in the UK that specializes in delivering Microsoft CRM solutions.
Authorization in CRM is controlled via security roles; a user is made a member of one or more roles, and receives the privileges associated with those roles. The privileges associated with a role can be viewed and modified via the tabs on the Role form:
Although this form displays a lot of potential privileges, there are a few hidden privileges within CRM that are not accessible via the CRM user interface. The built-in security roles in CRM are granted the relevant hidden privileges, but these privileges will not necessarily be granted to custom security roles. If you create a custom role from scratch, it will not receive any hidden privileges, whereas if you copy a role, then the new copy will receive the hidden privileges associated with the role that was copied. However, when viewing a role in CRM, there is no visible information about which (if any) role it was copied from.
Where the role and privilege data is stored
All roles and privileges are stored in the MSCRM database, and can be accessed most easily via custom reports. Relevant data is stored in the following tables and/or views:
| Objects | Table or View | Comments |
| FilteredSystemUserRoles | View | One record for each role a user is a member of |
| FilteredRole | View | One record for each combination of role and business unit |
| RolePrivileges | Table | One record for each privilege held by a role (equivalent to an icon on the role form) |
| FilteredPrivilege | View | One record per possible privilege |
| PrivilegeObjectTypeCodes | Table | Link table to relate a privilege to an entity |
| MetadataSchema.Entity | Table | Metadata table, with one record per entity |
Note that users only have SQL permission to access the filtered views directly. Those entities listed above as tables have no associated filtered view can only be queried if the SQL Server database owner grants permission on these objects. Also, it is not supported to directly access these tables, so their structure may be changed without warning; I have no qualms about reading data from these tables, but I would never consider modifying data directly in these tables.
Two columns need further explanation to help interpret the data in these tables: FilteredPrivilege.AccessRight. This identifies the action the privilege applies to:
| Value | Action |
| 1 | Read |
| 2 | Write |
| 4 | Append |
| 16 | AppendTo |
| 32 | Create |
| 65536 | Delete |
| 262144 | Share |
| 524288 | Assign |
Although the bit values could allow one privilege to be associated with more than action, this never happens in CRM.
RolePrivileges.PrivilegeDepthMask. This indicates the level of the privilege:
| Value | Level |
| 1 | User |
| 2 | Business Unit |
| 4 | Parent: Child |
| 8 | Organisation |
It is worth allocating privileges to one of two categories; entity privileges and miscellaneous privileges. Entity privileges necessarily apply to a specific entity, and separate privileges are required for each action (e.g. Create, Read). Miscellaneous privileges are most easily categorised as privileges that do not relate to one of the standard 8 actions on an entity. It is worth noting that some miscellaneous privileges do apply to a particular entity (e.g. prvPublishArticle), and some don’t (e.g. prvExportToExcel)
Miscellaneous privileges
The first report (MiscellaneousPrivilegesByRole) displays a matrix, allowing comparison of miscellaneous privileges between roles. This can be used to illustrate the issue with hidden privileges that was described earlier. The following output shows two roles, the built-in System Administrator role, and a custom role ‘Granted all Privileges via UI’ which, as named, was created as a blank role, but was then granted all privileges available in the CRM user interface. For space reasons I’ve only displayed the first 20 or so privileges.
Here you can see there are several differences, which are not apparent via the CRM user interface.
Entity Privileges
The second report (EntityPrivilegesByRole) displays all entity privileges in a similar way to the CRM user interface. This illustrates another point about privileges; that not all entity privileges are displayed in CRM, and that there are hidden entity privileges. Here are the first few entity privileges for the System Administrator role:
And here are those for my custom role:
Although the privileges for the more common entities (e.g. Account, Contact) are the same, there are some discrepancies in other entities, e.g. BusinessUnit and CustomerRelationship.
It should be stressed that not all of these privileges are used by CRM, and many of the hidden privileges will have no effect on your CRM system. However, these reports do allow you to drill deeper into the actual privileges than you can via the CRM user interface.
Summing up
There are some subtleties around the CRM privileges, especially as not all privileges are visible via the CRM user interface; however the privilege data can be accessed via SQL reports. When creating a custom role, it makes a difference whether you create the role from scratch, or whether you copy an existing role – you only get the hidden privileges if you copy an existing role with those privileges.
It is possible to programmatically access and change the hidden privileges via the CRM platform, using the AddPrivilegesRole, RemovePrivilegeRole and RetrieveRolePrivilegesRole messages, though this will require some development work.
