Operating system and software component security considerations for Microsoft Dynamics CRM 2011
In the broadest sense, security involves planning and considering tradeoffs. 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 software components that it uses.
In This Topic
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 2.0 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 it 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.
|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 in the Operating and Maintaining Guide.|
To help protect your system against viruses, see the following:
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.
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 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 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.
The Microsoft 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 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.
|Report Server administrators can enable RDL sandboxing to restrict access to the Report Server. For more information, see Enabling and Disabling RDL Sandboxing.|
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 access control lists (ACL) 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 E-mail Router requires an Exchange Server or POP3-compliant mailbox. We recommend that the ACLs on this mailbox be set to prevent other users from adding server-side rules.
The Microsoft Dynamics CRM E-mail Router service operates under the Local System Account. This enables the E-mail 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:
Microsoft Exchange Server 2003 Security Hardening Guide.
Microsoft Exchange Server 2007, see Security and Protection.
Microsoft Exchange Server 2010, see the Deployment Security Checklist.
Send comments about this article to Microsoft.
© 2012 Microsoft Corporation. All rights reserved.