Microsoft Dynamics crm planning Guide

Security considerations for Microsoft Dynamics CRM

Isolate the HelpServer role for Internet-facing deployments

To isolate the Microsoft Dynamics CRM Help pages, and help protect the other Microsoft Dynamics CRM Server roles from potential DoS attacks, consider installing the HelpServer role on a separate computer if you implement an IFD.

For information about the options for installing Microsoft Dynamics CRM roles on separate computers, see the Microsoft Dynamics CRM Installing Guide.

For more information about reducing the risk of DoS attacks, see Improving Web Application Security: Threats and Counter-measures (http://go.microsoft.com/fwlink/?linkid=128944).

Microsoft Dynamics CRM installation files

Minimum permissions that are required to install Microsoft Dynamics CRM Server

Network ports for Microsoft Dynamics CRM

The following table lists the ports used for a server that is running a full-server installation of Microsoft Dynamics CRM. Moreover, except for the Microsoft SQL Server role, and the Microsoft Dynamics CRM Connector for SQL Server Reporting Services server role, all server roles are installed on the same computer.

The following table lists the ports that are used for a computer that is running SQL Server and has only SQL Server and the Microsoft Dynamics CRM Connector for SQL Server Reporting Services server roles installed.

Microsoft Dynamics CRM security model

• 
  Support a licensing model for users.
  
• 
  Give users access only to the needed levels of information that are required to do their jobs.
  
• 
  Categorize users by 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 the user does not own or share.
  

Role-based security in Microsoft Dynamics CRM is a grouping of a set of privileges that consists of the responsibilities (or tasks that can be performed) of a user. Microsoft Dynamics CRM includes a set of predefined security roles, each of which is a set of user rights aggregated to make user security management easier. Each application deployment can also have its own roles to meet the needs of different users.

Object-based security in Microsoft Dynamics CRM is about user rights to entities. This applies to individual instances of entities and is provided by user rights. The relationship between a user right and a privilege is that user rights apply only after privileges have taken effect. For example, if users do not have the privilege to read accounts, they will be unable to read any account, regardless of the user rights another user might grant them to a specific account through sharing.

You combine role-based security and object security to define the overall security rights that users have in your custom Microsoft Dynamics CRM application.

Deployment-wide administrative-level security

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 Setup. The Deployment Administrator role is not a security role and does not appear in the Microsoft Dynamics CRM Web application as such.

Deployment administrators have complete and unrestricted access to all organizations in a Microsoft Dynamics CRM deployment. For example, Deployment Administrators can create new organizations or disable any existing organization in the deployment. On the other hand, members of the System Administrators security role only have permissions where the user and security role are located.

For more information about security roles and privileges, see the Microsoft Dynamics CRM Help. For more information about the Deployment Administrator role, see the Deployment Manager Help.

Microsoft Dynamics CRM Server security best practices

• 
  In the machine.config and web.config configuration files you can determine whether debugging is enabled, and also if detailed error messages are sent to the client. You should make sure that debugging is disabled on all production servers, and that a generic error message is sent to the client if a problem occurs. This avoids unnecessary information about the Web Server configuration being sent to the client.
  
• 
  Make sure that the Internet Information Services (IIS) Web root is installed on a non-system NTFS partition for file system-level security. A non-system partition is other than the partition that contains the operating system files. (For example, C:\Inetpub is on a typical system partition, whereas D:\Inetpub is not.)
  
• 
  Make sure that the latest operating system and IIS service packs and updates are applied. For the latest details see the Microsoft Security Central (http://go.microsoft.com/fwlink/?linkid=92540) Web site.
  
• 
  Microsoft Dynamics CRM Server Setup creates an application pool called CRMAppPool that operates under user credentials that you specify during Setup. To facilitate a least privilege model, we recommend that you specify a domain user account instead of using the Network Service account. Additionally, we recommend that no other ASP.NET-connected application be installed under this same application pool.
  

• 
  All Web sites that are running on the same computer as the Microsoft Dynamics CRM Web site can also have access to the Microsoft Dynamics CRM database.
  
• 
  If you use a domain user account, before you run Microsoft Dynamics CRM Server Setup you must verify that the SPN is set correctly for that account, and if necessary, set the correct SPN. For more information about SPNs and how to set them, see KB article 929650: How to use SPNs when you configure Web applications that are hosted on IIS 6.0 (http://go.microsoft.com/fwlink/?linkid=99582).
  

Microsoft Dynamics CRM administration best practices

• 
  Typically, there is no need for Microsoft Dynamics CRM users to have administrative privileges over the domain. Therefore, all Microsoft Dynamics CRM user accounts should be restricted to Domain Users membership. Also, following the principle of least-privilege, anyone who uses the Microsoft Dynamics CRM system should have minimal rights. This starts at the domain level. A domain user account should be created and used to run Microsoft Dynamics CRM. Domain Administrator accounts should never be used to run Microsoft Dynamics CRM.
  
• 
  Limit the number of Microsoft Dynamics CRM Administrator and Operator roles to a few people who are responsible for rule changes. Other Microsoft Dynamics CRM users who are Exchange Server or Active Directory administrators do not have to be members of the Microsoft Dynamics CRM users group.
  
• 
  It is a common practice to reuse passwords across systems and domains. For example, an administrator responsible for two domains may create Domain Administrator accounts in each domain that use the same password, and even set local administrator passwords on domain computers that are the same across the domain. In such a case, a compromise of a single account or computer could lead to a compromise of the whole domain. Passwords should never be reused in this manner.
  
• 
  It is also common practice to use Domain Administrator accounts as service accounts for common services such as back-up systems. However, it is a security risk to use Domain Administrator accounts as service accounts. The password can easily be retrieved by anybody with administrative rights over the computer. In such a case, the compromise could affect the whole domain. Service accounts should never be domain administrator accounts, and they should be limited in privilege as much as possible.