Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
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.
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.
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.
Hi Dan, Is there any update on Web Services and TLS 1.0? Most of our customers are using GP's workflow for AP Transaction Approval and one of the key features that makes this a good solution is the ability for workflow approvers to approve or reject AP invoices from the e-mail they receive, and as you know, web services is necessary for this to work. Lately we are getting more and more push from our customer's IT folks to disable TLS 1.0. Does Microsoft have a plan for dealing with this?
Just a quick note on my earlier comments. I was still getting the error "This login failed. Attempt to log in again or contact your system administrator." even having the latest version of the SQL Native Client. We had to have a MS Support person help. The solution was to login using sa on the client machine having this error, make sure the GP client fully loads, change the password of the user, logout with sa, and have the user login with their changed password.
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.
Business Applications communities