Security concepts for Microsoft Dynamics CRM

Article
05/27/2016

Applies To: Dynamics CRM 2015

You use the security model in Microsoft Dynamics CRM to protect the data integrity and privacy in a Microsoft Dynamics CRM organization. The security model also promotes efficient data access and collaboration. The goals of the model are as follows:

Provide a multi-tiered licensing model for users.
Grant users access that allows only the levels of information required to do their jobs.
Categorize users and teams by security role and restrict access based on those roles.
Support data sharing so that users can be granted access to objects they do not own for a one-time collaborative effort.
Prevent access to objects a user does not own or share.

You combine business units, role-based security, record-based security, and field-based security to define the overall access to information that users have in your Microsoft Dynamics CRM organization.

For more information about security topics, see the Microsoft Dynamics CRM SDK topic, MSDN: The Security Model of Microsoft Dynamics CRM.

Business units

A business unit basically is a group of users. Large organizations with multiple customer bases often use multiple business units to control data access and define security roles so that users can access records only in their own business unit. More information: Create or edit business units

Role-based security

You can use role-based security to group sets of privileges together into roles that describe the tasks that can be performed by a user or team. Microsoft Dynamics CRM includes a set of predefined security roles, each of which is a set of privileges aggregated to make security management easier. The bulk of the privileges define the ability to create, read, write, delete and share records of a specific entity type. Each privilege also defines how broadly the privilege applies: at the user level, business unit level, the entire business unit hierarchy or across the entire organization.

For example, if you sign in as a user that is assigned the Salesperson role, you have the privileges to read, write and share accounts for the entire organization, but you can only delete account records that you own. Also, you have no privileges to perform system administration tasks such as install product updates, or to add users to the system.

A user that has been assigned the Vice President of Sales role can perform a wider set of tasks (and has a greater number of privileges) associated with viewing and modifying data and resources than can a user who has been assigned to the Salesperson role. A user assigned the Vice President of Sales role can, for instance, read and assign any account to anyone in the system, while a user assigned the Salesperson role cannot.

There are two roles that have very broad privileges: System Administrator and Customizer. To minimize misconfiguration, the use of these two roles should be limited to a few people in your organization responsible for administering and customizing Microsoft Dynamics CRM. Organizations can also customize existing roles and create its own roles to meet their needs. More information: Security roles and privileges

User-based access and licensing

By default, when you create a user the user has read and write access to any data for which they have permission. Also, by default, the user client access license (CAL) is set to Professional. You can change either of these settings to further restrict data and feature access.

Access mode. This setting determines the level of access for each user.

Read-Write access. By default, users have Read-Write access that allows them access to data for which they have appropriate permission set by security roles.
Administrative access. Allows access to areas that the user has appropriate permission set by security roles but doesn’t allow the user to view or access business data typically found in the Sales, Service, and Marketing areas, such as accounts, contacts, leads, opportunities, campaigns, and cases. For example, Administrative access can be used to create CRM administrators who can have access to perform a complete variety of administrative tasks, such as create business units, create users, set duplicate detection, but cannot view or access any business data. Notice that users who are assigned this access mode do not consume a CAL.
Read access. Allows access to areas for which the user has appropriate access set by security role but the user with Read access can only view data and can’t create or change existing data. For example, a user with the system administrator security role who has read access can view business units, users, and teams but can’t create or modify those records.

License type. This sets the user CAL and determines what features and areas are available to the user. This feature and area control is separate from the user’s security role setting. By default, users are created with Professional CAL for the most feature and area access that they have permission granted. More information: Blog: Understanding Dynamics CRM Licensing 2015

Record-based security

You can use record-based security to control user and team rights to perform actions on individual records. This applies to instances of entities (records) and is provided by access rights. The owner of a record can share, or grant access to a record to another user or team. When this is done, they must choose which rights they are granting. For example, the owner of an account record can grant read access to that account information, but not grant write access.

Access rights apply only after privileges have taken effect. For example, if a user does not have the privileges to view (read) account records, they will be unable to view any account, regardless of the access rights another user might grant them to a specific account through sharing.

Hierarchy security

You can use the hierarchy security model for accessing hierarchical data. With this additional security, you gain a more granular access to records, allowing managers to access the records of their reports for approval or do work on reports’ behalf. More information: Hierarchy security

Field-based security

You can use field-level security to restrict access to specific high business impact fields in an entity only to specified users or teams. Like record-based security, this applies after privileges have taken affect. For example, a user may have privileges to read an account, but can be restricted from seeing specific fields in all accounts. More information: Field level security

Deployment-wide administrative-level security (on-premises only)

During installation, Microsoft Dynamics CRM Server Setup creates a special deployment-wide administrator role and attaches it to the user account that is used to run Microsoft Dynamics CRM Server Setup. Deployment Administrators have complete and unrestricted access to all organizations in Deployment Manager in the Microsoft Dynamics CRM (on-premises) deployment. The Deployment Administrator role is not a security role and does not appear in the Microsoft Dynamics CRM web application as such.

Deployment Administrators can create new organizations or disable any existing organization in the deployment. Conversely, members of the System Administrator Role only have permissions within the organization where the user and security role are located.

Important

When a deployment administrator creates an organization, that administrator must give db_owner privileges for the org’s databases to the other deployment administrators so that they also have full access to those organizations.

For more information about the Deployment Administrator role, see the Deployment Manager Help.

Share via