Sunday, February 10, 2013

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.

image

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

image

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.

3 comments:

jeff loucks said...

Do you prefer Magiannos or McCormick's? Can you name the 4 steak restaurants in Bellevue?

Ankit Shah said...

Hello Leon,

Thank you for sharing this post.

I have a list of questions. Please try to get answers of them,

1. When shall Dynamics CRM support HTML 5? Do we still need to continue with Silverlight development?
2. After Orion update, suppose, if there would be no ribbon on the forms, then what would happen with all the custom ribbon buttons?
3. The new form UI does not support Jscript. Do they plan to remove it for all forms? If yes then what would happen with the current JavaScript code?
4. Related to question #3. Do we need to start writing plug-ins for the current implementation or we should ask users to run the forms in classic mode till CRM provide Jscript support in next release?
5. When Internet Lead Capture feature will be available with CRM 2011 online for non-US customers/partners? According to my knowledge, at present it is available only for US region.
6. CRM 2011 online - how to change the goal roll-up system job scheduling time? For more details you can refer below link.
http://ankit.inkeysolutions.com/2012/08/dynamics-crm-2011-change-execution-time.html

Simon Hetzel said...

Hi Leon,

Like Ankit, I want to know what the upgrade paths are going to be UR12 -> Polaris -> Gemini -> Orion. Especially how are the "new features" going to be delivered separately to the "fixes"? This particularly applies to CRM Online where one is "not in control".

Getting two MS CRM Online organisations to be the same (let alone match on-premise) is becoming increasingly difficult (e.g. for Dev/Test purposes). The recent December 2012 Service Update only seems to have made things worse. MS assert that new features can be "disabled" once installed - it's mostly true except of course when it is not... (e.g. the changes to lead qualification dialog).

As the gulf between on-premise and (plus existing on-line orgs) and new trial orgs widens and the pace with which new features are released to Online, just how exactly will you be able to quickly spin up a new environment for Dev/Test purposes? You want it to match the pre-existing CRM online organisation you are still using in Live but if "new features" are installed by default and cannot be uninstalled (merely "disabled" is not realiable enough) you are now stuck.

And before MS says that is what the new multi-org O365 instances are for please tell them to think again. $500+/month to keep a Dev/Test environment alive even when you are not using it is just not realistic for smaller organisations - some of the main consumers of CRM Online.

Simon