Düzenle

Aracılığıyla paylaş

Security considerations for Dynamics 365 Customer Engagement (on-premises)

  • Makale

Dynamics 365 Customer Engagement (on-premises) is designed in a way that helps make your deployment more secure. This section provides information and best practices for the Dynamics 365 Customer Engagement (on-premises) application. More information:Overview of security for Microsoft Dynamics 365

What kind of service account should I choose?

When you specify an identity to run a Dynamics 365 Customer Engagement (on-premises) service, you can choose either a domain user account or the Network Service account.

If the service interacts with network services, accesses domain resources like file shares or if it uses linked server connections to other computers, you can use a minimally-privileged domain account. Many server-to-server activities can be performed only with a domain user account and can provide the most secure option. This account should be pre-created by domain administrator in your environment.

Note

When you configure a service to use a domain account, you can isolate the privileges for the application, but must manually manage passwords or create a custom solution for managing these passwords. Many server applications use this strategy to enhance security, but this strategy requires additional administration and complexity. In these deployments, service administrators spend a considerable amount of time on maintenance tasks such as managing service passwords and service principal names (SPNs), which are required for Kerberos authentication. In addition, these maintenance tasks can disrupt service.

The Network Service account is a built-in account that has more access to resources and objects than members of the Domain Users group. Services that run as the Network Service account access network resources by using the credentials of the computer account in the format <domain_name>\<computer_name>$. The actual name of the account is NT AUTHORITY\NETWORK SERVICE.

Minimum permissions required for Microsoft Dynamics 365 Setup and services

Dynamics 365 Customer Engagement (on-premises) is designed so that its features can run under separate identities. By specifying a domain user account that is granted only the permissions necessary to enable a particular feature to function, you help secure the system and reduce the likelihood of exploitation.

This topic describes the minimum permissions that are required by the user account for Dynamics 365 Customer Engagement (on-premises) services and features.

Microsoft Dynamics CRM Server Setup

The user account used to run Dynamics 365 Server Setup that includes the creation of databases requires the following minimum permissions:

  • Be a member of the Active Directory Domain Users group. By default, Active Directory Users and Computers adds new users to the Domain Users group.

  • Be a member of the Administrators group on the local computer where Setup is running.

  • Have Local Program Files folder read and write permission.

  • Be a member of the Administrators group on the local computer where the instance of SQL Server is located that will be used to store the Dynamics 365 Customer Engagement (on-premises) databases.

  • Have sysadmin membership on the instance of SQL Server that will be used to store the Dynamics 365 Customer Engagement (on-premises) databases.

  • Have organizational unit and security group creation and add membership permission to those groups in Active Directory. Alternatively, you can use a Setup XML configuration file to install Dynamics 365 Server when security groups have already been created. For more information, see Use the Command Prompt to Install Microsoft Dynamics 365.

  • If SQL Server Reporting Services is installed on a different server, you must add the Content Manager role at the root level for the installing user account. You must also add the System Administrator Role at the site-wide level for the installing user account.

Microsoft Dynamics 365 services and IIS application pool identity permissions

This section lists the minimum permissions that domain user accounts require for the services and the IIS application pools that Dynamics 365 Customer Engagement (on-premises) uses.

Important

  • Dynamics 365 Customer Engagement (on-premises) services and application pool (CRMAppPool) identity accounts must not be configured as a Dynamics 365 Customer Engagement (on-premises) user. Doing so can cause authentication issues and unexpected behavior in the application for all Dynamics 365 Customer Engagement (on-premises) users. More information:Problems in CRM when the CRMAppPool user account is a CRM user
  • Managed service accounts (group-managed service accounts (gMSA) or single-managed service accounts) and virtual accounts (NT SERVICE\,<SERVICENAME>) aren't supported for running Dynamics 365 Customer Engagement (on-premises) services.

The following subsections describe the domain user account permissions required for each service or application pool identity:

Microsoft Dynamics 365 Sandbox Processing Service

Microsoft Dynamics 365 Asynchronous Processing Service and Microsoft Dynamics 365 Asynchronous Processing Service (maintenance) services

Microsoft Dynamics 365 Monitoring Service

Microsoft Dynamics 365 VSS Writer service

Deployment Web Service (CRMDeploymentServiceAppPool Application Pool identity)

Application Service (CRMAppPool IIS Application Pool identity)

Microsoft Dynamics 365 Sandbox Processing Service

  • Domain Users membership.

  • That account must be granted the Logon as service permission in the Local Security Policy.

  • Folder read and write permission on the Trace, by default located under \Program Files\Microsoft Dynamics 365\Trace, and user account %AppData% folders on the local computer.

  • Read permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM subkey in the Windows registry.

  • The service account may need an SPN for the URL used to access the website that is associated with it. To set the SPN for the Sandbox Processing Service account, run the following command at a command prompt on the computer where the service is running.

    SETSPN –a MSCRMSandboxService/<ComputerName> <service account>

Microsoft Dynamics 365 Asynchronous Processing Service and Microsoft Dynamics 365 Asynchronous Processing Service (maintenance) services

  • Domain Users membership.

  • PrivUserGroup and SQLAccessGroup membership. By default, these groups are created and appropriate membership is granted during Microsoft Dynamics 365 Server Setup.

  • Built-in local group Performance Log Users membership.

  • That account must be granted the Logon as service permission in the Local Security Policy.

  • Read and write permission on the following folders.

    • The Trace folder. By default located under \Program Files\Microsoft Dynamics CRM\, and user account %AppData% folder on the local computer.

    • The CustomizationImport folder. By default located under \Program Files\Microsoft Dynamics CRM\. This may be required for solution import when you use the Dynamics 365 Customer Engagement Web Services.

  • All access permissions except Full Control and Write DAC to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSCRMSandboxService subkeys in the Windows registry.

  • The service account may need an SPN for the URL used to access the website that is associated with it. To set the SPN for the Asynchronous Service account, run the following command at a command prompt on the computer where the service is running.

    SETSPN –a MSCRMAsyncService/<ComputerName> <service account>

Microsoft Dynamics 365 Monitoring Service

  • Domain Users membership.

  • That account must be granted the Logon as service permission in the Local Security Policy.

  • If the Microsoft Dynamics 365 Monitoring Service is installed with a Front End Server server role, local administrator group membership on the computer where the service is running is required to monitor the web site and application pools. More information:Available individual server roles

  • Read permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM

  • SQLAccessGroup membership. By default, this group is created and appropriate membership is granted during Microsoft Dynamics 365 Server Setup.

  • The service account may need an SPN for the URL used to access the website that is associated with it.

Microsoft Dynamics 365 VSS Writer service

  • Domain Users membership.

  • That account must be granted the Logon as service permission in the Local Security Policy.

  • That account must be granted membership of Backup Operators group on the server hosting this service.

  • Read permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM

  • PrivUserGroup and SQLAccessGroup membership. By default, these groups are created and appropriate membership is granted during Microsoft Dynamics 365 Server Setup.

Deployment Web Service (CRMDeploymentServiceAppPool Application Pool identity)

  • Domain Users membership.

  • That account must be granted the Logon as service permission in the Local Security Policy.

  • Local administrator group membership on the computer where SQL Server is running is required to perform organization database operations (such as create new or import organization).

  • Local administrator group membership on the computer where the Deployment Web Service is running.

  • Sysadmin permission on the instance of SQL Server to be used for the configuration and organization databases.

  • Folder read and write permission on the Trace and CRMWeb folders, by default located under \Program Files\Microsoft Dynamics CRM\, and user account %AppData% folder on the local computer.

  • All access permissions except Full Control and Write DAC to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSCRMSandboxService subkeys in the Windows registry.

  • PrivUserGroup and SQLAccessGroup membership. By default, these groups are created and appropriate membership is granted during Microsoft Dynamics 365 Server Setup.

  • CRM_WPG group membership. This group is used for IIS worker processes. The group is created and the membership is added during Microsoft Dynamics 365 Server Setup.

  • The service account may need an SPN for the URL used to access the website that is associated with it.

Application Service (CRMAppPool IIS Application Pool identity)

  • Domain Users group membership.

  • Built-in local group Performance Log Users membership.

  • Local administrator group membership on the computer where the Application Service is running.

  • Folder read and write permission on the Trace and CRMWeb folders, by default located under \Program Files\Microsoft Dynamics CRM\, and user account %AppData% folder on the local computer.

  • All access permissions except Full Control and Write DAC to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSCRMSandboxService subkeys in the Windows registry.

  • PrivUserGroup and SQLAccessGroup membership. By default, these groups are created and appropriate membership is granted during Microsoft Dynamics 365 Server Setup.

  • CRM_WPG group membership. This group is used for IIS worker processes. The group is created and the membership is added during Microsoft Dynamics 365 Server Setup.

  • The service account may need an SPN for the URL used to access the website that is associated with it.

IIS Application Pool identities running under Kernel-Mode authentication and SPNs

By default, IIS websites are configured to use Kernel-Mode authentication. When you run the Dynamics 365 Customer Engagement (on-premises) website by using Kernel-Mode authentication, you might not need to configure additional service principal names (SPNs) for the CRMAppPool identities.

For more information about viewing, deleting, and registering SPNs using SetSPN.exe, see Service Principal Names (SPNs) SetSPN Syntax.

Microsoft Dynamics 365 installation files

If you plan to install Dynamics 365 from a location on the network, such as a network share, you must make sure that the correct permissions are applied to the folder, preferably on an NTFS volume, where the installation files are located. For example, you may want to allow only members of the Domain Admins group permissions for the folder. This practice can help to reduce the risk of attacks on the installation files that may compromise or alter them. For more information about how to set permissions on files and folders on the Windows operating system, see Windows Help.

See Also

Planning Your Deployment of Microsoft Dynamics 365
Microsoft Dynamics 365 security best practices