Security best practices for Microsoft Dynamics CRM

  • [アーティクル]

 

Applies To: Dynamics CRM 2013

Internet Information Services (IIS) is a mature web service that is included with Windows Server. Microsoft Dynamics CRM depends on an efficient and secure IIS web service. Consider the following:

  • 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 latest operating system and IIS service packs and updates are applied. For the latest information, see the Microsoft Security website.

  • Microsoft Dynamics CRM Server Setup creates application pools called CRMAppPool and CRMDeploymentServiceAppPool that operate under user credentials that you specify during Setup. To facilitate a least-privileged model, we recommend that you specify separate domain user accounts for these application pools instead of using the Network Service account. Additionally, we recommend that no other ASP.NET-connected application be installed under these application pools. For information about the minimum permissions required for these components, see “Minimum permissions required for Microsoft Dynamics CRM Setup, services, and components” in Security considerations for Microsoft Dynamics CRM 2013 in this guide.

Important

  • All websites that are running on the same computer as the Microsoft Dynamics CRM website can also have access to the CRM database.

  • If you use a domain user account, before you run Microsoft Dynamics CRM Server Setup, you may need to verify that the service principal name (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 How to use SPNs when you configure Web applications that are hosted on IIS.

Service principal name management in Microsoft Dynamics CRM 2013

The service principal name (SPN) attribute is a multivalued, nonlinked attribute that is built from the DNS host name. The SPN is used during mutual authentication between the client and the server hosting a particular service. The client finds a computer account based on the SPN of the service to which it is trying to connect.

The Microsoft Dynamics CRM Server 2013 installer deploys role-specific services and web application pools that operate under user credentials specified during Setup. To review the complete list of these roles and their permission requirements, see Minimum permissions required for Microsoft Dynamics CRM Setup and services.

When you deploy a hosted Microsoft Dynamics CRM infrastructure, two of these roles may require additional consideration:

  • Deployment Web Service

  • Application Service

In web farm scenarios, as is the case for a hosted offering, the recommendation is to leave kernel-mode authentication enabled. In addition, you should closely consider using separate domain user accounts to run these services because:

  • Having separate service accounts for these server roles facilitates being able to implement hardware load balancing.

  • The Deployment Web Service server role requires elevated permissions to provision organizations in the CRM database. If you want to adhere to a least-privileged model, the safest approach for implementing SPNs in a hosted Microsoft Dynamics CRM infrastructure involves having the Deployment Web Service run under a different domain user account than the Application Service.

If you follow this suggestion to use separate domain accounts for these server roles, you should check to make sure that the SPN is correct for each account before you start Microsoft Dynamics CRM Server Setup. This will make it easier for you to set the correct SPN when necessary.

If kernel-mode authentication is enabled, the SPNs will be defined for the machine account, regardless of the specified service account. When you implement a web farm, enable kernel-mode authentication and change the local ApplicationHost.config file.

If application and deployment web services are running on the same system, and kernel-mode authentication is disabled, you could configure both services to run under the same domaikuser account to prevent duplicate SPN issues. If you can’t enable kernel-mode authentication, install the Application and Deployment web services on separate systems. The SPNs may still need to be created manually since kernel-mode authentication is disabled.

For more information about SPNs and how to set them, see Service Principal Name (SPN) checklist for Kerberos authentication with IIS 7.0/7.5

See Also

Security considerations for Microsoft Dynamics CRM 2013
Administration best practices for on-premises deployments of Microsoft Dynamics CRM

© 2016 Microsoft Corporation. All rights reserved. Copyright