Known risks and vulnerabilities

This topic describes the risks and vulnerabilities that may exist when you use Microsoft Dynamics CRM. Mitigations and workarounds are also described when applicable.

In This Topic

Risks when users connect to Microsoft Dynamics CRM over an unsecured network

Issues that can occur when you run Microsoft Dynamics CRM without using Secure Sockets Layer (SSL) (HTTPS) are as follows:

  • Visual chart definitions can be altered over an unsecured HTTP connection by using "man in the middle" type attacks. To mitigate this vulnerability, configure Microsoft Dynamics CRM to only use SSL. For more information about how to configure Microsoft Dynamics CRM Server 2011 to use SSL, see “Make Microsoft Dynamics CRM client-to-server network communications more secure” in Microsoft Dynamics CRM 2011 Post-Installation and Configuration Guidelines in the Installing Guide.

Security recommendations on server role deployments

The following recommendations can help make your Microsoft Dynamics CRM deployment more reliable and secure.


Server role Recommendation

Sandbox Processing Service

Install this role to a dedicated server on a separate virtual LAN (VLAN) from other computers that are running Microsoft Dynamics CRM roles. Then, if there is a malicious plug-in running in the sandbox that exploits the computer, the network isolation from a separate VLAN can help protect other Microsoft Dynamics CRM resources from being compromised.

Help Server

Install this role on a separate computer if you implement an Internet-facing deployment (IFD). For more information, see Isolate the HelpServer role for Internet-facing deployments below.

Anonymous authentication

Microsoft Dynamics CRM Internet-facing deployment (IFD), Microsoft Dynamics CRM for Outlook, and E-mail Router require anonymous authentication. Anonymous authentication on the Microsoft Dynamics CRM website and webpages enables users to access the site without the need to re-enter their credentials with each page request. Authentication data sent to endpoints do not contain connection strings or encryption keys. However, the web.config file does contain configuration information about the authentication mode. For more information, see “Secure the web.config file” later in this topic. To secure the Microsoft Dynamics CRM website, use SSL.

Isolate the HelpServer role for Internet-facing deployments

Microsoft Dynamics CRM Internet-facing deployment (IFD) require anonymous authentication. Because anonymous Web site authentication is used, the virtual directory used by the Microsoft Dynamics CRM Help site can be targeted for denial of service (DoS) attacks.

To isolate the Microsoft Dynamics CRM Help pages, and help protect the other Microsoft Dynamics CRM 2011 roles from potential DoS attacks, consider installing the Help Server role on a separate computer if you implement an IFD.

For more information about the options for installing Microsoft Dynamics CRM roles on separate computers, see the Microsoft Dynamics CRM 2011 Installing Guide.

For more information about reducing the risk of DoS attacks, see Improving Web Application Security: Threats and Counter-measures.

Claims-based authentication issues and limitations

This topic describes issues and limitations when you use claims-based authentication with Microsoft Dynamics CRM.

Verify that the identity provider uses a strong password policy

When you use claims-based authentication, we recommend that you verify that the identity provider that is trusted by the security token service (STS) and, in turn, Microsoft Dynamics CRM, enforces strong password policies. Microsoft Dynamics CRM itself does not enforce strong passwords. By default, when it is used as an identity provider, Active Directory enforces a strong password policy.

AD FS 2.0 federation server sessions are valid up to 8 hours even for deactivated or deleted users

By default, Active Directory Federation Services 2.0 server tokens allocate a Web single sign-on (SSO) cookie expiration of eight (8) hours. Therefore, even when a user is deactivated or deleted from an authentication provider, such as AD FS 2.0, as long as the user session is still active the user can continue to be authenticated to secure resources.

To work around this issue, you can reduce the Web SSO lifetime. To do this, see the AD FS 2.0 Management Help.

Secure the web.config file

The web.config file that is created by Microsoft Dynamics CRM does not contain connection strings or encryption keys. However, the web.config file does contain configuration information about the authentication mode and strategy, ASP.NET view state information, and debug error message display. If this file is modified with malicious intent it can threaten the server where Microsoft Dynamics CRM is running. To help secure the web.config file, we recommend the following:

  • Grant permissions to the folder where the web.config file is located to include only those user accounts that require it, such as administrators. By default, the web.config file is located in the <drive:>Program Files\Microsoft Dynamics CRM\CRMWeb folder.

  • Limit the number of users who have interactive access to Microsoft Dynamics CRM servers, such as console logon permission.

  • Disable directory browsing on the Microsoft Dynamics CRM website. By default, this is disabled. For more information about how to disable directory browsing, see Internet Information Services (IIS) Manager Help.

Outbound Internet calls from custom code executed by the Sandbox Processing Service are enabled

By default, outbound calls from custom code executed by the Microsoft Dynamics CRM Sandbox Processing Service that access services on the Internet are enabled. For high-security deployments of Microsoft Dynamics CRM, this could pose a security risk. If you do not want to allow outbound calls from custom code, such as Microsoft Dynamics CRM plug-ins or custom workflow activities, you can disable outbound connections from custom code executed by the Sandbox Processing Service by following the procedure here.

Instead of blocking all outbound calls, you can enforce web access restrictions on sandboxed plug-ins. For more information, see Plug-in Isolation, Trusts, and Statistics.

Notice that disabling outbound connections for custom code includes disabling calls to cloud platforms such as Windows Azure and Windows Azure SQL Database.

Disable outbound connections for custom code on the computer that is running the sandbox processing service

  1. On the Windows Server computer where the Microsoft Dynamics CRM Sandbox Processing Service server role is installed, start Registry Editor and locate the following subkey:

  2. Right-click MSCRM, point to New, click DWORD Value, type SandboxWorkerDisableOutboundCalls, and then press ENTER.

  3. Right-click SandboxWorkerDisableOutboundCalls, click Modify, type 1, and then press ENTER.

  4. Close Registry Editor.

  5. Restart the Sandbox Processing Service. To do this, click Start, type services.msc, and then press ENTER.

  6. Right-click Microsoft Dynamics CRM Sandbox Processing Service, and then click Restart.

  7. Close the Microsoft Management Console (MMC) Services snap-in.

Secure server-to-server communication

By default, Microsoft Dynamics CRM server-to-server communication, such as communication between the Web Application Server role and the server that is running Microsoft SQL Server, is not executed over a security channel. Therefore, information that is transmitted between servers may be susceptible to certain attacks, such as man-in-the-middle attacks.

We recommend that you implement Internet Protocol security (IPsec) to help protect information that is transmitted between servers in your organization. IPsec is a framework of open standards for protecting communications over Internet Protocol (IP) networks through the use of cryptographic security services. For more information, see IPsec.

DNS rebinding attacks

Like many web-based applications, Microsoft Dynamics CRM may be vulnerable to DNS rebinding attacks. This exploit involves misleading a web browser into retrieving pages from two different servers thereby trusting that the servers are from the same domain and subsequently breaking the Same Origin Policy. Using this technique, an attacker can tamper with Microsoft Dynamics CRM data by using the victim’s identity through cross-site scripting attacks on Microsoft Dynamics CRM pages.

For more information about how to help protect against such attacks, see Protecting Browsers from DNS Rebinding Attacks.

See Also

Send comments about this article to Microsoft.

© 2013 Microsoft Corporation. All rights reserved.