Bad CRM Security Habits To Break

This time next week I will be on a plane heading to the MVP Summit at Seattle/Bellevue/Redmond. So, if you have any questions for the Microsoft Dynamics CRM Team in Redmond, feel free to add them below. I promise to ask all the questions you post (even the cheeky ones) and, for the answers which do not get me kicked out of the MVP programme, I will post the responses.

To the blog. There are some bad habits, when it comes to security, which are a remnant of previous versions of CRM (and from just doing things to cut corners when under pressure). I will show you what they are, why they are “poor man’s security” and the better approach.

Hiding Fields

Before CRM 2011, there was NO comprehensive field level security. Essentially, if you had access to the record, you had access to all the fields on the form. There was no way to let one user see a field on a record and guarantee another user could not see it. You could work around things a little bit with things like using jscript to hide tabs or hide fields on the form but you could always add the field as a column in an Advanced Find and see its contents this way. Even if the Searchable property is marked to ‘No’ this just means the field is not available as a condition for the Advanced find; it is still available as a column.

A cursory search on the internet generates many claims of field level security for CRM 4. There is even a Microsoft white paper on the ‘workarounds’ for version 4 which describes how plug-ins can be used to block the Advanced Find workaround above. However, the paper acknowledges the plug-ins cannot intercept access to the Filtered Views, as is done with Dynamic Excel exports.

Therefore, even the commercial products on the market at the time claiming field level security , unless they knew more than Microsoft themselves, either used unsupported methods or were not complete.

In my experience of CRM implementations back then, given the option of a comprehensive (and expensive) plug-in solution or some cheap jscript which was not airtight but did a rough job of it, the client picked the jscript every time. These systems are now being upgraded to CRM 2011 and, frankly, there is no excuse for this nonsense in a CRM 2011 system.

The Better Option for Fields

In CRM 2011 we now have proper field level security. When configuring the field, you tick the box.

Then you set up a security profile and say which users or teams can access it.

Ideally, in my opinion, the security profiles should be linked to a security role, rather than a user/team, to simplify on-going administration maintenance (users come and go but roles remain) but, given we had nothing before, this is a vast improvement.

Hiding Entities and Poor Assumptions

This section covers a couple of entity security sins. Firstly, the obvious one. With the sitemap, it was always possible to ‘hide’ entities by editing the XML. After all, if a user cannot click on the entity, they cannot access it, right? The second sin is the poor assumption that entity security ends with configuring user access via the security roles. For example, if we want to secure activities, all we need to do is set up our Business Units and set up the correct security roles, right?

The answer in both cases is, surprisingly (especially in the second case), “no”. Again, the CRM hacker’s favourite tool, Advanced Find undoes our good intentions.

In the first example, the Advanced Find lets us access all entities (even ones not linked to any other entity e.g. configuration setting entities, or in the sitemap). In the second example, while it is true we cannot access the activities (CRM security is sufficiently robust for that), we can access the child records such as notes. If there are good reasons to secure appointments, it is a fair bet that the same rules need to be applied to notes. If not, a user could pull up Advanced Find and access all the note records in the system and probably access inappropriate information. When setting up security, never forget the child entities, especially notes.

Conclusions

Security configuration in CRM has come a long way from version 4 but some habits die hard. Field level security should not be confused with user experience design and, now the tools are there to set field level security properly, they should be used. Also, when considering the security required to meet a business’ needs, think of the information being held, not just the entities otherwise notes will trip you up every time.

Good luck.