Share via

Operating system and platform technology security considerations for Microsoft Dynamics CRM 2013

  • Article

 

Applies To: Dynamics CRM 2013

In the broadest sense, security involves planning and considering tradeoffs between threats and access. For example, a computer can be locked in a vault and available only to one system administrator. This computer may be secure, but it is not very usable because it is not connected to any other computer. If your business users need access to the Internet and your corporate intranet, you must consider how to make the network both secure and usable.

The following sections contain links to information about how you can make your computing environment more secure. Ultimately, Microsoft Dynamics CRM data security largely depends on the security of the operating system and the required and optional software components.

In This Topic

Securing Windows Server

Securing SQL Server

Securing Exchange Server and Outlook

Securing mobile devices

Securing Windows Server

Windows Server, the foundation of Microsoft Dynamics CRM, provides sophisticated network security. The Kerberos version-5 authentication protocol that is integrated into Active Directory and Active Directory Federation Services (AD FS) allows you to federate Active Directory domains by using claims-based authentication. Both give you powerful standards-based authentication. These authentication standards let users input a single user name and password logon combination for resource access across the network. Windows Server also includes several features that help make the network more secure.

The following links take you to information about these features. You can learn how to help make your deployment of Windows Server more secure:

Windows error reporting

Microsoft Dynamics CRM requires the Windows Error Reporting (WER) service, which Setup will install if it is missing. The WER service collects information, such as IP addresses. These are not used to identify users. The WER service does not intentionally collect names, addresses, e-mail addresses, computer names, or any other form of personally identifying information. It is possible that such information may be captured in memory or in the data collected from open files, but Microsoft does not use it to identify users. In addition, some information that is transmitted between the Microsoft Dynamics CRM application and Microsoft may not be secure. For more information about the type of information that is transmitted, see Privacy statement for the Microsoft Error Reporting Service.

Important

By default, automatic error reporting is not enabled in Microsoft Dynamics CRM. For more information about how to enable automatic error reporting for Microsoft Dynamics CRM, see Enable Windows Error Reporting.

Virus, malware, and identity protection

To help protect your identity and your system against malware or viruses, see the following resources:

  • Microsoft Security. This page is an entry point for tips, training, and guidance about how to keep your computer up-to-date and prevent your computer from being susceptible to exploitation, spyware, and viruses.

  • Security TechCenter. This page has links to technical bulletins, advisories, updates, tools, and guidance designed to make computers and applications up-to-date and more secure.

Update management

Microsoft Dynamics CRM updates include security, performance, and functional improvements. Making sure that your Microsoft Dynamics CRM applications have the latest updates helps make sure that your system is running as efficiently and reliably as it can.

For information about how to manage updates, see the following:

Securing SQL Server

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 can be configured with less permission to run the SQL Server services. The Domain User 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 Management Studio 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.

  • Report Server administrators can enable RDL Sandboxing to restrict access to the Report Server. More information: 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. More information: Securing SQL Server

Securing Exchange Server and Outlook

The following considerations are for Microsoft Exchange Server, and some are specific to Exchange Server in a Microsoft Dynamics CRM environment:

  • Exchange Server contains a rich series of mechanisms for precise administrative control of its infrastructure. In particular, you can use administrative groups to collect Exchange Server objects, such as servers, connectors, or policies, and then modify the ACLs on those administrative groups to make sure that only certain users can access them. You may, for example, want to give Microsoft Dynamics CRM administrators some control over servers that directly affect their applications. When you implement efficient use of administrative groups, you can make sure that you give Microsoft Dynamics CRM administrators only the rights that they require to perform their jobs.

  • Frequently, you may find it convenient to create a separate organizational unit (OU) for Microsoft Dynamics CRM users, and give Microsoft Dynamics CRM administrators limited administrative rights over that OU. They can make the change for any user in that OU, but not for any user outside it.

  • You should make sure that you adequately protect against unauthorized e-mail relay. E-mail relay is a feature that lets an SMTP client use an SMTP server to forward e-mail messages to a remote domain. By default, Microsoft Exchange Server 2003, Microsoft Exchange Server 2007, and Microsoft Exchange Server 2010 are configured to prevent e-mail relay. The settings that you configure will depend on your message flow and configuration of your Internet service provider's (ISP) e-mail server. However, the best way to approach this problem is to lock down your e-mail relay settings and then gradually open them to allow e-mail to flow successfully. For more information, see the Exchange Server Help.

  • If you use forward mailbox monitoring, the Email Router requires an Exchange Server or POP3-compliant mailbox. We recommend that the permission on this mailbox be set to prevent other users from adding server-side rules. For more information about Exchange Server mailboxes, see Mailbox Permissions.

  • The Microsoft Dynamics CRM Email Router service operates under the Local System Account. This enables the Email Router to access a specified user's mailbox and process e-mail in that mailbox.

For more information about how to make Exchange Server more secure, see the following:

Securing mobile devices

As organizations move to support an increasingly mobile workforce, strong security remains essential. The following resources provide information and best practices for mobile devices, such as smartphones and tablets:

See Also

Planning Deployment of Microsoft Dynamics CRM 2013
Planning email integration
Security considerations for Microsoft Dynamics CRM 2013

© 2016 Microsoft Corporation. All rights reserved. Copyright