Hello GP community! The purpose of this blog post is to offer some clarity and information regarding the upcoming PCI compliancy changes that prohibit the use of TLS 1.0 in PCI Compliant environments. We’ve been planning on supporting environments that have TLS 1.0 disabled, and recently our team performed a first round of tests to see what would work and what would not work.
First off, a little information on what TLS 1.0 is, and why it’s being deprecated. TLS 1.0 is an industry standard security protocol originally developed in 1994. Back in 2016, the PCI council stated that moving forward, TLS 1.0 would not be a supported protocol if PCI compliancy were to be maintained. This original deadline has been extended through June 30th 2018, due to legacy browser support and a few other variables. After 30 June 2018, if the entity still has SSL or early TLS in their environment, they will need to document that it has been verified the systems are not susceptible to the vulnerability and complete the Addressing Vulnerabilities with Compensating Controls process for their environment. TLS 1.0 is being deprecated because there are several known and documented vulnerabilities with the protocol.
It is very important to note that just because TLS 1.0 has known vulnerabilities, this does not mean that your system is ‘vulnerable’. Staying up to date on updates is the best way past these vulnerabilities, the following link states that even if you’re using TLS 1.0, your computer is safe from the TLS 1.0 vulnerabilities if all the following conditions are true:
- The version of Windows that you are using is still in support for security updates as defined by the Microsoft Support Lifecycle.
- Windows is fully patched, and all available security updates are installed.
- The Windows default configuration of channel for TLS 1.0 is used.
Back in October, the SQL team published a document regarding TLS 1.2 supportability for connecting to SQL server. This article has links for SQL updates that are required for the various SQL Server versions to be able to connect via TLS 1.2, which is the protocol that would be used if TLS 1.0/1.1 were disabled.
https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server
The Microsoft SQL Server 2012 Native Client QFE patch is the main one that GP would require to be able to connect to SQL 2012 or SQL 2014 should TLS 1.0 be disabled.
Microsoft SQL Server 2012 Native Client - QFE
As I stated early on, my team performed some testing in environments with TLS 1.0 disabled in order to start getting ahead of the curve for potential issues that may occur should TLS 1.0 be disabled. Once the updated components for SQL were installed to allow TLS 1.2 connections, overall GP functionality was not affected by this.
The only ongoing issue that we are working through is that the install of Web Services will fail with the following error should you try to install in an environment with TLS 1.0 disabled:
"Access to the Authorization Manager store was denied."
This issue is being worked on by our Development team, and we are working at getting this resolved in a timely manner. The supported configuration for Web Services is to leave TLS 1.0 enabled until we can determine the cause and publish a resolution as Web Services will not function correctly if you should disable TLS 1.0 on the server post-install either.
The other ongoing issue is that the data sources on our Excel Reports are using a driver version that may not be supported for use with Excel. We are working with the Office team in order to see if there is a TLS 1.2 compatible method of connecting an Excel report.
Edit 8/6/2018: After further investigation, we've learned from the Office team that the default provider that our Excel Reports uses, SQLOLEDB, will not be receiving TLS 1.2 compatibility. In order to use the default Excel Reports for GP, you have to modify the connection string of each report to use a different provider other than SQLOLEDB  that IS TLS 1.2 compatible, such as the most recent version of Native Client 11. All supported SQL drivers are listed here;
https://support.microsoft.com/en-us/kb/3135244
If you change the connection string to something basic such as this, the reports will work.
Provider=SQLNCLI11;Server=yourServer;Database=yourCompany;Uid=username;Pwd=password;
Other than these issues, everything else in GP that we tested worked correctly with TLS 1.0 disabled. Some of what we tested was eConnect, ODATA, Integration Manager, Document Attach, Workflow, Identity Management, MAPI/Exchange emailing, Drillbacks, and SSRS/Excel Reports.
Edit 10/8/2018: If your email server type in GP is set to Exchange, and you have TLS 1.0 disabled, then your Exchange server must be running Windows Server 2016 and Exchange 2016 CU10 in order for GP to make the connection. No other deployment scenarios have been tested, so this will be the only supported model for using Exchange as your email server type.
Edit 8/25/2020: With ongoing research and testing, we have found that Web Client (single and multi-server) also requires TLS 1.0 to be enabled on the servers where the application is installed onto, i.e. IIS/web servers and session host servers. Along those lines, Service Based Architecture (SBA) which uses a lot of the same functionality as Web Client, also requires TLS 1.0 be enabled on the server where the SBA services are installed/running on.
Edit 9/23/2020: For more recent news on emailing see here: 
https://community.dynamics.com/gp/b/dynamicsgp/posts/dynamics-gp-email-troubleshooting-guide-1743830067
The work on this issue is ongoing, and I will post any updates as they appear, but I wanted to provide this information early so that you know what to expect if you have PCI compliancy concerns or simply want to disable unsecure protocols in your GP environment.
 
		
 Like
Like Report
Report
*This post is locked for comments