Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
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:
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.
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.
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;
If you change the connection string to something basic such as this, the reports will work.
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, SBA, ODATA, Web Client (single and multi server), Integration Manager, Document Attach, Workflow, Identity Management, MAPI/Exchange emailing, Drillbacks, and SSRS/Excel Reports.
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.
We are running an old version of GP (2013) and are encountering errors trying to run the Dynamics client on our computers. I noticed on the Dynamics.exe.config file that there is an entry at the bottom that is:
I don't know if this is the issue or if you know of something else to fix it. Once TLS 1.0 is disabled the clients no longer can login.
They get error messages stating "Your attempt to log in to the server failed because an unknown error occurred when the user ID and password were being verified. Attempt to log in again." or "This login failed. Attempt to log in again or contact your system administrator." I can tell the login attempt isn't able to establish a connection by the progress in the bottom left corner of the login screen. It usually tells you it is attempting to connect. Let me know if you have any insight. Thanks.
Are there any updates to this? We have a client that needs to disable the 1.0 protocol for NODUS, however and they are using the web client and web services for the workflow piece.
To speak to the comment regarding users not being able to log in when TLS 1.0 is disabled, this means the connection driver (Native Client 11) their ODBC connection is using isn't updated. If you navigate to the link in the article above and download the latest QFE patch for Native Client, then recreate your ODBC connection using this new version, the users will be able to log in.
To speak to the other issue regarding NODUS and Web Client, Web Client worked correctly with TLS 1.0 disabled, but Web Services currently does not. Web Services is currently not supported for use in an environment with TLS 1.0 disabled, due to legacy requirements.