Assigned and Inherited Security Roles
I bet you think that you absolutely, positively know the answer to the following question.
All users logging into the Microsoft Dynamics CRM 2011 must have an assigned user security role?
Yes or No?
Would you be willing to bet your reputation that the answer is Yes – guess what?
You got it wrong!
Don’t be embarrassed. I have been implementing CRM since 2003 and a fellow MVP – Mitch Milam, who authored the Dynamics CRM Deep Dive Security Book was equally shocked to discover that this is possible. How could two experienced CRM implementers get this wrong? I will walk you through how this can occur. (FYI – Mitch and I am collaborating together to further understand this scenario).
And as a CRM administrator if you have every removed the assigned security roles for a User so that they can’t access the CRM system, they still may be able to do so. It isn’t a certain method to remove a user’s access.
How is this possible you ask? It clearly states in the Office 365 setup that when you add a new user to CRM you must assign them a security role so they can access the Dynamics CRM Organization.
![]() |
And if you check several resources it sure implies that assigned security roles are essential:
Help on this page says “All users must have a security role assigned to them, or they will be unable to use the system. Even if a user is a member of a team with its own security privileges, the user will be unable to see some data and may experience other problems when trying to use the system.”
MSDN article #1 Users and Team Entities says “When you create a user, you must assign the user to at least one security role. Even if the user is part of a team that has assigned roles, the user should be assigned to a role.”
MSDN article #2 How Role-Based Security Can Be Used to Control Access to Entities in Microsoft Dynamics it says “All users must be assigned to one or more predefined or custom roles. In Microsoft Dynamics CRM 2011, roles can also be assigned to teams. When a user or team is assigned to one of these roles, the person or team members are assigned the set of privileges associated with that role. A user must be assigned to at least one role.”
The Help and MSDN articles sure seem to strongly imply that an assigned security role is a pre-requisite.
Let me show you how a new or existing user can access CRM without an assigned security role.
Step 1 – Create the user record but don’t assign a security role.
![]() |
Step 2. When they try to login they will get this message.
![]() |
Step 3. Assign the new user – Bill Tester to a the CRMIT2 Team. Which is the default Team. Or you could assign him to any Team. (see where we are going with this?)
![]() |
Step 4. Now Assign the Sales Manager role (or any active role, including the System Administrator) to the Team.
![]() |
Step 5. Now have Bill Tester login into the CRM system. You can see by this screen shot that Bill is logged in, he is viewing his own user record that has no assigned security roles but is clearly able to login to CRM and use the system with all the rights of the inherited role.
![]() |
So as the CRM System Administrator what should you do now that you are aware of this scenario?
- Never assign the System Customizer or System Administrator roles to the default Team.
- When you need to disable a user’s access, don’t rely on removing their assigned roles as a secure approach.
- Be very cautious when setting up Teams and assigning security roles to the Team. You can clearly provide unanticipated access to CRM.
- The security role inherited by the Team members doesn’t just apply to the records owned by the Team. It applies system wide in the case of inherited roles as per #1 above.
- Read my TechNet CRM Wiki article on How to Avoid Human Induced Catastrophe in CRM which I will be updating with this new cautionary note regarding the unanticipated power of Teams.
Stay tuned for more as Mitch and I delve into this further. One area that Mitch is investigating is that there is a possibility that inherited roles don’t provide 100% of the same rights as an Assigned Role.
[…] post Assigned and Inherited Security Roles appeared first on Innovating on […]
I think Microsoft’s double-speak in the various bits of documentation really means something like “it won’t work properly unless you assign at least one role to the user”. I’ve read a number of posts in the past where people say that Roles assigned exclusively to Teams don’t quite work properly.
Here are some examples I found quickly just now:
http://community.dynamics.com/product/crm/f/117/p/52982/100074.aspx
http://social.microsoft.com/Forums/uk/crm/thread/fd84f584-afe5-4373-80d7-030d5a9edc87
There way well be others.
—
Simon
“One area that Mitch is investigating is that there is a possibility that inherited roles don’t provide 100% of the same rights as an Assigned Role.”
This is true. In addition to the security role your users will get from the team, create one additional security role with user-level access for all privileges, for two entities only:
– User Entity UI Settings
– User EntityInstanceData:
This should solve the issue. I guess you need to perform a few more tests around this
I’ve found (using CRM Online) that Abhirup’s settings are not sufficient. Any user-level create priviledges on the team seem to only allow team members to create records with the owner explicitly set to the team itself (and not to themselves or any of the other team members).
Personally I consider that a bug (although Microsoft would doubtless consider otherwise). Is this your experience also?
Actually I’ve just realised this applies to ALL user-level privileges…