Securing SQL Server

  • Article

Because Microsoft Dynamics CRM relies on SQL Server, make sure that you take the following measures to improve the security of your SQL Server database:

  • Make sure that the latest operating system and SQL Server service packs (SP) and updates are applied. Check the Microsoft Security Web site for the latest details.
  • Make sure that all SQL Server data and system files are installed on NTFS partitions for file system-level security. You should make the files available only to administrative or system-level users through NTFS permissions. This helps to safeguard against users who access those files when the MSSQLSERVER service is not running.
  • Use a low-privilege domain account. Or, you can specify the Network Service or the Local System account for SQL Server services. However, we do not recommend that you use these accounts because Domain User accounts are more appropriate for the SQL Server services. This account should have minimal rights in the domain and should help contain (but will not stop) an attack on the server if there is a compromise. In other words, this account should have only local user-level permissions in the domain. If SQL Server is installed by using a Domain Administrator account to run the services, a compromise of SQL Server will lead to a compromise of the entire domain. If you have to change this setting, use SQL Server Enterprise Manager to make the change, because the access control lists (ACLs) on files, the registry, and user rights will be changed automatically.
  • SQL Server authenticates users who have either Windows authentication or SQL Server credentials. We recommend that you use Windows authentication for single sign-on ease of use and to provide the most secure authentication method.
  • By default, the auditing of the SQL Server system is disabled so that no conditions are audited. This makes intrusion detection difficult and aids attackers with covering their tracks. At a minimum, you should enable auditing of failed logins.
  • The SQL Server Reporting Services RDL Sandboxing feature does not apply to on-premises installations. If you want to implement RDL Sandboxing in an on-premises installation, you must manually enable this feature. For more information, see MSDN: Enabling and Disabling RDL Sandboxing.
  • Each SQL login is configured to use the master database as the default database. Although users should not have rights to the master database, as a best practice, you should change the default for every SQL login (except those with the SYSADMIN role) to use OrganizationName_MSCRM as the default database.

For more information, see Securing SQL Server.

Note

Report Server administrators can enable RDL sandboxing to restrict access to the Report Server. For more information, see Enabling and Disabling RDL Sandboxing.