Dynamics CRM Security Components Overview

Dynamics CRM Security Components Overview

Reference -

https://community.dynamics.com/crm/b/weaponizedcrm/archive/2015/02/27/dynamics-crm-security-components-overview

The core security components within Dynamics CRM are organizations, business units, privileges, security roles, teams and users. There are a lot of implications to how these components are used when designing a system. It is only with a proper understanding of what these components are and how they behave that you can ensure that the final product of your system design works as it should and protects your data. In the sections that follow I’ll take a short walk through each one of these and discuss what they are and can be used in your CRM system. While this will not be an exhaustive conversation it is a good start especially if you are newer to the platform.

Organizations

I look at an organization as the global boundary between two or more systems. In a single organization system this doesn’t come into play so much. In a multi-tenant system it matters especially if you choose to utilize some of the more advanced integration techniques between two or more organization (more on that another time).

Multi-organization can progressively take the form of one or more of the following:

1. Two or more tenants within the same system deployment running on the same front-end, back-end and database servers, etc.
2. Two or more tenants that are hosted in different deployments running on separate front-end, back-end and database servers, etc.
3. Two or more tenants hosted in different deployments running on separate front-end, back-end and database servers in different geo-located datacenters.

The “lowest form” of a multi-tenant system is one which deploys two or more tenants on the same system. This is of course the most economical because there are less hardware assets that need to be configured and maintained. This is a great option for a small systems that perhaps have grown and the customer has decided to separate the use cases out of a single tenant solution. This is the hardest transition to make out of the three iterations of a multi-tenant system because the work of spiting the use cases is where the most work needs to be done. Once separated scaling up or out is simply a matter of moving organization off into separate deployments or datacenters. The integration aspects of scaling out quickly become interesting as you may imagine (more on that another time).

Business Units

A business unit is a sub-organization of sorts within a system. The name of this security feature is unfortunately misleading. The name has been the same for a long time and there is probably no political will to change it so it is what it is. A CRM business unit is really what I refer to as a security group. It has absolutely nothing to do with the concept of an organizational business unit and it should not arbitrarily be used to recreate the actual structure of a company’s business organization. It should instead be used based on the security needs of the system. An example of this is in the financial industry. When opportunities of a certain value are created it may be considered an MNP or material non-public record. This means that only specific users within the system should be able to see that this opportunity exists. While the users may reside within the company business unit, a strategy to hide these kind of opportunities may be to create them in a separate business unit. As mentioned earlier a CRM business unit is purely a security boundary for hiding information within the same CRM organization and should be used as such.

The interesting thing about business units is that there is always a root business unit in each organization and has the same name as the CRM organization. You can think of this root business unit as the business unit that represents the whole CRM organization. If you want, the root business unit is planet earth and each business unit underneath is a country. There can only be one root business unit so all others must be a child of the root. The strategy for child business is that if you want to be able to grant some set of users the ability to see all data within a specific business unit and all child business units underneath you can. An example of this may be that there is a sales territory and underneath it are a set of regional sales territories. Salesmen may be assigned to a given region territory, but the sales manager for entire territory would want to be able to see records for all regions that report to him. This would be built having an understanding of the how the data is to be accessed and why security considerations should be part of the system design from the start of a project. In the scheme of system design the correct application of business units is important because the final result of that design will carry implications for the rest of the system.

Privileges

A privilege is a capability that a security principle (user or team) can be assigned. It acts much like a key to unlock a door and once granted it cannot be revoked. You can give copies of the same key to someone and effectively it doesn’t really matter because any one of them will work. The challenge arises when it comes to management because if you have given someone multiple keys and you take one of them away with the intent of restricting access you will then have to hunt down and collect the remaining keys as well before the restriction takes effect.

 Security Roles

Security roles are a collection of privileges that can be assigned to a security principle (user or team). You can’t assign a privilege to a user or team directly so it can only be given via a role. If desired you can create a role with a single privilege granted in it. There are occasions where this may make sense for scenarios like granting the export to Excel or Use CRM for tablets privileges. The typically strategy deployed within a system is to create a security role that equates to a business user role. As the default security role names suggest you can create a collection of privileges that can be assigned to a salesman, a customer support resource or a CEO.

Since security roles can be extremely granular a security designer has to weigh and balance creating very detailed roles where only a given set of privileges are granted to very broad roles where many privileges are granted in one or two roles. It is an unfortunate common practice on projects to consider the security implications last or as an after-thought. What tends to happen is that the design of the security subsystems is rushed and not designing pragmatically. Usually this means is that business units will be used for general separation of data and very broad security roles will be granted that fundamentally give users the ability to see and do whatever they want. Most often the only privilege that will be taken away is the right to delete.

On the other side of the equation you can make the roles extremely granular to the point where there are dozens of roles and an array of roles will need to be granted to each users or via teams to give them all the necessary rights to perform their job function. This is the most flexible option but without the proper tooling for roles management it fundamentally becomes a maintenance nightmare especially as the number of users grows in number.

The general thought process to find the right balance is to both look at each user class and ask

• What is the very minimum that this group of people need to see and do. Then you can begin to create a role around that conceptual set of privileges.
• The next question is what else do some of these users in this group need to be able to do but not others.

The privileges that fall out of the standard use case are candidates for becoming separate roles. At this point you should put those outlier candidates aside and move on to each of the other user classes defined creating minimal privileged roles. At the end of this exercise you may find that you have a few outlier roles for each group, but you also may find that there are a number of them in common. At this point you can consolidate what makes sense into generic roles that can be optionally assigned to users of each class.

In the case of a multi-tenant system I have come under the theory that the roles between these organizations should be created under the following guidelines:

• Each role should have a unique name that contains the organization prefix
• Each role should have the same exact name in each tenant
• Each role is tailored to what is necessary in the context of the system where it resides

Security in multi-tenant systems can be complicated because another layer has been added for how users are granted privileges. The reason my advice is to have security roles between systems have the same name is for manageability. If a salesman’s primary organization is system A has access to system B and the security roles name is simply “salesman”, but the salesman should not have the same privileges as the primary users of system B, then you have to resort to perhaps creating another role in B for this user. If the names are always the same and include the organization prefix then there is no question about what role should be assigned to each user. The use case for this scenario may be that a salesman in system operates within a particular sales region, but should have certain read-only access to view information in another sales region. As an administrator it is much easier to assign a role to this users called “Systems A – Salesman” than say something called “Salesman 2″ or what have you. Granted the names might be more elaborate but the point remains the same. If the roles have different names in each system, the more organizations that need to be maintained it can become a maintenance issue very quickly especially with a large number of users.

Teams

Teams are a form of virtual user. A user can’t login as a team, but they can act on behalf of a team. Teams are a way of distributing a set of privileges to a group of users. Most people who are familiar with Active Directory with automatically associate a team to be similar to an Active Directory User Group. The association is slightly incorrect because of the way team security works with CRM. In Active Directory if a privilege is granted it is granted to the user who is a member of that group. On the other hand when a privilege is granted to a team as a member of that team, I do not get that privilege directly. I can however perform operations on behalf of that team as if I was that virtual user. The thing with teams is that they can get tricky and not act how they would be perceived to work.

One example is if a user only has user level privileges granted within a business unit. If this user is a member of a team that has business unit level privileges he will be able to see everything that the team can see. Viewing information doesn’t present a problem, but updating, deleting, assign, or associating information can be deceiving. If that team has business unit level privileges then he will be able to do whatever he wants with those privileges within the business unit, but let’s say that team only has user level privileges. What this will mean is that the user will only be able to see his own records and the records owned by that team. Issues can arise when a user is performing an action in a different business based on team privileges if the user doesn’t ensure that the operation is team-centric. This means for example, if I create a contact for an account in this other business unit that I have access to via team membership I have to make sure that I change the owner of the record to the team else I may get an error. Why? Because I can only act as the team when I’m outside my home business unit jurisdiction.

In general it is best practice to model security early in the project to determine if a specific user class should be designated to a business unit or a totally separate tenant. The reason for this is that the more specific the privileges are the more of a performance impact the system will have to maintain those specific low level privileges. The reason for this is that if all users have organization level permissions the platform doesn’t have to work as hard to check if a given user should have access to a record. If every user in the system only has user level privileges then many more queries have to be made to check what records the user should be able to operate on. As the number of users and records in a system grows over time the system will begin to slow down. Initially it may not be noticeable depending on the hardware the platform is running on, but eventually the impact will begin to be noticed all things remaining the same.

Users

As you might expect users are the fundamental security principle in a system. They can be assigned as members of teams and they can also be assigned security roles directly. As security principles belonging to a particular business unit users can operate to the level of privileges granted directly to them. When users need to be able to cross business units they must be joined to teams that are in the specified business units. Teams grant privileges to users and allow them to impersonate the team virtual user.

The culmination of security privileges that a user receives within their own business unit is a product of all the security roles assigned to them. The reason I call out when the privileges within their own business unit is because of the variance in security behavior when dealing with records in an external business unit. The thing to remember about privileges granted to a user is that you if you take away a privilege from a role, but not others that grant that privilege then the user will still be able to use the privilege.

Record Ownership Models

There are three types of record ownership models in CRM

• User Ownership
• Team Ownership
• Hybrid Ownership

User Ownership

User ownership models tends to be used in systems where use case if focused on users. An example of this would be a sales team where each individual salesman owns a set of accounts that they are working. It could be that in this system salesmen are not supposed to be able to see each other’s accounts and may therefore only be assigned user level privileges. In this case if the salesmen are members of the same business unit then it would make sense that they would own and be able to manipulate their own records therefore security privileges would be granted directly to the users.

Team Ownership

Team ownership models on the other hand tend to be used in business scenarios where multiple people need to be able to collaborate on common sets of data. This could be a sales scenario where there is an account team with multiple members with different needed skillsets and expertise. Records would be shared across the team and therefore would make more sense for a team to be the owner. The members of the sales team would then be part of the team that owns the record. Each member could then make updates to the record with the ownership privileges granted to them via team membership. When dealing with external business units the scenario gets a little more complex because of the way teams security differs from user granted security. As mentioned previously this may require a training element to be involved if a user from an external business unit has trouble performing operations against a record in another business unit. In this case we are assuming that the record is already owned by the team so there should not be any problems under this model.

Under the team ownership model is tends to be a good idea to enforce record ownership using plugins. In a typical scenario if a user creates a record it will by default be owned by that user. When an entity is designated as “team owned” it is best for that ownership to be set automatically on creation so that it isn’t something that users have to continually maintain manually.

Hybrid Ownership

A hybrid model typically is deployed when there are multiple use cases being addressed within a given system. One typical scenario of a hybrid is when there are a shared set of accounts, but users may be performing operations against those accounts as individuals. Case in point would be a company with a shared customer master list but salesmen are working opportunities against those accounts. In this example the accounts are a master list not to be owned by any one salesman, but the opportunities are being worked by individual salesmen. The account records would probably be team owned while opportunities would be owned by individual salesmen.

Data Sharing

CRM offers a way of explicitly overriding security privilege assignment by allowing users to share records with another user or team. The purpose of this is to allow for use cases where a predefined security role doesn’t meet the need. If you find that users are performing a lot of record sharing it is typically an indication that the security model may not fit the use case of the system. The problem that can occur if this situation persists is that record sharing is an expensive feature in regards to system performance. It can be a particular problem if sharing is being performed via automation such as in plugins. Each time a record is shared a record is created in the table that CRM uses for keeping track of permissions within the system. This table is heavily used because CRM is using it often to check everything that has a security feature. As this table grows it can be a single point of performance bottlenecks in a system. It is a best practice to monitor the growth of the security table within a system so that if it grows to big or is growing at an alarming rate that the issue can be addressed before it begin to impact system performance.

Access Teams

Access teams was a feature that was introduced in CRM 2011. One of the use cases access teams were created to solve is when teams are dynamic. An example of this could be where the team that works on sales opportunities is different for each opportunity based on business requirements. In this case access teams allows for the sales team to be generated and granted privileges without having to create an owner team or a team that can actually own records. There is an overhead to creating owner teams that access teams alleviates.

The general guidance is that if you have fewer than 1000 teams in your system it is best to use owner teams while if you have more than 1000 teams access teams are recommended. Even with the guidance whether there will be a performance gain from access teams in your specific system may vary when it doesn’t fit the guideline.

Hierarchical Security

Hierarchical security is a feature introduced in CRM 2015. The use case of this feature is for implementing security via a business reporting relationship. For example, when a manager has several direct reports the security model can be setup to where he can see records that are owned by everyone on his team, but the team members can only view their own records. While this can be accomplished using standard security configurations the model allows for this to be setup more easily. The performance impacts of this feature is really yet to be tested heavily in a real scenario. I have not personally been on a project yet that utilizes it, but should I come across I’ll be sure to let you know.