Edit

Share via

Security best practices for Dynamics 365 Customer Engagement (on-premises)

  • Article

Internet Information Services (IIS) is a mature web service that is included with Windows Server. Dynamics 365 Customer Engagement (on-premises) 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.

  • Dynamics 365 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 365 Setup and services.

Important

  • Make sure all websites that are running on the same computer as the Dynamics 365 Customer Engagement (on-premises) website also have access to the Customer Engagement database.
  • If you use a domain user account, before you run Microsoft Dynamics 365 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 365

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 that it’s trying to connect to.

The Dynamics 365 Server 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 365 Setup and services.

When you deploy a hosted Dynamics 365 Customer Engagement (on-premises) 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 Customer Engagement database. If you want to adhere to a least-privileged model, the safest approach for implementing SPNs in a hosted Dynamics 365 Customer Engagement (on-premises) 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 Dynamics 365 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 domain user 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.

See Also

Security considerations for Microsoft Dynamics 365
Microsoft Dynamics 365 administration best practices