Known risks and vulnerabilities

Applies To: Dynamics 365 (on-premises), Dynamics CRM 2016

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

In This Topic

Risks when users connect to Dynamics 365 over an unsecured network

Security recommendations on server role deployments

Anonymous authentication

Isolate the HelpServer role for Internet-facing deployments

Claims-based authentication issues and limitations

Secure the web.config file

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

Secure server-to-server communication

DNS rebinding attacks

JavaScript allowed for Power BI URLs on personal dashboards

Risks when users connect to Dynamics 365 over an unsecured network

Here are some issues that can occur when you run Microsoft Dynamics 365 without using Transport Layer Security (TLS) or Secure Sockets Layer (SSL) (HTTPS):

• Microsoft Dynamics 365 user-provided data, including 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 365 to only use TLS/SSL. For more information about how to configure Microsoft Dynamics 365 Server to use TLS/SSL, see Make Dynamics 365 client-to-server network communications more secure.

Security recommendations on server role deployments

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

Anonymous authentication

Microsoft Dynamics 365Internet-facing deployment (IFD) requires anonymous authentication enabled on IIS for claims-based authentication. The claims-based authentication token doesn’t contain raw credentials or the connection string to Microsoft Dynamics 365 Server. 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 365 website, use TLS/SSL.

Isolate the HelpServer role for Internet-facing deployments

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

To isolate the Microsoft Dynamics 365 Help pages, and help protect the other Microsoft Dynamics 365 Server roles from potential DoS attacks, consider installing the Help Server role on a separate computer.

For more information about the options for installing Microsoft Dynamics 365 roles on separate computers, see Microsoft Dynamics 365 server roles.

For more information about reducing the risk of DoS attacks, see MSDN: 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 365.

Verify that the identity provider uses a strong password policy

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

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

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

Use any of these options to work around this issue:

• Disable the user in Microsoft Dynamics 365 and in Active Directory. For information about how to disable a user in Microsoft Dynamics 365, see Manage users. For information about how to disable a user in Active Directory, see the Active Directory Users and Computers Help.

• Reduce the web SSO lifetime. To do this, see the Active Directory Federation Services (AD FS) Management Help.

Secure the web.config file

The web.config file that is created by Microsoft Dynamics 365 does not contain connection strings or encryption keys. However, the 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 365 is running. To help secure the web.config file, we recommend you do these things:

• Give permissions to the folder where the web.config file is located to 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 Dynamics 365 servers, such as console logon permission.

• Disable directory browsing on the Dynamics 365 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 365Sandbox Processing Service that access services on the Internet are enabled. For high-security deployments of Microsoft Dynamics 365, this can pose a security risk. If you don’t want to allow outbound calls from custom code, such as Dynamics 365 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. More information: MSDN: Plug-in isolation, trusts, and statistics

Disabling outbound connections for custom code includes disabling calls to cloud services such as Microsoft Azure and Microsoft 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 365Sandbox Processing Service server role is installed, start Registry Editor and locate the following subkey:
   HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSCRM

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 365 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 365 server-to-server communication, such as communication between the Web Application Server role and the server that is running Microsoft SQL Server, isn’t executed over a secure channel. Therefore, information that is transmitted between servers may be susceptible to certain attacks, like man-in-the-middle attacks.

We recommend you implement secure networking, such as Windows Firewall, to help protect information that is transmitted between servers in your organization. More information: Windows Firewall with Advanced Security Overview

DNS rebinding attacks

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

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

JavaScript allowed for Power BI URLs on personal dashboards

Because JavaScript can be used so that personal dashboards can use Power BIURLs, be aware of the following risks of script injection attacks from malicious sources:

• Arbitrary redirection to an unexpected website, such as a phishing website.

• The creation of multiple large JavaScript objects in an attempt to crash the web browser.

To reduce the risk, consider implementing the following best practices:

• Only allow approved SharePoint sites to host Microsoft Office Excel documents used for embedding Power BI reports in dashboards. More information: Introduction to Power BI for Office 365 Admin Center

• Secure the SharePoint site that hosts the Power BI components so that only trusted sources can add documents that will be added to dashboards. Read about SharePoint permission levels

• Ask Microsoft Dynamics 365 users to avoid adding unapproved components to their dashboards. This is similar to educating users to not open attachments or click hyperlinks found in email messages from unknown sources.

See Also

Security considerations for Microsoft Dynamics 365
Network ports for Microsoft Dynamics 365
Microsoft Dynamics 365 supported configurations

© 2016 Microsoft. All rights reserved. Copyright