Archive for the ‘CRM Security Roles’ Category
SnapShot! for Dynamics CRM created by fellow MVP Mitch Milam of CRM Accelerators is proving to be a must have not a nice to have utility. Okay, so it isn’t one of those ‘free’ utilities on the codeplex site, but at $249 per CRM Organization it is dirt cheap! It is a great time saver.
In the last few weeks I have personally used it to:
- Extract the complete configuration of a ‘messed up’ environment so we could document what we need to bring forward as we manually re-create the correct configuration in a brand new environment. When done we will use SnapShot! to document the new environment for the client.
- Document the current security roles in use at a client so we could triage several roles so that users wouldn’t be as able to do as much damage as they had been originally allowed to do. I used the Security Roles visualization (shown below) and marked it up and sent it to the client’s Team for review and implementation.
Besides providing a visual display of security roles in a Word document format which allows for easy markup and editing SnapShot! also produces a detailed disclosure of the metadata in an Excel file with tabs for : Entities, Business Unites, Security Roles, Users, User and Team Security Roles, Teams, and Team Membership.
Last week I made a suggestion to Mitch to add some additional entity details to the documentation tool and 3 days later version 1.8 was released which included that info. Now that is responsiveness!
Often the weakest link in protecting the security of the CRM system is the user and not the technology infrastructure. There are some basic steps you can take immediately after installing CRM 2011 or signing up for the CRM Online service to protect your users from themselves. It is all about adjusting the security roles in CRM and taking some other basic precautions to minimize the risk of user induced catastrophe to the CRM system.
1. Never assign the CEO-Business Manager role to the owner of the company. This role has extensive privilege’s and without proper perspective and insight it can do a lot of damage. How often does the Owner get CRM training? Not very often. Unless that is you.
4. Turn on Auditing for all company critical records – Accounts, Contacts, Leads, Opportunities.
9. Besides running the ‘nightly disaster recovery backup’ for the SQL database, you might consider automating the scheduling of periodic onsite backups during the business day if the database isn’t too large.
These are the first 9 steps we perform on every CRM installation we implement.
One of the core underlying principles of security roles is that the permissions are additive and least restrictive. Today while helping a client I observed a situation where this seems to be mis-understood. In the User record below you can see that this CRM user has 14 roles applied to their security role.
A user’s rights are the union of all the roles to which he or she has been assigned. The least restrictive role always applies. There is no reason to pile on Roles that are similar to other roles. This is especially the case if one of the Roles is System Administrator. The System Administrator has full priveleges on all records and functions. This includes automatically granting full rights to any new custom entities.
The following are some guidelines for best practices for use of the Microsoft Dynamics CRM security model:
- Create roles according to the security best practice of least privilege, providing access to the minimum amount of business data required for the task. Assign users the appropriate role for their job.
- Diligently limit the number of people assigned the System Administrator role. Never remove this role.
- Never assign the built-in CEO to the CEO role unless the CEO is you. J. It has far reaching privileges (ie. delete any record)
- Create a new role with those specific privileges and add the user to the new role if a user needs additional access levels or rights. When creating new roles it is best to copy one of the built-in roles and modify it to meet the specific needs for that profile.
- Use sharing, when appropriate, to give specific users specific rights on individual objects, rather than broader privileges on all objects of a given type.
- Use teams to create cross-functional groups, so that specific objects can be shared with the team.
- Train users who have sharing access rights to share the minimum information needed.
- To manage rights to custom entities create roles that contain the specific privileges required for the custom entity function. Add that role to the users that require those rights.